Lucrum POS

A point of sale rebuild for cashiers who use it for eight hours at a stretch. Register, checkout, sale orders, warehouse requisition and branch search.

Role Senior UI/UX designer, lead

Timeline Four weeks

Team Junior designer, content writer, full stack developer, CEO oversight

Status Live in fifteen businesses

Cashier acceptance moved from 92% to 96%, measured across more than 30,000 transactions.

Still shipping, as Lucrum POS. The team posts releases on LinkedIn.

The problem

The previous point of sale system was a clunky legacy tool. Customisation was limited, its reporting produced data dumps with no clear resolution path, and the visual design was inconsistent from screen to screen. Cashiers slowed down at checkout, which is the one place in a retail business where slowing down costs money.

The one thing worth carrying forward was its keyboard shortcut system. Everything else needed rebuilding around a design language that could scale across branches, formats and business types.

The Lucrum register: category chips above a grid of products with photographs and prices, and a right rail holding the live cart, payment type, and an order summary with GST and the grand total — The register a cashier works all day. Real product, not a mockup.

Scope and role

I led discovery and design end to end: the research loop, the flows, the design system, and the sign-off passes that got it into cashiers' hands. The register was the visible part. Most of the work was agreeing what a transaction actually is with the people who run the floor.

The part that mattered most was the least visible. No flow was signed off in Figma alone. Each one went through a field inspection with the operations lead first, which is why so few came back after build.

Research

Before Figma opened, the process ran through a fixed loop: review goals, gather research, list every touchpoint a cashier hits in a shift, sketch an empathy map, translate that into a user journey, then refine and digitise it before wireframing anything.

Scope was not limited to the register. Early on I mapped every channel an order can arrive through, drive through, delivery, walk in and pickup, against every touchpoint that has to support it: order app, web, phone, kitchen display, self order kiosk, e-commerce, third party apps and WhatsApp.

Alongside direct feedback from cashiers I benchmarked how existing platforms and hospitality kiosks handled the same moments, to see which patterns held up under real transaction pressure rather than looking clean in a deck.

A notebook page listing the research loop: review goals, gather research, list touchpoints, empathy map, affinity diagram, sketch the journey, refine and digitise, then share for feedback, above a note separating user flow from user journey — The loop every screen went through before Figma opened.

A handwritten usability checklist covering customisability, data visualisation, accessibility, mobile friendliness, simplicity, consistency, search and filter, and usability testing, with form rules for progress indicators, error messages and field grouping — The checklist each screen was marked against.

Four weeks, start to handover

The timeline is the reason the component library exists. Four weeks does not allow for redrawing a screen because a button needed to be a different size, so the system had to be settled early enough that week three could spend its time on composition rather than on parts.

Week one

Research and ideation

Defining objectives, competitor benchmarking, cashier feedback, user research.

Week two

Wireframes and user flows

User flow mapping, low fidelity wireframes, design system structure, empathy mapping.

Week three

High fidelity design

Branding and typography, component library, prototyping, the bento layout system.

Week four

Testing and iteration

User testing, feedback iteration, flow refinement, field inspection with the operations lead.

A notebook audit of the legacy system dated October 2024: no good mobile experience, a clunky legacy interface, no customisation, unexplained application dumps with no resolution path, and inconsistent design, with its keyboard shortcuts noted as the one thing worth keeping — The audit of the tool being replaced, written on the day.

A notebook page mapping order channels including order app, web, phone, e-commerce, third party apps, WhatsApp, kitchen display and rider app against drive through, delivery, pickup and walk in — Every channel, against every touchpoint that carries it.

Colour and mark

Three colours carry the whole interface. Sea green is the product's own, jet does the structural work, and the orange exists to make one thing at a time unmissable: an overdue requisition, a failed payment, the total a cashier reads out loud.

A dark theme was designed alongside this one: a full set of screens on real product data, not a mockup. It never went live. Rolling a theme change across every client instance was a bigger deployment job than the change was worth, so it stayed in the file.

