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
22 action items
Decide which design patterns to deprecate, which to support, and which to create
-
-
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_likes.includes(268) ? 11 : "10" }}{{ answer_favs.includes(268) ? "Saved" : "Save" }}Share -
Increase team member adoption of the design system
-
-
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.
{{ answer_likes.includes(252) ? 12 : "11" }}{{ answer_favs.includes(252) ? "Saved" : "Save" }}Share -
Roadmap the evolution of your design system
-
-
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.
{{ answer_likes.includes(236) ? 22 : "21" }}{{ answer_favs.includes(236) ? "Saved" : "Save" }}Share -
Define principles to start your design system
-
-
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
{{ answer_likes.includes(265) ? 12 : "11" }}{{ answer_favs.includes(265) ? "Saved" : "Save" }}Share -