Android POS UI Redesign

---

The Problem

The legacy Android POS system had been in production for 4 years. What began as a clean interface had accumulated technical debt — features were appended to the navigation without reorganization, error messages reflected system language rather than operator language, and the information architecture was never validated with the users actually operating the terminals.

By late 2020, the symptoms were measurable:

• 12% operator error rate during critical flows: In session analysis, 1 in 8 transactions required manual intervention due to operator-induced errors — wrong button taps, lost confirmations, and failed recovery from error states. The most common cause: the main menu listed 12 options with near-identical visual weight and no clear hierarchy.
• Navigation confusion: Six of the 12 main menu options were used by fewer than 2% of operators in any given week. The 4 most-used functions (Charge, Settle, Refund, Reports) were visually indistinguishable from Advanced Settings, Device Diagnostics, and Terminal Lock — options that could disrupt operations if accidentally triggered.
• Opaque error recovery: Error messages displayed system-level descriptions ("Gateway timeout: ERR_AUTH_2204") without explaining what had happened or what the operator should do. Operators called support for error recovery at a rate that made settling-related tickets 40% of Transbank's total POS support volume.
• Accessibility gap: WCAG testing revealed 14 critical accessibility failures across the legacy interface — insufficient contrast ratios, icon-only navigation without text labels, and no keyboard navigation support for the review and settings flows.
• Competitive pressure: A competitor's iOS POS app was gaining market share in Santiago's food service sector, primarily on the strength of its simpler, faster interface. Merchant churn risk was real, with 3 enterprise accounts explicitly mentioning the competitor's UX in quarterly business reviews.

Why now: Transbank was preparing to launch contactless and digital wallet payment support in 2021. Adding new payment types to the existing interface without first resolving the underlying information architecture problems would compound the confusion. Leadership committed to a full interface redesign before adding new feature surface area.

---

What the research showed

We went in with four questions:

1. Which tasks cause operators the most errors, and what are the specific failure points?
2. What mental model do operators have of the POS system, and where does the current design conflict with it?
3. Can a single redesigned interface serve operators across all store types (retail, gas, restaurant, pharmacy), or are context-specific variants needed?
4. What design changes would reduce error rates for critical flows without requiring operator retraining time that merchants aren't willing to invest?

We ran five parallel research tracks over six months: moderated usability testing, session recording analysis, contextual inquiry across four store types, a full audit of support tickets, and interviews with merchants, managers, and operators.

They converged on the same conclusion from five different directions. Operators were not struggling because the terminal lacked features. They were struggling because the interface gave equal weight to a destructive action and a routine one, and left them guessing about everything outside a handful of buttons they had memorized.

Method	Participants / data	Key finding
Moderated usability tests18 sessions	24 terminal operators, ages 20–65, ranging from 6 months to 15+ years of experience, across retail, gas station, restaurant, and pharmacy environments	75% (18 of 24) made at least one critical error in the settle/close flow. The most common: tapping Void Transaction when they meant to view transaction history. The two options shared visual priority and sat next to each other. Recovery took 2–3 minutes per incident.
Session recording analysisHotjar	500+ recorded sessions from live Transbank terminals, 300+ hours reviewed over 10 days	Fewer than 2% of sessions touched 6 of the 12 main menu options. The 12-option menu was not creating decision paralysis so much as risk: 4 destructive options (Void, Terminal Lock, Factory Reset, Device Diagnostics) sat at the same visual level as daily-use functions.
Contextual inquiry12 full shifts	4 store types (grocery, gas, restaurant, pharmacy), 8–10 hours per site, observing operators through peak and off-peak periods	Workflow rhythms differed sharply by context: gas stations work in a 1–2 second transaction window, restaurants need splits and comps, pharmacies process frequent refunds, grocery settles at shift end. But all four leaned on the same 4 core functions. The variation lived in secondary flows, not primary ones, which meant one interface with a well-built More menu could serve every context.
Support ticket analysis	6 months of tickets (2,400 total, January to June 2020), categorized by issue type	1,040 tickets (43%) were navigation and error-recovery questions: “How do I settle?”, “I pressed the wrong button.”, “The screen says ERR_2204, what do I do?” Every one of them was an orientation and clarity failure, not a feature gap. No operator asked for new functionality.
End-user interviews	8 merchant owners, 10 store managers, 24 terminal operators (separate from the usability test group)	Operators consistently described 3–5 buttons they used daily and admitted they guessed at the rest or called support. One quote came back nearly verbatim from 6 independent participants: “I know Charge, Settle, and sometimes Refund. Everything else is a mystery. I’m scared to touch things I don’t recognize.”

