Point of Sales: Building a Local POS for Restaurants
Point of Sales: Building a Local POS for Restaurants
Point of Sales
Building a Local POS for Restaurants
Building a Local POS for Restaurants
Project overview
Project overview
Designer: Femisola Fatogun
Duration: 3 months
What I worked on
What I worked on
Design Direction
Product Direction
Web app · Mobile app · Responsive design
Prelude
Prelude
The brief sounded simple at first.
Build a Point of Sale system and checkout experience for restaurants and hotels.
But restaurant work is not simple. Orders move fast. Menus change. Staff switch roles. Payments happen in different ways. At the end of the day, business owners still need to know what was sold, who sold it, and how much money came in.
So I knew we could not just design screens.
We had to understand the business behind the counter.
My Role
My Role
I led the design across web and mobile, from early research and product thinking to high-priority screens, prototypes, and interactions.
I also had enough room to shape the direction of the product. That meant deciding what features were worth building, what needed to wait, and how the system could work for local restaurants while still being scalable.
The goal was not to copy a global POS product.
The goal was to build one that made sense for our market.
I led the design across web and mobile, from early research and product thinking to high-priority screens, prototypes, and interactions.
I also had enough room to shape the direction of the product. That meant deciding what features were worth building, what needed to wait, and how the system could work for local restaurants while still being scalable.
The goal was not to copy a global POS product.
The goal was to build one that made sense for our market.
Why We Needed to Look Closer
Why We Needed to Look Closer
At the beginning, there was no clear product direction. We had shared screens, stakeholder conversations, and a broad idea of what the product should do.
But that was not enough.
A POS system sits at the centre of a restaurant’s daily operations. If the product is slow, confusing, or too heavy, it does not just affect the user experience. It affects service, sales, and the customer waiting in front of the cashier.
So before going too far with design, I worked with the Product Manager to visit restaurants, ask questions, and observe how they worked.
We watched how orders were taken.
How orders moved from the counter to the kitchen or bar.
How menus were arranged.
How payments were collected.
How staff moved between tools during service.
That changed the direction of the product.
At the beginning, there was no clear product direction. We had shared screens, stakeholder conversations, and a broad idea of what the product should do.
But that was not enough.
A POS system sits at the centre of a restaurant’s daily operations. If the product is slow, confusing, or too heavy, it does not just affect the user experience. It affects service, sales, and the customer waiting in front of the cashier.
So before going too far with design, I worked with the Product Manager to visit restaurants, ask questions, and observe how they worked.
We watched how orders were taken.
How orders moved from the counter to the kitchen or bar.
How menus were arranged.
How payments were collected.
How staff moved between tools during service.
That changed the direction of the product.
What We Learned
What We Learned
The biggest lesson was simple.
Restaurants did not need more complexity. They needed speed, clarity, and control.
Some restaurants were already using tools like Lightspeed, but many of the advanced features were not part of their everyday work. What mattered most was the ability to:
Create menus easily.
Take orders quickly.
Collect payments without confusion.
Track sales at the end of the day.
Manage staff access.
See reports without digging too much.
I also reviewed products like Square, Zettle, and Lightspeed to understand how mature POS systems handled checkout, menus, reports, taxes, staff, and inventory.
That helped me to shape a product that was simple enough for daily use, but strong enough to support growing businesses.
Research helped us move from “build a POS” to “build the right POS for how local restaurants actually work.”
The biggest lesson was simple.
Restaurants did not need more complexity. They needed speed, clarity, and control.
Some restaurants were already using tools like Lightspeed, but many of the advanced features were not part of their everyday work. What mattered most was the ability to:
Create menus easily.
Take orders quickly.
Collect payments without confusion.
Track sales at the end of the day.
Manage staff access.
See reports without digging too much.
I also reviewed products like Square, Zettle, and Lightspeed to understand how mature POS systems handled checkout, menus, reports, taxes, staff, and inventory.
That helped me to shape a product that was simple enough for daily use, but strong enough to support growing businesses.
Research helped us move from “build a POS” to “build the right POS for how local restaurants actually work.”
Designing the System
Designing the System
Because the product had many moving parts, I started with low and mid-fidelity screens.
This helped us think through the structure before investing too much time in polished UI. For a system like this, the hard part was not making it look good. The hard part was making sure the flow made sense.
The product had to work across web and mobile. It also had to support different restaurant setups, from small businesses to larger operations.
The design focused on a few key areas.
Because the product had many moving parts, I started with low and mid-fidelity screens.
This helped us think through the structure before investing too much time in polished UI. For a system like this, the hard part was not making it look good. The hard part was making sure the flow made sense.
The product had to work across web and mobile. It also had to support different restaurant setups, from small businesses to larger operations.
The design focused on a few key areas.
Menu Creation
Menu Creation
Menus had to be easy to build and update. Restaurants needed to add items, group them properly, set prices, and customise how items appeared during checkout.
Menus had to be easy to build and update. Restaurants needed to add items, group them properly, set prices, and customise how items appeared during checkout.
Checkout
Checkout
Checkout had to be fast.
From our observations, this was one of the most important moments in the product. Staff needed to take orders, make changes, apply taxes or VAT where needed, and complete payment without too many competing actions on the screen.
The goal was to reduce hesitation.
Checkout had to be fast.
From our observations, this was one of the most important moments in the product. Staff needed to take orders, make changes, apply taxes or VAT where needed, and complete payment without too many competing actions on the screen.
The goal was to reduce hesitation.
Reports and Staff Management
Reports and Staff Management
Restaurant owners needed visibility after service.
Reports helped them understand sales performance, while staff management gave them control over who could access different parts of the system.
This was important because the product was not only for cashiers. It also had to work for managers and business owners.
Restaurant owners needed visibility after service.
Reports helped them understand sales performance, while staff management gave them control over who could access different parts of the system.
This was important because the product was not only for cashiers. It also had to work for managers and business owners.
What Changed After Launch
What Changed After Launch
After launch, the product started showing strong early results.
Time to value reduced by 80%.
Average goal conversion increased by 40%.
Customer Effort Score reached 8/10.
UX-based NPS reached 90%.
For me, these numbers mattered because they showed that the product was not just usable. It was helping people get things done faster.
And for a restaurant POS, speed is not a small thing.
It is the product.
After launch, the product started showing strong early results.
Time to value reduced by 80%.
Average goal conversion increased by 40%.
Customer Effort Score reached 8/10.
UX-based NPS reached 90%.
For me, these numbers mattered because they showed that the product was not just usable. It was helping people get things done faster.
And for a restaurant POS, speed is not a small thing.
It is the product.
80%
Reduction in time to value
40%
Increase in average goal comversion
8/10
Customer effort score
90%
UX-Based NPS
What I Took Away
What I Took Away
This project reminded me why research matters.
At the start, we could have simply designed what we were asked to design. But once we watched real restaurants work, the product became clearer.
I also learned that building for business operations requires restraint. There will always be more features to add. More edge cases to cover. More things stakeholders want.
But good design is knowing what should be there now, what should come later, and what should not distract the user from getting work done.
I left the project after launch, but I was proud of where we got it to.
What started as a vague request for a POS system became a clearer, more useful product because we took the time to understand the people who would use it every day.
This project reminded me why research matters.
At the start, we could have simply designed what we were asked to design. But once we watched real restaurants work, the product became clearer.
I also learned that building for business operations requires restraint. There will always be more features to add. More edge cases to cover. More things stakeholders want.
But good design is knowing what should be there now, what should come later, and what should not distract the user from getting work done.
I left the project after launch, but I was proud of where we got it to.
What started as a vague request for a POS system became a clearer, more useful product because we took the time to understand the people who would use it every day.