Sign up to follow
Sign up to save
Sign up to like
Sign up to respond
Sign up to follow
Sign up to follow
- Suggest a goal"{{search.query}}"
{{search_results.questions.label}}
-
Follow
{{search_results.people.label}}
-
A little context goes a long way...
-
Only you can see your suggestions
Diana Mounter
Design Operations Manager at GitHub
Design Ops & Design Systems Manager @ GitHub. Organizes Design Systems Coalition NYC meetup. I write and speak about design, code, and working with people.
7 action items
Get team members to adapt their workflows around a new design system and tooling
-
-
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
{{ answer_likes.includes(262) ? 9 : "8" }}{{ answer_favs.includes(262) ? "Saved" : "Save" }}Share -
Build the right team to create and maintain a design system
-
-
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_likes.includes(243) ? 6 : "5" }}{{ answer_favs.includes(243) ? "Saved" : "Save" }}Share -