Sign in / Sign up

Done
Thanks for the suggestion!

Sign up for Playbook. We’ll let you know when questions like yours get answered.

We'll never post to Twitter or Facebook without your permission.

Share

Cancel
Cancel

Join Playbook

Playbook gives the design community one place to share knowledge.

Created with Sketch.

We value your data

We only use social login to gather your name, email, and profile photo.
Cancel

Sign in

Playbook gives the design community one place to share knowledge.

Created with Sketch.

We value your data

We only use social login to gather your name, email, and profile photo.

Sign in / Sign up

Done
Sign up to follow

Sign up to follow this goal and get notified when others answer it.

We'll never post to Twitter or Facebook without your permission.

Sign in / Sign up

Done
Sign up to save

Sign up to save this answer.

We'll never post to Twitter or Facebook without your permission.

Sign in / Sign up

Done
Sign up to like

Sign up to like this action.

We'll never post to Twitter or Facebook without your permission.

Sign in / Sign up

Done
Sign up to respond

Sign up to respond to this answer.

We'll never post to Twitter or Facebook without your permission.

Sign in / Sign up

Done
Sign up to follow

Sign up to follow this person and get notified when they share answers.

We'll never post to Twitter or Facebook without your permission.

Sign in / Sign up

Done
Sign up to follow

Sign up to follow this collection

We'll never post to Twitter or Facebook without your permission.
Join
Collection

Build a Design System

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.

10 contributors

{{ expanded_navigation ? "Topics" : current_topic_title }}

Get buy-in

2 goals · 10 action items

Convince leadership to invest in a design system

2 contributors · 7 action items
  • Jina Anne

    • Have a plan

      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

    • Have a unified vision

      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

    • Show, don’t tell

      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.

    • Demonstrate early results

      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

      • See 1 more
    {{ answer_favs.includes(244) ? "Saved" : "Save" }}
  • Dustin Tanner

    • Find the Decider

      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

    • Come Prepared

      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

    • Take Ownership

      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

    {{ answer_favs.includes(242) ? "Saved" : "Save" }}

Know when it's time to start a design system

1 contributor · 3 action items
  • Elliot Dahl

    • When your team is scaling

      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

    • When patterns are emerging

      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.

    • When you've built the same thing... a few times

      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

    {{ answer_favs.includes(225) ? "Saved" : "Save" }}

Build the foundation

4 goals · 29 action items

Build your design system to be consistent, yet flexible

4 contributors · 13 action items
  • Andrew Coyle

      I wrote a guide on how to quickly create a design system. It provides the basic considerations to keep in mind. https://coyleandrew.medium.com/a-quick-guide-to-creating-a-design-system-7888e267171f

    • Conduct a design audit

      Taking inventory of your product’s UI illuminates inconsistencies and helps the team understand what currently exists.

    • Define basic design elements

      Design elements are the basic building blocks of a user interface.

    • Define design components

      Design components are functional pieces of a user interface.

    • Define views (screens, pages, compositions)

      Combine elements and components to create views.

    • Include design patterns

      Design patterns consist of common user flows and interactions.

    • Create documentation

      Define the best practices, guiding principles, and implementation examples.

    • https://www.figma.com/community/file/874766871676128442/Basic-Design

      I created a basic design system in Figma. Feel free to use it in your work.

      • See 4 more
    {{ answer_favs.includes(288) ? "Saved" : "Save" }}
  • Sam Soffes

    • Define what is flexible and what is rigid

      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

    • Provide ways to mix and match

      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

    {{ answer_favs.includes(237) ? "Saved" : "Save" }}
  • Jan Toman

      Nothing should be set in stone, everything can be adapted or changed. Being atomic is the key to flexible composability.

    • Don't rush design guidelines

      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

    • Encourage people to change things

      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

    • Be atomic for better flexibility

      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

    • Introduce regular experiments

      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

      • See 1 more
    {{ answer_favs.includes(279) ? "Saved" : "Save" }}

Deploy a new design standard to a multi-product platform

1 contributor · 6 action items
  • Cesar Zeppini

    • Have a dedicated implementation team.

      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

    • Be a curator, not a garbage collector…

      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

    • … BUT don’t be “cheap”, components are free.

      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

    • Measure the usage and reach of the design system.

      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

    • Agnostic or not. Your decision.

      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

    • Sync with designers and developers

      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

      • See 3 more
    {{ answer_favs.includes(282) ? "Saved" : "Save" }}

