At TravelPerk, my role here is to build a world-class interface that helps to improve the business travel experience.
I wonder how many of you, upon reading that first sentence, have begun thinking of user interfaces, search controls, and the latest shiny shot that you saw on Dribbble? Imagining travelers searching for and booking their flights and accommodation. This is of course a part of the process which I am concerned with but is fractional when you consider the entire landscape and all of the touchpoints that make up a business trip.
In TravelPerk, our main users are Travel Managers (someone who books many trips for many travelers) and then you have the business traveler themselves. In our case, it is possible for both parties to search and book travel — adding to the complexity of the application and the experience which we need to design for as to have a truly world-class experience you need to consider how the interface should behave and react to each user’s needs. There is no one-size-fits-all here.
The more you scratch behind the layers of complexity, the more overwhelming the challenge can become. To take a step back to my first days at TravelPerk (a sunny, winter day in Barcelona) I recall one of the first things I did that week was to speak regularly with our Business Development Manager Juli.
By the time I had started at TravelPerk, Juli had already held many demos with prospective clients and had been on the phone with existing clients, understanding how they were using our tool. Her insight at this time was invaluable. I, of course, do other things in my first week, but I made a marked effort to get to know Juli, and more importantly, get to know the things that Juli knew. Unfortunately, there are many key roles out-with the sphere of design that can play a huge part in the design of your product that is often overlooked.
The younger me…
Stepping back, I can remember how the younger version of me would have started in this exact same role. I would have looked at the application, printed some screens, scribbled some comments, and then opened up Photoshop (yeah, that’s what I used to use back in the day). Straight away I would be knee-deep in the interface, thinking about what color to make the arrow on the navigation bar, how many pixels from the edge the logo should be, and how best to shuffle around the components of the page.
These details are of course very important as aesthetics plays a huge part in a user’s perception of usable products, they are just not what we should focus on initially. It has taken many years, but now I will instinctively pause and consider the holistic context before even considering design solutions. Rather than shuffling components around on the page, I will start by questioning their existence in the first place.
Planes, trains, and automobiles
Understanding the entire flow of a business trip was concreted through taking part in many customer demos, which allowed me to hear first-hand which tools and workflows business travelers and travel managers were using today. These demo sessions also became a pseudo-user test of our product as we would get instant feedback on a user’s reaction to a particular screen or interaction within the app — all invaluable insights when you are looking to improve on that experience.
Coupled with that, we also had the added benefit of hearing what pains our prospective clients were having. This has been a fundamental insight that has been shared and reflected on with our Chief Product Officer. When you start to hear the same concerns or similar needs for services or features, your roadmap moves from being best guesses at the road ahead to being a concrete view that the successful delivery of feature X and service Y will double the value of the product.
Understand the system
To reflect again on my younger self, another notable trait was the naivety of feasibility. Too often I would be wooed by beautiful interfaces I’d seen elsewhere on the internet. Other products and services had nailed a particular problem or created a delightful piece of UI. If it works for them, it can work for us I would think. I was young. Experience has since taught me that of course, you can draw inspiration from these sources, but each refactored concept should be grounded in reality. The moment you have a concept your next step should be to quickly (note the keyword quickly) test the feasibility with your Front End and Back End team. Usually, their facial reaction will be telling if this is possible or not.
You don’t want to sap the rest of your team’s time on a concept that may not work at the development stage. Here, you are merely doing a sanity check to see if your idea is a worthwhile venture. If not, or if it feels like the cost/benefit ratio seems to be too skewed to the former — it’s maybe one for the shelf. There’s another benefit to these ad hoc inquiries. Once you have planted the seed of an idea into the team’s head, they may now start to consider how that may impact other areas of the system, meaning no nasty surprises down the line.
Visualizing the experience
After a number of months into the role, I managed to pull together a holistic view of the typical lifecycle of a business trip from speaking with everyone in the company and with many of our customers and prospective clients. There are obviously many more factors at play when considering the impact of a product, but for the purposes of this visualization, I have focused on the touch points that we as a company can directly influence and improve for business travelers.
In creating the end-to-end flow of what a user’s interaction and touch-points with your product will be, it is all too easy to get excited by big gaps in the experience which could be filled with many new ideas. It is therefore usually best to balance the act of zooming out with some equal measure of zooming in, and focusing on a particular problem — then getting into the detail, looking into the microcopy and micro-interactions that are of equal importance to the end experience.
Once you have spoken with key individuals within the company to truly understand how your product works, and once you have a clear idea of what your current users need and what your prospective users want then you can pick up the pencil and start to think about the interface.
