Design Systems and the Dirty Reality
Have you read the umpteenth article about creating perfect design systems? Beautiful accessible colors? Seamless design token integration from Figma to Code in your project? How do you feel? Do you wonder how on earth your product should ever be on par with those emerging industry standards? Especially when your stakeholders throw daily business after daily business at you? You are not alone. Let me share the imperfection that we are at the idealo Shopping App.
On The Road
Being one of Germany’s largest price comparison platforms, our journey is somewhere between. Our “mothership” idealo web has no dark mode at all yet. Thus our Corporate Design also does not reflect any dark mode considerations, we had to come up with our own color system. Our Android App received semantic colors about a year ago. This enabled the development of a Material-compliant dark theme, which we focus on later. The iOS counterpart is still stuck at a 1:1 translation of light to dark colors which makes nuanced adjustments a hassle. On the surface though: everything is fine. Visually for the end-user but also our libraries for design colleagues are as expected. We have individual libraries for iOS and Android components and they support theming with Themer Plugin. Furthermore one library for each color styles, text styles, illustrations, icons and misc. components.
Don’t Look Too Closely
When preparing to explain our Android color system to new colleagues we decided to take a look at the reality in code. We ended up being more confused than informed. Its one thing to have a neat color system and another how implementation requirements are handling it. Custom drawables are bundling attributes like border-radius, strokes and background colors. There are a lot of them in our project and they are not following a system. Now we could spec our designs close to the metal and reference those messy drawables directly. But its near impossible to make that complexity understandable. Or even include it in our design system somehow. For our devs cleaning those up would not create value despite a few bytes saved.
Everything Is Resource Management
We are about 4 UI/UX Designers working on both iOS and Android App at the same time. If you happen to have a small team like ours you need to think twice before you invest in emerging technologies. Or when to apply design system changes. Any of those is an effort not to be underestimated. “That’s what a design system is for” you might say. In theory, yes. Android theming is exactly there to make system-wide changes a breeze. Due to backward compatibility requirements and “grown” structures, we are not in that position yet. Any value generated by increased flexibility is hard to put into numbers to convince stakeholders. Especially when no redesign is ever planned. A short list of Material features that got introduced rather recently and which we did not find time to evaluate and implement properly yet:
- Material Motion (08/2020)
- Motion Theming (07/2021)
- Material 3 & Dynamic Colors (01/2022)
Design Tokens
The newest buzz that should bring design systems and any platform development onto a common basis is design tokens. These are atoms of a multitude of attributes and can be almost everything from colors to shapes to typographic styles. In a cutting edge workflow, a Figma plugin syncs all your individual definitions into the product repository. This makes the designer the single source of truth. Alas, relying on a plugin for such an integral part of production is something we are not comfortable with. Some are not even compatible with native styles or have other drawbacks. As the design token group of the W3C is preparing their final draft soon, here is hoping we will get some official Figma support sooner or later. Implementing this in both our apps will take quite a leap still but also provide a chance for way better control and consistency.
Change Management
What we are most curious about is how other companies’ rather small design departments handle inevitable change. Keeping up to date with yearly OS feature updates is hard enough. Staying somewhat close to UI trends and patterns at the same time can be incredibly difficult. Our approach is creating some quick+dirty vision drafts from time to time to get alignment. Additionally, we are trying to squeeze in appropriate design changes if a view gets touched in any ticket. This way we are pushing the product closer and closer to that imaginary ideal that might become outdated with the next user test. Tying all those constraints into a coherent product without revealing its messy bowels is what makes our job truly pleasing.
If you want to take part in our journey, check our vacancies.
