Designing A Business Travel Assistant
This past Spring, for Pratt’s UX/UI Mobile Design Certificate Program, I was presented with a travel brand client who sought to be top of mind for the whole customer journey of business travel. As a team of one, I took this to mean that I had to design a mobile solution that made a business traveler’s experience as effective and efficient as possible.
Two major challenges had to be addressed:
- Research and define key components of the user’s journey that caused significant frustration.
- Design a simple solution that would address those pain points.
Phase One: Discovery
In order to empathize with the needs of business travelers, I knew that I needed to observe and study the environment as keenly as possible. This would help me make an informed decision. To this end, I did an interview and comparative analysis.
I began by writing a series of interview prompts and identifying colleagues that traveled for business purposes. I ultimately conducted four interviews across several diners and coffee shops in New York City.
From this, I learned that business travelers want to:
- Maximize their time spent on matters of career consequence;
- Avoid cognitive burdens that take away from billable work; and
- Evade the hassle of expense reports—one employee that I interviewed recounted in painful detail how he had to print pdfs of pdfs just to get reimbursed.
An Interview Conducted at Vanessa’s Dumplings
With the individual stories of hardship in mind, I turned my attention towards the wider framework of services and applications. Where were they falling short? Where were they excelling? I began to do comparative analyses in this vein.
I decided to do a competitive audit to see what gaps my potential competitors had with their products, and identify a differentiating factor. Those competitors were namely: TripIt, Abacus, DealRay, Loungebuddy, and Freebird.
This competitive audit revealed that companies in the business travel space, in general, emphasize getting business travelers where they need to go. However, none of them did so automatically in a way that was intuitively designed; and none of them addressed expense reports. The only ones that came close were Freebird and Abacus, but the former was not a mobile application, and the latter was not geared towards travel reimbursements per se.
To further pinpoint opportunities and avert foibles, I then conducted a heuristic evaluation of those competitors based on the 10 Usability Heuristics of User Experience Design. From there, I ranked each service from 1 to 5, with 5 being the highest quality—and averaged those scores so as to get a sense of their usability strengths at a glance.
TripIt — Itinerary Management, 4.2
Abacus —Reimbursement, 3.75
DealRay—Deal Finder, 3.5
Loungebuddy—Airport Lounge Finder, 2.3
Freebird—Flight Rebooking, 5
Phase Two: Definition
Next, I took steps to consolidate the data into a format that was easy to communicate with others.
Using the data compiled thus far, and in order to both concretize, and readily empathize with, the needs of the traveling business person; I defined a persona, which I dubbed Jakob Schmidt. I quickly found that it was much easier to communicate with others with a persona than with uncollated information.
To further concretize Jakob’s needs, I took insights from the interviews I conducted and documented Jakob’s user journey, and highlighted ‘how might we’ statements for each phase, to better empathize with his needs
How Might We Statements For User Journey
Each stage of Jakob’s journey could not be viewed in isolation, as each presented unique challenges and opportunities. To better convey what those might be, I formulated ‘How Might We Statements’ to each part of his journey, so as it inform the larger objectives of the app.
These individual how might we statements helped to both frame and develop what ultimately became the larger core problem statement—
Core Problem Statement: How might we minimize Jakob’s idle time, so that he can focus on matters of actual consequence in his career?
Phase Three: Development
With this information in place, and now knowing that the application had to minimize Jakob’s idle time, I proceeded into designing the product.
The first step of development was determining the product’s scope. An initially design lab was geared towards a one stop shop model. This proved to be a mistake, as early drafts were too broad and unfocused. Artifacts from this stage in the process had task flows for getting reimbursed and hailing a cab and tracking your flight and getting a hotel.
I improved upon the wireframes several times, as informed through user testing.
An initial usability test showed that the concept for the application was too broad. A feature, affectionately dubbed ‘Tinder for Hotels’, proved to be too confusing. And from this, I realized that I was thinking of the application as a tool—which meant that the user had to work and strain to do things. This exertion on the part of the user, however slight, would be the application’s undoing.
Instead, I concluded, the application had to be an assistant. It had to presents completed tasks and knowledge to the user. And the application could not aggregate just any old tasks. It was about creating a timeline of receipts to produce an itinerary.
From here, I redid the design with these newfound insights. At one point, I did AB testing with users regarding an ‘Add Item’ button. The first option had the add-item button in the lower-right corner as a large plus set within a circle. The second option had the add-item button in the upper right as a smaller plus. Users found that the large button on the bottom right was easy to understand, and so that was included in the final design.
Phase Four: Next Steps and Deliverables
Below is the InVision Prototype for Martin.
Next steps would involve further usability testing and improving upon the commenting system . The most recent round of usability testing demonstrated that the annotative commenting system for receipts was not intuitive. A more traditional commenting system in the form of a feed may be the superior alternative.
As a footnote: I opted for the name Martin for a couple of reasons: (1) It evokes the bird, the swift, which are quick, light, and aerial; (2) it adds gender equity to the assistant market with a masculine name, as opposed to a feminine ‘Alexa’ or ‘Siri’; (3) Mart implies commerce, and -in evokes inclusiveness like ‘LinkedIn’; and (4) With domain names broadening out, applications no longer have to give themselves an -ify treatment. For example, see “Paste” or “Paper” or “Cash App”, or how Alphabet, Google’s holding company, went with abc.xyz for their domain.
Make Your Apps Be Like Hedgehogs 🦔
There’s an analogy about how foxes have a very superficial knowledge of lots of things, whereas hedgehogs know only one thing through and through. My earlier concepts for the app were like a fox, in that they did a lot of things okay but nothing really well. The most contemporaneous iteration of the product does itinerary management for the purpose of receipts quite well, and not much else. This is to its benefit. The added features flow naturally from that principle of being a timeline produced by receipts.
Design Without Research Is Nothing 🔍
I had a vague idea for what a business travel app would do, but it wasn’t until I conducted interviews and did the comparative research that I began to understand both the function and form that my application would need to fulfill.
Micro-interactions Beget Delight 😃
While some elements in the prototype have foregone micro-interactions, such as the big (+) button on the itinerary screen, having pages slide from one to the other and having icons spring up to indicate, say, loading, absolutely heighten the quality of wireframes and can have, done right, a palpable effect on users for the better.
Record In Quiet Places 🤫
While using an iPhone’s Voice Memo feature is a great way to conduct interviews, doing that interview next to someone laughing loudly with their friends is not.