The three patterns underneath

Destructive actions had the same visual weight as routine ones. Void sitting beside transaction history is not a labeling problem, it is a hierarchy problem, and it produced errors in three quarters of tested operators.

Most of the menu was dead weight. Half the main menu options went essentially unused, while the 4 that mattered competed for attention with everything else.

Nobody wanted more. 43% of six months of support volume was people asking where things were. Not one ticket asked for a feature that did not exist.

Problem Definition

Primary user — Terminal Operator: Age 20–65, retail or hospitality environment, processing 50–200 transactions per shift. No formal technical training. Goal: process payments quickly and accurately, avoid errors, and recover from problems without calling support.

Secondary user — Store Manager: Age 30–55, responsible for shift settlement, daily reconciliation, and reporting. Uses the POS for business intelligence as well as transaction management. Needs to complete reconciliation quickly and accurately at the end of each shift.

Job-to-be-done (Operator):

"When a customer is ready to pay and a line is forming behind them, I want to complete the transaction and see confirmation in under 10 seconds, so I can serve the next customer without stress, errors, or manual recovery."

Job-to-be-done (Manager):

"At the end of my shift, I want to close the terminal and reconcile transactions in under 2 minutes — without calling support — so I can hand off and leave on time."

How we defined success (set before designing):

Metric	Baseline	Target	Measurement Method
Operator error rate (critical flows: Charge, Settle, Refund, Close)	12%	< 5%	Post-launch production error tracking via mobile analytics
Task completion rate (critical transactions, unassisted)	88%	95%+	Usability testing pre/post with 8+ participants per task
Time-on-task: Settle/Close (full flow, including confirmation)	3–4 minutes average	< 90 seconds	Session recording analysis, pre/post production comparison
Support tickets (settling and transaction-related category)	~1,000/month	< 600/month	Zendesk category trending
Operator confidence: "I can complete transactions without calling support"	54% agreeing (pre-launch survey)	85%+	Post-launch survey, 200+ operators
WCAG AA compliance	14 critical failures	0 critical failures	Automated + manual accessibility audit

---

Design Process

Directions explored before converging:

1. Reorganize existing 12-option menu Improve grouping, typography, and visual hierarchy of the existing menu structure without removing options or changing the fundamental IA.

• Why considered: Least engineering and retraining burden; preserves merchant familiarity with existing layout
• Why we moved on: Session recording analysis showed that 6 of 12 options were used by < 2% of operators. Reorganizing them doesn't remove the risk surface — it just rearranges the danger. Operators' mental model, validated in interviews, was that they used 4–5 functions and were confused or afraid of the rest. Better labeling didn't solve the wrong information architecture.

2. Tile-based visual dashboard Replace the text list menu with a visual grid of icon tiles representing each function.

• Why considered: Visual differentiation might improve discoverability; modern aesthetic might reduce perceived complexity
• Why we moved on: Tested with 4 operators unfamiliar with the new design. Tile scanning took longer than text list scanning because operators needed to interpret icon meaning before acting — adding a visual decoding step. Tiles also didn't solve the core problem (all 12 options remained equally visible). 3 of 4 users said they'd need more training time than with a text list.

3. Progressive disclosure with clear primary/secondary hierarchy — what we built 5 large, clearly labeled primary action buttons (Charge, Settle, Refund, Reports, Settings) always visible. A visible "More" button provides access to all secondary and advanced functions without hiding them entirely.

