UX CASE STUDY

WiKi - Point of Sale System

Brief

A rise in restaurant industry led to managing the orders efficiently and give a hassle-free experience to it’s customers became much important. Managing all dine-in and online orders of a restaurant in a simple and efficient manner while maintaining the transparency of all the transactions was the biggest challenge. Second biggest challenge was to build this in such a way that, it should provide greater usability even to not highly educated employees/cashiers.

Hotel WiKi POS (Point of Sale) system was mainly designed for handling complete end-to-end order management, either offline or online. The design was kept Simple, hassle-free and up-to-the-point to use. While building this, we adopted a design-sprint approach to get to know what is currently being presented in a market, how it is being used, what features it provides and then progressed through full in-house design and development by keeping human-centered design approach. This system covered every restaurant ordering aspect ONLY IN 2 SCREENS with having different sections presented at a glance.

My role was to undertake early market research and to conduct client and stakeholder interviews prior to kick-off design sprints. Then, I followed the 5-stage Design Thinking process in a non-linear manner for carrying out the POS design.

Empathizing with users

In this phase, I’ve conducted the client interviews i.e. restaurant owners to gather information and helping my early market survey about what they’re currently using? How much efficiency it provides? What are the problems they’re facing with their existing systems? How much faster the Cashiers were able to use it? and so on.

While doing this, there are some of the important quotes the restaurant owners made that were considered as the severe pain points. Some of the quotes were,

“My manager need to educate a new cashier when appointed for using POS. And, that takes a lot of time as sometimes it would take more than 7 working days.”

“There are a lot of screens in POS and sometimes order gets misjudged and have to put a lot of orders on to hold when there’s a rush in a restaurant.”

“I’ve just lost a previous month’s data completely. I cannot track the transactions and I cannot blame my employees for that. I need the transparency in transactions.”

“It’s a huge task to modify or cancel any order through POS.”

“Once the system went offline so, we had to carry out the ordering completely on a paper.”

 

Empathy Maps

Based on the conducted interviews and the observations noted down, I’ve created empathy maps based on their behaviors of using existing systems, analyzing what the cashier/manager actually wants, what client wants and how it differs from what actually they did, thought and felt.

Defining Problems

By using Maslow’s basic hierarchy of needs, I’ve synthesized the user’s needs based on the empathy map created. This helped me to define the primary problem statement/design challenge.

The primary problems were,

  1. The system is not usable. It is useful to carrying out all the tasks, but not usable in a fast paced environment where customer is on the edge to get qualitative experience at the restaurants related to their orders.
  2. The order management and billing needs to be synchronized.
  3. There are a lot of screens on POS that confuses the new cashiers and has to undergo the training of at least 5+ days.
  4. Online Third-party orders are not well integrated due to some of the problems in their APIs.
  5. No transparency in cash flow when system is in offline mode.

By using this, I’ve also managed to synthesize relevant insights that are needed to solve the current problems.

Thus, I’ve created the POV (Point of View) templates to define the problems and relevant insights behind these problems.

Ideating a Solution

After analyzing all the possible problems and synthesizing them by using the POV madlibs, I’ve carried out the simple yet powerful user flows that actually helped me to define this complex system to understand better so that, I can provide solutions on the current complicated user flows.

Somewhat simplified User Flows:
user flows of CANCEL ORDER, Entering EXTRA MESSAGES from customers and JOIN TABLES
User flow of Main Menu screen
user flow of MODIFY ORDER and RESERVE TABLE
user flow of Restaurant Menu
user flow of Register and Login to POS
user flow of SPLIT ORDER and TABLE TRANSFER

Simple! Yet complicated… Isn’t it?

Hence, I went further considering the same somewhat simplified user flows to draw out the conclusions on the final user flow that helped me to solve some of the mentioned problems.

Final User Flow:
Final User flow for POS design

For carrying out the final user flow, I used the SCAMPER method in order to help innovate existing product, service and situations by putting out these 7 different lenses.

SCAMPER method applied on existing system:

