Actimo is an Employee Experience platform for mobile and web. With it, companies can create custom employee apps handling communications, training, employee handbooks and more.
Challenge
Since starting at Actimo I had been pushing for a Design System, and finally got to build exactly that—in Figma.
Design
With no common system, designers increase UI inconsistency with each produced mockup
Despite only being only two designers who collaborated well, we both still had very different styles. Not having set standards for typography, colors and patterns meant spending a lot of time in Design Reviews discussing the details. And despite not being the intention, we were increasing inconsistency with every design project in a product which was already pretty inconsistent design-wise.
DEvelopment
With no common language, development spends more time questioning designs
With no established rules for design foundations, components and interactions, all designs had to be produced as mockups in very great detail, and front-end developers wrote a lot of custom code, which meant projects took extra time. Also, developers had no where to look for all the states and use cases of a design component, and reusing designs across projects wasn’t easy to do.
Marketing
With no common visual identity, the product is experienced differently than the brand
Our Marketing and Product departments had two different perceptions of Actimo’s design. The Marketing department supported an overly playful design which us in product felt was a mismatch with the use cases and customers. A Design System for the Product could also mark a new beginning for a common design language with Marketing, shared inside Figma.
Initially, the app and administration had been built as two different universes, and as consequence, they had two different designs. The Design System would unify that, while still supporting white label options for the app.
Structure
To find a structure, I used Card Sorteding together with the other Product Designer and the Product Lead. This helped us get an overview of all the components, and decide on naming conventions. Looking back, I would have included Development in this process as well.
Design Foundation
Every good Design System starts with solid design foundations. I set up typography and colors as styles, added icons, spacing values, et cetera. During this process a new design language started taking form.
I argued in favour of also adding the website and brand assets to the Design System to cover brand assets, and attempted to collaborate with the Marketing department, who ruled over the Actimo brand.
I didn’t succeed in unifying design across our departments, because I was working from bottom-up, instead of first having buy-in from the top.
Theming
Actimo is a whitelabel solution, where customers can customise the design of the employee app to fit their brand. This meant a very wide range of completely free options, which made life for us designers pretty uphill.
Designing for the app meant designing for many different design combinations–including future, unknown ones.
The Design System had to support this, but at the same time, it also needed to simplify it, so we could guarantee the user experience and accessibility.
Instead of giving customers free input fields, fx. for border radius, they could choose between a “sharp,” “soft” or “round” app look. For the brand, customers add a main brand color and an accent color.
Since the main brand color would decide all the colors in the interface, I wanted to secure proper WCAG contrast ratios through code. I’d done something similar together with a developer colleague while at Learningbank.
The idea was if the main brand color failed a contrast check the theme would inform, and adjust the lightness until it no longer failed. In my first theming version, I only included a light and dark option using neutral greys.
Then the other designer on the team suggested to generate all colors for the app UI using the customer’s brand colors, from surfaces to buttons to text itself, creating a slightly tinted look throughout.
It’s actually the same logic used right here on my website, just a bit more advanced.
Components
I went through the system and noted down any and all components that should be built in Figma.
Taking inventory, I saw just how much inconsistency was in the system, for example four different types of tables, each with different thumbnails and settings.
Taking inventory also helps you understand all the different ways a component is used
With the foundations in place, a new file structure in Figma, and an inventory of components I could begin building the components. I also included details about intention, states and use cases.
I also wanted to cover the experience with the product; gestures, design patterns and tone of voice, but the main goal of this project was getting it in place to use it.
One thing emerged which I believed was particularly important to align design across the entire product.
Values
A Design System is not only a library of components. It can cover the full experience with a product, and should also communicate the governing principles behind it. I experienced first-hand how different design styles could affect a design. What about different values or beliefs?
If one designer designs for transparency when it’s not required, and another designer doesn’t when it is, that’s inconsistency. More than anything, I felt we needed this common ground in the design team.
Design values
Humane Design principles are part of my values as a designer, and it’s important for me those values are shared in the team. I design especially for transparency and inclusion, with a deep respect for people’s time and attention instead of a disregard of it.
“We want technology to enhance our sense of agency without dictating the rhythm of our lives.”
At the end of the project, we had a functioning Design System ready to be used and further developed plus a new, better direction for theming and some pretty important open questions about (design) values.
These screens are from 2020 and Figma has made many updates since then, including Variables.
Today, I believe Design Systems should live as code instead of in a program that can get outdated overnight.
