Social security, readable on a phone

Getting started

The National Social Security Fund (NSSF) administers contributions and benefits for workers across Cambodia. Members needed a mobile way to check payments and status without visiting a branch. I led UX/UI for the member app—translating policy-heavy information into screens people could actually use.

Project overview

Members do not want a “portal.” They want answers: How much did my employer pay in? What benefits apply to me? Is my account in good standing?

The legacy experience was built for administrators, not citizens—long PDFs, nested menus, and policy language copied verbatim into the UI. On a phone, that is not inconvenient. It is excluding.

Our mandate was civic tech in the true sense: make a complex government system legible on a 6-inch screen for workers, employers, and members across age and literacy levels—including users who rely on screen readers and large text.

[!NOTE] Insert 16:9 image: comparison of legacy policy-heavy screen vs. redesigned contribution summary card (blur any real member data).

Design process

I followed a four-phase process—Discover, Define, Develop, Deliver—to align policy constraints with member needs.

Discover

• Internal workshops with policy and operations teams
• Competitive review of civic and banking apps used in Cambodia
• Interviews and moderated tasks with members across age groups

Define

• UX strategy and success metrics (task completion, comprehension, support deflection)
• Task analysis for login, contribution lookup, and benefit status
• Storyboards for high-anxiety moments (first login, “action needed” states)

Develop

• Information architecture and user flows
• Low- and mid-fidelity wireframes
• Accessibility-first UI concepts and copy drafts

Deliver

• High-fidelity screens and interactive prototype
• Usability testing with policy review of every public-facing string
• Handoff patterns documented for future NSSF services

[!NOTE] Insert 16:9 image: four-phase process diagram (Discover → Define → Develop → Deliver) with NSSF-specific activities per phase.

User research

To understand what had to change, I ran local research with members, employers, and branch staff. Key findings:

Finding	Implication
Many members over 55 had never completed a digital government task	Onboarding must explain what NSSF is in one sentence before asking for credentials
Users feared tapping the wrong button on “official” screens	Destructive or ambiguous actions need plain labels + confirmation
Employers and members used different mental models for “contributions”	Separate entry paths; never mix employer payroll views with member benefit views
Low engagement with PDF policy downloads	Surface a one-line plain-language summary; link to legal text for those who want it

[!NOTE] Insert 4:3 image: research synthesis—top quotes and pain themes on sticky notes or affinity map (anonymized).

Market & competitive research

I reviewed how other Cambodian services present money, status, and rewards—banking apps, telco loyalty programs, and public-sector portals—to learn what members already understand.

Patterns that worked elsewhere:

• Timeline views for payment history (banking apps)
• Labeled status chips instead of paragraphs (telco account screens)
• Single primary action per screen (successful consumer apps)

Patterns we rejected for NSSF:

• Gamified “points” framing—benefits are rights, not rewards
• Dense dashboard tiles with no hierarchy—overwhelmed test participants
• Jargon borrowed from banking (“portfolio,” “insights”) without civic context

[!NOTE] Insert 16:9 image: competitive audit grid—3–4 apps with screenshots annotated for patterns borrowed or avoided.

Research synthesis

The backbone of the design direction:

• Show members what happened, when, and what it means—not statute references first
• Help users see contribution history as a scannable timeline, not a table of codes
• Make benefit status a single labeled state (“Active / Pending / Action needed”)
• Offer plain language + official policy link on every policy-driven screen
• Design for large text, screen readers, and low digital literacy from day one

[!NOTE] Insert 4:3 image: before/after copy block—dense government paragraph vs. plain-language card with “See official policy” link.

Usability scenarios

Scenario 1 — First-time member

A garment worker receives an NSSF letter and downloads the app. They need to see whether their employer paid last month’s contribution. They log in, land on a home screen with one clear “Contributions” entry, and complete the lookup without calling the branch.

Scenario 2 — Action needed

A member opens the app and sees “Action needed” with an icon and short explanation—not a red wall of legal text. They understand they must update a document, tap through to instructions, and know the deadline.

Scenario 3 — Older member, large text

A member over 60 enables system large text. Contribution cards reflow without horizontal scroll; screen reader order reads complete sentences for each period and amount.

User stories

Story 1 — Contribution lookup

As a member, I want to see my recent contributions in plain language, so that I can verify my employer paid without visiting a branch.

