Things I should’ve considered while making a design system
Its 2020 and almost every company out there is trying to make a design system for their product, for companies growing at the speed of light having a design system is inevitable. Catering to rapid changes and enhancements got me to make a design system for GuestHouser. Manifesting a design ecosystem is never easy, keeping all the teams on the same page is nearly impossible. Took us, a team of 25+ engineers and 13 months to get our design system up and running. Here I am sharing some of my insights and learning during this journey.
1. Selecting your tech/design stack precisely
Take time on selecting the right stack for your system. Not only designers but developers also need to have a hang of the product you intend to make. Its quite often to hear “we could’ve gone for that instead” in a team where the requirements are often not communicated clearly. Selecting a design tool that caters to your design system needs is the most primitive and important decision to make.
Having a plethora of tools out in the market, selecting the right tool should be Step 1. We used a combination of Sketch and Abstract to get our versioned system running.
Why Sketch? For a system, setting constraints and responsive layouts is inevitable. Focusing on multiple platforms for every design component, you need a tool that gives you the freedom to create scalable components. Even Figma is doing an incredible job helping designers stitch a system together.
Why Abstract? Team… you need a team as I said earlier, and for a team to work seamlessly you need a version controlling system. Only the Abstract has been able to solve the complete need. To read more in detail, I wrote an entire blog on this.
2. Designing while keeping all platforms in mind
One of the biggest mistakes we made whilst designing our system was not considering technical practicalities across multiple platforms. Common examples for this would be having soft shadows on cards, easily doable on iOS but very challenging when it comes to Android because of the material design guidelines.
Reading the documentation provided by different platforms should be a must for a designer before starting to design a system.
3. Knowing the use case
Engineers working on the system need to be clear if the system library has a set of protocols fixed or is the system completely open source. Protocols? What is a Protocol? Think of a modular phone by Apple, where each essential part(camera, sim slot, audio jack, speakers) of the device is a component. Either Apple can give customers the freedom to customize each component as they wish to or they can make a device that is fixed with these components. Each scenario has a different use case.
Three months down the line we realized we needed to make our system an open-source library and not rigid with fixed protocols, which took us 3 weeks of overhauling.
Putting it simply, decide whether to expose the system’s base classes or the derived classes(as extensions)
4. Nomenclature of the entire system
I still remember spending 2 full days just to name an API. We named our design system as “Garden”. Naming a component is an art, take time and choose something logically yet meaningful.
Make sure all your design tokens are shared between the platforms which you aim to code on. What are design tokens? Here is a link for your reference
5. Mind-mapping all your decisions
It’s quite often for designers to take decisions on the fly, make sure all your decisions are documented somewhere. We used XMind to keep all our brain dump. Even the smallest of the details should be documented to refer to later.
6. Having a sense of how code works
“Should a designer know how to code?” is the most debatable question on the internet right now, amid all the answers and discussions online. For me, the answer is simple… not syntax but semantics definitely. Making a design system has equal efforts of developers as it is of designers. Even if a designer is not technically sound, reading blogs and books online can really come in handy when developers talk about all the technical jargon.
Also, a lot of efforts can be saved on design-end if developers are looped in all discussions designers have.
7. Backing your decisions logically, ALWAYS!
I’ve quite often heard “design is just mere abstract implication, I’m sure you have no logical background to your decision” Well, as important it is to make a beautiful and functional design system, also have a logical explanation for your decision.
You should be able to answer questions like:
- “Why is the spacing in multiples of 8?”
- “Why are we not using jet black (#000) color?”
- “Why are the tappable icons 48x48 whilst normal ones as 24x24”
- “Why can we not use card color the same as the background color?”
- “Is it required to change the tracking of the font used?”
8. Treating your design system as a side project
Last but not least, never consider your system as a side project while running concurrently with several other projects. Designing a modular ecosystem requires full-time dedication.
Concluding everything, surely gonna be a tough time creating the system. Be ready for many ups-and-downs and maybe a lot overhauling… but in the end, it’ll all be worth it :D
