This project was a full-scale redesign of TripIt’s enterprise group travel arrangement solution. My contributions were preliminary research, high-level wireframes, prototypes, and validation testing. This was a cross-platform project; I was responsible for web and Android.

To give you an idea of the original, pre-redesign product, have a look at this:

Each pink box represents a web page (yep, there were 9 pages, not counting help documentation or account settings).

Preliminary Research
My research questions (defined jointly by me and the PM owner of this product) and abridged findings appear below:

• Who are (what is the internal organizational role of) people who arrange group travel using t4t?
  People who arrange travel using t4t tended to fall into two categories: small-to-medium business owners managing a traveling sales team (this accounted for about 1/4 of account holders), and executive assistants working at larger corporations responsible for team administrative tasks but ultimately reporting to a higher-up executive (roughly 3/4 of account holders).
• How does t4t fit into these users’ workflow?
  Business owners tended to be hands-off with t4t, using it mainly to view itineraries that employees had created, and occasionally looked at the “travel spend” page if they wanted a rough estimate of air or hotel expenses. Executive assistants tended to spend much more time in t4t — it was a significant chunk of their day, in fact — because most of them actively planned travel for employees as well as reported activity to their managers. These are the t4t power users.
  For both user groups, the most important feature (aside from the core use case of assigning one of your travelers a trip) was being able to quickly see who was in or out of the office that day, and in some cases, the next few days. Executive assistants who report to higher-ups at any time of day or night also needed to be able to see this information on a mobile device.
• Why do >70% of new users required phone support to get their account set up?
  The “onboarding checklist” did not adequately explain how to go about setting up a new t4t account, did not contain any clear calls to action, and most new users didn’t even notice it was there. The unnecessarily large number of pages and unconventional “add new user” flow led to customer support calls almost every time a new t4t account was created. During our onboarding test, users were confused by features that were available to them but non-functional until certain tasks were completed (e.g., adding managed travelers).
• Which existing features are most useful?
  “Who’s in/out of the office” was the most popular feature. For teams of fewer than four people (approx. 30% of teams), the calendar also ranked highly. This appeared to be because these features were the only way for someone to get a quick overview of the entire team’s activity.
• In general, which existing features could be more useful? (and in particular, is the “travel spend” page even worth keeping?)
  For teams of more than 5 people, the calendar was useless — the month-only view was unable to display more than 5 people’s trips on a single day. The ability to create groups is useful for larger teams, but the group management screen’s position in the hierarchy of pages is a common pain point. The difference between “planners” and “administrators” is not understood. The map is only useful for viewing travelers’ current locations, not where they will be tomorrow or the next day, so it largely goes ignored. The “travel spend” page is not particularly useful to executive assistants, but from time to time the executives they report to like to look at the page (again, for a rough estimate only).
• Which additional features would add value to t4t as a whole?
  Less is more: the most asked-for feature was fewer screens and more intuitive ways to accomplish tasks. Existing features were underutilized due to poor organization.

Methods I used for preliminary research included:

1. phone calls and contextual inquiry sessions with existing t4t users
2. 1:1 usability interviews with non-users who fell into the primary user group resulting from (1), mostly to address new user onboarding

Solutions
I began with the onboarding problem. The first step was to define a clear flow. Before a travel arranger can do anything else with t4t, they need to add travelers. Once they do that, they can start building trips (itineraries) for those users. Once travelers are assigned trips, there is content to display on the calendar. This is the core functionality most users require. Once they understand how to do this, creating groups of travelers (e.g., one for sales, one for marketing, etc) becomes advanced functionality. I illustrated this as a progress bar that gradually fills up as the new travel arranger completes these required steps:

This progress bar became the cornerstone for the new user onboarding flow, which tells the user exactly what they need to do, when they need to do it, and doesn’t distract them with additional functionality they can’t use yet. In these wireframes, the “travelers” module appears first, then when travelers are added, the progress bar advances and the “trips” module appears, and so on:

full onboarding experience

Of particular note is the calendar module, which is no longer a standard month view. By default, it shows the next seven days, starting with today. This serves the purpose of “who’s in/out of the office”, ensures all travelers are visible, and also allows the user to customize the date range to look further into the future (there are presets for day, week, and month view). Travelers can be sorted alphabetically or by who’s traveling in the selected range of time. The map view is tied to the calendar and will show travelers as a path over a range of time.

Separate group management pages have been done away with altogether. Travelers can be dragged into groups or trips directly from the main page. This drastically reduces the amount of time required to complete these basic tasks.

Travel Spend kept its own page and will later be folded into Concur Travel & Expense, a separate product.

Validation testing
Using this prototype (note: not the final version), I conducted 1:1 usability interviews with a four new and four existing users. Findings were extremely positive. The new users were able to set up their accounts without help right away. Existing users grasped the new structure quickly. Both users had difficulty discovering drag-and-drop, so in the final version, drag handles and a help overlay were made more prominent on the “travelers” blocks. I also added a context menu to the travelers blocks which allows them to be assigned to a trip or group, so people who prefer to click instead of drag are accommodated (not visible in this prototype).

I worked with a visual designer on the final version, and was later responsible for defining the development stages for this project and working with engineering to ensure a smooth rollout.