Acceptance criteria:

• Timeline shows period, amount, and employer name
• Each row has a “What this means” line in grade-8 reading level
• Official policy text is one tap away, not inline

Story 2 — Benefit status

As a member, I want to know my benefit status at a glance, so that I am not anxious about whether I am covered.

Acceptance criteria:

• Status uses color + icon + text (never color alone)
• “Action needed” explains the next step in one sentence
• Support entry is visible but not the only path

Information architecture

Top-level structure:

• Home — status summary, primary tasks, support
• Contributions — timeline, filters by period, detail drill-down
• Benefits — eligibility summary, status, policy links
• Profile & settings — language, accessibility, notifications
• Help — FAQs in plain language, branch contact

[!NOTE] Insert 16:9 image: information architecture diagram—top-level nav and second-level screens.

User flow

Core flow: Login → Home → Contribution timeline → Period detail → (optional) Official policy

Secondary flow: Home → Benefit status → Action needed → Instructions

Flows were validated in moderated sessions with emphasis on tap count and comprehension, not speed alone.

[!NOTE] Insert 16:9 image: Figma flow map—login → home → contribution timeline → benefit detail, with accessibility notes on each frame.

Design concept

UI principles

• Simplicity — one primary idea per screen; no scroll-heavy home
• Informative — amounts, dates, and labels before legal text
• Accessible — 44×44px targets, dynamic type to 200%, screen reader order tested
• Trustworthy — government tone without bureaucracy; no dark patterns

Simplification before decoration

We restructured information into scannable cards and timelines: contribution periods as a vertical timeline, benefit status as a single labeled state, not a paragraph of statutes.

AI for plain language—not chatbots

The highest-leverage AI use was translating institutional copy into human sentences under strict rules:

• One idea per line; grade-8 reading level target
• Every benefit statement links to “Official policy” for those who want the legal text
• Banned vague verbs (“processed,” “handled”) in favor of what actually happened and when

Human-in-the-loop workflow: model draft → designer + policy reviewer edit → UI string.

[!NOTE] Insert 3:4 image: contribution timeline at large text size—show cards reflowing without horizontal scroll.

Wireframing

Low-fidelity wireframes focused on hierarchy before visual polish:

• Home: one status module + two primary actions
• Timeline: card per period with expandable detail
• Benefit: status chip + “What this means” + policy link

Iterations removed nested menus and duplicate labels surfaced in testing.

[!NOTE] Insert 16:9 image: low-fidelity wireframe grid—home, timeline, benefit status (grayscale).

UI design

High-fidelity screens applied NSSF-accessible color contrast, consistent type roles, and icon+text status patterns.

Key screens shipped for Android and iOS-ready handoff:

• Login and onboarding
• Home with contribution and benefit entry
• Contribution timeline and detail
• Benefit summary and support entry

[!NOTE] Insert 16:9 image: benefit summary screen annotated with accessibility callouts (contrast, touch target, policy link placement).

Style guide

Documented for engineering and future NSSF services:

• Type — title, body, caption roles; minimum sizes for civic readability
• Color — status colors always paired with icon and label
• Components — timeline card, status chip, policy link row, primary button
• Content — plain-language rules and banned phrases list

[!NOTE] Insert 4:3 image: style guide excerpt—type scale, status chips, and timeline card specs.

The outcome

We delivered Android and iOS-ready flows for login, contribution history, benefit status, and support entry:

Measure	Result
First-time task completion (moderated, n=24)	61% → 89%
Participants 55+ completing contribution lookup unaided	4/6 → 6/6
Average taps to “see last contribution”	7 → 3
Accessibility audit (WCAG 2.1 AA target)	0 critical blockers on shipped paths

The moment members trusted the app

In testing, a participant over 60 said, “I always thought NSSF was only for office people.” After the plain-language benefit summary—with amounts, dates, and a single “What this means for you” line—they completed a contribution lookup without help. That sentence became the template for every policy-driven screen.

Patterns—timeline cards, status chips, plain-language + policy link—were documented for future NSSF services so the next policy update would not revert the UI to jargon.

What this case study shows: civic and government UX, radical simplification of bureaucratic systems, AI-assisted plain language with human oversight, and accessibility as a core deliverable—not an afterthought.