• Why this won: Research confirmed that 95%+ of daily transactions use exactly 4 functions (Charge, Settle, Refund, Close). Reports is used by managers for reconciliation. Everything else is secondary. Progressive disclosure applied Hick's Law directly: reducing visible choices from 12 to 5 reduced decision time and dramatically lowered the risk of accidentally triggering dangerous operations (Void, Factory Reset, Terminal Lock). In testing with 8 operators, 8/8 found primary functions without guidance — vs. 2/8 in legacy navigation testing.

The key design decision — placement of the "More" button:

We debated three placements: (A) hamburger icon in the header (compact, but not discoverable for less tech-savvy users), (B) explicit "More" button in the primary action row (visible, requires 8px of vertical space), (C) swipe-left gesture (modern, but not discoverable without training).

We tested all three with operators aged 20–65. Users 50+ failed to discover the hamburger icon (6/8 attempts) and the swipe gesture (7/8 attempts). The explicit "More" button had 100% discovery within 10 seconds across all age groups. We chose option B despite the layout trade-off. Accessibility and reliability across all operator ages outweighed aesthetic economy.

Key design decisions and tradeoffs:

What we prioritized	What we sacrificed	Why this was the right call
Simplicity and predictability for core operator flows	Visual sophistication and design novelty	Operators in contextual inquiry explicitly said they were afraid of "touching things I don't recognize." Their relationship with the terminal was built on predictability. A simple, functional design that operators trusted immediately was more valuable than a visually ambitious design with a higher learning curve.
Consistent interaction patterns across all store types	Context-specific UI optimizations per merchant vertical	Research showed the 4 core actions were universal. Context variation was in secondary flows (restaurant splits, pharmacy refunds) — not primary ones. Investing in one well-designed universal interface was more efficient and produced a more reliable user experience than 4 semi-designed vertical variants.
WCAG AA compliance from initial design	Faster initial design timeline	The accessibility audit found 14 legacy failures that had likely existed for years. Building compliance in from the start (not auditing at the end) saved 2 weeks of post-design rework and produced a better product. Accessibility constraints also improved the design for all users — the decision to avoid color-only differentiation, for example, made error states clearer for everyone.
Explicit progressive onboarding for "More" menu on first launch	Clean, uninterrupted first experience	Testing showed that without a tooltip, operators who didn't encounter a need for secondary functions in their first week forgot the "More" menu existed. A single, dismissible tooltip on first launch ("Tap 'More' for reports, settings, and advanced features") increased advanced function discovery from 18% to 71% in follow-up testing. One interaction for a large usability gain.

Iteration based on testing:

After initial prototyping, we ran moderated usability tests with 8 terminal operators across two rounds.

• Finding 1: Operators didn't distinguish between "Void Transaction" (cancels an authorized-but-not-settled transaction) and "Refund" (returns cash after settlement). Three operators in the first test round tapped the wrong option. We moved "Void Transaction" into the "More" menu (it's used in under 1% of transactions) and added a confirmation screen: "This will cancel the authorized payment. The customer will NOT be charged. Continue?" Confusion was eliminated in round 2.
• Finding 2: Error messages still used technical language in a first prototype draft — "Auth response: ERR_DECLINED_2201." We rewrote every error message to operator language ("Payment declined — the customer's bank didn't approve this payment. Ask the customer to try another card.") and added specific recovery steps. In round 2 testing, all 8 operators correctly identified the issue and took the right recovery action without asking for help — vs. 3/8 in round 1.
• Finding 3: The Settle/Close flow originally required 5 confirmations ("Are you sure?" screens at each step). Operators found this tedious and began tapping through confirmations without reading them. We reduced to 2 meaningful confirmations (final summary before submitting, and acknowledgment of successful settlement) and removed the intermediate screens. Completion time dropped from 4.2 minutes to 68 seconds in round 2 testing.

---

The Solution

A simplified, accessible Android POS interface built on progressive disclosure and a reusable component system designed to scale to new payment types and merchant contexts without requiring interface redesigns.

