70%
Fewer transaction errors
Cashier POS — interaction preview
Redesigning a point-of-sale app so cashiers can complete sales faster
Cashier POS — interaction preview
The problem: Cashiers needed 4+ taps and several screens to complete a basic transaction, and stores needed a separate system just to add a product.
What I did: Designed the mobile version of the POS, from research to final screens, with the PM, engineering and stakeholders. I interviewed store owners, ran workshops and tested the app with cashiers in a real store. After my colleague left, I also designed Connected devices.
Key decisions: One scrollable home screen with the cart always visible, and adding products straight from the till, scoped with engineering to keep product data secure.
Result: In a real-store test with 5 users, 70% fewer transaction errors, 30% faster cashier tasks, and 1–2 taps per sale instead of 4+.
Part of the Focalpay platform: the POS sells products and prices set up in the Back-office, and takes over cash payments from the Mobile shopping app.
Traditional POS terminals are heavy and expensive. Focalpay, a Swedish retail-tech company, built a cashier app that runs on any smartphone, tablet or touchscreen instead: on iOS, Android and in the browser.
I joined as one of two designers when the first version was already used in several stores. I owned the mobile version of the POS, the phone-sized screens cashiers hold in their hand, while my colleague designed the tablet and desktop versions. One sale meant moving between several screens, and when a product was missing at the till, the store had to add it in a separate back-office system. My job was to find what slowed cashiers down, redesign the main flows and test them in a real store.
I worked from research to final screens with the PM, engineering and stakeholders, the same team behind the Back-office and the Mobile app, and designed every screen to WCAG AA.
"We want something that just works — fast. Our staff shouldn't need training to use a cashier app."
— Store manager, research session. The same person also worked with us on the Mobile shopping app.The POS works with the store's hardware
In a store, the POS works with a handheld scanner, a receipt printer, a keyboard and sometimes a Cash Guard cash machine. Each can fail in its own way, so one settings screen shows clearly what's connected and what isn't. I designed this after my colleague left, as the only designer on the team.
Cable, wireless or the device camera. The screen always shows which one is active.
Green when ready, red when not, so problems show up before a customer is waiting.
If it disconnects, a warning appears straight away.
Opens from the Functions panel, with no separate system to switch to.
Adding products at the till, safely
Store owners wanted to add products in the POS. Engineering was worried: product data is sensitive, and the cashier app shouldn't be able to change the catalogue.
With the PM and the engineering lead, I found a middle ground. Cashiers can create a basic product record at the till (name, EAN and sales account), while full editing stays in the back-office. The data stays safe, and nobody gets stuck at the scanner.
Watching cashiers work
I combined interviews, workshops, observation and testing in a real store. Watching cashiers serve real customers taught me the most.
In the store, we saw that cashiers rarely look at the screen during a sale. They rely on muscle memory and peripheral vision.
"We need the cart front and centre, always. Everything else is secondary."
In usability testing, cashiers wanted to add products, apply discounts and scan barcodes without leaving the home screen.
In the workshops, store owners said adding products was a big problem. They wanted to do it in the POS, not in a separate system.
The main flows
Instead of many separate pages, I built the app around one scrollable home screen. The cart, product list, quick actions and daily summary are all on the same page. The Purchase button and the quick actions (Scan, Add bag, Add discount) are always visible, however many items are in the cart.
Empty cart — product grid visible below
Items in cart — Purchase CTA always visible
Expanded cart — all items visible
The phone camera works as a barcode scanner. When a product is found, it goes straight into the cart. When it isn't, the app asks the cashier to add it right away, instead of sending them to another system.
Nothing stops a queue quite like a product that doesn't exist.
Adding a product takes two steps: name, EAN and sales account, then an optional photo.
Scanning mode — camera active, product list visible
"Product not found" — prompt to add it instantly
Add new product — Name, EAN, Sales account
Step 2 — Upload product image
Product list — search by EAN or name
Discounts can apply to one product, shown as a badge on that item, or to the whole receipt. Cashiers can choose kronor or percent.
The keypad has large keys that work well on a touchscreen, even with gloves on, and clear toggles for the type and scope of the discount.
Swedish winters are part of the brief.
Discount input — SEK or %, receipt or product
Discount applied — shown as banner in cart
The refund screen has two tabs, Refundable and Non-refundable, so cashiers can see straight away what can be returned. They tap items to select them, the total updates as they go, and "Do refund" completes it.
Refundable items — tap + to select
Non-refundable — clearly separated
Selected items — total & "Do refund" CTA
Reporting is built into the POS. Cashiers can see the day's transactions, fetch the daily report, compare the register with the control check, and submit it, all in the same app.
The "Coming up" list shows upcoming report deadlines, so store managers can also submit empty reports for days with no sales. This prevents gaps in the reports.
Transactions — filter by method or date
Daily report — register vs. control check
Fetch today's transactions before submitting
Home, products and refunds
Try the flow yourself
You can click through the prototype to scan items, take a payment and move through the POS like a cashier would. No Figma account is needed. It loads when you tap it, to keep the page fast.
Emotion curve across a full transaction day
The foundation for every screen
Before designing the flows, I set up a design system: colours, typography, spacing, corner radius and component states, so design and engineering stayed consistent as the app grew. This release is light-theme only, to keep contrast predictable under bright store lighting.
Brand palette, type scale, spacing, radii, and scalable button states
Buttons, refund flow pattern, inputs, segmented controls, and search + scanning
We tested the app in a real store as well as in usability sessions. In the store, we could see how cashiers worked under time pressure, with real customers waiting.
Average taps to complete a basic transaction. Multiple page navigations required.
Cart, product list, Purchase and quick actions all on one scrollable screen.
"The scroll feels natural. I don't have to think about where anything is."
— Cashier, In-Store Usability TestFewer transaction errors
Faster cashier task time
Fewer taps per transaction
All three measured in the same test, in a real store: 5 users completed the same 5 core tasks (scan, add to cart, apply discount, process payment and generate receipt) in the previous and the redesigned versions.
Back-office trips needed to add a missing product: it can be created at the till
WCAG AA, checked with colour-contrast checks and screen-reader testing on the core flows, across the supported screen sizes.
The POS on a handheld device during in-store testing
What I learned
Every extra second matters when someone is waiting at the till. Most of my work was removing steps: less navigation, fewer decisions, and the most common actions always within reach.
Testing in a real store showed things the usability sessions didn't. Cashiers under pressure, with customers waiting, use the app very differently.
Fewer handovers between tools means fewer problems. Things went wrong where the POS ended and another tool began. Letting cashiers create basic products at the till closed that gap without risking the product data.
Looking back
I'd test in a real store earlier in the process, before the main flows were finalised, because that's where the most important problems showed up.