7 Questions to ask after creating a design system
In the last five years, many companies have woken up to the importance of design systems and the usefulness of having a consistent UI language. Tools have evolved well to empower the creation of design pattern libraries. At Zeta, I have helped in building and maintaining two design systems and I feel it’s not a simple one — time investment that generates value over time. Once the components were built, and we started managing the system, many concerns crept into my mind which I will be sharing in this post.
1. Does a design system bias people to ‘think inside the box?’
We have a design system for a B2C mobile product and often when new features are discussed we tend to think ‘How can we make the UI with the components we have?’ Well, I don’t have an issue with the constraints introduced by the design system, but what I wonder is does having a design system in place affect our creativity? Does it passively prevent us from exploring possibilities outside the system?
2. Does every component on a screen need to be from a design system?
No matter how well-made a component is, we always reach a point in the project where we need modification to the existing component. In such cases can we detach a component, make custom changes and proceed? Or do we have to follow the long route of updating the component every time there is a new requirement?
3. What about delighters?
Design systems work best for products that are function heavy; the ones with forms and tables. When it comes to a consumer-facing product that needs user delights to add character to the app, design systems starts to crack.
Delighters by nature are anti-design system
Delighters delight because they stand out from monotonous UI. It’s like a good joke that breaks the pattern of obvious things. In terms of the Design System, it is an inconsistency. So, every time we introduce a fresh delighter, does it need to be included in the design system? Most likely, delighters are not repeated, so components may not be reused. Again, it’s like a joke, you tell it too many times, it becomes boring, it loses the surprise element.
4. How to update components in the design system and code?
Most of the times making screens can not wait for design systems to update. How do we handle those situations? Should we break components, use them in UI and inform the design system manager to update the component? If they update the component, then should we go back to our screen and replace the component we had made with the new one? If we update something in the design system, how will the update reflect in the code? When will the code base be updated by FE engineers?
5. Who will manage a design system?
Should everyone be taught to create and manage a design system? The pros of it are whenever there is a requirement of updating a component, designers don’t have to wait for design system managers to update. The con of it is, if people mess up, it will reflect everywhere. So, can you rely on everyone or do you need a special team for managing the design system alone?
6. What about the career of a design system managers?
Chances are you have a career path for product designers in your organisation but have you figured something out for your design system managers? Managing a design system requires a very different skill set from product design. We can not grade the performance of a DSM using a product design scale. They have very little interaction with the product that is being built and more interaction in resolving tickets and building UIs. How do we carve a path for a DSM? Is it only for entry-level designers or is there a scope to be Senior DSM, Lead, DSM, etc?
7. Once the system matures, what happens to the design system manager?
There might come a time when after going through enough changes the updates on a design system will slow down. Instead of 100 changes per day, it may be 1–4 changers in a month, in such a situation, will it make sense to have a dedicated team to manage the design system? If you are planning to dissolve, when will you dissolve? 10 changes per day? 1 change per day? 1 change per week? How do you make sure the DSM smoothly transitions to their next role?
Endnote
Design systems grow from a simple tool to a complex monster in no time. If your organisation is scaling, it’s important to think about these questions before it’s too late. A certain decision may involve multiple stakeholders, so, it is better to start these conversations early in your design team.
🙏 Thank you for reading.
👇 Links to all my work + Our Telegram group + Newsletter + Notes + Book Summaries + many more stuff
