In a perfect world, you would be 100% dedicated to working on the design system of your company. But in many startups, that is sometimes hard to achieve.
I struggled to balance pushing the next feature out and maintaining the design system until I had a real talk about the importance of it and the need for someone in the team to use a lot of their time to maintain it.
If you need help with that pitch, it could go something like this:
"Design systems are an essential tool for any product. A design system is a collection of reusable components, guidelines, and best practices that help maintain consistency and improve the efficiency of product design and development. With a centralized library of components, designers, and developers can quickly and easily create new products and features consistent with the overall design language and brand identity. This results in a better user experience, faster delivery times, and more streamlined collaboration between team members. The fast-paced nature of our company implies we often need to deliver fast, and having a design system in place will help us achieve that without compromising on the user experience. It will also let us add new members with less risk around consistency."
Having some numbers there would help a lot, so try to look for some of them in case you are asked about them. Now let's dive into some key steps and tips for this.
(1) Research
If you treat your design system as any other product, you are on the road to success (ok, that may be a bit of a stretch).
But really, do your research. If you are new to design systems, you can look for good practices and common issues you will face. It helps if you create a plan to understand the design system you should use.
Understand the product
You should identify your user base, your product's unique features and goals, and the design challenges you face.
Interviews
You need to sit down and talk with everyone. And I mean as many roles as you can. In startups, you won't get a month of research to do this, so you should try to win as much time as possible and then prioritize your interviews around it.
It would be best to talk with other designers, developers, POs, managers, marketing, and sales, as they could provide valuable insights and pains. You are looking for insights into how the processes within your organization work.
You need to understand what libraries designers are using or which ones they would need to do their work. You should know how developers translate designs and their decisions due to a lack of specs. Please understand how each role works and how they interact.
These roles include how new features are being rolled out and what pains you can find in those processes. What makes designers rework, how everyone interacts within the design files, how developers see current handoff, etc.
Audit
Another important thing to do here is a product audit. Having a good understanding of what the current state is will help you with a lot of things. You want to look for patterns, UI elements, styles, and behaviors. Try taking screenshots and documenting your findings. Do the audit that time allows you to do.
References
Look for inspiration and best practices from other startups, and consider the benefits and limitations of various design systems. You can start here.
(2) Scope and goals
The next step is to define the scope and goals of your design system. Ask yourself: what do you want to achieve with this system, and who will use it? And more importantly: ask the decision-makers.
Scope
I worked at a company with three products: a website, an app, and an internal tools portal. I tried to take the three of them in when planning for the design system. That was be the best approach since the system should accommodate all of them.
But when I presented my plan, I was told that it was too long and that we should start with the app. We started small, and then we incorporated the other two products.
This approach had some pains, but showing the value of the most important product at the time helped me when I asked for resources to improve the DS.
Goal
Defining your goal means understanding your organization's most important issues that a DS could help with. After your interviews and when you have your insights, you can run a workshop to create an importance matrix or any workshop that allows you to identify the most valuable solution.
Usually, we are talking about either efficiency, consistency, or user experience. For startups, efficiency and quick-to-market features are generally the case. So, your design system will probably need to be more flexible to accommodate that.
This is important because your main instinct may be to construct Polaris, Carbon, or any other big design system out there. But those are different kinds of design systems. Yours needs to allow for a lot of experimentation and not be constructive.
(3) Roadmap
Creating a roadmap is essential to ensure your design system's success. In utopia, you would have a product owner that helps you with this. If you are pushing for this yourself, you must be your own product owner and project manager.
The following will help you develop a successful roadmap:
Planning
Planning and understanding all the work you have to do.
Communication
Being transparent about the tasks that have to be done and having clear documentation on the progress.
Check-ins
You can check in with whoever will tackle this project with you or your manager.
Prioritization
Prioritization will help you identify key priorities for your success.
I also recommend that you work in 1 or 2-week sprints to reevaluate your priorities and progress at the end of those sprints.
(4) Documentation Guidelines
Effective documentation is critical for a successful design system. Establishing clear guidelines for documenting components, styles, behaviors, etc., including how to name them, describe their functionality, and provide usage examples (this last one may be too much to start with).
Make sure to create a centralized location for documentation and update it regularly to reflect changes in the design system. You can do this in many different ways and with various tools. I suggest that you sync with your developers and decide it together. Your design tool may be a good place to start, or you all decide to use notion or something more robust like Supernova, Zeroheight, and Storybook.
When you create these guidelines, remember your objective. Are you trying to hardcore consistency and behaviors across multiple pods and teams? Or are you trying to create guidelines allowing for fast iteration and feature development? You may only need a little of the documentation you see in other design systems (yet). So, try to understand the minimum you need to document to get your team where it needs to be.
(5) Naming Convention
Creating a naming convention is essential for consistency and easy identification of components. It will also save you and the devs a lot of time when making decisions. The truth here is that design tools and development have different naming needs.
To take advantage of your design tool features, you may need to use a specific naming that needs to be clarified for devs. I would suggest that you try to understand at what level you are. Both departments may have to compromise to land on a naming system accommodating all needs.
Do some research on design tokens. Trying to tackle this on your first run at the design system can lead you up an alley. I recommend aligning as much as you can on naming to start with some fast decisions when creating sentence cases and structuring categories.
But do not get frustrated if you create a solid system and realize midway that you should have taken everything into account. This does happen, and you need to accept that, make adjustments, and move on.
I'll add some articles here that I have taken as references in the past:
- Backlight - 'Naming conventions for design systems'
- Zeroheight - 'Naming conventions for your design system.'
- Invisionapp - 'Best practices for design system naming conventions.'
(6) Basic Set of styles and Components
Ok, if you did your audit, you should have a pretty good idea of the product's top components and styles.
(a) Start with styles
It would be best if you accounted for at least the following:
- Color - divide them by categories according to function.
- Typography - set a font scale that works for your product.
- Grids - create the structure for your elements
- Spacing system - you can never go wrong with a 4-point system
- Elevations - will help you with decisions.
I will only go into a little detail here. But the important thing is that you can set guidelines for your basic styles for the full product.
(b) Start with a basic set of components
The most used components. These will probably be inputs, buttons, icons, badges, modals, and those types of elements. You can check out this site to guide you through the process and ensure you are not missing variants or accessibility actions.
The goal is to get to the list of reusable components that will save time for your design team and devs. You DO NOT NEED A PERFECT LIST. Repeat it aloud because you will probably try to make the perfect button before launching it.
And you must create it, test it and get feedback. But it is also important to start putting those components out for your devs to build and for all of you to start seeing the real-world problems with how you work within the system.
Ensure your components are flexible and adaptable to different scenarios and use cases. Add more complex components over time as your design system evolves. But before adding, you must improve the workflow.
(7) Feedback and Governance process
Finally, establish a feedback process to ensure your design system is continuously improving. Encourage team members to provide feedback and suggestions regularly. Set up a regular meeting. Understand how designers feel more comfortable giving feedback and how developers receive it.
Please ensure you receive the feedback because adoption will suffer if they have problems and you don't know about them. So as you know, enforcing adoption is the wrong way to go. You need to provide a tool that helps them; for that, you need to understand their issues with what you put out there.
Some ideas you can explore:
- Comments directly in your design tool
- Comments in a repo shared with devs.
- Using a google form for feedback
- Documenting feedback in your roadmap
- Weekly sessions with different users.
The Takeaway
Starting a design system in a startup requires careful planning, research, and collaboration among team members. You need to understand your goal, and you need to approach it as a product. I love startups because you usually have a lot of room to propose processes and new approaches.
But it also comes at the cost of a fast-paced environment where doing a design system the "proper" way is difficult. I have found that the "proper" is not really a thing. Please understand what design system you can build and start from there. For that, you must do what you always need to: ask many questions.
It's tough to provide a lot of insights in one article. A lot of topics are best reserved for a specific piece. With this, I hope to have provided you with some insight into how to handle some of the main challenges of creating a DS in a startup.
