Colour review & design system

2025

Colour review & design system

Project type Tactical
Project length Unlimited
Role Designer
Outcome New colour and design system

Brief

Farvegennemgang

We had a vast amount of colours in the design system which needed drastically reducing and aligning with different regions and departments. We needed to get the disorganised organsied in order to reduce confusion and workload for all effected employees. The design system was also complex, needed streamlining and had outgrown it Figma home

Planning

Arbejdsgang

The initial work flwo seemed simple but the project balloooned as it quickly became clear that changing the colour was not a simple task. Many people had strong opinions that upper managment supported and so navigating the stakeholders was a surprisingly large part of the task here.

Informal discussions

I discussed with developers and UX team whether the system worked, what was good and bad and why it was designed like that to get an understanding of how we could do it better

Audit

Carried out an audit of the site to define where the weak points were in WCAG compliance

Interviews

I sat down with internal developers and UXer's to go through a structured interview to discover insights on where we could improve the system

Mapping

Having pulled the pain points from the users I was able to map them to pitch the problem to management and get their buy in on why we needed this change

Evaluation

I evaluated the colours and found we have 55 different blues which was a great pitch for change. I also looked at the design system and found UXer's avoiding token because of complexity and rules being missed because of Figma overload

Pitching

With evidence gathered we needed buy in from management to see the value in new colours, new tokens and a hosting location for the design system.

Desk research

I did a deep analysis of colour rules and graphic break down to give my argumentation solid grounding come presentation time

Colour design

I carried out an intense and ruthless revamp of the colours taking into consideration the stakeholders input and reduced the colours down to 7 blues from over 50

Design and stakeholder loops

From there on there was persistent back and forth with stakeholders negotiating the rules and colours I had designed until the project was canned. A year later the colours were picked up by an external agency who pushed them through.

Delivery

There were strong objections to the direction I took but with negotiations and compromise I managed to get the majority of the decisions through and implemented into the new design system and colour pallete

We spend a large amount of time just rejecting non compliant work

— Mette b - Head of branding

Auditing

WCAG Audit

In order to push part of my point about the colours and design system across to management I carried out an audit on the website to see exactly where we were falling short on WCAG compliance.

The audit showed that we had several infringements in colours that we could easily fix. Buttons had background colours that meant text failed, there were promotion tags with the same issues, gradients meant WCAG compliance was variable, images behind text meant you couldn’t ensure compliance and link text failed everywhere.

Fixing these issue was a token change but just showed that we needed a wider review.

What we couldn’t fix easily was the raft of compliance failures on the dev side with missing ARIA on buttons, images, hover and accessibility issue accross the site.

Fixing those would be a process task moving forwards but again it added weight to the argument that we needed a review and better alignment and rules

Interviews

I did a series of interview with some of the developers and the UX team to establish what the problems were and what was worth keeping. The team worked together and we came up with some interesting insights on how we could improve

Gert Developer
We don't use the token values inside Figma, only the json file data

Insights

  • Token value are only for UXer's, dev don't use them
  • Dev cross reference the colour codes to their own system they use
Lirdon Developer
We rarely use the actual design system because Figma is so slow that we can barely open it

Insights

  • Figma's cannot handle the info have inside it
  • Developers avoid Figma and therefore miss crucial documentation
  • We need a more reliable host for documentation
Lise UX
I have no idea what the meaning of the token is, they make little sense to me

Insights

  • UX struggle to find the right tokens for the right situation
  • There are too many tokens
  • Tokens are too specific
Mette Head of branding
People just have their own freedom to design what they want, I battle to control what meets the CVI

Insights

  • Too much freedom means people break the CVI rules
  • Designs are being created by people outside of marketing and design
  • Rules and limitations need to be in place to limit infractions

Affinity mapping

Having done the initial discussions and interviews to ascertain what the issue were and formally record them in an interview process we were able to synthesise the results and group them so we could better see what we were dealing with and begin to outline a plan of attack.

WCAG Accessibility

  • Colours were not WCAG compliance
  • No rules for using text on colours
  • No rules for using text on images
  • No rules on gradients

Brand governance

  • Rogue colleague not following rules
  • Different regions, different rules
  • Resource drain battle CVI infringements

Colour confusion

  • Too many colours in the design system
  • Solar colours and Prime colours that never got used
  • Confussion around which colours to use and when
  • Breaking CVI rules because the scope was too wide

