Case Study 1 - UX & Flow (Auth‑Gated, Human‑Friendly)

Series: Part 1 of 6
Role: Project Lead (discovery → high‑fi)
Stack lens: Power Pages, Dataverse, SharePoint, Liquid, custom SCSS

The brief behind the brief

We didn’t just need a prettier listings page; we needed a first minute that matters. Stakeholders asked for a search experience that was fast and trustworthy and a business rule that gated search behind sign‑up/sign‑in so only eligible Specialist Disability Accommodation (SDA) participants (and their coordinators) were in the funnel. My job was to make the gate feel like a front door, not a brick wall.

North star: “Find a viable property in under a minute - without guesswork or dead ends - while meeting the eligibility and consent requirement.”

What this meant in practice

• The public marketing pages stay open and indexable.
• Search, listings, and detail become authenticated features tied to Participant/Coordinator roles.
• Consent and a light eligibility attestation are part of sign‑up - clear, short, respectful.

Flow, then pixels

I started with white‑board boxes and arrows, then moved to low‑fi Figma frames:

home → sign up / log in → eligibility check → search → cards → detail → apply.

Only once the path felt honest did I paint it.

User Journey

Why this order works

• The gate is light: sign‑in or quick sign‑up, pick your role (participant/coordinator), confirm eligibility, accept a plain‑language consent statement. Then search unlocks.
• We don’t over‑collect suburb‑level context and contact are enough pre‑application. Everything sensitive lives later in Apply.
• Marketing pages stay public and indexable; the catalogue sits behind auth.

Auth & Eligibility

Low‑fi to high‑fi: the decisions that matter

Low‑fi frames let us argue about flow without getting distracted by colour. High‑fi captured the reusable bits and the voice.

Kept from low‑fi

• Search and filters are above the fold; chips show active filters.
• The eligibility step is one screen with minimal fields and a clear consent line.
• Property cards show only what helps choose: type, suburb, bedrooms, SDA category, a tiny badge for availability.

Added at high‑fi

• Clear two‑door path: “I’m an SDA participant” / “I’m a support coordinator.”
• Microcopy that tells the user why we ask: “We gate search to ensure listings are used by eligible SDA participants and coordinators.”
• A tiny progress breadcrumb on Apply (Step 1 of 3) so users never fear a scroll‑abyss.
• Empty‑state coaching that suggests broadening filters or nearby suburbs when results are thin.

Mobile first, then stretch

• Filters collapse into chips and a modal on small screens; keyboard/VO order is preserved.
• Card content reflows to keep touch targets ≥ 44px. No precision tapping required.

Handover notes
I didn’t maintain a separate token sheet/component spec - Figma was the source of truth. Dev Mode exposes variables (colours, spacing, radii) and component states for inspection. That kept velocity high as a solo builder and ensured code mapped cleanly to design.

UX writing: plain words, precise intent

• Eligibility copy: “I confirm I’m eligible for Specialist Disability Accommodation (SDA), or I’m a support coordinator acting on behalf of an eligible participant.”
• Consent copy: “I agree NDISP may contact me about properties I view or apply for. You can update this later.”
• Privacy guardrail: “Street addresses appear after an application progresses. Listings show suburb/region only.”
• Why gate copy (inline explainer): “We protect participant privacy and keep this catalogue relevant to people in SDA.”

These lines reduce ambiguity, improve trust, and support later table‑permission logic.

Error & help copy (examples)

• “Please choose Participant or Coordinator so we can show the right options.”
• “We couldn’t verify your session. Try signing in again.”
• “No properties match those filters yet. Try expanding the suburb or removing a feature.”

Accessibility is table stakes

From day one: contrast that passes WCAG AA, visible focus rings, keyboard‑first flows, and components that announce themselves correctly.

• Filter chips are buttons with aria-pressed and a clear pressed state.
• Form errors tie to inputs via aria-describedby; success messages never rely on colour alone.
• Colour tokens in Figma map straight to theme variables in code, so the UI stays consistent.
• Focus order matches visual order; the Skip to filters link appears for keyboard users on listings.

Screens that tell the truth

The high‑fi kit moved as a small constellation of screens:

• Auth + Eligibility: one screen, two roles, one confirmation, one consent.
• Listings: filters, chips, paginated cards, empty‑state that teaches how to broaden a search.
• Detail: scannable facts, eligibility summary, stable gallery hero.
• Apply: three steps, clear labels, inline validation. Save isn’t needed for v1 (not enough steps to justify friction).

Micro‑interactions

• Apply CTA sticks on mobile without covering content.
• Filters announce counts (“4 results”) to assistive tech after updates.

Edge cases and how we softened them

• Friction at the gate? Keep the form minimal; allow SSO if available; show why we ask. Later, A/B a read‑only preview (blurred cards) with a prompt to sign in for details.
• No results found? Offer nearby suburbs and relaxed filters; keep a visible “Clear all” action.
• Slow connections? Skeleton screens; first paint favours filters and cards; images lazy‑load with fixed width/height to avoid jumps.
• Expired sessions? Retry pattern on queries; gentle reauth prompt that preserves the last state.

What we deliberately cut (v1 scope discipline)

• Guest deep browsing: avoided to respect the eligibility requirement; marketing pages cover discovery.
• Map‑heavy UI: cards + filters solved the decision faster; maps are a future enhancement.
• Save & resume: unnecessary for the short apply flow; noted as a v2 candidate.

What success looked like (without hard numbers)

We didn’t get a long runway for analytics post‑launch, so I used qualitative signals and proxies during review:

• Review sessions where coordinators could find a viable option within a minute on the prototype.
• Fewer “where do I click next?” questions in stakeholder playbacks.
• Back‑office editors publishing without hand‑holding (a sign the screens matched the schema you’ll see in Case 3).
• Auth + eligibility working without support tickets during cut‑over.

If runway had continued (measurement plan)

• Track time to first result from sign‑in to filtered list.
• Record apply step drop‑off (no PII; aggregate only).
• Watch filter usage to prune low‑value facets and promote high‑value ones.

From Figma to build (preview of the next cases)

Design decisions were made with build in mind: components are small and composable; copy is plain; states are explicit. That’s why the rest of the series plugs in cleanly:

• Case 2: Turning tokens/components into a theme and small Liquid parts.
• Case 3: Schema that mirrors these screens, with Participant/Coordinator roles and consent stored on the profile.
• Case 4: A model‑driven app that prevents half‑published listings.
• Case 5: Automation that turns uploads into stable galleries.