Overcoming Designer’s grief with a Design System
Or, things I wish I knew before building a design system
Experiencing 5 stages of grief as a Product Designer
Without having a structured design system in place, design process and implementation can go haywire. Before I talk about the process of creation and discovery of a Design System, let’s go through a scenario first.
You are either a single product designer in a start-up or you work with several designers in a large organization.
Stage 1: Denial
While designing for a new feature you realize that there are multiple shades or multiple colors for fonts used in the product. Primary buttons coexist with both rounded edges and sharp corners, and there are few different date pickers. As a novice and humble designer, you start creating mocks and add new elements which are suitable for the use case.
Stage 2: Anger
While design hand-off, UI developer informs you that creating a new date picker is quite complex and would be a lengthy implementation process. It would add more days to the sprint and delay the feature launch. After a few rounds of negotiation with product manager and UI Developer, you try to fine tune the existing date picker but you realize it’s not scalable for current feature enhancement.
Stage 3: Bargaining
Now you run back to the stakeholders and try to convince them that the existing date picker is not the correct solution for end users. After a few rounds of a friendly altercation, they agree to run an AB test using both versions of date pickers.
Stage 4:Depression
You are now feeling competent as you have shipped the product. Post-deployment, user research results show that users are happy with the new date picker you have created. But deep down you feel agitated about adding a few new colors to the library and a whole new date picker to the System.
Stage 5: Acceptance
Fast forward few months later…
You and your fellow teammates have decided to do a design audit to streamline the user experience and tackle inconsistency and lack of efficiency in the system.
As a result, you discover that
- you have over 100+ unique colors across. Most colors are very close to each other in hex value.
- Common styles, such as Buttons or Input boxes recreated with variations in the same style sheet.
- UX patterns are widely different across the site, leading to user confusion.
All of which result in
- Inconsistent product experience.
- Developers getting blocked frequently by design requirements.
- Wastage of enormous amount of time to resolve the same problem.
- Maintaining the library and finding components are equal to a nightmare.
- and most importantly, poor product decisions being made.
At this stage of acceptance, you realize the need for a “Design System”.
The need for design systems goes hand in hand with the need for scale, efficiency, and consistency in Design.
But How to Invest resources in a design system?
As designers, we know that the work we do has a large impact on growth. However, it can be challenging at times to explain the correlation between investing in a design system and Business Growth.
Design systems can help with scalability and consistency, which lead to massive capital saving for the business. But many organizations fail to provide the resources necessary to make the System successful.
Why?
Because Product Leadership generally feels immense pressure to launch new features. Building a design system seems like a course of slowing down the velocity on the product development process.
For a design system to truly deliver savings, scalability, efficiency, and consistency, it cannot take a back seat.
Getting the Design System built…
Initially, it will take considerable effort but if built properly a design system can save a lot of time in the future. Before you jump in to create a new System for your team you should keep a few things in mind…
A. One Size doesn’t fit all
Some of you might perceive design system as a one-time deal.
It’s not! It’s equal parts product and process.
Sometimes designers get influenced by existing design system and Component Library created by other organizations and try to replicate or use the same.
You should keep in mind that every project is different. Apps and websites all have a different critical user journey, a different suite of functionalities that require a different level of scope. Replacing everything with an external System can completely damage the product experience and increase design debt to an unthinkable volume.
For a start-up with a small team or a single product, a design system may be more overhead than its worth. Bringing its product to market fast may be more important than making the system scalable.
But if you and your team is managing multiple products within the same organization, you definitely need to create a way for teams to automate menial work so that they can focus on core problems.
B. Do an all-inclusive Design Audit
Before even thinking about how an individual component could work within the design system you need to understand the entire scope of the application. Look at every page, every state, every component — how are things implemented today? What’s consistent today, and what’s not?
Your design system should cover your application in its entirety, even those terrifyingly outdated legacy pages that nobody has touched in years. Schedule an hour daily, take screenshots of every page and follow up with developers to understand what is in use and what is not. While you need to understand every component in the application, it may not make sense to include everything in the design system. Unique components, for instance, that are unlikely to ever be reused are unnecessary for the system.
C. Start Small, Think Big
Once you start building you should start with what you need precisely.
If you want to generalize all the buttons try to remove the buttons which are used rarely and try to fit your primary, secondary or tertiary CTA for the same use case without interrupting the current product experience.
While you are at it, keep documenting the existing components and their real-life use. Documenting different UI concepts or patterns within your existing product will answer a lot of questions regarding the scope of your design system.
Build the elements you definitely need for the interface and try to keep the design debt under control. Once developers and designers within the org start using an earlier working version of the system you will have more clarity on the path needed to scale it up further and cut down unnecessary elements from it.
D. Documentation
During the initial stages, design systems are born in isolation. Getting people to adopt your design system is difficult. For some, the biggest challenge will be getting stakeholders to agree on design principles and how components should work.
Before defining the design principles talk to the stakeholders who might use the design system on a daily basis or use it for reference. Get everyone on board at the beginning, and collaborate with them throughout the process.
Having proper documentation will help everyone to make consistent decisions, quickly and efficiently. To improve the potential of the design system you need to do much more than defining component specs, include
- An actual working version of the component.
- Best practices for each element.
- Do’s and Don’ts
- “How to” Guide for both Product Designer and Developers.
Building a design system is a daunting task. It might be very ambiguous and scary at the beginning, but it is not different than building a new product. Just like building a new product start listening to the stakeholders. Run back and forth with their feedback and keep iterating until you solve the problems for the majority.
It’s better to start small and scale gradually from there with regular maintenance sessions. Partner with developers in the early stage and keep the momentum going.
In the next article, I will share the learnings from creating a component library and the need for it to manage a design system.
Thank you for reading. If you want to discuss more about design systems, please comment below or reach out to me on Linkedin.
