Case Study 1 - UX & Flow with Pre‑Approval Onboarding (NDISP)

Series: Part 1 of 6
Role: Product & UX lead (discovery → high‑fi → build handoff)
Stack lens: Figma, Power Pages constraints, plain‑language UX writing, accessibility heuristics

The brief (told from inside the room)

NDISP asked for something deceptively simple: make vacancies easy to find and apply to - without the email circus.

Two realities shaped the build:

1. The catalogue must be used only by eligible SDA participants (including those applying on their behalf).
2. Onboarding is pre‑approval: new visitors don’t get instant accounts; they join the community via a multi‑step registration that captures NDIS details, the Intake team verifies eligibility, and only then an account is issued so users can sign in to search and apply.

One more thread worth a nod: as part of the same program, I also rebuilt NDISP’s marketing site - more modern, content‑fit, and aligned with the portal’s voice. I’ll tip my hat to it here for context, but this series stays with the listings/applications story; the marketing rebuild stands as its own case study that I might put together one day.

North star: “Help the right people reach the right property in under a minute - after a respectful, pre‑approved onboarding - while keeping privacy and consent intact.”

Listening first, then drawing

I ran workshops with intake, property ops, and marketing. Those conversations surfaced the non‑negotiables: WCAG AA accessibility, predictable URLs, a consented funnel, and critically, an Intake‑verified onboarding that front‑loads the data they need.

Personas that actually drove decisions

I designed around three real people I could picture in the room. The participant or family who just wants clarity - “is this suitable, and is it near where life already happens?”- without re‑typing the same details twice. The support coordinator juggling calls who needs filters that behave and links that don’t break (even though, in the system, every issued account is simply a participant). And Intake, who only approves clean, complete submissions and therefore needs the right NDIS details up front so there’s no back‑and‑forth.

Flow before pixels

I used low‑fi frames to prove the Join → Verify → Search journey; then I translated it into high‑fi that Power Pages could wear.

End‑to‑end journey

Why this order works

Putting pre‑approval first meant only verified participants - including those applying on someone’s behalf - ever reached the catalogue, which keeps both privacy and relevance intact. By front‑loading NDIS details, contact and consent at registration, Apply becomes almost one‑click later; you’re confirming, not starting from scratch. And the public storytelling stays where it belongs: marketing pages are open and indexable, while the catalogue itself sits behind issued accounts.

What the registration actually captured (multi‑step)

I broke registration into a calm, multi‑step form: identity and contact; the NDIS specifics Intake actually checks; a clear, revocable consent line for future opportunities; and an optional note about accessibility needs so we could tailor comms later. After submit, the record landed in Intake. When approval came through, the portal issued an invitation to set a password. From there, logging in drops you straight onto Search & Filters, and Apply arrives pre‑filled with what we’ve already gathered — only a few specifics left to confirm.

Registration Step 1 — identity & contact

Registration Step 2 — NDIS details for eligibility check

Consent step with clear language and checkbox

Low‑fi → high‑fi: decisions that did the heavy lifting

On paper I argued with myself about the path; in high‑fi I set the language the platform could wear. I kept the post‑login, search‑first catalogue with filters above the fold, the eligibility summary high on the detail page so no one begins an application just to hit a blocker, and a three‑step Apply that mirrors how Intake thinks — only now it’s pre‑filled from registration. I added a friendlier Join the community entry with a visible progress bar, a single line explaining why onboarding comes first, and gentle empty‑state coaching. On mobile, the Apply call‑to‑action sticks in view without ever covering content.

Post‑login listings with filter chips and result count

Property detail with eligibility summary and sticky Apply

Mobile view — Search above the second fold

UX writing: plain words, precise intent

I wrote the screens like I was talking to one person across a desk. “Join once, and I’ll pre‑fill your applications. Intake will confirm eligibility and send your sign‑in.” The attestation is plain: “I’m eligible for Specialist Disability Accommodation (SDA), or I’m applying on behalf of an eligible participant.” Consent is explicit and revocable: “NDISP may contact me about properties I view or apply for. You can update this later.” And the privacy promise is unambiguous: “Listings show suburb/region; full addresses appear only as applications progress.”

Microcopy close‑up of attestation and consent language

Accessibility is table stakes

I baked accessibility in, not on. Focus rings are bright enough to see, and keyboard‑only paths work end‑to‑end — Tab → Skip to filters → Arrow through chips → Enter. Errors are tied to inputs with aria‑describedby so screen readers announce them at the right time. Filter chips are real buttons with aria‑pressed, and every control has a generous touch target. It looks good, but more importantly, it behaves predictably.

Screens that tell the truth (high‑fi set)

By the time high‑fi landed, the experience matched the promise: a welcoming Join the community flow with a progress indicator; a clean, no‑nonsense login; a post‑login listings view with filters and chips that behave; a detail page that leads with the facts that matter; and an Apply form that arrives mostly complete because we already asked the hard questions once.

Join the community — step progress indicator

Login screen with accessible labels and error handling

Detail — gallery hero and fact list

Edge cases and how I softened them

Where there’s friction, I softened it. Registration keeps each step small and saves as you go. If Intake declines, the site doesn’t dump you — it offers resources and a human contact. On slow connections, skeletons appear first and images lazy‑load with intrinsic dimensions, so the layout doesn’t jump. If a session drifts, the re‑auth prompt returns you to exactly where you were.

Onboarding & approval state machine

Evidence without vanity metrics

Because the business wound down a few months after launch, I didn’t get the luxury of long‑tail analytics. What I did see was clean: people moved from onboarding → approval → first search without support tickets; Apply was calmer because registration had already done the heavy lifting; and Intake confirmed the NDIS details they needed were arriving up front. If we’d kept going, I would have tracked onboarding completion, time to first result after the first login, filter usage, and any drop‑off inside Apply—aggregate only, no extra personal data.

Handover reality (solo, fast)

Figma was the living spec. Dev Mode exposed variables and component states; there was no separate token sheet.

Figma Dev Mode panel with color/spacing variables

Because I built the theme/components next, variable names in Figma matched SCSS, and component anatomy mapped 1:1 to Liquid includes.

What I shipped vs what I didn’t

I shipped the pre‑approval onboarding, Intake review and account issuance, the login‑gated catalogue, and a pre‑filled Apply flow. I also rebuilt the marketing site so the public story matched the portal’s voice - kept light in this series, but part of the same program. I didn’t ship the long‑tail analytics, a compare view, or save‑and‑resume (it wasn’t necessary once Apply became short and pre‑filled), and I didn’t build an external‑user version of the access management tooling.