For people looking to understand what goes into building a design system and the value it creates. Learn best practices for identifying your needs, building support for the investment, launching your foundation, and evolving it as your product scales.
You may start with research on how effective design systems have been in the industry. But it is more important to research how it will impact your product. Show visuals. You can conduct both a visual and a user interface inventory. Use tools like CSS Stats to reveal where you can merge color, typography, and more. If you have 30 different button styles, show that, too. Be realistic with your plan. Don’t try to address everything in one go. Present what your focus areas will be, when you plan to complete them, and who needs to adopt them. You’ll want to acknowledge the engineering impact.... See more
Talk to everyone who will be using, building, or benefitting from the design system. Get insights from designers, developers, product managers, leadership, etc. If you have third-party customers or partners using the system, talk to them, too. Ask about pain points. What are they always trying to find (in the context of design and frontend resources)? Find out how people will measure the success of the system. From there, you can derive your design goals and principles. Use your design principles as an actionable tool. Have a reason for each that focuses on your customer experience. Agree on a stack ranking of these principles. Then, use that stack-ranking to drive your design decisions with confidence.... See more
It may seem obvious, but people have to see your work. Show progress early and often. Broadcast your changes and additions. Get a prototype up fast. This way, people can see the value right away.
Start with a small pilot that shows a significant impact. If you have many products, show that you can update a global element (like a header) on all the products. Show that it was fast and required low engineering effort. When executives see change happen fast and error-free, they’ll buy in.... See more
Just as with any sales pitch, it’s critical to speak directly with the decision maker. Don’t waste time convincing folks who can’t make the call. If there are gatekeepers before you reach the decider, convince them to get you a meeting with the decider. Be proactive, show passion, communicate, and most importantly, be positive.... See more
Before presenting to the decider, do your homework. Identify and capture inconsistencies in your product. Understand the struggles of the product teams. Collect quotes from designers, engineers, and product managers. Present the problem, not the solution. Be ready to answer questions like: How long will it take to build the design system? How much it will cost? Who will be involved? Who will benefit?... See more
For a design system to be successful, it must have a leader and that’s you. Show the decider that they can trust you to lead the new system. Convincing them may seem like a lot of work but it’s just the beginning. The rest will be harder but if you take ownership and lead it well, you’ll have a lot of help along the way.... See more
The thinking behind your designs can be a lot for one person to keep in their head. Add a few more designers and engineers into the mix and you're bound to start stepping on toes. Start small and work together on a shared understanding of what should go into a design system.... See more
Visual patterns are beginning to emerge in shapes and colors but the rules are held in individual minds and not shared. It's time to start documenting and validating the thinking that got you this far.
Each time a common user flow comes up it's solved in a unique way. This is common when a product expands the breadth of its functionality and/or when new members are added to a team. It's time to get the product team aligned on the best practices to bring consistency for users and save time on product development.... See more
You should define what is flexible and what is rigid in your system. For example, fonts and colors are probably very rigid. You want everyone to always use your brand fonts and colors so the product feels like your product. Component details are usually a bit more flexible. If you had a button that was a specific size and someone needs to change it to be a bit smaller to fit in a new flow, that's probably okay and can still feel on brand. Maybe someone is adding a screen to take photos and they UI should be dark instead of light so they need to customize a bunch of components so work in dark mode. That's also probably fine.... See more
Defining multiple styles for the same component is a good way to make things flexible. You could have a "primary" and "secondary" style for a button component. You could also have a "normal" and "compact" size of the component. You could also allow team members to create their own styles or sizes. Allowing designers to mix and match sizes and styles can open up a lot of combinations that all feel consistent.... See more
Nothing should be set in stone, everything can be adapted or changed. Being atomic is the key to flexible composability.
Abstract components from your product, prepare them for easy use in your design tool and let people emerge larger patterns and templates. Don't bind up designers with detailed guidelines, let them their freedom in how they use components in the context of a problem they need to solve. Start documenting the discovered patterns after your product or design system gets more complex, not before.... See more
Give your users the certainty that the design system can be changed. Don't be design police. When you say "no," provide reasons why – people understand when they see why past design decisions were made. Let people challenge anything and accept contributions – it will improve your design system for everyone. Listen to external voices and extend your design system pro-actively based on these ideas.... See more
More specific and complex components design system has, less flexibility it provides. Have high-quality atomic components that work together and are easily composable. Let people experiment and try new combinations and patterns. Be willing to replace older patterns when someone comes up with a new one.... See more
In a fast-paced environment, people tend to look for quick solutions – it may lead to using the design system automatically for everything, skipping the exploration phase. Solve this issue by introducing regular experiments. Working on a new feature? Encourage designers to create it without using your design system and synchronize it later – together.... See more
When working with multiple products, “selling” your design system inside the company and expect different teams to implement it and update it when necessary, might become impossible. Having a dedicated team to implement and update the design system in all your different products will become the obvious solution, allowing other teams to focus on their current tasks.... See more
Don't give yourself nor your team the trouble to imagine what components will be used throughout the different devices. Instead, be minimal and neat, and only design and keep the components that are already being used on the design. Also don’t be afraid to deprecate components that are not being used, or that are not reusable in different features.... See more
Though you should not collect garbage inside your design system, you should not try to reuse the same components awkwardly on different devices and products, just for the sake of minimalism. It’s important to respect the differences between your products and the devices on which they run, and create specific components that allow the product to be successful.... See more
You can use open source scripts that will measure the usage and reach of your design system throughout multiple products. That way you can not only know where each component is being used and how, but also have real metrics on how much time you’re saving for the company.... See more
Some companies have products that run with different development stacks. In that case, you have two options. Rewrite some of them so they all use the same stack, or create an “agnostic” design system, which will be used independently of the stack being used. I’m not saying the second option is worse, but the first one is better ;) (in long term).... See more
Many companies have designers and developers spread around different product teams. Make sure you do a periodic sync meeting, where you present the new components launched in the system, and also where they can show their work in progress, ask questions and give feedback on existing components. That way everybody can contribute on creating the design system and the engagement is always strong.... See more
Start with making a list of where your legacy code is hurting the user's experience (e.g. slow login experience). Then make a list of the pain points of working with the legacy code (e.g. spaghetti code that takes awhile to parse). Get the team involved in plotting each user or team pain point on a 2x2 grid to evaluate the cost vs impact of each. Ideally you've identified a few low cost high value issues to address, which is a great place to start. With a fast moving team it can be helpful to run this exercise on a regular basis to ensure you're addressing the most pertinent issues.... See more
Take some of the issues you identified in the step above and create a step by step plan to deprecate some of the legacy code that's holding you back. Take into account the product areas and people this change will affect. The best way to get buy in from team members and stakeholders to prioritize this work is to include them on this entire process.... See more
In a large legacy codebase, your fancy new design system code will have to coexist. Plan how the new things will interact with the old. Having the ability to rollout new things gradually instead of requiring a full rewrite will build confidence in the new system since it can prove itself as you rollout each new thing when it's ready instead of all at once at the end.... See more
Jumping into a project with a legacy codebase can feel like the wild west. Bringing some consistency to the existing stuff with automated tools can help make migrating easier in the future. Source code linters to enforce best practice will make life a lot easier as you start migrating things.... See more
As you roll out new components, it will make things easier down the road if you can set aside some extra time to remove the legacy one and replace them with the new ones. This will remove any ambiguity about which one to use for new features.... See more
Design systems, when implemented holistically, are how designers and engineers design and build the product – so defining principles for the design system is the same as defining principles for quality design at your company. Although the system upholds the principles, this usually means that they are created by and decided on by design leadership.... See more
If you are in charge of taking on defining principles, make sure you involve diverse stakeholders from core features and departments for your brainstorm. Three departments to make sure you include: Legal, Accessibility, and Global. They will tell you what standards you've already (or should) agreed to as a company (don't want to get sued for accessibility like Beyonce.)... See more
• Where does your company stand on accessibility? legibility? localization? • What edge cases (devices, users) do you care about and which ones are less important? What does failing gracefully mean to you? • Do you have an approach to speed and simplicity? How much education do your users need to use your product? How do you handle loading states? • How do you handle broken windows? Is your philosophy to move fast & break things or are you building something for the future and solving the root issue? • How do you approach testing of your designs and builds?... See more
It is easy to accidentally veer down the path of general good design education when trying to write principles. Principles should be a line in the sand where there isn't one currently, so if you write something and every designer at a variety of companies would agree to it, then it's probably just good design. "Clear hierarchy and balance of elements" is an example of good design education vs "Dependable: It works every time, for every person, and every edge case" is an example of a principle.... See more
If you build it, they will come. If you make it great, they’ll use it. As the creators of design systems, our customers are designers and engineers. Our job is to make a system that’s easy for them to understand and use. Put your customers first. Understand their needs. Make a product they love so they can do the same for their customers.... See more
To be trusted, your system must be the truth. There will always be variations of your product in code repos, design files, and production but the design system must serve as the source of truth. You must decide where your design system is best represented - a Figma library, documentation website, or code repo. Then, point everyone there. Communicate that as the only place to look.... See more
Designs systems should be a medium in which to create. Keep the system as flexible as possible. Give folks components and let them make. Patterns will begin to form. Capture and componentize the most repeated patterns but allow others to be created. Don’t control designers and engineers, empower them.... See more
Adopting and migrating a product to the system is a huge task for any team. To accomplish this with the least amount of thrash, we have to drive home the benefits a system provides and, arguably more important, how much we truly care about them and their user's needs.... See more
After teams are bought in and start using the system, piecemeal updates and additions can be overwhelming and make the system feel unstable. Creating a consistent, batched workflow and announcement process sets expectations and documents why we did what we did.... See more
We see ourselves as teachers, not the police. We create documentation as a resource and we present as if we were in front of a classroom. When reviewing work, we always ask questions around the decisions made and follow along the process to how they got there. We studying our designers, and their habits, in the same way that they look at their own users - to try to serve them better.... See more
Our product teams are closer to our users and innovate faster than us. We know that sometimes the the system won't cover all their edge cases. By approaching our system as a living document, it remains flexible enough to be open to new ideas, challenge what we've created, and pull in new paradigms as they are proven successful.... See more
Designers and engineers desire ownership of their work and that can be difficult when using a system they didn't create. By creating clear pathways to get involved, we can share ownership.
Direct messages distract and only provide the answer to one person. We have constructed communication avenues, with a 24 hour response time promise, to protect our valuable work time.
When there's a bug in part of the design system—either in a Sketch Library, engineering implementation, etc.—it can greatly impact the whole product. You should be responsive and fixing these issues as quickly as possible so your team can trust the design system.... See more
When starting a new project, always do a kickoff meeting. It can be something as small as adding an icon to a button that previously only supported text or a huge new multiscreen flow. The designers and engineers working on the project meeting together before engineering starts to answer questions and iron out final details will make implementation go much smoother.... See more
When you make a change to anything, it is important to track this in your task management system. Be sure to create a task for design to update their libraries and documentation as well as for engineering team to implement it on their platform. Being sure to create tasks for everything helps prevent things from getting list.... See more
Set aside time every month or so to audit all of the naming and features of everything in your system on each platform. Even if you are extremely diligent about keeping things in sync as you build it, it is very easy for things to start to drift away from consistency. Create tasks for each inconsistency for design and engineering and knock them out.... See more
Introducing a new design system and tooling often means changes to the design and development workflow for your teammates, even though you might know why your new design system is awesome, lots of folks don't like change and will be resistant to using it. Becoming the style guide police won't go down well, you need to help people see the benefits of the new design system. Explaining why you needed a new system will probably help—it might be obvious to you, but to others it could seem like an unnecessary change. Follow with how it improves the design and development workflow for people and any other problems it solves. Even if there aren't significant workflow benefits and the change is to reflect a re-brand, most people want the shiny new thing, so show them how it easy it is to get there. In most cases, showing rather then telling if more effective—live demos, screencasts and gifs, and shipping parts of your product using the new system, will all be better demonstrations of the new system than telling someone why it's great.... See more
There are many potential touch-points with your design system. Slack, documentation, code review, design critique, and on-boarding are all opportunities to promote and show people how to use a design system. An on-call duty rotation might help your team respond to requests for help more quickly, code review is an opportunity to teach people and link to documentation so they can help themselves in future. Take stock of the many ways people can come into contact with your design system, and get creative about how you can use those opportunities to help people learn.... See more
People learn in different ways—some folks like a bit more hand-holding, while others prefer to learn more autonomously. Documentation is important and will help reduce the number of questions you get, but no matter how good your docs are, there will also be lots of folks who just won't read it. Providing alternative opportunities to learn will help, this could be bookable pairing time, a regular open office hours that anyone can join, or a planned training session. For the self-learners, tutorials or getting started guides can be a great way to learn, and a sandbox environment that has your design system already installed will help people get a feel for the new system quickly. Design system parity in design tools is as important as making it available in code so that designers and developers can speak the same language—make sure you make it easy for folks to get the latest design components too! Often a combination of tactics works since people want different types of resources and help depending on the stage they're at. Prioritize the approaches that work best for you and your teammates. This might feel like a lot of work, but remember anything you do for your new design system will also be helpful for new hires on-boarding into your company.... See more
If possible, work with folks who can be your early adopters while you're building your new design system. They can help you test new patterns and give feedback as you develop your system. Early adopters who speak the language of your new design system, and have had input into how it was developed, will become champions of the new system. They can help other people learn how to use it, help increase it's adoption, and hopefully spread enthusiasm for using it. Ideally you want champions embedded over a cross-section of your organization to gain widespread adoption. Remember to thank and reward the people who have helped you develop your design system, it's likely better because of their feedback, and you want them to encourage others to work with you in future.... See more
When building a new team without hiring externally, look for people internally who are passionate about design systems, who take a systematic approach to design and development, and want to solve the problems that design systems solve rather than because it sounds fun (though it is fun for many!). Often you'll find there are designers and engineers already doing the types of work you need to do when working on design systems and they'll be excited to help make it happen.... See more
Whether you're hiring externally or looking for people internally, hopefully you've decided you need create a design system because you can see how it will solve certain problems you're experiencing. The focus of your design system might be to improve workflow efficiency, help you scale a brand to multiple applications, or to effectively launch a re-brand. Some companies start with focussing on their web product, some with native applications. Different types of problems require a different skill set, find people who best match the skills you need.... See more
Design systems live at the intersection of design and code, so in the early days it's really helpful if you have hybrid designers and engineers. Similar to start ups, when you start a new team, it's helpful if you have people who can wear many hats. A designer with strong CSS skills, even if you're working with other technologies, will be a valuable asset to helping you organize and develop the design patterns you need. Designers who have experience implementing their own designs in production and prototyping will likely already design in a modular way and work well with engineers. Having engineers who enjoy front-end, and have design sensibilities or a background in design, will help you develop your design system in a way that works for both engineers and designers. It doesn't have to stop there—engineers with performance or accessibility experience, designers with content or research skills, or illustrators who can prototype interactions—could all be part of your hybrid team. As your design system and company scales, bringing on people with more specialized roles will help your team do what they've already been doing better, and grow the area of needs your design system can support.... See more
A design system is an internal product. Like any product, it's good to start with understanding the real problems your company has that a system can solve, but also be open to the possibility that not every company needs a design system. Questions to ask: • Is your company in hyper growth? or at a size where not everyone can attend a review and agree on a solution? Are multiple designers trying to solve the same problem, unbeknownst to each other? • Is your code built in one offs? If you need to update the style of a button, do you need to hunt for every use and adjust it? • Do you designs and code meet a11y compliance? are they ready for localization? Do you have solutions for every state or edge case a component might encounter?... See more
Once you have your problems defined, you can create goals that have business impact. Some examples might be (based on the problems above): • Deliver consistency/coherency and predictability in our products • Reduce design and engineering time and debt • Raise the quality of our experiences for every person and every edge case... See more
Many design systems start as grass-roots efforts, but in order for them to gain traction beyond the designer and engineers who are already on board – leadership buy-in is a must. Prove the worth of a system with one portion of a system. I recommend messaging templates + guidelines or buttons and make sure to show off an audit that captures the current state vs the benefits of the proposal.... See more
Educate teams on how to use core elements and apply the principles to build their own. The biggest way we do this is through documentation. Additionally, lecture at all-hands and brown bags, teach classes, host office hours, and answer questions.... See more
Participate in the adoption and migration of current designs and code into the system. Promote the adoption of the system elements when teams create new features. Migrate features and flows that teams don't own (or don't plan to work on) into the system for them.... See more
This is what most people think of when they talk about design systems. Build & maintain flexible, foundational elements and components to your company's standards. Work with teams to prioritize which elements will have the greatest impact. Make sure they solve the root cause of the real need and work every single time, for every person, and every edge case.... See more
Start with a small amount and build over time as needed. We started with two designers focused on mobile, grew to two engineers (one Android, one iOS), and now have more engineers, illustrators, motion, web systems and tooling.
Build tools that help designers and engineers use your system is a fast and easy way. The easier it is to use the system, the more likely they are to do it.
Encourage designers and developers on external teams to contribute back to the system. Think about creating something to reward contributors, like an enamel pin or stickers.
• When first starting, make sure you have the basics covered. Every page needs a button, right? • As the system matures, align with product planning. If you see that a bunch of teams are going to be working on surveys, you could also plan to work on survey elements with them collaboratively. • Notice trends. If you see three designers working on something and all solving it a little differently, you can propose it becomes a pattern. • Lastly, helping those who are struggling. If a product designer is having a hard time getting an unsupported component approved, the system can step in and help them get it through the door.... See more
• If there is a bug in a system component, that is priority 0. System components are used everywhere and if they break, they break everywhere. Fix the bugs immediately! • Listen to your engineers. If you're fortunate, they will reach out with feature requests for one of the system patterns (because their designer changed it slightly.) Get to the root of why it was changed. Just cause they felt like it? Because they didn't know the rules of the pattern? Because of a legitimate use case? • Decide, as a team, if that new feature is worth supporting. You can do this by assessing if it still follows the goals of the pattern or breaks them. • Ask the team if they'd be willing to contribute their new feature back to the pattern or if it's something the system team should take on. Contributions are the best!... See more
Always keep an eye on which components are being used and which aren't – through code (easier) and design. • Is there still a need for the pattern, but the way it was originally solved didn't work? If so, try to look at how designers are solving it now and better understand the root of their problem. • Was the use case for this pattern deprecated as well? Kill it. :)... See more
Using the company’s business or financial goals is a very powerful tool for proving the value of a design system. Design systems offer some effective methods to optimize a design and engineering organization.
Without a design system, designers must re-create every (or most) elements in their designs. This is time consuming. By showing the amount of time that could be saved with a design system, you are able to prove the value in terms of hours given back to the organization.... See more
Engineers will often need the exact measurements of elements in a design. When no design system exists, they will need to re-ask these measurements every time. Additionally, other questions may frequently be repeated without a source of truth. Show how many hours would be saved if a design system existed.... See more
When new designers join, how long does it take for them to understand your design language? Show the value of a design system by explaining how much faster designers could be on boarded.
The impact of a design system reveals itself through communication. Do you have a regularly-scheduled design systems advisory board or office hour? Who comes to those? What questions are they asking? If you have a support intake system, what questions come up the most? Focus your time on the common problem areas that surface.... See more
Your principles and goals, derived from user research, should drive your metrics. Otherwise, you’re collecting information that can be arbitrary. If consistency is one of your principles, measure how many components you’ve merged. If you have efficiency as a principle, you can measure how fast it takes to roll out a feature. Note: it’s difficult to track time saved because most people will fill that time with more tasks.... See more