Building A Robust Design System
Working on defining a design system has been the most involved project. Documentation, requirements, design guidelines, and defining best practices single-handedly has been challenging, yet extremely fulfilling. Best learning grounds ever! I thought I'd share my experiences and my insights on what it takes to build a robust design system. So let's start at the very beginning.
How many of us know what these two words really mean? No really, what is a design system? I ask several designers and it's surprising that very few of them are able to comprehend what goes into building a good design system. Several companies are struggling to build and maintain a good design system. So why is that? Companies such as Google, Salesforce, IBM, GE, and many others have successfully build their own design systems. Yet, many of them (and from my conversations with designers from these organizations) state that it is difficult to sustain this due to many different challenges.
What is a Design System?
A good design system is a cohesive toolkit with a seamless user experience, that several teams can use to launch an application or end product. It is a framework that provides all the components (building blocks), tools and resources one needs to design, build, debug, and deploy attractive and feature-rich web applications. It helps all the teams to stay in-sync with minimal effort and resource allocation.
With the help of such a system, teams can build seamless workflows, applications, etc, and product elegant solutions that are fully functional and usable.
Now that we know what a good design system involves, what are the next steps to making this successful?
Buy-in First
What's a product, if you don't have consumers? What is a toolkit, if you don't have users?
Once you define what your design system must entail, the next logical step is to get buy-in from your users. Explaining it's core value is very important. Merely saying this is good won't work. Engage your users, demonstrate that it actually works, and how it benefits each of the teams involved. Get aggressive and invest in this process.
These are not just your clients. Your consumers are your designers, engineers and architects, other colleagues, technical writers, sales and research teams. Your stakeholders (assuming this is mostly business owners) will need to buy into the idea as well.
Getting buy-in is the most important step in the process. Unless you have 100% (or at least close to), it would be very difficult to enable adoption or even consideration. Conversion is key!
Foundation of Your Design System
Once you have advocated as to why teams must invest and adopt your design system, you will have to start building the foundation. Fine-tune how these building blocks would fit together. What do you need to define a good design toolkit?
Consistency is key! Defining a design language will only help in achieving consistency and continuity. A robust style guide is the next obvious step. Your puzzle pieces for a good styleguide are: Fluid Grids (remember Responsive Design!), Typography, Color, Icons and Documentation.
Design System Styleguide
Set Rules
Not too many, but set some rules. What this will do is relieve your teams of the burden of making their choices on elements such as typography (no folks, Comic Sans is not an option!), color, etc. Once your design team has established a good style guide, other teams can then focus on their actual skillset, and not have to worry about reinventing the wheel. Engineers can work on building logic and functional aspects of the system. Not only saves time, but also resources. Additionally, it also enables consistency and continuity, thus providing strong guidelines and best practices with outlines for do's and don'ts
Good Documentation
I cannot emphasize as to how important good documentation is. Decide on what tools your team would be using for documentation. I prefer Confluence Wiki. I have also used Google Docs, Trello, etc. I am not just talking about technical writers, but this involves writing product specs, requirements, and user experience specs that your engineers would be following. QA teams will also heavily rely on the docs once the product is in testing.
This isn't rocket science, and does not need too many bells and whistles. However, a good template may help kick start your documentation space. Define the key elements that other teams will need to read upon. Engineers will need a good prototype, however, they will also need functional specs, validation docs, requirements for edge cases, etc.
Your documentation can look something like this -
Component Name & Definition
Usage
Past User Pain Points (if there is a previous version of the product/feature/component)
Enhancements (if any)
Product Requirements
UX Specs + Mockups + Functional Prototypes (demos)
Engineering Specs (UX notes for engineers that'll help with implementation/customization)
Fewer Tools, More Productivity
Lastly, try to minimize the numbers of apps, or tools you would involve in the process of building your project. People do not have the time to log into different sites, or tools. Try to use tools that are compatible with one another. Track your project within the same suite of products. Create a seamless project plan that enables all the teams to maximize their time building the design components, and not figuring out the tools involved. Do some groundwork and save your team valuable time in actually getting work done!
Progress and Learning...
No process is perfect, and no progress is wasted! There is nothing that says one size fits all. My team and I have tried to switch our methodologies, adopt an iterative process, change course, and are still learning. The journey has been great! Helped me get out of my comfort zone, and try harder each time.