Building a new version of a tool for hoteliers from the UX point of view
I’d like to tell you about a case in which we set out to build a new (beta) version of a tool for people who work in hotel public relations. The hotels get most of their bookings from HolidayCheck and are located in Spain, Egypt, and Turkey. Our team is based in Poznań, Poland, which presented additional challenges — for example where to get the data from and how to get test participants.
Immersion
Projects based on rebuilding older tools are gratifying. We have a clear starting point: the current tool and the problems it causes. Naturally this inspires us to describe the tool architecture so we can understand its structure, features and potential. At this point we can already see the level of complexity, the hierarchy of elements, and those elements that are assigned incorrectly in the structure. Then, we added the business aim and everyday problems of our users. We got that data from customer service and other channels, such as emails from users or relationships between sales representatives and hotels. At this point - having gathered all this knowledge - it’s was easy to see how to solve these issues.
We obviously also looked at our competition and tried to understand the reasoning behind their solutions and whether they make sense in our context. We did online research to teach ourselves about the travel industry and its trends, but also looked into trends in building tools like that regardless of the industry.
Online questionnaire, contextual inquiry, and a persona
To my surprise, I realized that there are things I still don’t know. This, to me, is a vital part of the design process. I didn’t know, for example, what is important to people who travel using HolidayCheck. I also didn’t know if there was a way for me to conduct tests at my location — quickly and without traveling too far. All of that motivated me to create an online questionnaire. It asked people about the motivation behind their vacation plans and the features that they thought were most important when choosing a hotel.
The results were a great help for me when designing (“eighty-six percent of your users find this important, so fill it out”). I also got points of reference — like the fact that hotel employees rate most features as important or very important, because that’s how hotels raise their standards. However, when I asked the same question in a group of a thousand HolidayCheck users in Germany, they rated features as both very important (like cleanliness) and trivial (like shops in hotel). This served as a way to broaden my perspective. I could look at the product from the point of view our end users and their customers. This made the whole process highly interesting.
On top of that, I arranged a number of meetings in local hotels, where I conducted contextual inquiries with potential users. They gave me a sense of a person who manages a hotel, which then led to getting more mileage out of the Empathy Map and creating a data-driven persona. Thanks to all that, our user was well-defined, with a face and distinctive features. In turn, we could see our ideas through the eyes of the end user.
Designing and usability testing
This stage is when I get to use my expertise to its full extent. I attempt to solve problems I researched and the interfaces that causes them. This might be the most satisfying part of our profession — understanding how something should work in order to make it work well. Add graphic standards to that and you get a concept that’s compelling on multiple levels.
The implementation time was short, so we began testing on a living product. Our documentation was created in Sketch, InVision, and Zeplin.
The tests took place in one of main markets: Spain, in Majorca. I realized it’s a booming tourist destination, with the kind of tourist traffic you can’t experience in Poznań. This influences the number of daily tasks, time on task and the number of guests. We set out to test not only the interface and solution logic, but also the processes in the old tool that we felt weren’t user-friendly.
We gleaned many interesting conclusions from the tests. On the one hand, we found out that the tool is simple and intuitive and lets the users quickly locate the information they don’t know. I still remember the best sentence you can hear while testing: “this tool will make my everyday job easier.” Of course we also noted a number of improvements that were needed, but we also gained the knowledge on how people set out to use the tool. We saw their reaction to it and how they understood the processes of inputting and publishing data.
What comes after the beta?
That’s how we arrive at the first presentation of a product already available to hotel managers. What lies ahead? Plans to grow and add functionalities, which promises an exciting round of updates. We still meet with users at their hotels and show them new bits of the tool. We try to get a better understanding of their habits, expectations, and tasks. After a few months I’m satisfied that not only did we build a good tool that solves problems, but, above all, I also managed to get to know a group of users from a new industry. From personal perspective it was challenging to recognize the new type of users. Before this project I only had experience in e-commerce and e-learning. During the interviews and testing we conducted, I have learned how these users work, what they expect and what problems they have.