Redesigning a high-frequency point-of-sale app for faster, intuitive transactions
Cashier POS — interaction preview
Speed is the Product
Traditional POS terminals are heavy, expensive, and inflexible. The Focalpay cashier application was built to change that — a lightweight, device-agnostic system that runs on any smartphone, tablet, or touchscreen terminal, with no bulky hardware required.
I joined this project as the lead designer at the redesign phase, with the existing v1 product already in use at several stores. My job was to understand what was slowing cashiers down, redesign the core flows, and ship something that could be validated in a real store environment — not just a usability lab.
The core idea: give small and medium-sized stores a complete point-of-sale solution that is faster, greener, and easier than legacy infrastructure — with everything from product management to daily reports built into a single scrollable interface.
End-to-end ownership
Project context
Focalpay is a Swedish retail-tech company building payment and store-management software for independent retailers. The cashier app runs on iOS, Android, and browser — replacing legacy terminals with a lightweight, device-agnostic POS.
Connected store hardware
The Focalpay cashier app doesn't live in isolation. In a real store environment, the POS terminal sits at the centre of a small ecosystem — a handheld barcode scanner, a receipt printer, a physical keyboard, and a Cash Guard cash management unit all need to talk to it reliably, every single shift.
Designing the External Devices settings screen meant thinking beyond UI. Each peripheral has its own connection type, its own failure mode, and its own impact on the cashier's flow when something goes wrong.
Cashiers can connect via cable, wireless, or fall back to the device camera — or set it to no scanner at all. The active connection type is always visible, so there's no guessing when a scan doesn't register.
Print confirmation is a non-negotiable part of every transaction. Connection status shows live on the screen — green means ready, red means act now — so a disconnected printer never becomes a surprise mid-queue.
For stores that rely on manual input — product codes, quantities, amounts — keyboard connectivity is tracked the same way. A disconnected keyboard shows a clear warning before it causes a problem at the till.
For stores using automated cash management, the Cash Guard integration is handled directly through the Functions panel — alongside deposits, bag charges, and price checks. No separate system, no extra steps.
The result is a single settings screen that gives store managers a real-time picture of everything connected to the till — and the confidence to catch a problem before a customer is standing at the counter.
Watching Cashiers Work
I combined qualitative and observational research methods, including testing the application in an actual live store environment — one of the most valuable inputs in the entire process.
Real-world store testing revealed that cashiers rarely look at the screen during a transaction — they rely on muscle memory and peripheral vision.
"We need the cart front and centre, always. Everything else is secondary."
Usability testing showed users wanted to add products, apply discounts, and scan barcodes without ever leaving the home screen.
Stakeholder workshops revealed that product management was a major blocker — stores needed it built into the POS, not a separate system.
One tension that emerged early: store owners wanted product management built into the POS, but the engineering team was concerned about scope and security — product data is sensitive, and they didn't want the cashier-facing app to have write access to the catalogue. I worked with the PM and engineering lead to find a scoped solution: cashiers could create minimal product records (name, EAN, sales account) directly from the till, but full product editing remained in the back-office. This kept the security model clean while solving the real user problem — the dead-end at the barcode scanner when a product wasn't found.
Every Second Counts
Cashiers work fast. Every extra tap, every screen transition, every moment of confusion costs real time — and frustrated customers. The core design challenge was presenting a large amount of functionality on a small screen without slowing down the transaction flow.
Legacy POS systems required navigating multiple pages to complete a single transaction, breaking the cashier's flow.
Stores had to rely on a separate back-office system to add or edit products — a slow, disconnected workflow.
Traditional terminals were expensive and energy-intensive. Stores wanted a leaner, mobile-first alternative.
"We want something that just works — fast. Our staff shouldn't need training to use a cashier app."
— Store Owner, Usability Research SessionFast, Tested, Iterated
Instead of a fragmented multi-page system, I designed the application around a single scrollable home screen. The cart, product list, quick actions, and daily summary all live on one page — reducing taps and keeping cashiers in a continuous flow.
The persistent Purchase button and quick-action row (Scan · Add bag · Add discount) are always visible, no matter how many items are in the cart.
Empty cart — product grid visible below
Items in cart — Purchase CTA always visible
Expanded cart — all items visible
Scanning mode — camera active, product list visible
"Product not found" — prompt to add it instantly
Add new product — Name, EAN, Sales account
Barcode scanning turns any smartphone camera into a product scanner. When a product is found, it's added to the cart instantly. When it's not found, the app prompts the cashier to add it on the spot — eliminating the need to go to a separate system.
The "Add New Product" flow is a key innovation of this project. It lets store staff create new products directly from the POS — with name, EAN, sales account, and an optional product image — all in two steps.
Step 2 — Upload product image
Product list — search by EAN or name
Discounts needed to work at two levels: applied to a single product (shown as a badge on that item) or to the entire receipt. Cashiers can choose between SEK amount or percentage, making the flow adaptable to any promotional scenario.
The discount screen uses a large-format numeric keypad — optimised for touchscreen use, even with gloves — with clearly segmented toggle buttons for type and scope.
Discount input — SEK or %, receipt or product
Discount applied — shown as banner in cart
The refund flow separates items into two clear tabs: Refundable and Non-refundable — helping cashiers quickly identify what can be returned. Items are selected with a single tap, the total updates in real time, and a "Do refund" button finalises the process.
Refundable items — tap + to select
Non-refundable — clearly separated
Selected items — total & "Do refund" CTA
One of the biggest differentiators of this application is that reporting is built directly into the POS. Cashiers can view the day's transactions, fetch the daily report, review register vs. control check data, and submit — all without switching to a separate system.
The "Coming up" feature shows upcoming report deadlines, allowing store managers to submit empty reports for days with no transactions — preventing gaps in the reporting chain.
Transactions — filter by method or date
Daily report — register vs. control check
Fetch today's transactions before submitting
Home · Products · Refunds
Click through the real flow
The screens above come to life here. Launch the embedded prototype to ring up items, take a payment, and move through the POS exactly as a cashier would — no Figma account needed. It loads on tap to keep the page fast.
Emotion curve across a full transaction day
Foundations Before Flows
Before detailing individual journeys, I defined a shared Focalpay POS design system — colour, typography, spacing, radii, and component states — so design and engineering could scale the interface consistently. The cashier experience is built for light mode only in this release: there is no dark theme, which kept contrast, legibility, and peripheral scanning predictable under bright store lighting and varied devices.
Brand palette, type scale, spacing, radii, and scalable button states
Buttons, refund flow pattern, inputs, segmented controls, and search + scanning
Measurable Impact
Beyond lab-based usability sessions, the application was tested in a live store — the most demanding environment possible. This revealed issues that no prototype test could surface: how cashiers behave 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 taps per transaction
Measured by comparing tap counts across the same 5 core tasks (scan, add to cart, apply discount, process payment, generate receipt) in the original flow versus the redesigned scrollable home screen. Validated during in-store usability testing with 5 participants.
Extra systems needed — product management built into the POS
AA compliant — accessible on all screen sizes and devices
Live store validation — handheld POS in use during in-store usability testing
What This Project Taught Me
In a cashier context, every extra second matters. Designing for speed means eliminating navigation, reducing cognitive load, and making the most frequent actions zero-effort.
Testing in a live store revealed behaviours that no usability lab could simulate. Cashiers under real pressure interact with interfaces very differently than they do in controlled sessions.
Integrating product management and reporting into the POS was resisted early on as "scope creep." But the data from usability testing made the case clearly: the most common cashier errors happened not within the app, but at the seams between the app and the external tools they had to use alongside it. Reducing the number of systems in play wasn't a feature — it was the fix.