The Rocketrip travel platform gives business travelers a precise estimate of what their trips should cost, and a real reason to spend less. Using historical and real-time market prices, as well as behavioral information and the company’s travel policies, Rocketrip gives travelers a precise amount of what their trips should cost. For every dollar they save, they keep ¢50. Companies save, employees earn rewards. Everyone wins.
Where We Started
I joined Rocketrip in May, 2016 as the start-up’s first Product Designer. The team was great, and the business interesting, challenging, and unique. My impression of the platform, however, was mixed. Lack of design was holding them back in a few important ways:
First, the product was not very intuitive. On both the micro and macro levels, users were too often confused about what they were supposed to do, when to do it, and where to find the information they needed. Customer Support was shouldering the work that a well-designed product should be capable of handling on its own.
Second, the product lacked a cohesive design system. Besides from the sloppy appearance, this often contributed to disorganized pages, as there wasn’t a principle governing when to use which font size, which color or which component.
Lastly, the product didn’t have a clearly defined “character.” There was a general whimsy to the existing design, but it clashed with the soul of the app: help business travelers make better decisions. Overly exaggerated corner bevels, large cartoonish icons, overly large and bold fonts, and a weak, inconsistently applied color palette seemed at odds with the purpose the product served and the users it hoped to attract.
Here are a few of the key pages, as they existed when I joined:
The project kicked off in July and my objectives were clear:
- Improve the existing flow to better guide users through the process, from booking a trip to redeeming rewards.
- Improve the information architecture of the pages, making it easier for users to find the information they needed.
- Create a scalable, logical design system that supported the IA and made creating new components, pages and designs a matter of applying principles.
- Create a new look and feel that better supported not just the existing product, but set the stage for the identity into which the company was growing.
Phase 1: Research
Over the course of three weeks, I sat down with nearly everyone. And I do mean EVERYONE. Executives, developers, salespeople, users, project managers, data analysts, travel administrators–everyone who contributed to, touched or managed the products. The goals were:
- Understand what the product was doing well.
- Understand where the product was falling short.
- Understand the relationship that people had with the company and the product.
This information was invaluable and proved to be the building blocks for project requirements and brand identity, and often led to suggestions that I talk to people I hadn’t previously considered.
Research can be tricky: it’s essential to separate what people think they want from the actual problem they were encountering. Over the course of these three weeks, I constantly reminded myself of one of my favorite UX-isms:
“People will say they want a waffle maker in their car, when what they really mean is that they want more time to eat breakfast.”
I also began looking at any examples I could find of travel, dashboard and analytic designs. I scoured google, dribbble and behance, looking at the different ways designers had attempted to solve some of the problems facing the product. I wound up with a large number of pinterest boards drawing examples from everything from banking to smart home to coffee.
Phase 2: Iterate
I believe in transparency when designing, but with this project it was especially important to achieve buy-in across a huge number of stakeholders. A thumbs down from any department could potentially sink the whole project. So how do you please a huge range of people? You turn them from deciders into contributors.
I set up meetings three times a week, inviting representatives from each department, making sure that an executive was present at each meeting to act as the ultimate decider. Each meeting was a live requirements-gathering and wireframing session. I would lead the discussion, record notes, sketch out ideas, then go back and refine the ideas to present at the next meeting. Gradually, through constant iteration, wireframes for the new design emerged. It was a process that worked very well–with one notable exception.
Try as we might, we were unable to arrive at a design or consensus on the Trip Details page. This was not surprising–it’s by far the most complicated and unique page in the application, needing to provide a huge amount of information, clarify a strange review process, provide trip itinerary information, motivate people to change their behavior, and provide itinerary information. There was no way to create something that complicated through live-wireframing. It was time to Sprint.
Phase 2a: Sprint!
I’ve led Design Sprints for a number of different products and organizations. Overall, I find them incredibly effective at solving thorny design problems when there’s proper organizational buy-in. Fortunately, with both the Head of Product and the V.P. of Operations onboard, the Rocketrip team was in a great place to run a Design Sprint.
Going in, we knew there were a few problems we needed to solve: the existing page was confusing and led, by far, to the most support calls. There were two main reasons for this. First, the existing page provided a ton of information about how your budget was generated, but very little about what you could expect next–it left users uncertain of how to proceed. Second, some of the information that was provided was only relevant to users during specific parts of the process.
The key to cracking this came when we were looking at some outside of the box examples, and I pulled up some check-out flows from Apple and Amazon. Suddenly, it became clear that rather than trying to jam everything into a single page, that we instead needed laser-focus on defining a clear flow so users understood where they were in the process and only providing essential information that was needed to get to the next step. In itself, it sounds simple, but the challenge was in agreeing what could be cut and what the different stages were.
Over the course of a week, a team of PMs, Developers, Designers, and Customer Support Reps heard from users, subject matter experts, and executives about the problems we needed to solve, iterated on multiple ideas, reached consensus on a best approach, built a prototype, then tested our idea with live users.
The prototype we tested proved that we were on to something. In testing with both power users and inexperienced users, the feedback was positive. However, it was clear that further tweaks were needed.
It was grueling, but incredibly rewarding five days. And while our prototype wasn’t a homerun, it did illuminate the changes we needed to make and provided alignment for the team about the way forward.
Phase 4: Branding
Following the Sprint (and a few days of clean-up), we had wireframes and specifications for every major page in the application. However, before I could start creating a Design Language, I needed to understand the identity of Rocketrip–not just who they were and how customers viewed them, but where they wanted and needed to go.
Fortunately, the research phase involved a lot of discussions about just this topic. I augmented my findings with a brand survey, which I sent out to many, many people:
With this information, I called the executive team together, walked them through the results, and quickly reached consensus on the direction we needed to go: professional, trustworthy, approachable (as opposed to friendly), and innovative. Based on all this, I worked through a series of moodboards to hone in on the correct tone, augmented with pinterest boards displaying individual aspects of the brand as I understood it.
Phase 5: Visual Design
Ultimately, the executive team decided to hold off on a comprehensive rebranding, which would have required much more time and work. The logo, the core font (Proxima Nova) and orange brand color would remain untouched for the time being. However, I was given the freedom to tweak elements to bring them inline with the new direction.
I worked from both ends at once–starting with small, individual elements (buttons, font styles, form elements, etc.) and immediately applying them to complete pages and artboards. The “molecule” work helped establish a repeatable design style, while the pages, allowed me to assess whether the some of the whole was appropriately capturing the decided on identity.
While there were many, many different iterations, these three snapshots capture the evolution through the process:
Iteration 1 made it clear that we needed to adjust our color palette, and move farther away from our existing brand. Photography was something new to the brand, and while we liked the idea of duotone, the initial versions conflicted with the look we were going for.
Iteration 2 was better, using images a bit more effectively, but ultimately lacked the attention to white space and feel of sophistication that was necessary. The icon usage was still too heavy, and while the photography use was better, it was serving as a distraction rather than supporting the trip information.
Here’s where we ultimately wound up. The addition of a second font, toning down many of the more dramatic colors, gradients and icon usage in previous versions finally led us to a design that we were happy with. It’s flexible, clean, professional yet approachable, and provides a great foundation for everything from Data Visualizations to emails.
Phase 6: Let’s Build!
As design had been winding down, the development team had been busy, moving the application from a legacy framework to the more modern React. This was essential, not only to improving performance but for supporting a true design system. With a single source of truth for each style and component, it was easy to apply designs across the platform.
As the team began implementing the design, we invariably discovered edge cases, components, and elements that hadn’t been considered. In addition to working on these, I also whipped up a number of “empty state” images to provide help and character when there was no information to display.
Wrapping Up: What did we learn? Where are we now? What comes next?
This was an intense project, spanning 6 months, from kick-off through build. And while we’re proud of what we’ve accomplished, we’ve only just started down the path of design maturity.
Over the course of the project, the team gained an appreciation for how the UX process can not only result in a great product, but help make everyone’s life a little easier. Going in, we discovered that each department had a slightly different perspective on who the company was, its priorities, and what challenges were facing it. This cross-discipline team not only allowed us to complete a successful project, but created alignment across the company.
On a personal level, this project tested virtually every skill in my toolbelt. Wrangling large project teams, pitching to executives, winning over developers, researching, wireframing, moodboarding, prototyping, usability testing, branding, visual design…there were lots of twists and turns on the path to success.
What’s next? Well, you might have noticed I left out mobile designs. It wasn’t accidental! Mobile design was part of the project, but still a ways out on the roadmap. We’ve got some exciting things for small screens coming in the future and I can’t let the cat out of the bag just yet.
The platform has come a long way in this short time, but it only represents a start. Rocketrip is still growing up, establishing itself, and branching out in new and exciting directions. Design has to grow along with the company; it’s a living, breathing entity, with many owners and stewards, supporting success and challenging people to up their game.