Establishing a design discovery process

how can ux be involved earlier in the product life cyle?

Background

When I first started at Expedia UX was seen primarily as a production team that created designs based on already-decided product ideas. I believed we could add value sooner in the product lifecycle process and wanted to find a way to do that.

The challenge

Being involved in the beginning of a product life cycle meant dealing with ambiguous, undefined spaces. This THRILLED me, but many of the design team members were used to having a firm set of constraints and an established process to follow. I knew if I was going to find a way for us to be a participant in this space I would need to be able to establish some sort of “process” to help other designers feel comfortable in the space.

My process for establishing a process

1. Start with an existing design discovery process

2. Iterate on the process to make it work for Expedia

3. Start documenting the process when aspects of the process consistently show success

4. Onboard the rest of the UX team

My role

I was the swarm lead for my team, working most often with a content strategist and visual designer. I was the sole individual responsible for onboarding teams and am still know as the “swarm master” at work :)

Skills used

• Product strategy

• Project management

• Mentoring

Step 1. Start with an existing process

My manager passed along an article on The Double Diamond that inspired me to try out what we now all refer to as a “directional design swarm”. A swarm is an agile term meant to describe a group of people that work together and spend 80% of their sprint on a single project.  We defined a directional design swarm as a team that focuses 80% of their effort working with product through the first diamond of The Double Diamond. It is broken up into two phases- Discover and Define. The goal of a directional swarm is to establish a product strategy that gets product aligned on scope and tech capabilities, setting us up to transition the concept into executional “real” work that will get put on the site.

Step 2. Iterate on the process to make it work for Expedia

The first swarm we did took four weeks — double the time it was supposed to take. We tried and failed a lot but ultimately got to a place that product, UX, and engineering agreed was a good strategy for the product. We iterated on the process 3 more times, tweaking major things along the way such as: number of UX roles, how to incorporate product involvement, what artifacts to make, and what mini-milestones

Step 3. Start documenting the process

As we started to get the hang of this process, and more importantly as I started to see the process being effective, I started to document what was working. Documenting it in a google doc, I got constant feedback from swarm members, stakeholders, and my manager.

Step 4. Onboard the rest of the UX team

When I felt the documentation was in a good enough spot, I introduced the larger UX team to the idea of directional design swarms. I shared the documentation and started meeting with teams to onboard them. At the same time, I continued to lead swarms on my team and continued to iterate the process. As teams began performing their own, it was great to learn from them as well!

The directional design swarm process today

100% of the UX teams at Expedia have been onboarded to the swarm process, and use it in various capacities today when needed. I have even onboarded a few teams on other brands that live under the Expedia umbrella. We’ve found that directional swarms are most useful when a product team has a broad topic but no plan. For example, if product says “we want to invest in user generated content for SEO pages” with no other guidance, a directional swarm would be a great next step. Alternatively, a directional swarm is useful if a product team has a plan but it feels random and is not building towards something.

General swarm process

Week 1 (or the 1st half of the swarm): Discover

The goal of the first week is to rip open the problem space and collect as much information as you can that’s related to it. The first week is the most ambiguous but it’s important to keep diving into the problem with the overall goal being to have an understanding of the space.

In summary, the team should have a variety of informal findings that begin to paint a picture of what the strategy should/could be for the product. The team should be able to walk out the first week with the situation understood as well as an idea of the opportunities or challenges of current situation, to set up for week 2 where you figure out the solution and the story to tell.

Common tasks happening during this week might be:

• Review of any other background material from any source (industry, product owners, etc.)

• Talk to subject matter experts in the space to get an understanding of current state and where opportunities exist

• Take to stakeholders for fact finding meetings that may or may not be useful

• Spreadsheet creation of existing Expedia content

• Competitor audits on various components related to the swarm topic

• UX research conducted or exiting research gathered from research team.

  • If a research team member is not on the swarm team but new research will be needed, the sponsor should request research help prior to starting the swarm and ensure they can meet the schedule.

• Expedia site metrics or data useful to the swarm collected. The product owner(s) involved on this swarm should know who the analytics team members are, and should have made them aware UX may reach out. The product owner should also share any pre-existing metric artifacts that may be relevant in the project kickoff.

• Competitor design patterns used to solve user problems related to the swarm

Week 2 (or the 2nd half of the swarm): Define

With a perspective on the problem space and an idea of what Expedia’s best opportunity is, Week 2 is all about setting up a framework that designs can be based off on. Common tasks happening during this week might be:

• Creating a slide deck that concisely summarizes our discovery findings and sets up the direction we headed for the design work. Personally I tend to apply a Situation-Opportunity-Resolution framework to tell the story.  The goal of the last meeting is is to tell a story that sets up designs for stakeholders to understand the scope and capabilities necessary for our recommendations to work. Ultimate success it to get buy in and alignment.  

• Defining a few key user scenarios or use cases, and choosing one or two to focus on.

• Taking the identified use case/scenario to focus on and begin iterating our way through wireframing. Eventually we get to a set of visual comps and/or a prototype that illustrates our recommended approach to the identified user problems.

• Still focused on the single use case/scenario, we break out designs for short term and medium term and be ready to discuss pros/cons for each. We also want to incorporate the scope and capabilities necessary for these designs to work, to get alignment on the entire idea, not just the concept.

Directional Design Swarm Benefits

• This process can be scaled for big or small projects, and a strategy can be developed on average in 2 weeks

• This process can be used for a well scoped problem space, or a vague problem space

• It works on a variety of team sizes. I’ve successfully been on a 2 person, 3, person or 5 person swarm, as well as completed a few on my own (though not ideal!)

• There’s ability to involve product, engineering, and UX with defining the problem space and Expedia’s best opportunity

• There are always ways to make it your own - all the teams that use it today do things a little different - and that’s the point! No two swarms are exactly the same, so the process across teams shouldn’t be either.

Common artifacts

It’s common to come out of one of these swarms with:

• A story deck that offers a short term and medium term sets of solutions.

• UX perspective on next steps to generate a discussion with the larger team for alignment

• Content audit of Expedia and competitors

• Competitor design findings

• Reference concept designs/wires

• Concept Prototype

• UX Map or Scenario document w/ capabilities and scope specified

Business Impact

• In the first year

  • My team completed 8 swarms, 80% of which ended up being utilized on execution work.

  • 100% of Expedia UX teams were onboarded to the process

  • Myself and a coworker advocated and split off from our UX team to form a new team that focused entirely on design swarms that connect the entire Expedia ecosystem. In our first year we have completed 13 swarms, 11 of which have had at least 5 or more A/B tests launched based on the frameworks we established.