Worth saying plainly, because it is the more common way design work dies. Not rejected in a review, just outrun by what it would cost to deploy. It is also why the palette is built to hold up in one theme rather than assuming a second would arrive.

The mark sits in the register's top left all day, so it had to work small.

Light Sea Green #20B2AA

Jet #343434

Giants Orange #FE5A1D

The parts it is built from

Every control a cashier touches, drawn once and reused across the register, the order lifecycle and warehouse replenishment. Buttons are sized to at least 48 by 48 pixels: cashiers are already fluent on their phones, and a register that ignores that fluency makes them slower for no reason.

The paid amount card, showing what the customer has handed over so far

The amount still to be paid, carried beside the paid amount so a cashier reads both at once

The change due back to the customer, the number a cashier reads out loud

A single product line inside the cart, carrying its thumbnail, name, unit price, quantity stepper and line total

Text input fields shown in both their resting state and their focused state, with the label sitting above the field

The invoice panel in two states, one collapsed to a summary and one expanded to every line item with its tax

The vertical toolbar down the left of the register, shown collapsed to icons and expanded to icons with labels

Payment type selection offering card, cash and bank transfer, with the chosen type carrying a filled state

A product tile as it appears in the register grid, with its photograph, quantity badge, name, price and an add control

An option list for a product variant, with the selected option marked and the remaining options still tappable

A toggle control drawn in both positions, off and on, at the size a thumb has to hit during a shift

Radio buttons in their selected and unselected states, sized to the same 48 pixel target as every other control

At the counter

A cashier searches for an item, adjusts quantity or applies a discount, and sends it to the cart in a couple of taps. Redeeming loyalty points, calculating change and choosing a payment type all live on the same payment screen, so nothing requires a separate trip through a menu.

Not every transaction goes smoothly, and the design has to be as good at the exceptions as it is at the happy path. Cashiers can void a transaction before it completes, cancel an order in progress, or process a return once it has gone through, without a manager override for the everyday cases. An order can be put on hold and pulled back later through quick recall, which matters when a customer steps away mid purchase.

Item search during checkout, with results filtering as the cashier types and quantity and discount controls beside each line — Search, quantity and discount, without leaving the cart.

An order placed on hold and later recalled from a list of held orders, with its line items intact — A held order comes back without being retyped.

Order status detail showing the lifecycle of a single order with its line items and current state — One order, its whole lifecycle, in one place.

Everything reachable from the home screen, six top level modules, several with actions of their own branching off underneath.

Where the parts become screens

The same components, assembled into whole screens and grouped by the part of the business each one belongs to. Reusing one set across all three subsystems is what let a four week timeline cover this much surface.

Register and checkout

Building a sale order, with the cart always in view.

Payment, tender and change on one surface.

Order lifecycle

History, filtered by the state a manager is chasing.

The returns queue, with void and return in reach.

Warehouse and branches

Requisition speaks the language the register taught.

Branch and warehouse search showing stock levels by location alongside the requisition controls — Stock by branch, with requisition in the same view.

Who runs it

Fifteen businesses, from a bakery chain to a fashion house to a golf club. Each one gets the same components under a different catalogue, which is the argument for building a system rather than a screen.

Coffee Layers

Craving

What I took from it

The smallest decisions made the biggest difference to how the system felt to use, every day. Sizing a button for a thumb, putting change and loyalty on the same screen, letting a held order come back without being retyped: none of those are interesting in a portfolio and all of them are what a cashier notices in hour seven.

It also taught me to balance what a business wants against what the people using the thing actually need, which is a harder negotiation than it sounds when the person paying is not the person tapping.

What I would redo is the dark theme. I designed a full second set of screens before anyone had asked what it would cost to deploy across every client instance, and that answer arrived too late to matter.
Muhammad Bin Saif, design lead on Lucrum POS