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.

  1. Existing
    Component already in system
  2. Extending
    Adding new features/variations to existing component
  3. Modifying
    Changing fundamental interaction or structure of component
  4. 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.

    1. Component design and code implementation complete
      Decision: Use components out of box
    2. Component design complete but no code implementation
      Decision: Use component in product feature designs, contribute code to library to achieve scale
    3. 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.
    4. 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.

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. Experimental components are components that have not yet been added to the system. They are flagged as experimental in the platform component libraries and design system tokens, and in the case of our Figma design library, they live in a separate project outside of the core UDS component library.

As outlined in the process workflow, the first decision a product team will make is whether or not existing components do the job the product team needs them to do for the purpose of the feature and the purpose of the test. 

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:

  • Do we see this pattern in the wild?
  • Do we have internal use cases for it or is there use for it beyond just this specific test?
  • Is an existing component doing the job of the proposed component?
  • Do we have components within the system that could work for the specific goals of this test?
  • What is the impact to the system if we added this proposal in?
    • Does it solve a problem that we see multiple teams trying to address?
    • Are we adding unnecessary complexity and fragmentation to the system?

There are 3 resolutions to the discussion of the proposal:

  1. Add to system now
  2. Will not be added (though may be reconsidered at a later date if we have different answers to the questions above)
  3. Experimental, if the community and the product team cannot come to a resolution to add to the system or not based on the answers to the above questions.

If experimental, we will gather learnings from user research and testing to help inform the decision on whether or not to add the component to the system. Product teams ultimately own these components and are responsible for either contributing them back to the system or removing them based on learnings. We will use experimental components as a pressure release valve, understanding that as the system scales, product needs will as well and the system may choose not to support each need every time.

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