Defining the future of a new Recommendations API for Expedia Group.
Create a user-centered view of future use cases that Expedia Group Recommendation API can enable. Taking into account the priorities of multiple teams in the company.
Leading a cross-disciplinary design discovery and working with different stakeholders to develop a prioritised list of future capabilities.
A list of over 20 capabilities prioritised in order of importance to multiple teams in Expedia Group, design specifications for individual recommendation use cases and conceptual thinking relating to travel and recommendation experiences.
Recommendations API discovery
Expedia Group's platform team was hard at work developing a recommendations API that could service all Expedia Group brands, lines of business, and external partners. The team had an initial understanding of the use cases that would be enabled by this API, but they lacked a customer-centric view of future use cases.
This is where I came in to lead a cross-functional discovery. The challenge with this type of discovery was the large pool of people that had a stake in the recommendations API, as well as maintaining a balance between providing practical outputs and being overly prescriptive with the use cases.
To tackle this, I organised a stakeholder mapping workshop. The premise is simple: present a mapping similar to RASCI to the group and spend 10 minutes going through it, making any necessary changes. The collaborative aspect of the workshop allowed for constructive debate about who should or should not be involved, and resulted in a more streamlined core working group.
One of the first activities was to collect all of the previous qualitative and quantitative data on recommendations. With some help, I distilled the previous data we gathered into a series of insights. These insights, in addition to being a great resource for future workshops, also helped to raise awareness among some stakeholders that recommendations are not a silver bullet solution for creating a more personalised and relevant experience.
Following that, I planned two workshops to shape our discovery efforts. The goal of the first workshop was to share insights and to outline core pain points that we aim to address by introducing recommendations. The goal of the second workshop was to create a variety of recommendation experience concepts based on the core pain points identified in the prior workshop.
The concept of the first workshop was quite straightforward; the audience was divided into multiple teams and presented with our traveller journey map - a mapped out flow of different actions and stages travellers undertake when searching for accommodation. The team then began capturing the various pain points related with each stage of the journey in relation to the research and insights presented earlier.
Following a discussion with the core working group about the outcomes of the first workshop, we realised that having a number of user pain points will not be very actionable in the following workshop, so we decided to rewrite them as 'How might we' statements and prioritise a few based on the biggest opportunity and previous knowledge/insights.
This was followed by a second workshop in which the teams used the newly written 'How might we' statements to generate various recommendation experience concepts. The session was a success, resulting in a great number of unique concepts.
As previously mentioned, there was an underlying challenge with this type of discovery: the final output needed to strike a balance between generating actionable outputs and not being overly prescriptive with the use cases. However, the concepts created by the teams during the workshop were overly prescriptive, so we decided to break each concept down to the underlying technical capability and remove any duplicates along the way.
This resulted in a wide list of technical capabilities informed by known user insights, that were generic enough to be scaled out to multiple teams via the new recommendations API. All that remained was to prioritise these capabilities in order of importance to provide the platform team with a more actionable long-term view.
To achieve this, product managers from the core working group took the initiative and developed a unified prioritisation framework. This was then used to gather input from different stakeholders, and a shared list of prioritised capabilities was created using a normalised scoring approach.
With that, the project's discovery phase was completed, and the prioritised list of capabilities was handed over to the platform team. This type of discovery process, while effective, differed slightly from the more familiar double diamond process. As a result, some stakeholders were unclear how the output - a prioritised list of capabilities, can be used.
To demonstrate the power of these capabilities, I went through an exercise in which I mocked up a few use cases for the top prioritised capabilities. This has proven to be quite effective in communicating the concept of having one capability that can power several use cases, and that it is up to API consumers to define the details of each individual use case.
Recommendations on map
Following the discovery and capability exploration, I began working on one of the high priority capabilities we identified - similar nearby properties. After reviewing previous research and priorities among other teams, we determined that our map experience was a great starting point for this.
When comparing different lodging alternatives, especially their proximity to multiple POIs and the broader area, a map is a crucial tool for travellers. As a result, I had to keep a few things in mind: interaction patterns, model output, zoom levels, and availability edge cases.
When it came to the model output, our product manager and I had numerous discussions with the data science team to ensure that the output resulted in the experience we intended. The main topic of contention was whether the model should prioritise proximity of properties or similarity of properties. Working through several simulations of various models, we arrived at one that could provide the desired experience.
Following agreement on the model output, scoping various considerations, and multiple feedback cycles, it was time to define the specification for the development team. The feature is currently in the backlog of the team, awaiting development.
After working on recommendations for over a quarter, I took the opportunity to document some of my conceptual thinking about challenges with recommendations for travel companies. The main point I wanted to convey is that irrelevant or incorrect recommendations can impair the user experience, and the more complicated the criteria a user has, the more costly it is to get recommendations wrong.
To illustrate this, consider the following scenarios: searching for sponges on Amazon and searching for a hotel on Expedia. When it comes to sponges, the user's criteria may be relatively basic and easy to compromise on - low price and reasonable quality. When it comes to hotels, the criteria might be lengthy, with very specific needs such as budget, amenities, location, quality, and aesthetics. As a result, recommending a sponge that does not meet the user's criteria would not be as detrimental to their experience as recommending an irrelevant hotel option.
After some time has passed and recommendations API has started to mature, Expedia Group platform team reached out to me for some help to visualise a user centred way to consume their API. The current way of accessing it required developers and was quite manual and the ambition was to move to something that is more self serve. I had limited time on this but working closely with stakeholders and developers I mocked up a prototype for a recommendations API console and wrote up some handover notes, including a recommendation to conduct a usability study.
2021 © Benas Skripka