UX review process¶
This is a living process document. It describes how to review the customer-facing and staff-facing applications for usability, completeness, and consistency. It is not an architecture decision record — it will evolve as the applications grow and as better tooling becomes available.
The process is designed to be plug-and-play: anyone with access to the running app and this document can conduct a review without needing to carry knowledge from a previous session.
Scope¶
Two applications are in scope:
| Application | Entry point | Primary modules |
|---|---|---|
| Customer app | / — retail and SME customer-facing screens |
MOD-069, MOD-070, MOD-071, MOD-072, MOD-073, MOD-077 |
| Staff app | /staff or /backoffice — internal operations |
MOD-074, MOD-053 |
What AI can and cannot assess¶
Understanding this split is essential before running a review.
| AI-suitable | Human-required |
|---|---|
| Missing error and empty states | Whether a flow feels natural to a first-time user |
| Copy and microcopy quality | Emotional response — trust, anxiety, confidence |
| Consistency across screens (labels, patterns, tone) | Whether information hierarchy reads correctly at a glance |
| Accessibility attributes (ARIA labels, alt text, semantic HTML) | Cultural and demographic nuance |
| Information completeness (are all required fields labelled?) | Whether the interaction rhythm feels right |
| Unhappy-path coverage (what happens when a payment fails?) | First-impression visual appeal |
| DOM structure and semantic correctness | Screen reader and keyboard navigation feel |
| Console errors and network failures during a journey | Whether the app conveys the brand correctly |
A review is most effective when AI handles the systematic checks (completeness, consistency, accessibility) and a human handles the experiential judgement calls.
Personas¶
P1 — New retail customer¶
Profile: Individual customer who has just completed onboarding. First time using the app. No existing payees, no transaction history. Likely on mobile. May be unfamiliar with digital banking.
Goals: Activate account, understand the dashboard, add a payee, make a first payment.
Sensitivities: High anxiety around security prompts. Needs clear guidance at every step. Will abandon if confused by terminology (BSB, IBAN, reference fields).
Risk areas: KYC continuation screens, empty-state dashboard, first-payee flow, payment confirmation wording.
P2 — Established retail customer¶
Profile: Existing customer who uses the app regularly. Has payees saved, has transaction history. Efficiency-focused — wants to complete tasks quickly with minimal friction.
Goals: Check balance, pay a known payee, review transactions, manage a recurring payment, retrieve a document.
Sensitivities: Intolerant of extra steps. Notices when patterns change between sessions (button moved, label changed). Will notice slow loads.
Risk areas: Payment initiation speed, payee list usability, scheduled payment management, document download reliability.
P3 — SME business customer¶
Profile: Business owner or finance manager at a small-to-medium business. Uploads payroll and batch payment files. Manages a large payee list. Higher transaction volumes and amounts than retail. Responsible for payroll accuracy.
Goals: Upload batch file, review validation results, confirm and monitor batch settlement, handle quarantined or returned items, manage business payees.
Sensitivities: Errors are high-stakes (missed payroll, duplicate payment). Needs clear audit trail. Will need to handle the rejected-item and return flows, not just the happy path.
Risk areas: File upload UI (ABA/CSV), validation result presentation, quarantine notification clarity, partial-batch failure handling, batch settlement summary.
P4 — Customer service agent (staff)¶
Profile: Bank employee handling inbound customer queries, complaints, and disputes via the staff application. Has access to the customer 360 view. Works under time pressure with multiple cases open.
Goals: Look up a customer quickly, understand their account position and recent transactions, raise or update a complaint case, follow up on a dispute.
Sensitivities: Needs to locate information fast — any extra click has cost. Must be able to see exactly what the customer sees in their own app. Case status must be unambiguous.
Risk areas: Customer search and lookup speed, transaction drill-down, case creation form, case history readability, navigation between customer view and case view.
P5 — Back-office / compliance officer (staff)¶
Profile: Bank employee responsible for reviewing flagged transactions, AML alerts, and escalated cases. Needs full audit trail access. Decisions are documented and regulatory-grade.
Goals: Review a flagged case with full context, add a decision note, escalate or close a case, access supporting documents.
Sensitivities: Every action must be logged. Cannot accidentally trigger an action without confirmation. Needs to navigate complex cases without losing context.
Risk areas: Case detail completeness, decision logging UX, document access from within a case, audit trail readability.
Journey catalogue¶
Each journey is a unit of review. Run journeys independently — a single session need not cover all of them.
Customer app journeys¶
| ID | Persona | Journey | Entry | Exit condition |
|---|---|---|---|---|
| J-01 | P1 | First login and dashboard orientation | /login |
Customer sees account balance and understands the primary navigation |
| J-02 | P1 | Add a new payee and make a first payment | Account dashboard | Payment confirmed, appears in transaction history |
| J-03 | P2 | Pay a saved payee | Account dashboard | Payment confirmed within 3 steps |
| J-04 | P2 | Set up a recurring payment | Payment initiation | Scheduled payment visible in upcoming payments |
| J-05 | P2 | Edit or cancel a recurring payment | Scheduled payments | Payment removed or updated, confirmation shown |
| J-06 | P2 | View transaction history and search | Account dashboard | Customer finds a specific transaction |
| J-07 | P2 | Download a statement or document | Document vault | File downloaded successfully |
| J-08 | P2 | Update contact details | Profile / settings | Change saved with confirmation |
| J-09 | P3 | Upload a batch payment file | Batch payments | File accepted, validation results displayed |
| J-10 | P3 | Review batch validation and confirm | Batch validation screen | Batch moves to processing |
| J-11 | P3 | Handle a quarantined batch item | Batch status view | Customer understands which item was held and why |
| J-12 | P3 | View batch settlement summary | Batch history | Customer sees settled, quarantined, and returned counts |
| J-13 | P2 | International (SWIFT) payment | Payment initiation | Payment confirmed with FX rate and fee disclosed |
| J-14 | P1/P2 | Session timeout and re-authentication | Mid-session (idle) | Customer re-authenticates without losing context |
| J-15 | P1/P2 | Payment failure (insufficient funds) | Payment confirmation | Error shown clearly, no amount debited, recovery path offered |
| J-16 | P1/P2 | Payment failure (invalid account) | Payment confirmation | Error shown, payee not saved, guidance offered |
Staff app journeys¶
| ID | Persona | Journey | Entry | Exit condition |
|---|---|---|---|---|
| J-17 | P4 | Look up a customer by name or account | Staff search | Customer 360 view loaded with account summary |
| J-18 | P4 | View customer transaction history | Customer 360 | Agent can see last 30 transactions with amounts and status |
| J-19 | P4 | Raise a new complaint case | Customer 360 or case list | Case created, reference number shown |
| J-20 | P4 | Update an open case | Case detail | Note added, status updated |
| J-21 | P5 | Review a flagged case with full context | Case queue | Officer has all context needed to make a decision |
| J-22 | P5 | Record a compliance decision on a case | Case detail | Decision logged with officer ID, timestamp, and reason |
| J-23 | P5 | Access a document attached to a case | Case detail | Document opens or downloads without leaving case context |
How to run a review¶
Before starting¶
- Confirm the app is running:
pnpm devinbank-app→http://localhost:5173/ - Identify which persona and journey(s) you are reviewing
- Have this page open alongside the app
With AI assistance (browser tools)¶
When Claude has browser tool access (Claude in Chrome or Claude Preview connected):
- Tell Claude the persona and journey ID (e.g. "Run J-03 as P2")
- Claude navigates the journey, screenshots each meaningful screen state
- Claude reports findings against the checklist below
- Human reviews the screenshots and AI findings
- File a GitLab issue in
bank-appfor each finding (label:ux::review)
Without browser tools (human-led)¶
- Walk the journey yourself
- Screenshot or screen-record each screen state
- Drop screenshots into a GitLab issue with label
ux::reviewand notes - Tag Claude in the issue for a copy review pass if needed
Review checklist (per screen)¶
Completeness - [ ] All expected fields and labels are present - [ ] Empty states are handled (no blank/broken layout when list is empty) - [ ] Error states are defined (what shows when the action fails?) - [ ] Loading states are handled (spinner, skeleton, or progress indicator)
Consistency - [ ] Button labels match the action they perform (and match other screens doing the same thing) - [ ] Terminology matches the product glossary (no "transfer" vs "payment" inconsistency) - [ ] Navigation patterns match across comparable screens
Copy - [ ] All visible text is clear to the target persona - [ ] Error messages explain what happened and what to do next - [ ] Confirmation messages state what was done (amount, payee, date) - [ ] No placeholder text, lorem ipsum, or developer labels visible
Accessibility (automated) - [ ] No console errors on page load - [ ] Interactive elements have accessible labels (run axe or Lighthouse) - [ ] Images have alt text - [ ] Form fields have associated labels
Compliance touchpoints - [ ] PAY-001: Payment confirmation screen shows full details before commit - [ ] CON-005: FX rate and fees disclosed before international payment confirmation - [ ] AML-007: No indication of screening outcome exposed to customer
Issue taxonomy¶
File all UX findings as GitLab issues in totara-bank/bank-app with:
| Label | Use for |
|---|---|
ux::missing-state |
Empty, error, or loading state not handled |
ux::copy |
Text unclear, inconsistent, or incorrect |
ux::consistency |
Pattern differs from comparable screen without reason |
ux::accessibility |
ARIA, alt text, keyboard, contrast |
ux::compliance |
Disclosure or consent touchpoint not meeting policy |
ux::journey-broken |
Journey cannot be completed |
Include in every issue:
- Journey ID (e.g. J-03)
- Persona (e.g. P2)
- Screenshot of the problem state
- Expected vs actual
- Severity: critical (journey broken) / high (significant confusion likely) / low (polish)
Cadence¶
| Trigger | Scope | Who |
|---|---|---|
| New module deployed to staging | All journeys touching that module | AI-assisted walkthrough + human sign-off |
| Before go-live of any feature | Affected journeys only | Full checklist pass |
| Monthly | Random sample — two journeys per persona | Human-led, issues filed |
| On user complaint or support ticket | Specific journey reported | Immediate targeted review |
Visual regression (future)¶
When the app has sufficient stability:
- Add Playwright to bank-app CI with
--screenshotat key screen states - Commit visual baselines to
visual-baselines/in bank-app - CI diffs on each PR and posts changed screenshots as a merge request comment
- Human approves or dismisses the diff — CI flags but does not block
- Baselines updated deliberately when a visual change is intentional
This catches accidental regressions (button shifted, spacing broken, text truncated) without requiring a full review on every push.
Extending this process¶
This document is intentionally incomplete. As the application grows, add:
- New journeys as modules are deployed (add a row to the journey catalogue above)
- New personas as new customer types are onboarded (SME, wealth, corporate)
- New compliance touchpoints as regulated features go live
- Automation scripts for journeys that are stable enough to script repeatably
Changes to this document do not require an ADR. Update it directly as the process evolves.