B2B SaaS
Full revamp
Product Design
Three System. One Screen. One Week
Redesigning a fragmented restaurant POS and the analytics dashboard that sat behind it
ROLE
Product Designer
TIMELINE
V1 2023 · V2 2025 · V3 2026
SPRINT
1 week
TEAM
tapin Team
THE PROBLEM
Restaurant staff juggling three separate systems mid-service, orders, payments, and analytics, all disconnected.
MY ROLE
Sole designer. End-to-end ownership of both the POS interface and the analytics dashboard, from sketch to sign-off.
THE SOLUTION
A unified interface that handles the full service workflow in one screen, with a separate manager analytics view, no second login required.
THE OUTCOME
Projected 15% adoption increase, 21% dev efficiency gain, 12% reduction in manual workload delivered in five working days.
REQUEST DEMO
01 - OVERVIEW
A real brief, a real deadline, a real mess to clean up
Tapin Platforms came to me with an existing system and a clear verdict: it wasn't working. The current POS a dense, dark-themed interface packed with colour-coded buttons and text-heavy lists had been built for function, not for people.
I was brought in as the sole designer to redesign two connected products: the front-of-house POS that waitstaff use to take orders and process payments, and the back-of-house analytics dashboard that managers use to track performance. Both needed to feel like they belonged to the same system. Neither currently did.
User problem
Waitstaff context-switching between systems mid-service
High cognitive load during peak hours
Separate logins for every task
Complex training requirements for new staff
Business problem
Slower table turnover due to system friction
Increased staff training costs
Near-zero real-time visibility into performance
No consistent design language across tools
Technical constraints - Fixed from day one
Windows-first
Angular
Clover payments
Cash drawer
Receipt printer
Password-protected admin
02 - RESEARCH & DISCOVERY
The existing system was my research
There were no user interviews on this project. One week doesn't allow for it. But I wasn't going in blind, the client provided detailed requirements and, crucially, screenshots of the existing system.
I treated that existing interface the way I'd treat a user interview: looking for the patterns, the pain points, the decisions that made sense once and had never been revisited.
Existing POS
Existing dashboard
No visual hierarchy
Every element competed equally, buttons, lists, totals, and navigation, all at the same visual weight. Nothing told the eye where to start.
Mixed order flow
Input, confirmation, and payment were crammed into the same panel with no clear separation between stages.
Spreadsheet analytics
Performance data was raw numbers with no structure, meaningful only to someone who already knew what they were looking at.
How might we...
"design a unified POS that supports the full service workflow, from order to payment to analytics, without adding cognitive load for staff who are already under pressure?"
03 - IDEATION
The structure came first. The details followed
I started with paper. That sketch is still one of the most useful things I produced that week, because the three-panel structure it established held all the way to the final.
Day 1 sketch - categories, menu grid, live order summary. This layout remained unchanged until the final design.
The layout wasn't instinct; it was the most direct answer to the problem. Staff needed everything in one view, with no reason to navigate away from an active order. Once that structure was locked, iteration focused on the details that matter under real service conditions.
Sketch to wireframes
04 - THE SOLUTION
One system. Two surfaces. No overlap
The final design consolidated three fragmented workflows into two role-aware surfaces. Every decision traced back to one question: what does this user need right now, and what can wait?
The POS - built for speed under pressure
Visual menu grid, category tabs with item counts, live order summary panel
The visual menu grid leads with food photography and clear pricing. Category tabs with item counts let staff navigate without having to browse. Adding, customising, and removing items all happen in one view, and the order summary panel updates in real time throughout.
The admin layer is password-protected as specified, allowing operators to manage menu items without touching the codebase. That single requirement shaped the entire information architecture.
Inline modal overlay - modify an item without leaving the active order
The Dashboard - built for clarity, not completeness
Year-to-Date, Period to Date, benchmark comparison - navigation to inventory, payroll, reports
The analytics surface was rebuilt around one question: what does a manager actually need to see? Year-to-Date and Period to Date revenue, benchmark comparison against comparable restaurants, and direct access to reports, inventory, and payroll, all from the same sidebar. No nested windows.
05 - IMPACT
What the design was built to achieve
Increase in user adoption
Interface simple enough for new staff to learn without extended onboarding
Dev efficiency improvement
Lean component system gave engineers reusable building blocks, not screen-by-screen specs
Reduction in manual workload
Automated discounts and structured analytics replaced manual reporting
Default widget in the wild with Locatelli
08 - REFLECTIONS & NEXT STEPS
What I'd do differently, and where this goes
01
Designing for users I couldn't speak to
The brief gave me a clear picture of the problem. The existing system gave me something to push against. But I never watched a waiter use either version under real service conditions. The interaction model I designed is logical. Whether it's instinctive under pressure is a question only usability testing can answer, and that's the first thing I'd run with more runway.
02
The structure held because the thinking was sound
The two-panel layout sketched on day one made it to the final design unchanged. That's not luck, it's what happens when you spend the first hours mapping workflows before opening a design tool. The time I didn't spend redesigning the structure was time I spent getting the details right.
03
Speed is a stress test
A real brief, a defined tech stack, hardware constraints, and stakeholder feedback to incorporate, all in five days. You find out quickly which decisions you can defend from first principles and which ones you were coasting on. I'd do this kind of sprint again.
Next steps, if this projects had a second chapter
Usability testing
Specifically, the customisation modal and order flow speed, with actual front-of-house staff, during a real service shift.
Expanded payment integrations
Additional processors beyond Clover, and connections to delivery platforms and accounting software.
Multi-location reporting
The dashboard gestures at multi-location comparison. A full build-out for operators running more than one site.
Mobile / tableside ordering
The brief specified Windows-first. A tablet or handheld version for tableside ordering is the natural next surface.