Dark mode with a brand new colour system
Dark mode with a brand new colour system
Company
Humi
My role
Senior product designer
Year
2024
Impact
13.5% adoption rate
Context
Dark mode has become a fundamental expectation in modern SaaS applications today. As users spend more time on screens, especially in low-light conditions, dark mode helps reduce eye strain, improving user comfort and focus. For mobile and OLED users, it also offers energy efficiency by consuming less battery. For Humi users, dark mode has been a top-requested feature. This year, I was lucky to have the opportunity to lead the design for the dark mode for the Humi web platform.
Dark mode has become a fundamental expectation in modern SaaS applications today. As users spend more time on screens, especially in low-light conditions, dark mode helps reduce eye strain, improving user comfort and focus. For mobile and OLED users, it also offers energy efficiency by consuming less battery. For Humi users, dark mode has been a top-requested feature. This year, I was lucky to have the opportunity to lead the design for the dark mode for the Humi web platform.
The challenges of designing dark mode
Letโs be honest - the dark mode is not fancy in 2024 anymore. During a discussion, a senior product manager joked about simply โflipping the colours from light to darkโ and showed us how he created a dark mode for the platform using a browser extension.
This perception highlighted our greatest challenge: the truth is that the dark mode isn't about simply inverting colours โ it requires fundamentally rethinking our entire colour system. As the product designer, I needed to help our team understand that the complexity lay in developing a new colour system capable of supporting multiple themes while maintaining consistency and accessibility.
Uncover the problems in the current colour system
At the project's outset, I organized a collaborative workshop with our design and front-end teams to discuss the current issues within the existing colour system and the goals we should aim for at this time. The attached image below is the old colours we had in the design system, and several issues were flagged by the team:
Limited tonal range: There were limited colours in each colour type to use in the design. Sometimes designers/developers need to make small adjustments to achieve the desired visual contrast
Inconsistent lightness of colours: The perceptual lightness of colours in the same level in these colour types looks inconsistent visually (e.g., error-400 looks way darker than the other 400 colours). This caused visual inconsistency on the component level
Lack of standards: There are no clear standards defined about which colours should be used where even though colours are tied with components in the design system
The challenges of designing dark mode
Letโs be honest - the dark mode is not fancy in 2024 anymore. During a discussion, a senior product manager joked about simply โflipping the colours from light to darkโ and showed us how he created a dark mode for the platform using a browser extension.
This perception highlighted our greatest challenge: the truth is that the dark mode isn't about simply inverting colours โ it requires fundamentally rethinking our entire colour system. As the product designer, I needed to help our team understand that the complexity lay in developing a new colour system capable of supporting multiple themes while maintaining consistency and accessibility.
Uncover the problems in the current colour system
At the project's outset, I organized a collaborative workshop with our design and front-end teams to discuss the current issues within the existing colour system and the goals we should aim for at this time. The attached image below is the old colours we had in the design system, and several issues were flagged by the team:
Limited tonal range: There were limited colours in each colour type to use in the design. Sometimes designers/developers need to make small adjustments to achieve the desired visual contrast
Inconsistent lightness of colours: The perceptual lightness of colours in the same level in these colour types looks inconsistent visually (e.g., error-400 looks way darker than the other 400 colours). This caused visual inconsistency on the component level
Lack of standards: There are no clear standards defined about which colours should be used where even though colours are tied with components in the design system
The challenges of designing dark mode
Letโs be honest - the dark mode is not fancy in 2024 anymore. During a discussion, a senior product manager joked about simply โflipping the colours from light to darkโ and showed us how he created a dark mode for the platform using a browser extension.
This perception highlighted our greatest challenge: the truth is that the dark mode isn't about simply inverting colours โ it requires fundamentally rethinking our entire colour system. As the product designer, I needed to help our team understand that the complexity lay in developing a new colour system capable of supporting multiple themes while maintaining consistency and accessibility.
Uncover the problems in the current colour system
At the project's outset, I organized a collaborative workshop with our design and front-end teams to discuss the current issues within the existing colour system and the goals we should aim for at this time. The attached image below is the old colours we had in the design system, and several issues were flagged by the team:
Limited tonal range: There were limited colours in each colour type to use in the design. Sometimes designers/developers need to make small adjustments to achieve the desired visual contrast
Inconsistent lightness of colours: The perceptual lightness of colours in the same level in these colour types looks inconsistent visually (e.g., error-400 looks way darker than the other 400 colours). This caused visual inconsistency on the component level
Lack of standards: There are no clear standards defined about which colours should be used where even though colours are tied with components in the design system
Align on the goals as a team
Together, we aligned on a few key objectives for the colour system upgrade with the dark mode in the workshop as high-level directional guidance for further discovery:
Accessibility: All colours must meet WCAG AA standards, ensuring universal readability and usability
Scalability & Future-proofing: The system should flexibly accommodate future design updates and additional themes
Ease of Use: Both designers and developers should find the system intuitive to implement and work with
Maintainability: A small team should be able to manage the system without unnecessary complexity
Align on the goals as a team
Together, we aligned on a few key objectives for the colour system upgrade with the dark mode in the workshop as high-level directional guidance for further discovery:
Accessibility: All colours must meet WCAG AA standards, ensuring universal readability and usability
Scalability & Future-proofing: The system should flexibly accommodate future design updates and additional themes
Ease of Use: Both designers and developers should find the system intuitive to implement and work with
Maintainability: A small team should be able to manage the system without unnecessary complexity
Align on the goals as a team
Together, we aligned on a few key objectives for the colour system upgrade with the dark mode in the workshop as high-level directional guidance for further discovery:
Accessibility: All colours must meet WCAG AA standards, ensuring universal readability and usability
Scalability & Future-proofing: The system should flexibly accommodate future design updates and additional themes
Ease of Use: Both designers and developers should find the system intuitive to implement and work with
Maintainability: A small team should be able to manage the system without unnecessary complexity
Brand identity vs. Accessibility
Being a visual thinker, I began by experimenting with several key product screens and turning them into different dark mode options to understand the implications.
Brand identity vs. Accessibility
Being a visual thinker, I began by experimenting with several key product screens and turning them into different dark mode options to understand the implications.
Brand identity vs. Accessibility
Being a visual thinker, I began by experimenting with several key product screens and turning them into different dark mode options to understand the implications.
Through the early explorations, I realized that there were a few critical accessibility challenges in our brand colour and other system state colours:
The brand (also primary) colour failed to meet WCAG AA contrast requirements against dark backgrounds
System state colours (e.g. error, success, and warning) also can not meet the accessibility standards if used directly in dark mode
While we could pick some new system state colours to meet contrast requirements, the real challenge lay in handling our brand colour. It appeared throughout the design system โ in text buttons, links, navigation labels, and other text components.
Through the early explorations, I realized that there were a few critical accessibility challenges in our brand colour and other system state colours:
The brand (also primary) colour failed to meet WCAG AA contrast requirements against dark backgrounds
System state colours (e.g. error, success, and warning) also can not meet the accessibility standards if used directly in dark mode
While we could pick some new system state colours to meet contrast requirements, the real challenge lay in handling our brand colour. It appeared throughout the design system โ in text buttons, links, navigation labels, and other text components.
Through the early explorations, I realized that there were a few critical accessibility challenges in our brand colour and other system state colours:
The brand (also primary) colour failed to meet WCAG AA contrast requirements against dark backgrounds
System state colours (e.g. error, success, and warning) also can not meet the accessibility standards if used directly in dark mode
While we could pick some new system state colours to meet contrast requirements, the real challenge lay in handling our brand colour. It appeared throughout the design system โ in text buttons, links, navigation labels, and other text components.
With this question, we went back to research. After looking closely into the solutions in other digital products with dark mode, we identified three potential approaches:
Approach #1: Adjust the brand colour in dark mode to meet the accessibility requirements
Example: LinkedIn, Jira
LinkedIn and Jira use their brand colour extensively in light mode but adjust their colour value slightly for dark mode. This approach preserves the visual similarity of the brand while meeting accessibility requirements.
The brand blue value used on LinkedIn is changed slightly from #0166C2 to #71B7FB when switching to dark mode. This helps to achieve the necessary contrast while maintaining visual consistency. Similarly, I observed a similar colour approach applied to the primary colour in Jiraโs dark mode.
Pros:
Ensures the primary colour used in the platform stays accessible to everyone
Stay true to the brandโs identity in all modes
Cons:
Inconsistent brand colours in the dark mode might potentially dilute the brand identity
It will introduce significant challenges for organizing and managing the colours in the design system
With this question, we went back to research. After looking closely into the solutions in other digital products with dark mode, we identified three potential approaches:
Approach #1: Adjust the brand colour in dark mode to meet the accessibility requirements
Example: LinkedIn, Jira
LinkedIn and Jira use their brand colour extensively in light mode but adjust their colour value slightly for dark mode. This approach preserves the visual similarity of the brand while meeting accessibility requirements.
The brand blue value used on LinkedIn is changed slightly from #0166C2 to #71B7FB when switching to dark mode. This helps to achieve the necessary contrast while maintaining visual consistency. Similarly, I observed a similar colour approach applied to the primary colour in Jiraโs dark mode.
Pros:
Ensures the primary colour used in the platform stays accessible to everyone
Stay true to the brandโs identity in all modes
Cons:
Inconsistent brand colours in the dark mode might potentially dilute the brand identity
It will introduce significant challenges for organizing and managing the colours in the design system
With this question, we went back to research. After looking closely into the solutions in other digital products with dark mode, we identified three potential approaches:
Approach #1: Adjust the brand colour in dark mode to meet the accessibility requirements
Example: LinkedIn, Jira
LinkedIn and Jira use their brand colour extensively in light mode but adjust their colour value slightly for dark mode. This approach preserves the visual similarity of the brand while meeting accessibility requirements.
The brand blue value used on LinkedIn is changed slightly from #0166C2 to #71B7FB when switching to dark mode. This helps to achieve the necessary contrast while maintaining visual consistency. Similarly, I observed a similar colour approach applied to the primary colour in Jiraโs dark mode.
Pros:
Ensures the primary colour used in the platform stays accessible to everyone
Stay true to the brandโs identity in all modes
Cons:
Inconsistent brand colours in the dark mode might potentially dilute the brand identity
It will introduce significant challenges for organizing and managing the colours in the design system
Approach #2: Use semantic colours for primary and active states, avoiding brand colours on components
Example: Slack
Rather than rely on their brand colour as the primary colour, Slack employs standard semantic colours for components โ using green for primary buttons and blue for active states in components like checkboxes and navigation. Slack supports customizable themes and provides users the flexibility to personalize their colour mode, and this approach will allow the components to fit into different themes.
Pros:
Semantic colours (e.g., green for success, blue for active states) are often more recognizable and intuitive for users, improving accessibility and usability
Using standard colours for common UI states creates a consistent and predictable visual experience, helping users navigate more easily
Cons:
Not using brand colours could make the product feel less unique, potentially diluting the brand identity
Heavily relying on common semantic colours may make the product interface feel generic and similar to competitors
Approach #2: Use semantic colours for primary and active states, avoiding brand colours on components
Example: Slack
Rather than rely on their brand colour as the primary colour, Slack employs standard semantic colours for components โ using green for primary buttons and blue for active states in components like checkboxes and navigation. Slack supports customizable themes and provides users the flexibility to personalize their colour mode, and this approach will allow the components to fit into different themes.
Pros:
Semantic colours (e.g., green for success, blue for active states) are often more recognizable and intuitive for users, improving accessibility and usability
Using standard colours for common UI states creates a consistent and predictable visual experience, helping users navigate more easily
Cons:
Not using brand colours could make the product feel less unique, potentially diluting the brand identity
Heavily relying on common semantic colours may make the product interface feel generic and similar to competitors
Approach #2: Use semantic colours for primary and active states, avoiding brand colours on components
Example: Slack
Rather than rely on their brand colour as the primary colour, Slack employs standard semantic colours for components โ using green for primary buttons and blue for active states in components like checkboxes and navigation. Slack supports customizable themes and provides users the flexibility to personalize their colour mode, and this approach will allow the components to fit into different themes.
Pros:
Semantic colours (e.g., green for success, blue for active states) are often more recognizable and intuitive for users, improving accessibility and usability
Using standard colours for common UI states creates a consistent and predictable visual experience, helping users navigate more easily
Cons:
Not using brand colours could make the product feel less unique, potentially diluting the brand identity
Heavily relying on common semantic colours may make the product interface feel generic and similar to competitors
After a thorough evaluation together with the team, we decided to move forward with approach #1, and here were the rationales behind the decision:
Strong brand presence in the product: Given that Humi just underwent a rebrand this year, this approach allows us to further reinforce our brand identity within the Humi web platform, and ensure consistency across all touchpoints for users
Easier for implementation: This approach will allow both design and engineering teams to easily design and implement the new colour system given our limited resources
Balancing aesthetics and accessibility: This approach also provides the flexibility to design colours that achieve a good balance between visual appeal and accessibility compliance
Define a new colour system for both light and dark modes
The colours defined in Humiโs design system evolved organically over time with contributions from various designers in the past. While it could serve the basic needs now in most design projects, we still identified a few critical limitations in our existing colour palette as mentioned above. In the early discovery of the dark mode, we saw an opportunity to redefine a truly scalable, future-proof colour system. But how to get there? Here is the breakdown of the approach I took step by step:
Step 1: Define the core colours for the light mode
The goal of this phase was to define a new set of core colours for the light mode with consistent โvisual lightnessโ. Here is a list of the colour palettes we have today in our existing design system and frontend library:
Primary: Brand colour and tonal variants.
Grey (Neutral): The overall tone of your application.
Warning: Highlights potential issues or actions that require attention.
Success: Indicates positive outcomes, confirmations, or completed actions.
Error: Signals critical issues, failures, or actions that need immediate correction.
Informative: Provides neutral information, guidance, or general notifications.
Accent: Complementary colours used to draw attention.
This time we did not want to just pick a few colours randomly simply relied on the designerโs gut feeling to make them look right. We wanted to come up with a more scientific (if there are any) and objective approach that is future-proof and scalable.
In the research of seeking a scientific approach, I came across the article "The Science of Color & Design" posted by James OโLeary who is a Colour Scientist at Google. The "HCT colour measure" method he mentioned in that article inspired me:
The color system used by designers today is HSL, or hue, saturation, lightness. HSL isnโt remotely accurate, and doesnโt try to be: it was built to make computing colors fast on 1970s computers.
Our brand new, perceptually accurate, color system is called HCT, which stands for hue, chroma, tone.
HCTโs lightness measure, tone, is the same as L*a*b*โs lightness. Using that lightness measure, along with some math tricks, meant we could measure contrast with HCT, directly integrating contrast checker algorithms and accessibility requirements.
After a thorough evaluation together with the team, we decided to move forward with approach #1, and here were the rationales behind the decision:
Strong brand presence in the product: Given that Humi just underwent a rebrand this year, this approach allows us to further reinforce our brand identity within the Humi web platform, and ensure consistency across all touchpoints for users
Easier for implementation: This approach will allow both design and engineering teams to easily design and implement the new colour system given our limited resources
Balancing aesthetics and accessibility: This approach also provides the flexibility to design colours that achieve a good balance between visual appeal and accessibility compliance
Define a new colour system for both light and dark modes
The colours defined in Humiโs design system evolved organically over time with contributions from various designers in the past. While it could serve the basic needs now in most design projects, we still identified a few critical limitations in our existing colour palette as mentioned above. In the early discovery of the dark mode, we saw an opportunity to redefine a truly scalable, future-proof colour system. But how to get there? Here is the breakdown of the approach I took step by step:
Step 1: Define the core colours for the light mode
The goal of this phase was to define a new set of core colours for the light mode with consistent โvisual lightnessโ. Here is a list of the colour palettes we have today in our existing design system and frontend library:
Primary: Brand colour and tonal variants.
Grey (Neutral): The overall tone of your application.
Warning: Highlights potential issues or actions that require attention.
Success: Indicates positive outcomes, confirmations, or completed actions.
Error: Signals critical issues, failures, or actions that need immediate correction.
Informative: Provides neutral information, guidance, or general notifications.
Accent: Complementary colours used to draw attention.
This time we did not want to just pick a few colours randomly simply relied on the designerโs gut feeling to make them look right. We wanted to come up with a more scientific (if there are any) and objective approach that is future-proof and scalable.
In the research of seeking a scientific approach, I came across the article "The Science of Color & Design" posted by James OโLeary who is a Colour Scientist at Google. The "HCT colour measure" method he mentioned in that article inspired me:
The color system used by designers today is HSL, or hue, saturation, lightness. HSL isnโt remotely accurate, and doesnโt try to be: it was built to make computing colors fast on 1970s computers.
Our brand new, perceptually accurate, color system is called HCT, which stands for hue, chroma, tone.
HCTโs lightness measure, tone, is the same as L*a*b*โs lightness. Using that lightness measure, along with some math tricks, meant we could measure contrast with HCT, directly integrating contrast checker algorithms and accessibility requirements.
After a thorough evaluation together with the team, we decided to move forward with approach #1, and here were the rationales behind the decision:
Strong brand presence in the product: Given that Humi just underwent a rebrand this year, this approach allows us to further reinforce our brand identity within the Humi web platform, and ensure consistency across all touchpoints for users
Easier for implementation: This approach will allow both design and engineering teams to easily design and implement the new colour system given our limited resources
Balancing aesthetics and accessibility: This approach also provides the flexibility to design colours that achieve a good balance between visual appeal and accessibility compliance
Define a new colour system for both light and dark modes
The colours defined in Humiโs design system evolved organically over time with contributions from various designers in the past. While it could serve the basic needs now in most design projects, we still identified a few critical limitations in our existing colour palette as mentioned above. In the early discovery of the dark mode, we saw an opportunity to redefine a truly scalable, future-proof colour system. But how to get there? Here is the breakdown of the approach I took step by step:
Step 1: Define the core colours for the light mode
The goal of this phase was to define a new set of core colours for the light mode with consistent โvisual lightnessโ. Here is a list of the colour palettes we have today in our existing design system and frontend library:
Primary: Brand colour and tonal variants.
Grey (Neutral): The overall tone of your application.
Warning: Highlights potential issues or actions that require attention.
Success: Indicates positive outcomes, confirmations, or completed actions.
Error: Signals critical issues, failures, or actions that need immediate correction.
Informative: Provides neutral information, guidance, or general notifications.
Accent: Complementary colours used to draw attention.
This time we did not want to just pick a few colours randomly simply relied on the designerโs gut feeling to make them look right. We wanted to come up with a more scientific (if there are any) and objective approach that is future-proof and scalable.
In the research of seeking a scientific approach, I came across the article "The Science of Color & Design" posted by James OโLeary who is a Colour Scientist at Google. The "HCT colour measure" method he mentioned in that article inspired me:
The color system used by designers today is HSL, or hue, saturation, lightness. HSL isnโt remotely accurate, and doesnโt try to be: it was built to make computing colors fast on 1970s computers.
Our brand new, perceptually accurate, color system is called HCT, which stands for hue, chroma, tone.
HCTโs lightness measure, tone, is the same as L*a*b*โs lightness. Using that lightness measure, along with some math tricks, meant we could measure contrast with HCT, directly integrating contrast checker algorithms and accessibility requirements.
This approach provides an objective and exercisable method to 1) generate colours with consistent lightness, and then 2) use the tone values to measure whether two colours have enough contrast ratio.
I applied the same approach to generate the core colours in the light mode to ensure consistent perceptual lightness:
This approach provides an objective and exercisable method to 1) generate colours with consistent lightness, and then 2) use the tone values to measure whether two colours have enough contrast ratio.
I applied the same approach to generate the core colours in the light mode to ensure consistent perceptual lightness:
This approach provides an objective and exercisable method to 1) generate colours with consistent lightness, and then 2) use the tone values to measure whether two colours have enough contrast ratio.
I applied the same approach to generate the core colours in the light mode to ensure consistent perceptual lightness:
Step 2: Develop colour variations for each colour type, ranging from lightest to darkest for light mode first
Based on the colour values defined for these key colour types, next we expanded each of these core colours into 9 colour tones for light mode.
In this phase, we leveraged a Figma plugin called Supa Palette to support the generation of colour tonal variations, using its built-in accessibility checker and colour measure to ensure the new colours are WCAG AA compliant. Again, the HCT colour measure approach was used as guidance to validate if colours have perceptually consistent lightness.
We named these colours with 100 to 900 in each palette as their basic token names, which is a commonly used scalable naming convention for primitive or core tokens in both design systems and frontend practices.
Neutral colours
We picked the primary text colour from Humiโs brand colour palette for the neutral colours and expanded it into 9 tones in our new colour system. Similar to the approach for primary colours, we applied the HCT approach by controlling the tone value only to generate these colours.
Step 2: Develop colour variations for each colour type, ranging from lightest to darkest for light mode first
Based on the colour values defined for these key colour types, next we expanded each of these core colours into 9 colour tones for light mode.
In this phase, we leveraged a Figma plugin called Supa Palette to support the generation of colour tonal variations, using its built-in accessibility checker and colour measure to ensure the new colours are WCAG AA compliant. Again, the HCT colour measure approach was used as guidance to validate if colours have perceptually consistent lightness.
We named these colours with 100 to 900 in each palette as their basic token names, which is a commonly used scalable naming convention for primitive or core tokens in both design systems and frontend practices.
Neutral colours
We picked the primary text colour from Humiโs brand colour palette for the neutral colours and expanded it into 9 tones in our new colour system. Similar to the approach for primary colours, we applied the HCT approach by controlling the tone value only to generate these colours.
Step 2: Develop colour variations for each colour type, ranging from lightest to darkest for light mode first
Based on the colour values defined for these key colour types, next we expanded each of these core colours into 9 colour tones for light mode.
In this phase, we leveraged a Figma plugin called Supa Palette to support the generation of colour tonal variations, using its built-in accessibility checker and colour measure to ensure the new colours are WCAG AA compliant. Again, the HCT colour measure approach was used as guidance to validate if colours have perceptually consistent lightness.
We named these colours with 100 to 900 in each palette as their basic token names, which is a commonly used scalable naming convention for primitive or core tokens in both design systems and frontend practices.
Neutral colours
We picked the primary text colour from Humiโs brand colour palette for the neutral colours and expanded it into 9 tones in our new colour system. Similar to the approach for primary colours, we applied the HCT approach by controlling the tone value only to generate these colours.
Primary colours and system state colours
Similarly, we generated the colour sets for our primary colours and other system state colours for the light mode:
Primary colours and system state colours
Similarly, we generated the colour sets for our primary colours and other system state colours for the light mode:
Primary colours and system state colours
Similarly, we generated the colour sets for our primary colours and other system state colours for the light mode:
Step 3: Create corresponding colour palettes for dark mode
As mentioned above, as a team we have aligned on the approach to pick a slightly different colour value for the brand colour for the dark mode to ensure accessibility compliance.
The question in this phase came to - how do we decide on the right colour values for dark mode for the brand colour and other colours? Again, rather than randomly picking a colour that looks "right" and relying on the designโs "gut feeling", we wanted to come up with an objective and scalable approach to set a solid foundation in the colour generation for the dark mode to support further scale.
We went back to research and later noticed the colour approach "Contrast-generated colours" in Adobeโs design system Spectrum. It makes so much sense to me as high-level guidance when making colour adjustments based on the theme - you should always aim for a consistent contrast ratio for a colour token across different themes (e.g., red-900 in the example below).
Step 3: Create corresponding colour palettes for dark mode
As mentioned above, as a team we have aligned on the approach to pick a slightly different colour value for the brand colour for the dark mode to ensure accessibility compliance.
The question in this phase came to - how do we decide on the right colour values for dark mode for the brand colour and other colours? Again, rather than randomly picking a colour that looks "right" and relying on the designโs "gut feeling", we wanted to come up with an objective and scalable approach to set a solid foundation in the colour generation for the dark mode to support further scale.
We went back to research and later noticed the colour approach "Contrast-generated colours" in Adobeโs design system Spectrum. It makes so much sense to me as high-level guidance when making colour adjustments based on the theme - you should always aim for a consistent contrast ratio for a colour token across different themes (e.g., red-900 in the example below).
Step 3: Create corresponding colour palettes for dark mode
As mentioned above, as a team we have aligned on the approach to pick a slightly different colour value for the brand colour for the dark mode to ensure accessibility compliance.
The question in this phase came to - how do we decide on the right colour values for dark mode for the brand colour and other colours? Again, rather than randomly picking a colour that looks "right" and relying on the designโs "gut feeling", we wanted to come up with an objective and scalable approach to set a solid foundation in the colour generation for the dark mode to support further scale.
We went back to research and later noticed the colour approach "Contrast-generated colours" in Adobeโs design system Spectrum. It makes so much sense to me as high-level guidance when making colour adjustments based on the theme - you should always aim for a consistent contrast ratio for a colour token across different themes (e.g., red-900 in the example below).
Inspired by this colour approach from Adobe Spectrum, we generated colour values of the key colour type for our dark mode.
Inspired by this colour approach from Adobe Spectrum, we generated colour values of the key colour type for our dark mode.
Inspired by this colour approach from Adobe Spectrum, we generated colour values of the key colour type for our dark mode.
Using the same approach, I converted the core functional colours for the dark mode.
Using the same approach, I converted the core functional colours for the dark mode.
Using the same approach, I converted the core functional colours for the dark mode.
With these key colours defined for dark mode, we applied the same approach used for the light mode to generate the dark mode colour palettes, ensuring accessibility compliance.
With these key colours defined for dark mode, we applied the same approach used for the light mode to generate the dark mode colour palettes, ensuring accessibility compliance.
With these key colours defined for dark mode, we applied the same approach used for the light mode to generate the dark mode colour palettes, ensuring accessibility compliance.
Through this process, weโve developed a colour system that includes a complete set of palettes for both light and dark modes. While I tried to document the approach as clearly as possible to outline how we arrived at the final results, the process was far from straightforward at the start. There was a lot of back-and-forth during the exploration phase, with numerous small adjustments to specific colours to ensure they met WCAG AA requirements.
Through this process, weโve developed a colour system that includes a complete set of palettes for both light and dark modes. While I tried to document the approach as clearly as possible to outline how we arrived at the final results, the process was far from straightforward at the start. There was a lot of back-and-forth during the exploration phase, with numerous small adjustments to specific colours to ensure they met WCAG AA requirements.
Through this process, weโve developed a colour system that includes a complete set of palettes for both light and dark modes. While I tried to document the approach as clearly as possible to outline how we arrived at the final results, the process was far from straightforward at the start. There was a lot of back-and-forth during the exploration phase, with numerous small adjustments to specific colours to ensure they met WCAG AA requirements.
From a set of colour palettes to the single source of truth for design decisions for colour
We've built a new colour system that works in both light and dark modes โ a big win! But we're not done yet. One of the biggest challenges we've faced is that designers and developers use colours inconsistently in Humi, and this is because we haven't had clear rules about which colours should go where.
Within this project, there were a few more objectives that we wanted to achieve:
Consistency between design and code: We need to make sure designers and developers use the colours consistently
Clear rules for using colours: We need to define how colours should be used in different parts of our products
Easy to maintain: With our current team size, we need a system that's easy to update and keep working smoothly for this stage
To turn this colour system into a strong design system that everyone can follow, we need a single place to store all our colour decisions, and this will be the truth for both designers and engineers.
The tech world has been talking about "Design Tokens" for a while. Since it was first introduced in 2014, many large companies like Salesforce, Google, Shopify, and Adobe have used them as a key piece of the foundation of their design systems to ensure their successful scale.
After talking with the design team and our staff frontend engineer, we decided to use Design Tokens for colours within this project for these reasons:
One source of truth: Design Tokens give us one central place for all our colour decisions, so everyone's on the same page
Bridging the team gap: They make it easier for designers and developers to work together
Built to grow: Design Tokens help us scale our system as our products get more complex
Set up colour tokens that work for Humi
Let's be completely honest - this phase took approximately 80% of the time I spent on this initiative, focused on integrating colour tokens into components in our design system and creating a document in Notion for team members without direct access to view "Variables" in Figma. It was also a learning process for me to gain knowledge and learn best practices shared by the community.
Building on the design token best practices learned, I structured our colour tokens into three tiers:
Primitive tokens: Base colour values. E.g., primary-600: #FA4E90 (light mode) / #8F71A0 (dark mode)
Semantic tokens: Usage-specific tokens that reference primitive tokens and include implementation guidance. E.g., background-primary-default, or text-primary-default
Component tokens: Component-specific tokens that reference semantic tokens for unique styling needs. E.g., sidebar-background-default, or sidebar-label-active-hover
From a set of colour palettes to the single source of truth for design decisions for colour
We've built a new colour system that works in both light and dark modes โ a big win! But we're not done yet. One of the biggest challenges we've faced is that designers and developers use colours inconsistently in Humi, and this is because we haven't had clear rules about which colours should go where.
Within this project, there were a few more objectives that we wanted to achieve:
Consistency between design and code: We need to make sure designers and developers use the colours consistently
Clear rules for using colours: We need to define how colours should be used in different parts of our products
Easy to maintain: With our current team size, we need a system that's easy to update and keep working smoothly for this stage
To turn this colour system into a strong design system that everyone can follow, we need a single place to store all our colour decisions, and this will be the truth for both designers and engineers.
The tech world has been talking about "Design Tokens" for a while. Since it was first introduced in 2014, many large companies like Salesforce, Google, Shopify, and Adobe have used them as a key piece of the foundation of their design systems to ensure their successful scale.
After talking with the design team and our staff frontend engineer, we decided to use Design Tokens for colours within this project for these reasons:
One source of truth: Design Tokens give us one central place for all our colour decisions, so everyone's on the same page
Bridging the team gap: They make it easier for designers and developers to work together
Built to grow: Design Tokens help us scale our system as our products get more complex
Set up colour tokens that work for Humi
Let's be completely honest - this phase took approximately 80% of the time I spent on this initiative, focused on integrating colour tokens into components in our design system and creating a document in Notion for team members without direct access to view "Variables" in Figma. It was also a learning process for me to gain knowledge and learn best practices shared by the community.
Building on the design token best practices learned, I structured our colour tokens into three tiers:
Primitive tokens: Base colour values. E.g., primary-600: #FA4E90 (light mode) / #8F71A0 (dark mode)
Semantic tokens: Usage-specific tokens that reference primitive tokens and include implementation guidance. E.g., background-primary-default, or text-primary-default
Component tokens: Component-specific tokens that reference semantic tokens for unique styling needs. E.g., sidebar-background-default, or sidebar-label-active-hover
From a set of colour palettes to the single source of truth for design decisions for colour
We've built a new colour system that works in both light and dark modes โ a big win! But we're not done yet. One of the biggest challenges we've faced is that designers and developers use colours inconsistently in Humi, and this is because we haven't had clear rules about which colours should go where.
Within this project, there were a few more objectives that we wanted to achieve:
Consistency between design and code: We need to make sure designers and developers use the colours consistently
Clear rules for using colours: We need to define how colours should be used in different parts of our products
Easy to maintain: With our current team size, we need a system that's easy to update and keep working smoothly for this stage
To turn this colour system into a strong design system that everyone can follow, we need a single place to store all our colour decisions, and this will be the truth for both designers and engineers.
The tech world has been talking about "Design Tokens" for a while. Since it was first introduced in 2014, many large companies like Salesforce, Google, Shopify, and Adobe have used them as a key piece of the foundation of their design systems to ensure their successful scale.
After talking with the design team and our staff frontend engineer, we decided to use Design Tokens for colours within this project for these reasons:
One source of truth: Design Tokens give us one central place for all our colour decisions, so everyone's on the same page
Bridging the team gap: They make it easier for designers and developers to work together
Built to grow: Design Tokens help us scale our system as our products get more complex
Set up colour tokens that work for Humi
Let's be completely honest - this phase took approximately 80% of the time I spent on this initiative, focused on integrating colour tokens into components in our design system and creating a document in Notion for team members without direct access to view "Variables" in Figma. It was also a learning process for me to gain knowledge and learn best practices shared by the community.
Building on the design token best practices learned, I structured our colour tokens into three tiers:
Primitive tokens: Base colour values. E.g., primary-600: #FA4E90 (light mode) / #8F71A0 (dark mode)
Semantic tokens: Usage-specific tokens that reference primitive tokens and include implementation guidance. E.g., background-primary-default, or text-primary-default
Component tokens: Component-specific tokens that reference semantic tokens for unique styling needs. E.g., sidebar-background-default, or sidebar-label-active-hover
Token naming convention
We adopted the naming conventions outlined in Nathan Curtis's widely-respected approach to token naming and simplified that to meet the requirements for our use cases:
Token naming convention
We adopted the naming conventions outlined in Nathan Curtis's widely-respected approach to token naming and simplified that to meet the requirements for our use cases:
Token naming convention
We adopted the naming conventions outlined in Nathan Curtis's widely-respected approach to token naming and simplified that to meet the requirements for our use cases:
Token structure to support multiple themes
This is an example of how the design token structure looks like for the colour used on the active state of the sidebar label:
Token structure to support multiple themes
This is an example of how the design token structure looks like for the colour used on the active state of the sidebar label:
Token structure to support multiple themes
This is an example of how the design token structure looks like for the colour used on the active state of the sidebar label:
Set up colour tokens as variables in Figma
Colour tokens were added to our design system Figma file, and then all shared components in the design system were updated with the new colour tokens (โvariablesโ in Figma) while ensuring the new colours added to the components meet the WCAG AA requirements.
Set up colour tokens as variables in Figma
Colour tokens were added to our design system Figma file, and then all shared components in the design system were updated with the new colour tokens (โvariablesโ in Figma) while ensuring the new colours added to the components meet the WCAG AA requirements.
Set up colour tokens as variables in Figma
Colour tokens were added to our design system Figma file, and then all shared components in the design system were updated with the new colour tokens (โvariablesโ in Figma) while ensuring the new colours added to the components meet the WCAG AA requirements.
Prototyping and testing with the new colour tokens๏ผ
Prototyping and testing with the new colour tokens๏ผ
Prototyping and testing with the new colour tokens๏ผ
Document colour tokens in Notion as the single source of truth
Once we completed the colour token implementation and testing from the design side, then I created a detailed document for our development team, outlining specific updates needed in our front-end colour library.
Additionally, we developed comprehensive documentation in Notion for design tokens, ensuring all team members could understand and reference our colour system regardless of their access to our design tools (Yeah, Figma requires an โEditโ access to view variables and not everyone in Humi has that).
Document colour tokens in Notion as the single source of truth
Once we completed the colour token implementation and testing from the design side, then I created a detailed document for our development team, outlining specific updates needed in our front-end colour library.
Additionally, we developed comprehensive documentation in Notion for design tokens, ensuring all team members could understand and reference our colour system regardless of their access to our design tools (Yeah, Figma requires an โEditโ access to view variables and not everyone in Humi has that).
Document colour tokens in Notion as the single source of truth
Once we completed the colour token implementation and testing from the design side, then I created a detailed document for our development team, outlining specific updates needed in our front-end colour library.
Additionally, we developed comprehensive documentation in Notion for design tokens, ensuring all team members could understand and reference our colour system regardless of their access to our design tools (Yeah, Figma requires an โEditโ access to view variables and not everyone in Humi has that).
Implementation and release strategy
With the new colour system defined and tested, we moved into implementation. Working closely with our development team revealed an unexpected challenge: years of organic growth had left us with multiple colour standards across different platform parts.
Jesse MacDougall, the Staff Developer at Humi, invested significant effort in standardizing these inconsistencies, methodically replacing legacy colour values with our new token-based variables.
Once completing the colour update and the dark mode implementation, we adopted a staged rollout strategy:
Stage 1: Internal Testing Phase
We began by rolling out dark mode to all Humi employees, leveraging our internal team's daily platform usage to identify edge cases and potential issues. This phase proved invaluable for initial debugging and refinement.
Stage 2: Beta Release
Following internal validation, we extended access to a select group of customers who had previously requested dark mode functionality. This targeted beta release allowed us to:
Gather feedback from our most engaged users quickly
Identify colour-related issues in real-world usage scenarios
Make necessary adjustments to our colour system before the full release
Impact and reception
Two months after the full release to all Humi users, the dark mode achieved a ๐ 13.5% adoption rate (based on the data observed in Pendo), with users actively choosing it as their default theme. At the same time, we also received some love from our users like these:
Implementation and release strategy
With the new colour system defined and tested, we moved into implementation. Working closely with our development team revealed an unexpected challenge: years of organic growth had left us with multiple colour standards across different platform parts.
Jesse MacDougall, the Staff Developer at Humi, invested significant effort in standardizing these inconsistencies, methodically replacing legacy colour values with our new token-based variables.
Once completing the colour update and the dark mode implementation, we adopted a staged rollout strategy:
Stage 1: Internal Testing Phase
We began by rolling out dark mode to all Humi employees, leveraging our internal team's daily platform usage to identify edge cases and potential issues. This phase proved invaluable for initial debugging and refinement.
Stage 2: Beta Release
Following internal validation, we extended access to a select group of customers who had previously requested dark mode functionality. This targeted beta release allowed us to:
Gather feedback from our most engaged users quickly
Identify colour-related issues in real-world usage scenarios
Make necessary adjustments to our colour system before the full release
Impact and reception
Two months after the full release to all Humi users, the dark mode achieved a ๐ 13.5% adoption rate (based on the data observed in Pendo), with users actively choosing it as their default theme. At the same time, we also received some love from our users like these:
Implementation and release strategy
With the new colour system defined and tested, we moved into implementation. Working closely with our development team revealed an unexpected challenge: years of organic growth had left us with multiple colour standards across different platform parts.
Jesse MacDougall, the Staff Developer at Humi, invested significant effort in standardizing these inconsistencies, methodically replacing legacy colour values with our new token-based variables.
Once completing the colour update and the dark mode implementation, we adopted a staged rollout strategy:
Stage 1: Internal Testing Phase
We began by rolling out dark mode to all Humi employees, leveraging our internal team's daily platform usage to identify edge cases and potential issues. This phase proved invaluable for initial debugging and refinement.
Stage 2: Beta Release
Following internal validation, we extended access to a select group of customers who had previously requested dark mode functionality. This targeted beta release allowed us to:
Gather feedback from our most engaged users quickly
Identify colour-related issues in real-world usage scenarios
Make necessary adjustments to our colour system before the full release
Impact and reception
Two months after the full release to all Humi users, the dark mode achieved a ๐ 13.5% adoption rate (based on the data observed in Pendo), with users actively choosing it as their default theme. At the same time, we also received some love from our users like these:
This was just the beginning of integrating design tokens into Humiโs design system. After the release of the dark mode, I started looking into implementing other token types (typography, spacing, borders, radius etc.) with the same foundational principles established for color tokens.
Ultimately, these tokens aim to enhance operational efficiency, ensure cross-functional consistency, and improve system scalability for the Humi team. By streamlining workflows, weโre able to accelerate value delivery to end users while maintaining a high standard of product quality.
Learnings
At the end, here are a few takeaways and learnings to share:
The most challenging part of implementing dark mode is how often its complexity gets underestimated. As a product designer, I had to invest considerable effort in helping the team understand why we needed to build a comprehensive colour system and incorporate colour tokens into our design system. Aligning everyone takes time, but itโs absolutely worth it. A design system is inherently a collaborative effortโit canโt thrive on the work of product designers alone.
Collaborate with developers early and often. Take the time to understand their constraints, workflows, and aspirations to ensure the solution fits their needs. Huge thanks to Jesse โ this wouldnโt have been possible without his expertise and relentless effort to keep everything on track and moving in the right direction.
When implementing colour tokens, test them frequently and thoroughly within your components. Itโs critical to ensure the standards you define are not only practical but also purposeful in real use cases.
Dark mode isnโt just a one-off project. With this first release, weโve laid the groundwork in our design system to support dark mode, but this is only the beginning. Moving forward, weโll need to approach designs thoughtfully, always considering how theyโll work in dark mode. Itโs equally important to establish a seamless process for handing off designs with clear and thorough documentation for dark mode design specs.
This was just the beginning of integrating design tokens into Humiโs design system. After the release of the dark mode, I started looking into implementing other token types (typography, spacing, borders, radius etc.) with the same foundational principles established for color tokens.
Ultimately, these tokens aim to enhance operational efficiency, ensure cross-functional consistency, and improve system scalability for the Humi team. By streamlining workflows, weโre able to accelerate value delivery to end users while maintaining a high standard of product quality.
Learnings
At the end, here are a few takeaways and learnings to share:
The most challenging part of implementing dark mode is how often its complexity gets underestimated. As a product designer, I had to invest considerable effort in helping the team understand why we needed to build a comprehensive colour system and incorporate colour tokens into our design system. Aligning everyone takes time, but itโs absolutely worth it. A design system is inherently a collaborative effortโit canโt thrive on the work of product designers alone.
Collaborate with developers early and often. Take the time to understand their constraints, workflows, and aspirations to ensure the solution fits their needs. Huge thanks to Jesse โ this wouldnโt have been possible without his expertise and relentless effort to keep everything on track and moving in the right direction.
When implementing colour tokens, test them frequently and thoroughly within your components. Itโs critical to ensure the standards you define are not only practical but also purposeful in real use cases.
Dark mode isnโt just a one-off project. With this first release, weโve laid the groundwork in our design system to support dark mode, but this is only the beginning. Moving forward, weโll need to approach designs thoughtfully, always considering how theyโll work in dark mode. Itโs equally important to establish a seamless process for handing off designs with clear and thorough documentation for dark mode design specs.
This was just the beginning of integrating design tokens into Humiโs design system. After the release of the dark mode, I started looking into implementing other token types (typography, spacing, borders, radius etc.) with the same foundational principles established for color tokens.
Ultimately, these tokens aim to enhance operational efficiency, ensure cross-functional consistency, and improve system scalability for the Humi team. By streamlining workflows, weโre able to accelerate value delivery to end users while maintaining a high standard of product quality.
Learnings
At the end, here are a few takeaways and learnings to share:
The most challenging part of implementing dark mode is how often its complexity gets underestimated. As a product designer, I had to invest considerable effort in helping the team understand why we needed to build a comprehensive colour system and incorporate colour tokens into our design system. Aligning everyone takes time, but itโs absolutely worth it. A design system is inherently a collaborative effortโit canโt thrive on the work of product designers alone.
Collaborate with developers early and often. Take the time to understand their constraints, workflows, and aspirations to ensure the solution fits their needs. Huge thanks to Jesse โ this wouldnโt have been possible without his expertise and relentless effort to keep everything on track and moving in the right direction.
When implementing colour tokens, test them frequently and thoroughly within your components. Itโs critical to ensure the standards you define are not only practical but also purposeful in real use cases.
Dark mode isnโt just a one-off project. With this first release, weโve laid the groundwork in our design system to support dark mode, but this is only the beginning. Moving forward, weโll need to approach designs thoughtfully, always considering how theyโll work in dark mode. Itโs equally important to establish a seamless process for handing off designs with clear and thorough documentation for dark mode design specs.