1. Simplified Main Dashboard 5 large primary action buttons (Charge, Settle, Refund, Reports, Settings) occupy the full primary view, sized at 56px tall × 140px wide with clear text labels and distinguishing icons. A "More" button in the footer provides clearly labeled access to secondary functions (Void Transaction, Terminal Lock, Device Info, Receipt Settings, Admin). The visual hierarchy makes the daily-use functions immediately obvious and the high-risk functions non-prominent.

2. Plain-Language Error States Every error state in the system was rewritten to answer three questions: (1) What happened? (2) Why? (3) What should I do now? For example:

• Before: "ERR_2204: Gateway timeout"
• After: "Payment couldn't be processed. The connection to your bank timed out. Check your internet connection, then tap 'Retry.' If this keeps happening, call Transbank support at 800-XXX-XXXX."

28 distinct error scenarios were documented and individually designed with appropriate tone (informative for operator-recoverable errors, urgent-but-calm for errors requiring support escalation).

3. Simplified Settle/Close Flow Reduced from 5 confirmation steps to 2. The flow shows a transaction summary screen (total transactions, total amount, any flagged discrepancies), a single-button confirm submission, and a success acknowledgment screen with timestamp. Operators can complete settlement in under 90 seconds from flow entry.

4. Reusable Component Library 85 screens built from 34 reusable components (buttons in 4 states, alert types in 5 severity levels, input fields, progress indicators, navigation patterns, modal confirmation dialogs). Component specifications include state rules, accessibility requirements, and spacing definitions. The library reduced engineering implementation time for the initial build and, post-launch, enabled the contactless payment UI to be built in 4 days (vs. estimated 3 weeks) using existing components.

5. WCAG AA Compliance All 14 legacy accessibility failures resolved. Key decisions: 4.5:1 minimum contrast on all primary elements, icon + label + color redundancy on all status indicators (no color-only differentiation), 56px minimum touch targets, VoiceOver/TalkBack support on all critical flows, and Spanish-language interface by default with Portuguese language variant shipped simultaneously.

---

Results & Impact

Measurement approach: Staged rollout. Phase 1 deployment to 20% of the terminal network (1,600 devices) across 8 geographic regions. Parallel monitoring of Phase 1 terminals vs. legacy terminals over 4 weeks. Full network rollout followed in weeks 5–12.

Measurement period: 4 weeks of A/B comparison data (1,600 redesigned vs. 6,400 legacy terminals) + 8 weeks post-full-rollout monitoring.

Scale during A/B window: 1,600 terminals, 400+ stores, 800+ operators, 30,000+ daily transactions in Phase 1 cohort.

Metric	Before	After	Change
Operator error rate (critical flows)	12%	2.5%	-79%
Task completion rate (critical transactions, unassisted)	88%	96%	+9%
Time-on-task: Settle/Close (full flow)	3.8 minutes avg	58 seconds avg	-75%
Support tickets (settling/transaction-related)	~1,000/month	~580/month	-42%
Operator confidence: "I complete transactions without needing support"	54%	89%	+35pp
WCAG AA accessibility failures	14 critical	0	100% resolved
Support ticket resolution time (this category)	8–10 minutes avg	2.5 minutes avg	-70%

Business impact:

The 79% reduction in operator error rate translates directly into checkout quality across Transbank's full 8,000-terminal network. At 150,000 daily transactions, a 12% error rate represented 18,000 transactions per day requiring manual recovery (each costing 2–3 minutes of operator time). Phase 3 reduced this to 3,750 — and then further, with the full network rollout showing sub-3% error rates. The throughput recovery during peak hours was immediately visible in merchant satisfaction surveys.

Support ticket reduction of 42% across the Phase 1 cohort, applied proportionally to Transbank's full merchant base, represents approximately $210K/year in support labor savings at fully-loaded cost per ticket.

The reusable component library reduced design-to-engineering time for contactless/NFC payment feature addition (Q4 2021) by an estimated 50% — a feature that would have required 3+ weeks of interface design was completed in 6 days using existing components. This created a compounding efficiency gain for every subsequent feature addition.

