Distributed Ownership
How to maximize acceptance & adoption of your design system
Most design systems teams are lean and the expectations placed upon them are disproportionately large. Does improve the quality of all of the company’s 70+ products sound familiar? When we first started our system, our conversation with leadership around ownership felt a bit like the Lion King:
Foundational elements and reusable components? Definitely. Quality principles? Accessibility? Of course. Brand in product? Yup, that too. Sound? Localization? Road Safety? Yup, yup and yup. A successful system’s adoption rate scales faster than the teams resources, resulting in ultimate power without the bandwidth or specialities to back it up.
For many companies, this can result in a bottleneck policing structure. If you want to ship, it has to be approved by the design system’s team. It makes designers and engineers using the system feel powerless and the design systems team the “bad guys” — even constraints they have no control over. An example scenario:
During office hours a feature team shows a screen where they’re using white text on top of a light green background. The design systems team explains that it is not accessible, but the feature team designer pushes back, not understanding why the design systems team created this rule… they can read it just fine.
When the design systems team is responsible for upholding too much, even government mandated requirements (like legal accessibility guidelines) get misinterpreted as being created and owned by them. So how do you flip the script? Distribution of ownership & quality. Redistribute that phenomenal cosmic power to those who specialize in it and instead have the design systems team focus on what they do best & proactively opening communication channels between teams.
Lyft’s confederated hierarchy of quality
At Lyft we’ve distributed ownership of quality down into a four tier model where the needs higher up in the hierarchy must be satisfied before individuals can attend to needs lower down.
Guidelines
General rules, principles, or requirements that the company has agreed comply with at large. Including, but not limited to, product design and brand principles, accessibility / WCAG requirements, localization and road safety design guidelines.
We found it best to separate the overarching guidelines from the design system and find or facilitate the creation of teams or task forces who can own or represent them. The design system team can then direct feature teams to these specialists when guidelines are questioned. Having a blind Quality Engineer or a legal VPAT specialist explain the importance of accessibility gains more empathy and acceptance of the requirements.
Additionally, the design systems team can facilitate conversations between these teams when two sets of guidelines collide. For example: Which guideline does a feature team follow when Android Auto says not to use more than 20 characters on a screen while driving, but localization best practices say to always wrap and never truncate text? By showing real examples in reusable components we can help all parties involved make the best decision.
It must be made clear by leadership that all tiers are required to follow the guidelines, including custom components. This is expectation being clearly set is the key to success of the entire model.
Design system
Foundational elements, components, guides and tools that can be reused across multiple products — mainly built and maintained by a design systems team.
The design systems team must make it clear in their communication and actions that the system’s ownership is shared by all of product. There should be clear avenues for platform and feature teams to review new work, offer feedback and contribute back to the system. When a reasonable adjustment to a system element occurs, the design systems team should encourage learning from the alteration (usually through testing) and update the element if it performs positively. Keep a growth mindset!
The design system is required to follow the guidelines. Product component libraries & custom components are required to follow the system’s attributes, like color, elevation and type. Tools, like linters, help designers and engineers more easily follow the mandatory requirements. Using the components and guides are highly encouraged, but not mandatory because they don’t cover every nuanced use case.
Product component libraries
Components that are only reused across one product — mainly built and maintained by a platform team.
Platform teams are responsible for the main flows within a product and should be key stakeholders and contributors to the Design System. They know the goals and the users of the single product better than the design systems team ever could, so their insight into if foundational elements or components will work for their use cases is incredibly valuable. The design systems team should give them the power to approve / disapprove of anything that affects those “golden paths.”
Similar to the design system’s team, the platform team must make it clear in their communication and actions that the component libraries’ ownership is shared by all of the feature teams working on that product.
Product component libraries adhere to guidelines & design system attributes. Components within these libraries can be up-leveled into the design system when they are reused by multiple products.
Custom components
Components created for use cases that require specific interactions not currently covered by the design system or product component libraries that are currently not reused — built and maintained by designers and engineers on feature teams. When designing and building custom components, we ask that feature teams keep in mind the additional cost and potential for the component to be reused in the future!
Custom components must adhere to the guidelines, design system attributes and product specific styles & requirements. They can be up-leveled into the product component library when they are reused within the same product or into the design system when they are reused by multiple products.
Last thoughts
One of the hardest parts of working on a design system is empowering others vs deterring them. By agreeing on and uphold constraints as large set of cross-functional partners, rather than having one “bad guy” or scapegoat team, everyone feels supported. Distributing ownership across teams and roles above and below the system increases acceptance because it’s collaborative rather than authoritative.
This four tier ownership model was created in partnership with many teams at Lyft. I’m Linzi Berry, currently product design manager on the Design Systems team. My hope in documenting system design thinking and process is to contribute and learn from the design community at large. Please subscribe!
