At first I started analysing the current library and got familiar with the projects using it. I talked to the designers and developers to better understand their particular needs. Common sense and best practices don't necessarily apply to enterprise software.
Improved color palette
The defined colors had shades for the brand color red and grey, but not for the other supporting colors. Also color contrast wasn't taken into consideration. The brand color is red, which is easily mistaken as an error state. I worked on an extended proposal of a color palette. It included shades for all colors, a WCAG compliant check, as well as the secondary color teal. [image color palette]
The first big challenge was setting up a token structure. At that point this was a hot topic in the design system community. Everybody knew this is way to go, yet little companies already implemented it. I did an inventory on the current library, looking for common patterns in color, size, typography and other areas.
This was a great start for a mapping exercise. Together with our competence leads for design and frontend, we did several workshops on taxonomy and naming. It resulted in a first set of core and semantic tokens. We decided to exclude component tokens for now in order to keep the work load feasible on our small team.
The json files are in sync for code and design. In Figma, we make use of the token studio plugin, importing the json files. Those again are in sync with figma variables. This is easier to apply for our designers than working with a plugin.
Component discovery fase
For each new component I started a discover phase. We knew the basic features and properties from the previous library. But who wouldn't profit of this great opportunity to rebuild from scratch, challenging and extending those ideas?
Usually this exploration started with a quick inventory of existing use cases and a competitor analysis. Based on this, I did a first proposal and set up an API meeting to sync early on with development. If you want tokens to be in sync, it is so crucial to align the Figma implementation with the implementation in code.
Parallel I worked on little UI improvements of the component. In our biweekly design sync meetings, I asked for input and opinions of the designers and presented the work-in-progress.
For more complex components I set up small user testings. This way I could check if the designers are comfortable working with them. I learned that most designers in our company found nested slots too challenging to manage.
All those prep work as well as handover and guidelines is collected in a dedicated figma file per component.
Component design and handover
Once all details are defined and decided, I could add the component to the figma library. As mentioned I try to mirror the properties as much as possible to the component API. Some figma limitations and user comfort make the exceptions.
Back in the lab file I added guidelines and handover for the developer. A special shout out for the gorgeous plugin EightShapes Specs which is such a time saver!
Our documentation site currently runs on backlight. It works with basic markup language, which makes it easy for me to add pages, write and update content. The documentation starts with a one liner of the component. Then it provides some best practices and content guidelines. I was also helping setting up the general structure of our documentation site. I added content to the general pages.
Advocacy, communication and PR
In my role as designer for the design system, I helped promoting the design system for the designers. The design team at KatoenNatie is still very small. Luckily all designers already understand the added value of a design system. Still it is important to keep them involved and informed. They all contacted me directly if they need support or want to report an improvement or bug of a component. An ideal scenario!
Our Design OPS manager was the main contact for PR and selling. I supported him in setting up a communication strategy and creating sales pitch presentations. I have also set up a Viva Engage Community to promote Hexagon and announce our biweekly releases.
Building while scaling
As mentioned earlier, our previous library was made for information heavy desktop applications. Our initial scope was to rebuild those components. Soon, new project teams approached us. They were keen to be early adopters of our new design system. But frankly those projects had a very different scope. Examples are Mobile applications for in field operators in the yards of Katoen Natie, touch screen kiosk applications, tablet applications for truckers, ….
All those applications need large click zones, big typography, simple interface designs. I did a lot of research how to tackle this in the most efficient way. This topic is so hugh that I will cover it in a separate article [published soon]. Spoiler alert: we created a large sizing theme, scaling our dimension and typography tokens with a factor x.
Results and pitfalls
Within a little more than a year's time we managed to release a solid version 1. This included rebuilding the entire old library. We added token support, enabling theming for light and dark. We even offer large size theming for automotive applications. The design library makes use of the latest figma releases. This includes nested component properties, booleans, variables synced with token studio, …). And the documentation site is a great way to find all information in one place.
Now Version 1 is released, we will face new challenges. How do we enhance growing adaption? How can we support migration of applications built with the old component library? We feel that there is still distrust in the choice of technology. And there is little support and believe from higher management.
A solid finance model is still a major discussion point. Probably this is an issue most design systems are facing. It is so hard to get funds building the system, but even harder getting funds for advocacy, support and sales. All the important bits and peaces of the iceberg below sea level. Future will tell us …Discover more projects
Nice to meet you!
I am Petra Sell, UX & UI designer working on Design Systems.
I am a freelancer helping clients on design systems and product design. Before that I was design director at two Belgian digital agencies and designer at various European companies. More on LinkedIn
I am into the smallest detail and passionate about usability, accessibility and aesthetics (in this order). I work systematically but also let me guide through my natural gut feeling for beauty and proportions. For me, design feeling is the most overlooked growth hack – it supports the users’ unconscious mental processing. This makes me a perfect counterpart for UX designers/thinkers in any design team.
What else you need to know
Although I've already spent half of my live in Belgium, I am a native German, including the famous deutsche Gründlichkeit.
If you think I can help you I’d love to hear from you.