Qualitative signal:

Post-launch survey of 200 terminal operators (6 weeks post-rollout, across 40 store locations):

• 94% agreed: "The new interface is easier to use than the old one"
• 89% said: "I can complete transactions more quickly with the new design"
• 84% reported: "I don't need to call support as often now"

Representative operator feedback: "I don't have to remember where everything is anymore. The buttons I use every day are right in front of me. When something goes wrong, the screen actually tells me what to do — I haven't called support once this week."

Store manager: "Before, I'd watch my team spend 5 minutes just trying to settle because they couldn't find the button. Now it's under a minute. That adds up every single shift."

---

Learnings

What worked:

1. Progressive disclosure is the right pattern for high-stakes, low-training-time interfaces. Operators didn't want more features or more guidance — they wanted fewer choices at the moment of decision. Surfacing 5 primary actions and hiding the rest removed the fear of accidentally doing something irreversible. The "More" button gave power users access without burdening daily operators. This pattern — surface what 95% of people need 95% of the time — is now my default for any interface used under time pressure.

2. Error messages are the most undervalued design surface in operational software. Rewriting 28 error messages from system language to operator language reduced support tickets in this category by 42%. The design effort was minimal — a writing exercise, not an interaction design exercise — but the impact was among the highest of any change we made. Every operational interface I design now has an explicit error language guide as a deliverable.

3. Component systems pay dividends immediately, not just over time. The conventional argument for component libraries is future velocity. In this project, the component library paid off within the same project: the contactless/NFC feature, launched 5 months after the redesign, was built in 6 days instead of an estimated 3+ weeks. Any project that expects feature additions after launch should treat the component library as a first-class deliverable, not a nice-to-have.

4. Testing with the oldest and least technically experienced users first. Our "More" button placement decision was driven entirely by testing with operators aged 50+. Had we tested only with younger, more tech-savvy operators, we would have shipped a hamburger icon that 75% of our real user base couldn't find. Designing for the edge of the user spectrum consistently produces better outcomes for the center.

What I'd do differently:

1. Instrument production analytics before design, not after. We defined success metrics at the start of the project but didn't configure production tracking until 2 weeks into the staged rollout. This meant our first 2 weeks of A/B data had gaps. I should have written the analytics instrumentation spec as part of the design handoff document, ensuring tracking was ready before the first terminal went live.

2. Conduct longitudinal usability observation. All our testing was single-session. Real operator proficiency (and real failure modes) emerge after someone has used a system for a week — habits form, shortcuts get created, errors shift from novice to expert patterns. A 2-week in-field pilot with 3–4 volunteer stores, where I observed operators using the actual system (not a prototype) over multiple shifts, would have caught the intermediate-proficiency failure modes we only discovered post-launch through support ticket analysis.

3. Involve Transbank's support team in the research phase, not the design review phase. Support staff had a detailed, lived understanding of the 20 most common operator confusion points. We interviewed them in Week 8 of design (when the IA was 85% locked). Their input changed several error message designs but came too late to influence the navigation structure. Involving them in Week 1 — as a primary research source alongside terminal operators — would have shaped the IA from the start.

What this opened up:

This project established Transbank's first formal Android design system — the 34-component library and 85-screen Figma file became the source of truth for all POS interface work going forward. The direct follow-on outcomes were:

• New payment types at 50% lower design overhead: Contactless/NFC (Q4 2021), digital wallet integration (Q1 2022), and installment payment UI (Q2 2022) were all built on the existing component system, each requiring design work measured in days rather than weeks.
• Internationalization template: The component system's separation of content from design enabled the Portuguese-language variant (Brazil market expansion) to be delivered in 3 days — compared to a projected 4-week effort before the component library existed.
• A/B testing infrastructure: The modular component architecture made it straightforward to test UI variations with live operator cohorts (button size variations, color theme testing, notification timing). Transbank's product team ran 4 A/B tests in the 6 months following launch — a capability that didn't exist before because the monolithic legacy design couldn't be modified in isolation.