My thoughts on designing for dark mode
Right now I do most my reading and writing on my phone in bed at night when the rest of the family is sleeping. This make me really appreciate dark mode and Safari Reader Mode which I gave a dark palette and use on all sites not providing a dark alternative. But what should one consider when designing for dark mode? I’ll cover a few things such as color and type here. I’m also touching on high contrast modes.
What’s your light mode context? Does your light mode follow any guidelines, such as Apples Human Interface Guidelines or Googles Material Design? It’s probably a good idea to follow suite for your dark mode.
If you’re designing for a website or an app by following any internal or brand guidelines I believe it’s a good idea to design a dark alternative to those guidelines. Is it possible to have a dark version of your light palette and keep the same emotion? Remember that not all colors work very well as a tinted black. Be creative!
And always always keep contrast and accessibility in mind. Use tools as Stark to make sure all your users can access your content and that you comply with the WCAG guidelines.
Other services, such as Netflix, already have a dark UI to fit their context - should they provide a light mode?
Increasing collaboration between teams with Figma
Being a lone designer at the company can be exhausting. You’ll need to gather feedback and quickly iterate a few projects simultaneously. To offload myself I’m fortunate to work alongside great front end developers who can mock and iterate on ideas and designs.
In turn, to offload them I provided a (simple) design system containing type, colors and our most common components. I did this in Figma, which is my go to tool, as a shared library.
To improve the collaboration further I wanted the entire development team to be able to use Figma. There’s three reasons for this:
- everybody should be comfortable testing prototypes and leaving feedback early and often during the design phase
- be able to use Figma as deliverables
- include everyone early and let them contribute to the design
To achieve this I hosted a workshop for the development team of six. The workshop was two hours and consisted of three parts.
The Interfaces of Things
Why do we always talk about the interfaces when we’re talking about design and User Experience (UX)? I recently attended a talk titled UX of the Internet of Things by Tommy Sundström at FooCafé in Malmö and we kept falling into that trap.
Internet of Things (IOT) has great potential and the time spent there was not near enough to cover everything. Unfortunately, we used most of the time to talk about interfaces rather than to discuss which issues IOT could solve or enhance. Is this because an interface is tangible? or is it because we need to feel in control?
The main topic of the discussion was control. How could we control all these objects around us. Would there be a universal pattern language for gestures? Is voice the preferred way to interact with IOT? Could gestures conflict between different products? We cannot argue for which interactions to use when we lack both a context and a problem to solve.
We have a responsibility to improve everyday life, and that is not to remote control as many things as possible from the sofa. We should be able to live life without our watch reminding us to stand for a while.
Engaging User Participation with Prototypes
How we used prototypes to reach an uninterested stakeholder in a small CoDesign project.
I am an interaction designer and I am trained in user centered design (UCD). I work a lot with different prototypes throughout a design process. Whether prototypes are made of paper or plastic, are digital or analog, they are often used for user testing.
The UCD approach highlights the importance to involve users in the design process, as they are the ones who will use the product or service on a daily basis. To be able to build a better product or service for the user, we try to understand them through various design metods and user tests. The things we learn from the user tests is utilized in an iterative design process. But the participants are not in the power to directly modify the prototypes. The prototypes are developed by what the designers believe the user wants. Of course, if the user tests are done well the better we know the user (Sharp et al. 2007, Halse 2010).
In CoDesign prototypes tend to be used differently. They are not only shared with the participants earlier in the design process, but also used as invitations to participation, and to collaboratively iterate the design. Prototypes invite the user into a collaborative design process where prototypes are built togheter with the participants. This could make it easier to criticize and modify the design by the participants. Furthermore, in CoDesign prototype better explores scenarios of the participants point of view and they are invited to modify the prototypes to explore further possibilities. Whereas, in UCD the designers tend to be the experts using their and their teams insights (Halse 2010, Simonsen & Robertson 2012).