A guide to successfully navigating through all the challenges of building a design system
Building a mobile design system in tandem with a design project
Background
Back in January 2022 I was hired as a Design System, Research and Product Intern at Crux Intelligence. At the time when I joined I truly wasn’t aware of what it takes to build a design system for a company. But I had a basic understanding of how systems work and was eager to learn more. Fast forward six months we were successful in creating a design system which powers all devices and is intuitive for both developers and designers.
Process to follow:
Start with an app audit
To build a design system, you must be familiar with all the different features that make your app what it is today. That is when an app audit comes into play.
Start by taking screenshots of each screen in your app and critically examine them. One must click on all possible CTAs and explore all that can be done inside the app, capture it and arrange it in multiple flows.
Personally, this helped me understand all the different types of buttons, cards and other components that are used in the app. Additionally, it is a good opportunity to become acquainted with the already existing design system.
At crux, we did have one which had limited tokens and components but still, it was important to understand it.
Create a basic mind node
Because of the audit, you now know all the components that will be included in your design system.
To begin with, consider the first level of your mindnode and add branches that you believe will transform into individual pages in your DS project file.
Finalise the design system architecture
The design system should be tailored to your product, thus the architecture must be tailored to your needs and the number of products sourced from your DS. At crux, we had evaluated four key factors:
i. Blocks:
- This file serves as the foundation for all of the text, colour, and style tokens. It already existed, and we attempted to generate all component or context level tokens using only these selected styles.
- This guaranteed that we did not introduce a new colour for each new token, and that our library was constrained yet easily reusable in varied circumstances.
ii. Tokens:
- At crux, we used four types of tokens: text, colour, effects and grid, which were further divided depending on the context in which they were used.
- Apart from this, we built a mind node to assist us with token nomenclature.
iii. Components: Following that, we separated our mobile and web components into two independent files.
iv. Icons: Finally, we had a single file that had all of the icons in the appropriate sizes for both the web and app.
Create tokens and styles
If your token nomenclature mind node is correctly made, then this should be simple. Now you need to follow the mind node and name tokens accordingly. All the web token names can have the prefix $web added to them, whereas mobile ones can have $m. Remember that you do not need a new token for each component, if a component is likely to move in tandem with any UI element then you could very well use the $ui token.
At crux, there were specific components which were white labelled. Honestly, it requires a blog to explain this concept in depth, but to summarise, our clients can add primary colours of their product and specific components like headers, buttons etc in the crux app would change in colour. So for us, these components needed a distinct token which was called $web-app-header or whatever the component was.
Each token was now mapped to a style from the blocks file, thus we were using limited colours or styles just in a different context. And tomorrow if our product gets a revamp and we change the primary brand colour then we just need to update our blocks file and all the tokens, components and screens would be updated.
Pick up a product design project and make the newly designed screens your starting point
Design systems can be very complex and time-consuming to build if you don’t have a specific starting point. I was really glad that my lead designer Avi Agarwal told me to start working on the components of my own designs that I had created for a new feature that we were about to release. That became my starting point, I started with one screen at a time and covered all the components on that screen from top to bottom, transferring them to the DS while also replacing their instances in my design. This also ensured that the new project was sourcing components from the new System. Make sure to use the tokens you generated in the previous step when creating these new components.
A component is considered to be ready when it is perfectly resizable and has all the colour and text tokens in place.
As soon as you add a component to the file, create a branch for that component in the mind node. This allows the mind node to keep growing and you can also keep a track of all the components in the DS and where they are located. This will make sure that there is no node that does not exist in the DS. In the end, my mind node looked something like this 👇
Categorising components and creating variants
Let’s assume that the screen you have selected has a search field component. When you add it to the fields page in the DS add all the variants of that component and remember to complete it. This includes adding states that aren’t used in the project you’ve selected. Another point that Avi Agarwal often reminded me of was that variants can be created in multiple ways using different logics, we need to keep in mind that it should be intuitive to the designer who will be searching for it in their respective projects design file.
Documenting the Design System
Lastly, keep in mind that you will not be around forever and that someone will most likely replace you, as a result you need to document all the decisions you have taken. Also, mention how to use the component correctly. When I started using the design system while working on projects I realised a lot of things that needed to be communicated to anyone else who selects a component. For example, instructions on how to set the width of buttons in the resizing panel. Apart from these general rules, I also documented all the variants and expected scenarios where that component will be used. And when they are used in these scenarios other details like what spacing should be maintained by the developer or a designer.
Key learnings
If you manage to sail through all this then I can guarantee you will have no problem doing all the things mentioned below 👇
- Understanding and building a mindnode that servers your product.
- Creating resizable and reusable components and applying the correct logic while creating variants.
- Understanding how a designer will look for that component in the future and also the way developers will work with them.
That was it for this blog. I want to thank my mentor Avi Agarwal for teaching me all that I know today and for making me fall in love with design systems. And for always believing in me.