Token naming and findability

  • Confusion with token naming
  • Can't find the right token so using anything
  • UX designers unsure which tokens to use when

Documentation

  • Avoiding figma because it was too slow
  • Design system had outgrown figma
  • Figma not designed for documentation
  • No place to keep design system rules

AI readiness

  • No set rules for AI to follow
  • Confusion between team members
  • Scattered single source of truth

Communication

  • Disconnect between dev and UX on which tokens to use
  • Misalignment from the design to dev
  • Misalignment between designers on token usage
  • Poor communication between UX and dev

Defined Pain points

Having completed discussion and interviews I was able to pin point a few crucial areas that created friction for the users of the systems and pinpoint what we needed to focus on in order to improve.

Problem 1

WCAG accessibility

At the time there were just a few months until the rules for WCAG compliance came into force and that meant that we could be on the hook for a fine. Whilst we were only B2B we didn’t fall directly under the WCAG rules but they represented a standard we should be meeting and had good reason to be in forced. There was also some grey area to the law which left speculation as to whether we would fall under the B2C rules

Problem 2

Brand governance

The head of branding was spending a large amount of time firefighting rogue employees that disregarded the brand guidelines and did their own graphics and designs. This cost resources and damaged the Solar image.

Problem 3

Colour confusion

With over 50 blues alone and a similar story with orange, yellow, red and green the colours ran into hundreds and no one knew what to use or when to use it. This lead to different blues being used across the site and slight mismatches in designs. Both UX and dev had trouble in identifying which colours to use when.

Problem 4

Token naming & findability

The tokens were named using coding terms which the UXer’s didn’t understand or find logical so they didn’t use them. They were made that way so the developers could use them more easily but they never did.

Problem 5

Documentation

Whilst we had a structure for writing the documentations with does and don’t we didn’t have a usable place to store it. Figma was overloaded and we needed a specific place we could use that could serve devs needs and UXer’s as well

Problem 6

AI readiness

With such chaos and a lack of structure we were not set up for implementing AI. Both myself and my colleague knew that the key to getting AI set up and working efficiently was to ensure solid and comprehensive documentation of components but we did not have that in a structure that could be used

Problem 7

Communication

The designers and developers were not communicating well and part of that was the systems in place not working for either part and being avoided because of that. We needed to get one working system for both teams so we communicated with the same language

Stakeholder loops

Because  the ideas involved so many stakeholders I kept them in the loop and took on board their feedback about what would work and what wouldn’t.

I was quite radical in my suggestions so they were controversial but generally well accepted.

That being said there were obstacles that needed to be overcome through negotiation and compromise.

Design

Mock ups

It was cruitial to do mock up of the current site with my new proposals to see if they works as I envisioned and to communicate to stakeholders and eleviate their concerns. Whilst we as designers can easily visualise how a design concept or rule set will function in real life it is much harder for someone with a different skills set to appreciate where we are coming from

Proposals

Main colours

Having created and negotiated the colours I proposed a limited set of main colours and function colours. The main colours were for braning and the function colours were for functional tasks. There had to be a clear rule set because of the challenges that branding governance had with employee freedom. By restricting the colours available it would reduce the workload on the governance team in catching errors.

For accessibility it was important to create clear definitions of text and background colours so there was enough contrast.

These colours I categorised as “graphical” because they primarily were for graphical decoration of the site

Proposals

Function colours

Additional categories

Every web site need utility colours or as I called them, “function colours” because they had a function and were only used for functions.

They still used the same text, background and accent stratergy

Priority messaging

The function colours were given a usage explanation so that we could determine how to use them.

High priority messages were for messages that would prevent the users from carrying out their task

Medium priority was for message that might prevent them from carrying out their task

Low priority were for task related messages that would have no effect on completing the task

Tokens design

Using the colours as a base I redesigned the naming and structure of the token to have a foundational layer and a semantic on top.

Foundational were all the raw values so for colours red, blue, green etc and numerical worked in REM

Semantic allocated them simple uses like, button, font size, weight, spacing etc.

The key though was that foundations could not be used, they were hidden an semantics were named logically, non coded and locked to certain functions so you couldn’t have certain colours for backgrounds or texts, that was all predefined which reduced choice and made alignment easier

Kontakt os, og lad os arbejde sammen :)

Lige nu tilgængelig for freelancejobs og kreative partnerskaber verden over. Lad os bygge noget exceptionelt sammen.

Lad os tale