WizPOS™
A next-generation POS built for people who move fast.
DESCRIPTION
A cloud-based Point of Sale (POS) system designed to support high-volume retail operations, with a focus on speed, reliability, and scalability for international markets.
CONTEXT
WizPOS™ was developed in Sri Lanka in partnership with eWiz Solutions and an independent engineering team from one of the world’s largest food supply organizations.
The core system was largely complete from a functional standpoint when I joined. However, the product lacked a cohesive visual language, POS ergonomics, and market-ready usability required for international deployment.
By the time I joined the project, the system was already functionally mature. Core POS workflows, backend logic, and a React-based frontend were in place. However, the product was not yet ready for real-world retail usage or market adoption due to significant gaps in usability, visual consistency, and POS ergonomics.
My role was to bridge that gap-transforming a technically complete system into a usable, market - ready POS product.
Designing a POS for the speed of retail - from Colombo checkout counters to American wholesale floors.
Introduction
WizPOS™ is a cloud-based point-of-sale system built by eWiz Solutions in Sri Lanka, with the end goal of entering the United States retail market - supermarkets, wholesale clubs, and high-volume chain operations where speed and reliability are non-negotiable.
While the product was developed in Colombo, our ambition extended far beyond the local market. The system needed to work equally well for a Sri Lankan supermarket cashier processing LKR transactions and an American wholesale operator running USD tenders across multiple lanes. Two very different retail cultures, one product.
I joined the project when the core system was functionally complete - backend logic, React frontend, and POS workflows were in place. What was missing was the human layer: POS ergonomics, visual coherence, touch optimization, and the kind of usability polish that separates a functional tool from a market-ready product.
I worked as a UX Engineer on this project - designing the experience in Sketch, prototyping interactions in Principle, and then building the production frontend myself in HTML and CSS. I integrated the UI directly with a React developer, closing the gap between design intent and shipped product.
WizPOS was designed as a touch-first system from day one. The primary interface runs entirely on touchscreen terminals with no physical keyboard dependency. That said, during our research phase we interviewed and observed both traditional keyboard-based POS operators and touch-based system users to understand the full spectrum of operator habits, muscle memory, and expectations before committing to our touch-only direction.
My Role
I worked on this project as a UX Engineer, not just a designer. That meant I owned the full pipeline: research, design in Sketch, interactive prototyping in Principle, and building the production frontend in HTML and CSS. I then worked directly with a React developer to integrate my frontend code into the React component architecture.
This design-to-code ownership meant fewer handover gaps. What I designed is what got built, because I built it. When a touch target needed to be 2px larger or a transition needed to feel faster, I adjusted it in code, not in a spec document.
I collaborated closely with:
- eWiz Solutions (Sri Lanka) - product owners who drove the engineering and market vision
- React Developer - worked alongside me to integrate my HTML/CSS frontend into the React component system, handling state management and backend connections while I owned the UI layer
- Retail Operators - cashiers, shift managers, and store owners observed and interviewed in live retail environments across Sri Lanka
- US Market Advisors - retail consultants who provided insights into American POS conventions, compliance, and operator expectations
Research & Discovery
Before drawing a single screen, we invested significant time understanding how POS operators actually work - not how product specs say they should work. Our research approach combined existing industry data with hands-on fieldwork.
Leveraging Existing Research
We didn't start from zero. We studied published research on retail POS operator diversity and literacy levels across the US and South Asian markets. Key findings we built upon:
- Operator demographics: US retail employs a wide range of ages and tech literacy levels - from teens in their first job to senior staff with decades of register experience. Sri Lanka's retail workforce skews younger but with lower touchscreen familiarity outside of smartphones
- Literacy & language: US operators include non-native English speakers. Sri Lankan operators may work in Sinhala, Tamil, or English. The UI needed to communicate through visual hierarchy and spatial consistency, not just text
- Fingertip & touch ergonomics: We referenced ISO touch-target research and anthropometric data on fingertip sizes across populations. Average adult fingertip pad width is 10-14mm, but effective touch targets need to account for angle of approach, screen position, and fatigue. We settled on 18mm minimum targets with 4mm spacing - exceeding Apple's HIG recommendation of 44pt
Field Observations: Sri Lankan Retail Market
We spent weeks observing cashiers in live retail environments across Colombo and suburbs - large-scale supermarket chains, mid-size grocery stores, and small independent shops using random POS setups.
Observational research across Sri Lankan retail - supermarkets, independent shops, and wholesale environments
What we observed in the field:
- Speed under pressure: Experienced Sri Lankan supermarket cashiers process 20-30 items per minute during peak. Their hands move in a rhythm - scan, bag, scan, bag. Any interface interruption that breaks this rhythm creates visible frustration and queue buildup
- Finger behavior: Operators use index fingers for most taps, but switch to thumbs on smaller screens. Angle of approach changes throughout a shift - early morning taps are precise; end-of-shift taps drift toward screen edges. Touch targets need to forgive this degradation
- Workarounds are data: Cashiers at one major Sri Lankan supermarket chain had developed unofficial shortcuts - sticky notes with item codes, handwritten price lists taped to monitors, cheat sheets for discount workflows. These workarounds told us exactly where the existing UI was failing
- Drawer culture: Unlike US operations where the drawer opens only at tender, Sri Lankan retail involves frequent cash handling - mid-shift reconciliations, cash drops, change-making for non-purchase transactions. The POS needed to support these as first-class workflows, not buried settings
- Multi-role operators: In smaller Sri Lankan shops, one person is cashier, inventory manager, and store owner. The interface needed role-fluid access, not rigid permission hierarchies
Sri Lankan Payment Terminal Constraint
In Sri Lanka, only banks are authorized to run card payment terminals. These are bulky dumb terminals - completely separate devices with no integration capability. Every card transaction forces the operator to physically shift focus away from the POS screen to a disconnected banking terminal, process the payment in isolation, then return to the POS to confirm. This fragmented flow breaks the transaction rhythm, increases checkout time, and prevents us from offering the sleek integrated card reader experience that US POS systems take for granted. We had to design our payment workflow to gracefully accommodate this forced context switch rather than fight against it.
Interviews: Large-Scale Sri Lankan Supermarket Staff
We conducted structured interviews with 15+ cashiers and shift supervisors working in large-scale Sri Lankan retail chains - the closest analog to the US market we were targeting. These were operators processing hundreds of transactions daily on existing POS systems.
I know where every button is by feel.
Experienced operators develop muscle memory. Redesigning layouts means temporarily making your best users slower. We had to balance improvement with familiarity.
The refund screen takes too long.
Returns and voids were the #1 complaint. Not because they're rare, but because when they happen, there's already a frustrated customer waiting.
I wish I could see if something is in stock without leaving this screen.
Inventory visibility during transactions was consistently requested across every interview.
When the internet goes down, we write receipts by hand.
Network dependency was a business-critical pain point, especially outside Colombo metro areas.
Random POS System Audits
We audited POS systems in select independent shops - hardware store, pharmacy, textile shop, bakery - to understand the diversity of POS usage beyond supermarkets. These small businesses often used budget POS hardware with off-the-shelf software, giving us insight into the baseline expectations and pain points of the broader market.
POS system audits across independent retail - hardware, pharmacy, textile, bakery
US Market Research & Benchmarking
For the US market - our primary commercial target - we combined secondary research, competitive analysis of incumbent systems (Square, Toast, NCR, Oracle MICROS), and advisory input from retail consultants familiar with American operator workflows.
Compliance expectations
US retailers expect PCI-DSS compliance, ADA accessibility considerations, and EMV chip/tap support as baseline - not premium features.
Training budgets are minimal
Large US chains allocate 4-8 hours for POS training. The system must be learnable in that window or operators will reject it.
Speed benchmarks
American wholesale operators expect sub-3-second transaction totals. Any lag is perceived as a system failure, not a loading state.
Diverse operator pool
US retail has high turnover. Systems must onboard new staff quickly regardless of tech literacy, age, or language background.
Touch Ergonomics & Operator Physicality
One of the most critical and often overlooked aspects of POS design is the physical interaction. A POS terminal isn't a phone or tablet - it's operated for 8-hour shifts, at specific angles, with varying hand sizes and fatigue levels. We treated touch ergonomics as a core design constraint, not an afterthought.
Fingertip Size Variance Across Populations
Adult fingertip pad widths range from 10mm to 14mm across demographics. Sri Lankan female operators trend toward the smaller end; American male wholesale staff trend toward the larger end. A single touch-target size must accommodate this full range.
We standardized on 18mm minimum touch targets (exceeding both Apple HIG 44pt and Material Design 48dp guidelines) with 4mm inter-element spacing. For primary action buttons (Tender, Void, Refund), we went larger - 24mm targets - to reduce mis-taps on high-stakes actions.
Mis-tap rates dropped significantly in prototype testing. Operators across both markets could hit targets reliably regardless of hand size, screen angle, or shift fatigue.
Tap Speed & Fatigue Patterns
Through observation, we tracked how operator tapping behavior changes across a shift. Early in the day, taps are centered and precise. By hour 6-8, taps drift toward screen edges, become less precise, and operators unconsciously decrease tap pressure.
We designed hit zones slightly larger than the visible button boundaries (invisible touch padding). Primary actions were placed in the screen's natural "comfort zone" - center-right for right-handed operators - with less-critical options pushed to edges.
End-of-shift error rates in testing were comparable to start-of-shift. The interface forgave the natural degradation that comes with 8 hours of physical interaction.
Screen Position & Approach Angle
POS terminals are mounted at various angles - flat countertop, tilted stands, vertical kiosks. The angle of finger approach changes which screen regions are easy to reach and which cause wrist strain.
We mapped comfortable reach zones for common terminal positions and placed high-frequency actions within the "effortless reach" area. Manager-only functions were placed in harder-to-reach zones - reducing accidental triggers while remaining accessible when needed.
Operators reported reduced wrist fatigue during extended testing sessions. The layout felt "natural" across different hardware setups without any reconfiguration.
Touch target sizing, reach zones, and fatigue-adjusted hit areas
The Problem Space
Synthesizing field observations, interviews, and market research, we identified four core problems that defined our design challenge:
High Cognitive Load in Fast Environments
Cashiers work under sustained time pressure - processing transactions, managing queues, and handling interruptions. Every UI element competes for attention, and slow decision-making creates bottlenecks that ripple through the entire store.
A Sri Lankan supermarket cashier faces a dense menu with 20+ options (Refund, Suspend, Discount, Tender, Customer, Drawer, Settlement) with no visual hierarchy. A customer returns an item during peak hours - the cashier hunts for the correct workflow while six people wait in line.
Transaction times inflate by 30-60 seconds per exception. Customer frustration builds. Staff stress leads to more errors, creating a negative feedback loop during the busiest periods.
Two Markets, Two Mental Models
American and Sri Lankan retail operate on fundamentally different assumptions. US chains prioritize speed-per-transaction and labor efficiency. Sri Lankan operators prioritize cash management, flexibility, and multi-role access. A single interface trying to serve both created friction for everyone.
In US wholesale, a cashier processes 40+ items, hits "Total," taps a payment method, and moves to the next customer. In Sri Lanka, the same transaction might involve a mid-sale price check, a manual discount negotiation, a partial cash/card split, and a drawer reconciliation - all before the next customer.
One-size-fits-all workflows meant US operators saw unnecessary complexity, and Sri Lankan operators missed critical shortcuts. Both markets required workarounds to get their jobs done.
Inventory Blindness at the Register
Operators frequently need to answer stock questions during transactions - "Do you have this in another size?" "When will this be back?" - but the POS kept transactional and inventory data completely siloed.
A wholesale floor manager spots a fast-moving item running low. To check stock levels, they need to leave the register, log into a separate inventory system, look up the SKU, and return. By then, three more customers have arrived and the item may already be out.
Lost upsell opportunities. Stockouts during peak periods. Managers spending half their time context-switching instead of serving customers. Small retailers losing revenue because they couldn't see what was right in front of them.
Error Recovery Was Designed for Developers, Not Operators
When things went wrong - declined payments, barcode failures, network drops - the system showed technical error codes and generic menus. Operators were left to figure out recovery paths on their own, often with a frustrated customer watching.
A payment terminal returns "Error 0x4E - Transaction timeout." The cashier doesn't know if the payment went through, whether to retry, or if money was already charged. They call the manager. The manager doesn't know either. The customer is now irritated. Everyone is guessing.
Manager calls for routine issues. Double-charges or lost transactions. Customer trust eroded. Staff anxiety around payment handling - the most critical moment of every transaction.
Our field research revealed a consistent truth across both markets: the problem was never missing features. Every transaction type was technically possible in the existing system.
The problem was findability, context, and physical ergonomics - the human layer that makes software usable under real-world pressure.
The Challenge
WizPOS™ faced a specific set of constraints that shaped every design decision:
Sri Lankan product, American ambition
Built by eWiz Solutions in Colombo, but targeting the US retail market as the primary commercial goal. The product had to meet American operator expectations while being validated in Sri Lankan retail first.
6-8 month runway
Limited time to ship a market-ready product for international deployment. No room for exploratory design - every decision needed to be validated quickly.
Dual-market workflows
Supporting fundamentally different retail cultures without forking the codebase or shipping two separate products.
Hardware diversity
7" mobile carts, 10" tablets in small shops, 15" touchscreen terminals in chains - one interface across all screen sizes.
Network resilience
Sri Lankan retail operates with inconsistent connectivity outside metro areas. US wholesale floors have dead zones. Offline-first wasn't optional - it was survival.
Sri Lankan payment terminal constraints
In Sri Lanka, only banks are authorized to operate card payment terminals. These are bulky dumb terminals running as completely separate devices - the operator must switch focus away from the POS to a disconnected banking terminal for every card transaction. This prevented us from using an integrated card reader and forced us to design around an inherently fragmented payment flow.
The Strategy: Configurable Workflows, Not Feature Flags
Rather than building separate versions for each market, we designed the core POS with workflow configuration at its center. Regional partners could customize transaction flows, menu layouts, drawer behaviors, and shortcut mappings while sharing a common codebase.
This approach meant designing interactions that were flexible yet consistent - a Sri Lankan operator's drawer settlement flow and an American operator's quick-tender flow had to feel like the same product, even though they served different needs.
Goals
Enter the US retail market
Ship a product that can compete with incumbent American POS systems (Square, Toast, NCR) - meeting compliance, speed, and usability benchmarks expected by US chain retailers and wholesale operators.
Validate through Sri Lankan retail first
Use Sri Lanka's diverse retail landscape - supermarkets, independent shops, wholesale - as an intensive testing ground before US market entry. If it works in Colombo's chaotic retail environment, it'll work anywhere.
Enable partner ecosystem
Design the system to be extensible - allowing regional partners to configure workflows, branding, and operational patterns without engineering involvement.
Make transactions feel instant
Speed up checkout by reducing taps, eliminating menu hunting, and surfacing the right actions at the right moment. Target: 95% of transactions completable without navigating away from the main screen.
Accommodate diverse operator hands and habits
Touch targets, layouts, and interaction patterns must work across the full range of operator demographics - varying fingertip sizes, tech literacy levels, language backgrounds, and 8-hour fatigue cycles.
Give managers operational visibility
Live transaction data, inventory alerts, and shift performance - accessible from the register without context-switching to separate tools.
Our Users
Through field research across Sri Lankan and American retail environments, we identified four primary operator archetypes - each with distinct needs, physical constraints, and workflow expectations:
Cashier / Front-Line Operator
The daily power user - processing hundreds of transactions across 6-8 hour shifts. Works under constant time pressure, manages customer interactions, and handles edge cases while maintaining speed. Ranges from first-job teenagers to 20-year veterans with deeply ingrained muscle memory.
When I'm at the register during peak hours, I want to process every transaction - including returns, discounts, and payment splits - without hunting through menus, so I can keep lines moving and avoid frustrating customers or calling my manager.
Shift Manager / Floor Supervisor
Supervises operations, handles cashier exceptions, approves voids and refunds, and needs real-time visibility into sales performance and inventory status. In Sri Lankan retail, often doubles as the primary cashier during slower periods.
When I'm managing the floor, I want instant access to live transaction data, override approvals, and stock status without leaving the register area, so I can resolve issues in seconds - not minutes.
Store Owner / Manager
Responsible for store-level profitability, staffing, inventory management, and operational decisions. In Sri Lankan independent retail, this person often is the cashier. In US chains, they're focused on metrics and policy configuration.
When I'm reviewing store performance, I want clear sales trends, inventory health, and staff efficiency data in one place, so I can make quick decisions about ordering, pricing, and staffing without juggling multiple systems.
IT / Regional Administrator
Deploys and configures POS systems across multiple locations. Handles hardware setup, workflow customization, payment processor integration, and regional compliance. The gatekeeper between product capability and operational reality.
When I'm rolling out WizPOS across stores, I want to configure market-specific workflows, payment integrations, and hardware settings through intuitive admin tools - so I can deploy 10 stores in a week without custom development for each.
Process
Workflow Mapping & Task Analysis
I mapped every transaction workflow at granular level - not just "process sale" but every decision point, exception, and recovery path. What happens when a barcode doesn't scan? When payment declines mid-tender? When a customer wants to split payment across three methods? When manager approval is needed for a refund above the threshold?
We mapped these flows for both market contexts side-by-side, identifying shared patterns (which became core workflows) and divergent patterns (which became configurable modules).
Side-by-side transaction flows for US and Sri Lankan retail contexts
Exception handling paths - refunds, payment failures, inventory lookups
Interaction Patterns & Speed Testing
For the highest-frequency tasks - item scanning, tendering, discounts, voids - I prototyped multiple interaction patterns and speed-tested them with actual operators. We measured taps-to-completion, time-on-task, and error rates for each approach.
Every millisecond of decision time matters in retail. A POS that takes 2 seconds longer per transaction costs a busy cashier 30+ minutes of wasted time per shift.
Sketches & Early Exploration
I explored multiple layout directions through rapid sketching - challenging assumptions about where action buttons should live, how item lists should scroll, and whether the traditional "left-list, right-actions" POS layout was actually optimal. The answer, based on research: it depends on the operator's handedness and screen angle.
Divergent layout exploration - challenging traditional POS screen conventions
Key Design Solutions
Here's how we solved the core challenges - each decision informed by field research, operator testing, and the dual-market constraint:
Progressive Disclosure with Contextual Menus
Rather than displaying all 20+ options at once, the transaction interface shows only the most common actions for the current context. Scanning items? You see quantity, discount, void. Ready to pay? You see tender methods. Processing a return? You see refund options.
The main screen stays clean: Tender, Refund, Discount, Void, Suspend, Customer. Everything else is one contextual tap away - no nested menus, no hunting.
Main transaction screen - context-aware action surfacing
Market-Configurable Workflow Templates
US partners get streamlined, speed-optimized checkout flows - minimal steps from scan to tender. Sri Lankan partners get drawer settlement, mid-shift reconciliation, and flexible cash-handling workflows as first-class features. Both share one codebase, one design system, one training approach.
Admin panels let regional teams customize menu visibility, keyboard shortcuts, transaction behaviors, receipt formats, and tax rules without touching code.
Workflow customization for US and Sri Lankan retail contexts
Human-Language Error Recovery
Instead of "Error 0x4E," the POS speaks operator language. Payment declined? "Card was declined. Try again, use a different card, or switch to cash." Barcode not found? "Item not recognized. Enter SKU manually, search by name, or scan again."
Every error state becomes a guided decision tree - not a dead end. Operators always know what happened and what to do next.
Contextual error handling - every failure has a clear recovery path
Integrated Manager Dashboard
We embedded a lightweight operations dashboard accessible from the main register - live transaction feed, inventory alerts, shift performance metrics, and approval queues. Managers don't leave the floor to manage the floor.
Real-time operations view - accessible without leaving the register
Responsive Touch Across Hardware
One interface across 7" mobile carts, 10" tablets, and 15" terminals. Layouts adapt intelligently - not just scaling, but restructuring. On smaller screens, secondary actions collapse into swipe gestures. On larger screens, inventory and reporting panels appear alongside the transaction view.
Touch targets remain 18mm minimum on every screen size. Primary actions stay in the comfort zone regardless of terminal angle or mounting position.
Offline-First Architecture
The POS works fully offline - transactions process locally, receipts print, drawers open. When connectivity returns, data syncs automatically with conflict resolution. No more "Internet is down, we can't ring sales." No more handwritten receipts during outages.
This was non-negotiable for Sri Lankan retail outside Colombo metro and equally critical for US wholesale floors with connectivity dead zones.
Impact & Outcomes
WizPOS™ shipped within the target timeline and has been deployed across retail partners in both markets:
Sri Lankan retail partners confirmed the system handled their complex cash-management workflows without friction. US-market testing validated that the speed and simplicity met American operator expectations. The configurable architecture proved its value - regional deployments required minimal engineering involvement.
Handover & Continuity
After successfully building and validating the system, we handed over WizPOS to the respective product owners at eWiz Solutions for continued development and improvement. The design system documentation, component libraries, workflow configuration guides, and frontend codebase were structured for long-term maintainability so their team could evolve the product independently from that point forward.
What We Learned
Watch hands, not faces
The most valuable research data came from watching operators' hands - where they hesitated, where they mis-tapped, where their rhythm broke. Interviews told us what operators thought they did. Observation showed us what they actually did. The two rarely matched.
Design for the 7th hour, not the 1st
A POS interface that works perfectly for a rested operator in the morning means nothing if it falls apart during the fatigue and pressure of hour 7. We learned to test at the end of shifts, not the beginning. That's when the real usability problems reveal themselves.
Colombo stress-tests better than any lab
If a POS system survives the chaos of Sri Lankan retail - inconsistent power, unreliable internet, diverse hardware, operators handling cash and conversation simultaneously - it's ready for any market. Our Sri Lankan validation phase caught issues that controlled lab testing would have completely missed.
Configurability is a design decision, not a dev decision
The choice to make workflows configurable rather than hard-coded wasn't just an engineering architecture decision - it was a UX decision. It meant designing interaction patterns that remained coherent regardless of which modules were active. That's harder than designing one fixed experience, but infinitely more scalable.
WizPOS taught me that POS design is physical design. It's not just screens and flows - it's fingertips, fatigue, and the unforgiving pressure of a customer waiting. Getting the human layer right means faster transactions, less training, and real economic impact for every retail partner who adopts the system.
Thank you for reading through the WizPOS case study.
References & Further Reading
- Apple Human Interface Guidelines - Touch Targets - Minimum 44pt touch target recommendations
- Material Design 3 - Accessibility - Touch Targets - Google's 48dp minimum touch target guidance
- ISO 9241-420:2011 - Ergonomics of human-system interaction - Selection-based input for interactive systems
- Nielsen Norman Group - Touch Target Sizes - Research on touch target sizing for usability
- PCI Security Standards Council - PCI-DSS compliance standards for payment processing
- U.S. Bureau of Labor Statistics - Cashiers - Occupational outlook and demographics data for US retail cashiers
- Nielsen Norman Group - Progressive Disclosure - UX pattern for reducing cognitive load
- Smashing Magazine - Accessibility Guide - Accessibility considerations for interactive interfaces