Stepping Out of the Light: Tips for the design and development of dark mode

With the recent release of both Android 10 and iOS 13, awareness around dark mode is starting to grow. Google and Apple have both been steadily dedicating attention and resources to “dark mode” in the last year or so, which may leave you considering a dark mode version for your UI as well. This guide aims to provide some helpful tips and anecdotal accounts for what designers may encounter while working through the creation of a dark mode UI.

For insight into the development process, see part two of this article series.

Early draft for TripIt’s dark mode

What is dark mode anyway, and why should we do it?

A quick internet search will provide many similar answers to the big question. The most useful in our case was from Google’s Material Design guidelines, which states:

“Dark themes reduce the luminance emitted by device screens, while still meeting minimum color contrast ratios. They help improve visual ergonomics by reducing eye strain, adjusting brightness to current lighting conditions, and facilitating screen use in dark environments — all while conserving battery power. Devices with OLED screens benefit from the ability to turn off black pixels at any time of day.”

If looking to get buy-in from your team, consider speaking to these points:

1. Innovation : For some teams, simply opting to keep up with the times is enough of a reason to dedicate resources. Dark mode is, at the very least, a trend that is making its way into a vast majority of digital products, and it is likely to grow in significance.
2. Customized Experience: Somewhat related to the first point, being able to offer up a different version of your UI can enable users to customize their experience depending on their preferences. Android and iOS have offered the ability to do this with less effort than a total redesign, and it’s worth capitalizing even if it’s just to be able to offer another “flavor” of your UI.
3. Universal Design: Dark mode is not only beneficial for users with temporary or permanent light sensitivity (e.g. dilated pupils after an eye exam, or people suffering from photophobia), but is also more comfortable for non-visually impaired users, particularly when in low-light environments.

Once you’ve gotten buy-in from your stakeholders and product team, the real work begins. As mentioned above, Android and iOS have offered an arguably straightforward way to implement dark mode. Details can be found in the accompanying development-focused continuation to this article. There are however some initial decisions to make before jumping into your code.

Defining Your Color Palette

The main challenge we encountered during the design phase happened when we realized that our dark mode required a little more nuance than our default light mode. For example, we have two active text colors in our default light mode (a very dark grey and a slightly lighter grey) which help define hierarchy between main text and sub text. Dark mode, however, was a little more difficult because, in trying to ensure our screens had sufficient contrast, we were mostly limited to white text. This created a bit of a domino effect which led to our light and dark palettes differing ever so slightly.

Dark mode implementation was designed for a “switch” to flip which would basically turn your light palette into your dark palette. This means that for every “light” color, there is a corresponding “dark” color. Because our two palettes differed slightly, this meant we had to go in and update our default light palette as well to make the switch work seamlessly.

Main content layers were to have backgrounds in #fff in light mode and #1b2440 in dark mode but both hex codes are named “tripit_layer_bg”

There are two main points to keep in mind when selecting your palette:

1. Make sure your default color palette is defined by function, and not by color

This will likely result in certain color names calling to the same hex code, which could feel silly until you implement dark mode and realize that keeping your colors function-focused, gives you more wiggle room when considering an altered state palette.

#efeff4 had to be broken up into two color names (tripit_screen_bg and tripit_sub_headers) because though those two elements use the same color in light mode, we chose to use two different colors in dark mode

2. Keep the palette small

Similar to the last point, this is more of a general rule to keep in mind regardless of whether you’re working on light mode or dark mode. The more stripped down your light palette is, the easier it’ll be to handle the switch to your dark palette.

The basic breakdown for our palette is the following:

• Screen BG: Think of this as the color of an empty canvas in Sketch. In the image below, this is the slightly blue grey color in light mode, and the darkest blue in dark mode.
• Layer BG: This is the background color for any layer of content. In our light mode, this is white (#FFF). This helps create a definition between the empty screen and the content.
• Secondary Layer BG: This is the background color for secondary content elements such as section headers. This helps create a definition between blocks of content. It’s not completely necessary in most apps but does help create a more defined hierarchy if you tend to have a number of screens with multiple sections.
• Action Color: In our case, we use a version of our main brand color to define when an element is actionable. This stays relatively the same between light and dark mode with a slightly lighter version for dark mode to ensure proper contrast is maintained.
• Main Text: This is pretty self explanatory and covers elements such as screen titles, main copy (text),… etc. In our light mode, this is a dark grey (#333.) For dark mode, we use white.
• Sub Text: This is one of those cases wherein our light and dark mode differ. For light mode, our secondary text (such as sub headers, labels, helper text… etc.) is in a slightly lighter grey (#666) than our main text to help better define hierarchy. Our dark mode however uses white for both main text and sub text as we found it’s a little more difficult to maintain maximum readability if using varying levels of white as opposed to grey.

Though in dark mode both main text and sub text are in white, they are technically still two different colors (tripit_main_text and tripit_sub_text) to allow two different hex codes to be used in light mode.

There are going to be other colors for more specific use-cases (such as status colors, inactive states, pressed states, selected states… etc.) but this small palette makes up the bulk of our most commonly used colors.

In summary (TLDR)

Preparing your design system for dark mode is more or less an exercise in organization. The most important thing to keep in mind is that the implementation process for dark mode is based off of a 1:1 concept wherein each color name in your palette will have one corresponding hex code each for light and dark mode. This means that building a tight palette based on the functions of each color name as opposed to the specific hex code will give you more freedom to create nuances between light and dark mode to ensure your design is optimized in either mode.

For a detailed look into the development process, see part two of this article series.

Additional Resources

Implementing Dark Theme on Android
Android Material Design: Dark Theme
Apple’s Human Interface Guidelines: Dark Mode