The problem

Through design system tokens, components designed for Expedia’s Unified Design System are skinned to support multiple brands and both web and native app platforms. Our process for creating components that work across brands and platforms involves an extensive internal and external audit, taxonomy and grouping of like subcomponents, explorations, component construction, and documentation for designer usage and developer handoff.

One of the more complex components I designed was our attributed content component, which had several varying use cases across our products and therefore detailed design requirements and variations were needed.

Back to top

The process

Audit

Going into this project, I knew there were already multiple use cases within the Expedia ecosystem which attributed content to an external customer or business. A colleague and I audited these use cases, noting similarities and differences in information architecture, typography relationships, and features.

We completed a similar audit of competitor and popular e-commerce sites to understand if there were any established trends and patterns that we should consider when creating this component.

We also dug into the details of a few specific micro-patterns such as feedback loops and translations that we wanted to also tackle as part of this project noting how the items themselves behaved upon interaction and pattern differences based on the overall page context.

Back to top

Scoping and defining

We knew, after completing the audits, that this project was going to be a huge undertaking, so we decided to scope down the project into a couple of phases. After a quick card-sort of all of the content, we grouped pieces of content into larger themes and numbered them in order of importance. First and foremost, we wanted to tackle the primary pieces of content that we knew were necessary across all use cases and go down the list one item at a time. Little did we know that with every additional piece of content, we’d have to re-evaluate every design decision we made prior.

Back to top

Naming, taxonomy, and grouping

First things first, we had to understand and articulate the job of the component. Ultimately this component is comprised of content that

• Is attributed to someone whether it be a person or brand

• Provides a level of trust that a [property, flight, activity, etc] meets my travel needs.

• Provides other points of view to help me make a decision.

Understanding the jobs that this component needed to fulfill helped us decide what this component would be called. We brainstormed quite a few options and listed pros and cons for each, trying to keep the name as generic as possible since this component spanned multiple use cases that served slightly different jobs. After many rounds of brainstorms, we finally settled on Attributed Content.

Back to top

Explorations

Starting with main content as we outlined in our scoping exercise we started by diverging, each of us exploring primary and secondary typography relationships in context of the 2 primary use cases, eliminating options that did not work for both and looking at our favorites in context of the page.

Once we found relationships within the main content, we moved to what we called Meta Data - content that describes more about the person of business that the content is attributed to. The addition of the meta data required us to go back and finesse our main content relationships to ensure that all pieces of the component worked together.

We continued to explore and iterate with every new piece of content we had identified, every time circling back and adjusting prior decisions with every addition.

Back to top

Component construction

After many weeks of explorations and reviews with the design system community, we were able to finally narrow in on an execution that incorporated all of our use cases and allowed for designers to choose variations that met their needs.

Based on the taxonomy that my colleague and I defined, we broke down Attributed Content into smaller, reusable sub-components that were able to be assembled to construct more complex parent components. These subcomponents can then be used by product designers as overrides when using Attributed Content in their designs.

Back to top

Documentation and handoff

After constructing the component, we had the arduous task of creating documentation that designers could reference when using Attributed Content and that developers could reference when building it.

The documentation shown below provides usage guidance in addition to available variations, best practices, accessibility considerations, and platform guidance.

Back to top

Iterating

After the initial component was created, another colleague needed to extend Attributed Content to include new features such as a summary of the main content’s sentiment and the ability to translate main content into different languages. I mentored her as she made these enhancements, working through the same process as described above.

With these additions, we also needed to take another look at the content groupings and found that with some major changes in component construction, we could make the component even easier to use with all of the many possible variations that designers could choose from.

The changes in component composition also meant some pretty big changes to the component’s taxonomy and documentation.

Back to top

The outcome

This component was the first one built using Shared UI which gives all progressive web apps to ability to share the same code, using sub-components from the design system to provide a level of consistency we’ve never seen before at Expedia. It also simplifies the code, since every PWA app no longer has to build the exact same bespoke experience.

Back to top