Designing for stressful systems: lessons from SENDadvisor

SENDadvisor is a national directory for families of children with Special Educational Needs and Disabilities. The people using it are not browsing for fun. They’re often stressed, time-poor, and navigating a system that feels designed against them — full of jargon, fragmented across 153 local authority websites, and structured around council boundaries rather than how families actually look for help.

Designing for that context is different from designing for a casual user. Here’s what I learned.

The user is already overwhelmed before they arrive

Most product design assumes a user in a relatively neutral state — curious, maybe goal-oriented, not in distress. SEND families are often the opposite. They’ve been through a diagnosis, a referral, maybe a rejected EHCP request. They’re looking for help, and they’re looking for it now.

That changes everything about the interface:

• No splash, no marketing. The first thing they see is search. Location-aware, category-filtered, results-first. No hero banner, no "Get started" — just the tool they came for.
• No jargon without a plain-English translation. EHCP, Local Offer, SENDIASS, IPR — real terms families need to know, but also barriers. Every one is paired with a plain-English explanation, inline or one click away.
• No friction in the critical path. No account required to search. No login wall, no newsletter popup. The thing they need — listings near them — is available immediately.

Trust is the primary feature

A directory is only as good as the trust families place in it. Stale, inaccurate, or commercially biased listings make the product worse than useless — they make it a false promise.

So trust signals are part of the product model, not bolted on:

• Genuine review counts. Not "★★★★★" with no context. Actual moderated reviews from actual families, with dates and provenance.
• Verified provider claims. A provider can claim a listing, but the claim is verified — not just "this email matches" — and the verification state is visible.
• Source attribution on every listing. Where did this data come from? When was it last updated? Council, provider, or community contribution — it’s visible.
• Moderation that’s visible. Q&A is moderated, and there’s a visible "reviewed by our team" signal, not a silent filter.

Trust isn’t a badge. It’s a system.

The taxonomy follows the family, not the council

SEND services are administratively complex: 153 English local authorities, each with its own Local Offer, its own SEND team, its own EHCP pathway. The temptation is to mirror that structure — one page per council, organised by boundary.

Families don’t think that way. A parent in Norwich doesn’t care that a specialist service is technically in South Norfolk vs Norwich City. They care that it’s 20 minutes away and it does what they need.

So the taxonomy is built around family needs:

• Category routes for days out, services, and schools — the things families actually search for, not "Category A / Category B".
• Location-aware search as the primary surface. Postcode or location, then results, then filter.
• Every LA gets a dedicated page with Local Offer URL, SEND team contacts, and EHCP pathway notes — not because families care about the council, but because the council is the gatekeeper, and having that information in one calm place saves hours of fragmented searching.

Accessibility is non-negotiable — and it’s an advantage, not a constraint

SEND families include disabled parents and carers. An inaccessible site excludes the exact people it exists to serve.

But accessibility in this context is more than WCAG compliance — it’s cognitive load:

• Plain English throughout. Simplified without being condescending — stripped of unnecessary complexity.
• Clear category routes, not a sidebar of filters. Horizontal icon bars, photo-first cards. The interface should feel like a calm place, not a database query form.
• Keyboard, screen reader, 200% zoom — all tested. The user might be a parent with a visual impairment, a carer using a switch device, or someone on a phone in a hospital waiting room.

Designing for accessibility in a stressful context makes the product better for everyone. The calm interface, the plain language, the fast search — they help the stressed parent and the casual visitor equally.

The data pipeline is the product

None of the above matters if the data is bad. SENDadvisor’s 11,000+ listings come through a verified pipeline — gatherer → enricher → verifier → publish — with a state machine that keeps half-finished records off the public site. A local enrichment audit server reviews batches before any D1 write. Every pipeline write is logged with source attribution.

That’s not visible to the user, and it shouldn’t be. But it’s the reason the user can trust what they see.

The lesson: in a stressful-system product, the invisible infrastructure is what makes the visible experience trustworthy.

What I’d do differently

• Start with the content earlier. I built the platform before the data pipeline was fully mapped. In hindsight, the pipeline should have been the first thing.
• Invest in moderation tooling upfront. It was initially manual and ad-hoc. Proper tooling from day one would have saved weeks of operational debt.
• Local Offer pages were underestimated. I thought they’d be a small feature. They’re one of the most-used parts of the site, because they consolidate information families currently spend hours hunting for across council websites.

Designing for stressful systems isn’t about removing all the stress — you can’t do that. It’s about not adding to it. A calm, trustworthy, fast directory that works on a phone in a waiting room is a small thing. But for the family using it, it’s the difference between giving up and finding help.