#user-centereddesign

As we talked with travellers and travel arrangers, we dug into their current processes and tools, and also gave the opportunity to offer feedback on some conceptual prototypes we’re working on. 

We have been working on a current-state service blueprint for the travel experience. While we know the overall steps to the processes of creating a travel request, booking and expensing travel, we are finding that we’re uncovering different tools and workflows as we talk with more people.

This is rewarding and drives home the value of ‘getting outside the building’ to look beyond what we think people are or should be doing, to observing what they’re really doing. Practically every travel arranger we spoke with could point us to their own departmental training or reference materials. In some cases, this was because they had specific departmental needs, but in many cases it was because they couldn’t find or weren’t aware of any official materials, so they made their own. 

Designing a service is much, much more than putting a product in place and telling people to use it. 

We gathered a lot of information from these interviews, and the product team gathered for a “What did we learn this week” synthesis session on Tuesday.

We identified topics that popped up across interviews, focusing primarily on areas that made the process time-consuming or error-prone. We used a unique sticky note colour for each interview so we could tell when issues applied to multiple participants, rather than just having one person who talked at length about an issue.

In case you’re wondering, yes we initially did this with hand-written sticky notes, though we brought them into MURAL so we could keep a digital copy to refer back to later. 

On Wednesday, we did another team exercise  - this time including more of the broader NextGEN Travel team. In this case, it was a design critique-style meeting where I had prepared three different samples of ways to communicate the current-state service blueprint, and the team asked questions and offered feedback. 

Mojgan, Maddy and George write questions and comments on sticky notes and post them next to three different displays of information. 

This session gave us the chance to talk through questions about the level of fidelity and detail of the blueprint. One was better at showing the magnitude of systems and touchpoints at a given stage, and the other was better at showing foreground/background and time aspects of the service. 

One of the participants said that he preferred the more content-rich design, and it took him seeing the other versions to understand why it appealed to him. Having multiple options to look at raised questions, and ultimately we decided to incorporate elements from several of the blueprints. 

I realized afterwards that I had unintentionally used three different tools to create them: one each using mural, figma and whimsical. They each had their own strengths in helping me create the visualizations. 

After a lot of synthesis, we were eager to get to work! Maddy and Mike met and created a prioritized backlog to continue to work on our estimator prototype, based on what we’d heard from our early testers. 

Maddy has also been flexing her “stakeholder management/relationship” skills as our product manager, meeting with representatives from other departments to formalize working more closely as we continue to iterate on product ideas.  As anyone who does UX Research knows, recruitment is a major painpoint, so having a group from a department commit to working with us will be a huge help as we roll into the last few months of our fellowship. 

Coming up with this blueprint is interesting, to see the current state, but we want to actually design solutions that can make a real difference in improving the experience. The best way for us to do that is to actually try something, to identify the strengths and weaknesses, and then try again. This is what will allow us to have confidence in what we present: that we’ve worked with users to understand their barriers, and received feedback in the solution we’re proposing.