Users had to configure the system before understanding its value.
The ABA platform was designed to help barristers access courts, forms, and legal resources. But the experience created friction before users could even begin.
New users were forced through a heavy onboarding flow: select jurisdictions, add courts, navigate multiple setup screens. ~4 steps before they could touch the product.
What I Heard
I interviewed Michael Green, a practising barrister and the product's primary stakeholder, and Sean Simpson, our librarian SME, to understand how the existing platform was actually being used. The feedback was blunt.
"I hate it too."
On the existing onboarding experience
"It's just a long way of getting to the High Court website."
On the platform's perceived value
"163 forms for Fair Work Commission alone."
On the scale of content that needed structured access
Forced jurisdiction selection before access
Multiple setup screens (~4 steps) blocking entry
Value proposition invisible until setup complete
System-driven flow misaligned with user intent
Reframing the problem
This wasn't an onboarding issue. It was an access problem. Users should be able to start immediately and configure later.
Remove the Onboarding Entirely
Instead of fixing the onboarding, I removed it. Users land directly into the product. Courts can be added optionally. The system is usable from first interaction.
Zero setup required. Two immediate actions available: search anything, or browse by task. The product works before any configuration.
Task-based Entry
The new landing experience opens with a single hero prompt: "What do you need to do?" Supported by search as the primary entry and task shortcuts for common actions: commence, respond, appeal, and more.
Barristers arrive with intent. "I need to file a defence" not "I want to browse." The interface respects that.
4-step onboarding wizard replaced by a single optional modal. 5 courts, 2 jurisdictions, one action.
Setup When Ready, Not Before
Court configuration still exists, but it's optional and available when the user is ready. Grouped by jurisdiction (Commonwealth, NSW, Victoria), barristers can pin the courts they work with most.
The difference: this is a shortcut, not a gate. The product works without it.
Court-based Information Architecture
The original platform organised content by type: forms in one section, rules in another, practice directions elsewhere. But barristers don't think in document types. They think in courts.
"I need the form for the Federal Court" not "I need to browse the forms section." This insight, validated through SME interviews, drove the entire IA restructure. Courts became the primary object. Each court contains its own forms, rules, practice directions, and fees. 163 forms for Fair Work Commission alone needed structured, court-scoped access.
All Courts: 12 courts across 9 jurisdictions. Form counts, practice directions, and filing methods visible at a glance.
My Courts: pinned courts with relevant acts, rules, and forms surfaced per court
Court detail: forms grouped by task intent. "Commence proceedings" and "Respond / Appear" reflect how barristers arrive at forms, not how a CMS organises them.
Saved Items: Quick Access Over Navigation Depth
Through SME interviews, I found that users frequently revisit the same items: Defence forms, Statements of Claim, specific court rules. Quick access matters more than navigation depth.
Saved items and recent links persist in the left panel across all views. Return users go straight to what they need.
Saved items (Defence, Statement of Claim) and recent links in the left panel, accessible from any page
The key wasn't adding features. It was removing the wrong ones.
Removed Forced Onboarding
Eliminated the ~4-step setup flow. Users access the product immediately.
System-driven → Task-driven
Shifted from "configure your environment" to "what do you need to do?"
Court-based Mental Model
Barristers think in courts, not document types. The IA follows their mental model.
Lightweight Personalisation
Saved items and recent activity instead of heavy upfront configuration.
The answer was subtraction.
This project moved fast because the problem was clear. PRD, SME interviews, stakeholder feedback rounds, and design iteration compressed into a tight cycle. The biggest design decision wasn't what to add. It was recognising that the onboarding flow was the problem, not the solution, and removing it entirely.