S — Substitute

I substituted the number of screens that are actually not essential (for hold bill, cancel order, modify order, apply discount, select table, tax, payment and so on)and tried to integrate the operations on the same screen so that, the ordering, billing and customer management would be faster.

C — Combine

As I did substitution, obviously, I’ve combined multiple operations on one screen as there was a great real estate that can be used on a screen. I combined the above mentioned screens into different dialogs so that eah dialog represents the each operation.

A — Adapt

As, I’ve carried out the competitor’s analysis, I’ve adapted the status updates from Limetray’s System where they have actually displayed all the offline and online order status, table status in a beautifully and psychologically effective color formats.

M — Modify

I’ve modified the basic layout structure of the existing POS system mainly to increase the frequency of use and increase it’s speed. I’ve also added extra value to better mention any special note while performing any action by the cashier on POS. This extra note feature on every operation actually made a difference.

P — Put to another use

I’ve reused or put the current system of selecting tables for selecting the menu items and that worked perfectly. Simply, a user can touch on his/her tablet and touch PC to select the menu items directly from menu. I’ve also given the search option for searching any particular item.

E — Eliminate

As clearly mentioned, I eliminate the use of excessive number of screens that are simply not needed and not effective for the user.

R — Rearrange

I’ve rearranged all the operations into different sections on the same screen in order to make the system more simple and effective to use.

Wireframing & Prototyping

I’ve created initial sketches of the solution which was provided. I’ve considered the final user flow as a solution in order to make these wireframes. Then, I created the High-Fidelity wireframes in order to visualize the final system.

Even though the final flow is discussed in this project, there were multiple iterations of the low-fidelity wireframes in order to discuss and decide which would be the final solution working out for the user and the client. My team and I thought testing and editing the low-fidelity wireframes could actually result in “agile” method of working.

Thus, we wireframed and tested out a lot of iterations and then came up with the conclusion of the final ones. We used prototyping and validating the solutions together closely working with the development team in order to identify the best possible solutions and go ahead with the one.

Low-Fidelity Screens:

As per the final flow, I divided POS system into two main screens and different sections being shown on these screens and I’ve focused more on providing CTA dialogs for the internal functionalities. For this, I’ve used the IDF’s (Interaction Design Foundation’s) prototyping sketch templates.

Low-Fidelity wireframes at early stages
Wireframes - High-Fidelity:

1. Main Screens with Appropriate Sections

Two main screens — Home and Billing Screen with appropriate sections

2. All POS Related Actions

All relevant sections as dialogs on respective CTAs
Prototyping:

Click on the following link to access High-Fidelity Prototype,

Conclusion on this Case Study

Managing all dine-in and online orders of a restaurant in a simple and efficient manner while maintaining the transparency of all the transactions was the biggest challenge. Second biggest challenge was to build this in such a way that, it should provide greater usability even to not highly educated employees/cashiers. Thus, I’ve designed the Wiki POS system on basis of simple and effective user flows and carrying out complex tasks easily on the main screens without affecting user’s attention.

Although, I learnt that by giving too many options on such complicated systems may also confuse the user by driving his/her attention towards all the operations that are running on the system. Thus, I’ve reworked on the some parts of the system as, I gave different color schemes to different sections in the next iteration to avoid confusion in two different sections.

The five stage design thinking process was carried out and there were multiple iterations of wireframing and ideating happened in order to identify and finalize the best possible solution in Agile manner. The result of this was, our final design was successful. During a 3-week user testing, the cashiers were able to manage to learn the system quickly compared to the older ones and they reduced the number of days for learning by 60%. Our application is being developed and will be deployed in two big restaurants in Pune.

During this project, I worked on all the aspects of UX and UI design, while the development team constantly supported me and some of the user tests were actually carried out by the development team by meeting the cashiers in different restaurants. Big thanks to all of them!

Thank you for Reading!

Thank you for giving your time to read this. Much appreciated. Do leave any feedback you feel is necessary. There’s no End of Learning for me.