Product Design Component Contribution Process
Scaling Expedia’s design system to work for multiple products across multiple brands and platforms beyond foundational components requires contributions from the product design community. There is naturally tension that arises between a design system, where the process is focused on ensuring high quality, scalable, and cohesive components, and a product team, who is focused on improving a particular product’s features. Workflows are different, and when product teams are working on tight timelines, component contribution can be seen as a frustrating expense of time. However, as Nathan Curtis puts it, “A system team must know both its own workflow and be empathetic to the workflows and values of contributors too.” I created a product design contribution process to help unblock product teams while still ensuring quality contributions.
Results
Decreased component acceptance/rejection time from 2 weeks to 1 – 2 days
No custom component design or tech debt across all products and platforms
Software:
Team:
1 UX, 3 Engineers
Problem
Product feature work requires components that may not be available via the design system yet. This leads to bespoke design and custom code, resulting in inconsistencies in the experience across platform and lines of business.
Goal
Leverage Expedia’s Unified Design System (UDS) as a way to centralize design and code to reduce debt and keep ourselves accountable while also staying efficient in product work.
Process
States
I first outlined each possible state of component contribution in order to start understanding where contribution requirements may need to differ.
- Existing
Component already in system - Extending
Adding new features/variations to existing component - Modifying
Changing fundamental interaction or structure of component - New
Design system scenarios based on product needs
In addition to component states, we know based on past contributions that when doing product design feature work, teams have four potential paths.
-
- Component design and code implementation complete
Decision: Use components out of box - Component design complete but no code implementation
Decision: Use component in product feature designs, contribute code to library to achieve scale - No component design or code implementation, product team contributes to system
Decision: Contribute design and code to the library to achieve scale
We had no process in place to help teams identify when and how to contribute to system. This often results in design churn, slowing down tests and discouraging teams from prioritizing component contributions. - No component design or code implementation, product team works outside of system
Decision: Design lives outside of UDS library, custom local code – tech and design debt
Similar to 3, not having a process in place lead to significantly increased contribution time, and some teams began to forgo the design system altogether. Goal of creating process is to move away from this scenario.
- Component design and code implementation complete
Contribution process flow and experimental components
I created a decision tree to simplify the contribution process for product teams and illustrate who would be responsible for each decision as a team progresses in the workflow.
I introduced the concept of experimental components, pulling from IBM’s Carbon Design System.
As outlined in the process workflow, t
If the product team decides that gaps with existing components need to be addressed for this feature and test, a proposal will be put together to make a case for adding an extension or addition to the system.
At this point, the design system community, composed of the core system team and designers across all products, decide “is this a thing or not.” We’ll talk through different factors:
There are 3 resolutions to the discussion of the proposal:
Knowing that reducing design and tech debt is one of our UX and engineering teams’ primary goals, I worked closely with our platform design system engineers to create clear designer and developer documentation for how to build experimental components.
Trialing this process for a year, we found that the component workflow improved product and component design speed and efficiency, often saving product teams weeks of work. We are ultimately able to better meet our travelers’ needs by helping product teams focus contributions efforts.
Results:
- Decreased component acceptance/rejection time from 2 weeks to 1 – 2 days
- No custom component design or tech debt across all products and platforms