Project
ResDiary Plus
A hospitality in-service operation Android app
Summary
In-service mobile app for restaurants
Role
User research, prototyping, user testing, UI design
INTRODUCTION
OVERVIEW
Control your in-service operations
ResDiary’s restaurant booking system is responsible for placing millions of covers into thousands of restaurants every month. ResDiary Plus app is designed to give hospitality staff control over in-service operations in their venue. It allows restaurants to make and receive reservations, allocate tables, update meal statuses and view expected arrivals, among many other restaurant management features.
WHY AN ANDROID APP?
ResDiary wanted to expand to the Asian market where Android devices are far more popular than iOS.
ResDiary wanted to expand and establish in the Asian market, especially in China, Hong King, Singapore, where Android devices are really popular.
The iOS app - designed in 2016, struggled to scale alongside the growth of the company. Usability was challenged. Features competed for focus. App reliability and performance issues fast increased.
GOALS & CHALLENGES
FLEXIBLE AND EASY TO USE IN-SERVICE TOOL
With many features incoming and busy hospitality environments, our solution should be flexible, easy to use and easy to maintain.
Our users were mainly receptionists and serving stuff. Within a short period of time we would need to develop a product that they would use during their shifts in a busy environment to manage existing and upcoming bookings.
​
Our high level goals were to:
-
Make it fast and easy to use for everyone.
-
Give hospitality stuff more control during in-service operations.
-
Create a product that will meet needs and expectations of our new market.
ROLE
AS A PRODUCT DESIGNER I WAS INVOLVED DURING THE WHOLE PROCESS
I was involved during the whole process and collaborated with one other designer on the booking process. In addition, I worked alongside a Product Manager and 3 Mobile engineers. I never stopped working on the project even after we launched it. Stage 2 of the product was already planned with new features.
The app (MVP) launched globally on June 2020.
KICKOFF
MEETING WITH STAKEHOLDERS TO UNDERSTAND WHAT AND WHY
Stakeholders explained to us what we are trying to achieve
and why.
To bring everyone on the same page and unite over one common goal we had a meeting with stakeholders to understand what and why we are trying to achieve for the business and on what timeframe. Check their expectations regarding look and feel, functionality, and target audience.
BUILDING EMPATHY
USER INTERVIEWS, USABILITY TESTS ALONG WITH SALES AND SUPPORT INSIGHTS
Discover existing problems and understand our new market needs
Our support and sales teams were engaging daily with our users. They were recording complains, requirements, cancellation reasons and improvement suggestions. Everything was recorded in our product board which was a very useful tool to keep track of everything. Our team in Singapore also identified features that were missing and they were quite popular in the Asian market.
​
Conducted user interviews and usability testing with our existing customers and observed how they are using our product and performing key tasks such as "create a booking", "edit booking". The results gave us a more clear picture of their frustrations.
Users were confused with the bottom timeline.
Booking list too complicated.
Users were annoyed that the booking status was not visible at first glance.
Users had difficulties with the navigation. Too cluttered and no space for adding features.
Booking process was missing steps and UI not clear enough especially for warnings.
Users were annoyed when editing a booking, since they had to complete all the booking steps.
Existing edit process
DISCOVERY
USER EXPECTATIONS CHANGED OVERTIME
Discover existing problems and understand our new market needs
I was surprised by the issues we found but after some thinking, it became clearer that users expected the app to just work with minimal effort.
In-service tools was a key part of their business and their expectations had evolved. Hospitality stuff wanted to perform key tasks with the minimum required steps, wanted to get information about their venue at all times at a glance and consistency was important for their busy environment.
AGILE METHODS, JOBS TO BE DONE
Understand user's motivations and expectations
Working in an agile environment was not always possible to create empathy maps and personas due to time frames. We defined "Jobs to be done" to understand user's motivations and expectations when using our app.
DECONSTRUCT EXISTING APP
Inspect and understand existing design decisions
There was some thinking and research that went into the creation of the original solution. Our goal was to inspect the current design, try to understand how it works, and the intention behind each decision.
REVIEW EXISTING ANALYTICS
Using Firebase, we wanted to check the performance of our current design
We had the luxury to have an existing product, so we were able to check analytics from our current design performance and focus on key tasks.
​
One of the things we noticed was the heavy traffic and usage our table plan view was getting. Users preferred it compared to the grid view to perform and complete in-service tasks. For our MVP and because of our tight deadlines, we focused our efforts there.
HOW DO WE COMPARE WITH THE REST
Conducting competitor analysis
Our customers will have to choose between our product and its alternatives, and we had to analyse the experience they provide to customers. We looked for commonalities and similar flows. Defined what is considered a standard experience for our case and we had to understand where we stand.
REDESIGN
IMPROVED USER FLOWS, SKETCHES, WIREFRAMES
We started by making improvements on key tasks and flows such as the booking flow and edit booking flow since they were two of their main pain points and most used actions they had to perform.
​
For example, in our existing edit flow, the user could choose a field to edit such as date or promotions. With our existing flow the user was diverted to the original booking process and had to take all the steps to change a single field. In case there was an error (for example by changing the time, promotion was not available), users were not informed about it and they were saving the booking without their knowledge.
Existing edit process
Our users should be able to change directly the required field and apply the changes, but when there was an error/warning with the rest of the fields, to make them aware at the same time for any changes occurred.
Improved edit process
Edit panel sketch
Settings sketch
Booking panel sketch
Continued by creating wireframes and flows for our table plan view according to our research findings and observations
Table plan view
PROTOTYPE
& TESTING
PROTOTYPE FOR TESTING
(INVISION & MAZE)
We built it for users
We built RD Plus for our users. Release it without testing it makes no point at all. We created a prototype and tested it internally first. It was a constant loop. Receiving feedback, do the require changes, test again until we were happy with our final solution.
​
We used Maze to test it with our customers. Our users required to complete tasks such as change booking status, edit booking, create booking. Maze generated heat maps, duration to complete the task, duration on each screen which was really helpful to make our final changes before release.
​
At last we created a document with all the required specs and assets our engineers needed so they can start developing the product.
DESIGN LANGUAGE
MATERIAL GUIDELINES - DESIGN SYSTEM
We had to create a design library for Android products.
To maintain consistency and ensure efficient design to developers handover, I have created our Android design system according to Material guidelines and based on reusable components and their states, such as cards, list items, and controls. Every component can be rearranged and combined with others while maintaining design consistency and recognisable UI patterns for the user.
LEARNINGS
Faster development, easier life
The introduction of design system was a really helpful aspect. It needs a constant reference, particularly when operating within teams. We were working on different features at the same time, but due to our design system the end result was consistent and the engineers were able to develop it faster.
Never ends
Lesson learned. Existing products need constant maintenance. User needs
are evolving every day, your features might not cover their new needs.
Releasing a product doesn't mean you start working on it. You need to keep tracking everything for further improvements and better results overall. If you abandon it, your users will abandon you as well.