Date: Apr. - Sep. 2017
Course: Capstone Project
Team: Nadia Shamsedin (me), Brenon Kalu, Megan Matsumoto, Veronica Hernandez
Roles: UX Researcher, Content Strategist & Writer
Tools: Omnigraffle, Axure RP, Adobe CSS
Background: Pegasus Solutions is a technology firm who develops a centralized platform for the hospitality industry. They produced the first platform for connecting hotel reservation systems with global distribution. Currently, Pegasus is undergoing a complete overhaul of their central reservations system (CRS) platform comprised of several different modules and asked our team to create an entirely new module to increase engagement within their system and foster communication between hotel employees.
Goal: Create a novel experience within Pegasus' current CRS in the form of a new module in which to improve internal communication and promote the fostering of relationships between hotel employees, and give them a competitive advantage in the marketplace by doing so.
Final Product: Watch a demonstration of our final prototype, the Relationship Module, below.
View the full process report written by me here
Goal: Understand the wants and needs of our specific users in the hospitality industry so we can begin to formulate potential features for this new module.
Approach: Background + market research, user interviews, user journeys, personas
The hospitality industry is unique in that it's a 24/7 business focused on customer service first-and-foremost. Because of the nature of the industry, our users' needs are unique and we need to fully understand how our technology can really help them. Invoking user empathy and practicing a multitude of qualitative research methods was extremely important in our case. We completed background research on various types of communication channels meant to share information such as blogs, forums, etc. to understand how they promote internal and external dialogues between hospitality professionals. We also did market research on current options on the market for communication between employees and their features. Most importantly, though, we conducted four interviews with various types of hospitality managers, our intended users, to gain insight into potential new features they would want in a new CRS module. Particularly, we asked several questions about their communication habits with fellow employees. We continuously iterated the personas and user journeys based on the user interviews.
For more in-depth looks at our process:
*Note: the above deliverables went through several rounds of iteration before the "final" version you see. Of course we can always add, change, or edit any part of our deliverables based on new information or feedback, but the "finalized" versions are the state the deliverables were in before we moved on to a new step in the process. Please let me know if you'd like to see any previous versions of the deliverables through the Google history feature.
The market and background research illuminated the fact that there is no all-encompassing product on the market to facilitate internal digital communication between hotel employees. The interviews with users was extremely beneficial for us to start formulating ideas about what types of features could be in this new module. We also found that our users were often switching between several different programs and communication channels to get the information they need in order to do their jobs. Some types of managers need to see social media and online travel agency analytics and reviews of their properties which requires either going to all those programs separately. Our new module could really help create a seamless process for our users to gather the information they need, and hopefully make their work lives a bit less hectic.
One particularly salient point emerged from the user interviews that we needed to consider: face-to-face communication is important in the hospitality industry. Hotel staff frequently use in-person meetings to discuss a range of topics. Thus, we should not try to replace face-to-face communication, but enhance the ways in which they asynchronously communicate. Hospitality employees currently send and receive a lot of their information via channels such as e-mails, bulletin boards, memos, etc. We found out a lot of information gets lost in transit if employees aren't always checking their e-mails or the bulletin boards. We need to find a way to streamline these channels of information so employees can go to one place and get the information they need in a timely manner.
Goal: Develop and work through intricacies of the potential new features and define the user experience, navigation, and interactions in the module.
Approach: Information architecture, use cases, user flows
Based on the user interviews, we brainstormed several potential new features of the Relationship Module, and eventually decided on three: an announcements section, a journal section, and a reputation section. We decided to put an emphasis on keeping communication at the forefront of the Relationship Module because communication between hospitality employees, communication between employees and guests, as well as employees relationships with themselves, is of utmost importance for our users. Good customer service is always their number one goal and good communication fosters that goal. The Announcements section is a place where managers can post announcement and events. The Journal is a place where users can keep a running log of any notes they need to take during the day with an embedded search function, which will allow them to recall their notes from any time period. The Reputation section will be an analytical tool for our users. This section will pull analytical data from social media channels, as well as online travel agents like TripAdvisor.com and Booking.com. From speaking with our users, they are constantly searching for guest feedback and reviews on these sites because good customer service is always of utmost importance to them. They need to know how guests are reviewing their property because those reviews can either bring new customers in or drive potential ones away. We learned from our users, as well as market research, that no other CRS platform can currently give them this type of data. They must use several different platforms throughout the day to gather these analytics. Thus, implementing a way in which our users could have most of, if not all, of the analytical information they need in one central location would greatly enhance their work day experience and save them a lot of time.
After defining the new sections and their features, we needed to go deeper and flesh out all the entire user experience and all the interactions. For information architecture, we created a site map that presented landing pages, navigation, features, and interactions of the Relationship Module. We also wrote out all the potential use cases of each feature of our the module for our users to help guide us in creating user flows. We had to get into the heads of our users to understand why they would be using our Relationship Module and what tasks they are hoping to accomplish. We then created user flows based on the site map and use cases to show, step-by-step, how our users would navigate through the module. The user journeys helped us think through each interaction completely and ensure we were not adding any unnecessary steps.
Going through the definition phase helped us immensely in figuring out interactions and editing our navigation scheme and various features. We spent a long time talking and thinking through the site map and how the various pages of the module would function. From our user interviews, we know our users are busy people who need to be able to get the information they need quickly. Thus, we wanted to design the Relationship Module to be as quick and simple to use as possible. No complications necessary.
*Note: see above note in Discover section
Goal: Put our concepts for the Relationship Module in action by exploring different design options and then refining based on feedback from our partners, as well as developing and iterating wireframes so we may begin user testing.
Approach: sketches, wireframe iterations
Because we had to define what the relationship module would ultimately be (at least in the first stage), we didn't begin to develop wireframes until we had a clear understanding, based on all of our research, of the sections and features we wanted to test first. Thus, we sketched our hearts out. Our team spent a lot of time sketching out various designs for the Relationship Module. All of our sketching helped us visualize potential UIs for each section of the module. Our sketches led to many long discussions about how we wanted our concepts and ideas for the module to look and act for our users in real time. For example, we struggled with how to present our Events section. Should we use a calendar view or a list view? Which would be easiest for users? Ultimately we decided that a combination of a calendar and a list view would be the best for our users. Sketching directly helped us come to this conclusion.
We also started doing some lo-fi wireframing in Axure RP (the program Pegasus uses) for a few different designs during our sketching phase to understand how they would look in actuality. These low-fi wireframes took the concepts from paper to what our users might potentially see in the module. The process of lo-fi wireframing is low time-commitment way to visualize our ideas.
We created various low-fi wireframe options for the Relationship Module to present to our stakeholders at Pegasus for feedback. We tried out different navigation, layout, and filtering options. We were in a constant cycle of feedback with our stakeholders and we were constantly iterating based on it. The feedback helped us refine our wireframes and hone in on a specific layout and features so we could start prototyping. After much discussion, we chose to utilize what we hoped was a simple, intuitive layout, which testing could either confirm or deny.
*Note: I cannot share the wireframes.
Goal: Test out our concepts and initial designs with actual users and iterate based on their feedback
Approach: prototyping, user testing
After fleshing out our wireframes to include all the screens we hopefully needed, we used the built-in prototyping features of Axure RP to create a clickable and interactive prototype. During our prototyping process, I wrote a testing plan and script that encompassed a way to test out each feature and interaction of our prototype, while also encouraging our users to think out loud during their sessions. Our sessions occurred over Google Hangouts since our users were spread out geographically and we recorded each session with their consent so we could always go back and re-watch. Our first prototype iteration contained the first iterations of our initial three sections: Announcements, Journal, and Reputation). Because the Relationship Module is a novel product, we learned a lot about our users and tried and tested out several different concepts with not all of them being successful. After our first round of testing, we learned that our version one prototype was conceptually confusing or disorienting to users, and we discussed how we can evolve the module to fit our users’ needs better. After discussions with our partner at Pegasus, we decided to remove any potentially confusing sections, such as the Journal and certain aspects of the announcements section.
After talking with users during testing, we came up with the concept of a Recognitions section in place of the Journal section. Without going into too much detail, we heard in our testing sessions how hospitality employees sometimes feel disconnected from their colleagues and we thought this could be a potential way to boost employee morale. The Recognitions section would be a place for employees to give each other accolades. We "gamified" the section in a way that encourages our users to actually go into Recognitions and engage with it. We tested the Recognitions section during our second round of testing and users responded positively to it, but our stakeholders decided to hold off going forward with it for a bit. Thus, we decided to create a minimum viable product (MVP) for version one of the Relationship Module. In doing so, we separated the Events portion from the Announcements section and now have a dedicated section to it.
For our last round of testing, we testing the MVP with the Announcements, now separate Events, and Reputation section.
We also included a post-test questionnaire to following the SUS scoring guidelines. I like employing the SUS survey after user testing because it is a simple and effective way for users to evaluate your system on a high-level and provides a quantifiable way to see how users view your system as you iterate upon it. From our first round of testing to our last round of testing, our SUS score improved by 25 points, indicating that our later designs were easier to understand and navigate. We had a time constraint in doing our user-testing, but we were able to complete 7 one-hour sessions, which gave us an immense amount of feedback and results to help us cultivate the Relationship Module to be the best it can hopefully be currently for our users.
Watch the prototype of the version one Relationship Module below:
From the beginning, the goal of our partners at Pegasus was to take the work we do for them on the Relationship Module and put it into production. Currently, the Relationship Module consists of an Announcements, Events, and Reputation section. These sections were regularly touted in user testing as the most useful. We removed a lot of aspects of the module to keep it simple and easy to use. First and foremost, we want the Relationship Module to be useful to our users. Pegasus wants to put the Relationship Module into production, and thus, the Relationship Module took the form of a minimum viable product (MVP) at the end. However, there is room for the Relationship Module to grow. Our partners at Pegasus will keep the other ideas and wireframes for sections such as Recognitions, as well as the idea of sharing industry-related articles amongst their peers, in their back pocket for potential future use.
We hope our Relationship Module design encourages communication in the workplace for our users, which in turn, creates a better overall work experience for everyone. We hope to add some value to the hospitality industry as a whole.