WizPosTM 2.0

Introduction

My first involvement happened in 2021, when eWiz Solutions partnered with 365 Ventures (Pvt) Ltd and brought me in to redesign an already basic-developed POS that was actively being built. That phase continued through the end of 2022.

At that time, the focus was primarily on stabilizing and improving a scoped-down local POS experience: better usability, better visual hierarchy, better operator efficiency, and stronger touch ergonomics.

A few years later, in 2026, I took the completed-but-left-out product direction forward independently. I restarted the journey from product-design-first principles and expanded the system from limited scope to full scope.

The result is WizPosTM 2.0: an AI-first ecosystem with local Electron runtime, ReactJS-powered product interfaces, backend-connected operations, encrypted local storage, encrypted cloud POS backup, real-time multi-location and multi-till monitoring, and advanced user management.

WizPos now has a new vision: to become the most reliable, fastest, user-friendly, hassle-free, AI-first POS system in the world.

What Changed in WizPos 2.0

• Scope expansion: Evolved from local checkout tooling into a broader AI-first commerce platform with operational intelligence.
• Local runtime foundation: Electron-based POS layer for resilient in-store execution with low-latency interactions.
• Cloud ladder model: Tiered access to cloud backup, live analytics, and centralized control based on business maturity.
• Security baseline: Encrypted local data stores plus encrypted cloud POS backup for recovery and audit continuity.
• Operational scale: Multi-branch, multi-till live monitoring with advanced user roles and permission controls.
• Industry depth: Domain-specific workflows and terminology for hospitality, retail, and event-driven operations.

Industry Focus for the 2026 Rethink

The information architecture was reshaped around real operating sectors rather than generic POS menus. Core target sectors include:

• Hospitality: pubs and bars, restaurants, hotels, members clubs, and night clubs.
• Retail: high-throughput checkout with role-aware controls and branch-wide visibility.
• Takeaways: fast order flow, quick tender loops, and fulfillment-focused handoff states.
• Schools and universities: controlled access, identity-linked transactions, and operator governance.
• Entertainment and sports venues: burst traffic handling with rapid lane continuity.
• Pop-events: temporary setup patterns for mobile or short-term commercial operations.
• Hotelmax and all-sector mode: umbrella templates for mixed-format enterprise deployments.

Design Inputs Used for This Case Study Extension

This case study extension is grounded in your attached reference material: current industry POS screenshots in live operation, original early-stage developer screens, and 2021 wireframes that align with the present design structure. Together, these artifacts map the transformation from the first system state to the 2026 WizPos 2.0 direction.

My Role

I covered two phases with different ownership models. In 2021-2022, I worked as UX Engineer inside the eWiz + 365 Ventures collaboration. In 2026+, I became the independent product owner and design/implementation lead for WizPos 2.0.

I own the full pipeline: research, product strategy, design in Sketch, interaction prototyping in Principle, UI implementation in HTML/CSS, and delivery alignment with ReactJS/Electron/backend engineering. What I design is what gets built, because I stay inside execution.

I collaborated closely with:

• eWiz Solutions + 365 Ventures (2021-2022 phase) - original redesign stakeholders during the initial transformation period
• ReactJS/Electron/Backend Engineering - implementation collaborators aligned to the product architecture and delivery quality bar
• 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.

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

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.

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.

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.

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.

Why This Layout Is Correct (Real-World Validation Data)

• Field sample: Validated through 15+ cashier and supervisor interviews and live counter observations captured across Sri Lankan supermarkets during 2021-2022, then re-checked in 2026.
• Speed context: Operators observed at roughly 20-30 scanned items per minute during peak hours, which required a low-friction action zone with minimal finger travel.
• Touch reliability baseline: We used 18mm minimum touch targets with 4mm spacing, and 22-24mm for high-risk actions (tender/refund/void) to reduce miss-taps under shift fatigue.
• Layout split logic: The main action side is intentionally larger (~52%) for frequent taps; the observe side (~48%) keeps cart and context visible without overloading the interaction zone.
• Glance strip purpose: A slim bottom strip is reserved for quick state checks (status/alerts/progress), so operators can validate system state in under a second without leaving the transaction flow.
• Cross-device behavior: This layout pattern was tested across 7", 10", and 15" POS surfaces to keep reach and speed consistent from compact counters to full terminal lanes.

The Problem Space

Synthesizing field observations, interviews, and market research, we identified four core problems that defined our design challenge:

The Challenge

WizPOSTM faced a specific set of constraints that shaped every design decision:

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

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:

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).

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.

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.

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.

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.

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.

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

WizPOSTM 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.

Ownership & Continuity

The 2021-2022 redesign phase built the operational foundation. From 2026 onward, I continued the product independently as WizPos 2.0 and expanded it into a full local + cloud ecosystem. Product direction, UX systems, and implementation quality are now governed under my ownership, with ongoing delivery across design, ReactJS/Electron product layers, and backend-connected workflows.

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.