Going Dark — how we implemented dark mode on the Angel Broking mobile app
Given the deluge of digital interfaces adopting dark mode, one might be inclined to think that this is just another passing fad. But there’s more to it than that.
Beyond its aesthetic appeal, a dark theme serves a functional purpose. From reducing eye strain to improving battery life, darker interfaces are built with the goal of being more utilitarian. Hence, certain apps, such as a GPS, launched dark themes even before operating systems did.
With the ever-growing list of apps adopting dark mode, hopping over to the “dark side” was inevitable for us at Angel Broking. More than following a UI trend, we adopted the dark mode to strategically enhance the end user experience.
According to visual physiology, adaptation from dark to light is comparatively quicker than light to dark. This small window, where a human eye adjusts to various levels of light, might cause friction in the overall app experience. We want users to seamlessly transition between various interfaces without having to recalibrate their pupillary light reflex each time.
Joining the dark side: a step-by-step guide
1. Define the palette
Background colour
The first step in creating a dark mode palette is to define your background colour as it is going to be a dominant one. We avoided pure blacks and went with a darker blue for two reasons: 1. To give the UI a character which is in line with the brand and 2. To stay away from pitch black, which gives us space to create depth in the interface.
In addition to the primary background, we have cards that give the appearance of being slightly “raised” above the surface. We created the effect of elevated elements by lightening the background: the closer the card to the user, the lighter its tone is.
Basic palette
While creating the key colours of the dark theme, we started with replacing primary colours with less saturated versions of their counterparts in light mode.
In the light theme, we used several shades of blue colour for buttons, line icons, and the header. The header and large buttons with varied tones of blue had the potential to be distracting. We eliminated this with the more simplistic new dark theme palette by defining a single primary blue colour for all actionables. For the rest, we ended up modifying the style and colour of several components. This helped us achieve consistency in our UI and documentation.
We replaced three blue hues with a single one — a major improvement.
In addition to primary blue, we also used orange, yellow, green, and red for several indicators and UI states.
Check contrast
Before finalising the new colour scheme, we made a point to test it for accessibility. The fact is, many people, especially those with less than ideal vision or a poor screen, will have a hard time making out elements that only weakly contrast with the background. This is especially true if these elements consist of thin lines, such as text and line icons.
We tested for the ideal contrast on the website contrast-ratio.com and tweaked some values to ensure the contrast was optimum.
2. Prepare a colour library to cover each instance
Just like a UI kit, colour library remarkably expedites implementation for both — the designer and developer. We put one together after creating several mood boards, testing various palettes and capturing inputs from various stakeholders. Once the new dark palette was selected, we tested the new colours on several primary app screens. The library includes:
- Two distinctive colour palettes for dark and light more with 1:1 mapping
- A colour guide of styles for the usual state of elements, hovers, and colour for inactive elements, inputs in focus, and so on
- Definition and use case for each shade of black/grey based on the predefined UI components
3. Agree on the names of colours
To ensure clarity in communication between designers and developers, we defined global colour names for both the themes. In the pre-existing system, we followed no naming conventions for colours. This turned out to be painfully inconvenient because, during discussions people referred to different colours with a generic name like blue, black, grey, and the like.
However, with the advent of the dark theme, it was practically impossible to use hues in the colour names. Which made it imperative for us to create and adopt a new naming convention.
The new colour names were meticulously defined based on the following parameters.
- Purpose of the colour, or of the element in which it is used
- Degree of priority of use (optional)
- State of the element, if applicable (optional)
Fundamentally speaking, a tidier naming convention helps you save tonnes of time and confusion while collaborating with developers.
4. Illustrations
This was a tricky one. It is not ideal to have two different types of palettes for the illustration of each theme. We worked on creating a single library of illustrations using a hue shifting technique and playing with the opacity in several cases. With a few tweaks, we managed to use same illustration for both modes which eventually lead to a consistent app experience and easy implementation for the developers
Maintenance and continuing development
Since we developed the dark theme we’ve added several new features, the implementation of which was buttery smooth thanks to the system we’ve defined for using colours. But that being said, we’re still evolving the dark mode palette as we introduce new UI components and styles.
If your interface needs a dark theme, it’s best to incorporate it from the start, immediately after finalising the visual concept. This will help you avoid nearly all the problems we encountered. Here’s quick recap:
- Define the palette
- Prepare a colour library
- Create a naming convention
- Prepare illustrations for dark theme