Address legacy code constraints when building a design system

2 contributors · 6 action items
  • Elliot Dahl

    • Understand your constraints

      Legacy code can be outdated technology, poorly implemented code, or both. For example, Javascript frameworks are all the rage but they change rapidly. Getting left behind on an old version of a framework can be limiting and expensive to remedy. Sit down with the engineers on your team to understand why your current implementation is limiting your ability to build a great design system. Alignment on the pain points is the key to making any progress on addressing legacy code constraints with your team.... See more

    • Evaluate the impact to the end user vs your team

      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

    • Create a deprecation plan

      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

    {{ answer_favs.includes(247) ? "Saved" : "Save" }}
  • Sam Soffes

    • Plan to coexist

      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

    • Start to enforce best practices

      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

    • Replace as you go

      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

    {{ answer_favs.includes(255) ? "Saved" : "Save" }}

Define principles to start your design system

1 contributor · 4 action items
  • Linzi Berry

    • Step back

      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

    • Involve the right people

      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

    • Things to consider

      • 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

    • Separate principles from good design

      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

      • See 1 more
    {{ answer_favs.includes(265) ? "Saved" : "Save" }}

Collaborate on the design system

4 goals · 20 action items

Increase team member adoption of the design system

3 contributors · 10 action items
  • Sam Soffes

    • Build trust

      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

    {{ answer_favs.includes(254) ? "Saved" : "Save" }}
  • Dustin Tanner

    • Make a great product

      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

    • Be the source of truth

      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

    • Create a medium

      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

    {{ answer_favs.includes(261) ? "Saved" : "Save" }}
  • Linzi Berry

    • Empathize with teams & their users

      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

    • Reassure stability

      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

    • Educate, don't enforce

      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

    • Be flexible

      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

    • Share ownership

      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.

    • Construct communication avenues

      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.

      • See 3 more
    {{ answer_favs.includes(252) ? "Saved" : "Save" }}

Keep design and engineering systems in sync

2 contributors · 3 action items
  • Sam Soffes

    • Always do a kickoff meeting

      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

    • Track changes for each team

      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

    • Do regular audits

      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

    {{ answer_favs.includes(256) ? "Saved" : "Save" }}

Get team members to adapt their workflows around a new design system and tooling

1 contributor · 4 action items
  • Diana Mounter

    • Incentivize change

      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

    • Use every opportunity as a learning opportunity

      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

    • Offer multiple options for learning

      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

    • Work with early adopters

      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

      • See 1 more
    {{ answer_favs.includes(262) ? "Saved" : "Save" }}

Build the right team to create and maintain a design system

1 contributor · 3 action items
  • Diana Mounter

    • Find people already doing the work

      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

    • Match skills with your companies needs

      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

    • Start with hybrids before expanding to specialized roles

      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

    {{ answer_favs.includes(243) ? "Saved" : "Save" }}

Evolve the design system

3 goals · 17 action items

Roadmap the evolution of your design system

1 contributor · 9 action items
  • Linzi Berry

    • Define the problem

      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

    • Set goals

      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

    • Get buy-in with a test project

      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

    • Support

      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

    • Adopt & Migrate

      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

    • Build the system

      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

    • Build a dedicated design & engineering team

      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

      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.

    • Accept contributions

      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.

      • See 6 more
    {{ answer_favs.includes(236) ? "Saved" : "Save" }}

Decide which design patterns to deprecate, which to support, and which to create

2 contributors · 3 action items
  • Linzi Berry

    • Create

      • 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

    • Maintain / Support

      • 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

    • Deprecate

      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

    {{ answer_favs.includes(268) ? "Saved" : "Save" }}

Measure the impact of a design system

2 contributors · 5 action items
  • Jina Anne

    • Track your communication.

      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

    • Start with your design principles and goals.

      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

    {{ answer_favs.includes(260) ? "Saved" : "Save" }}
  • Joshua Sortino

      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.

    • Calculate the amount of time designers spend creating elements from scratch and compare to how much time would be saved with a design system.

      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

    • Similarly, determine how much time engineers spend asking designers for specs and clarification.

      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

    • Track how long it takes to onboard a designer.

      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.

    {{ answer_favs.includes(207) ? "Saved" : "Save" }}