You'll see phrases like "science-backed" and "designed for accessibility, including ADHD" on this site. Here's what stands behind them, in plain language.
Several of us on this team are autistic, have ADHD, or both. We know what it's like to lose a task to a context switch, freeze at a form with too many choices, or spend more energy fighting an interface than doing the work it was meant to help with. We built Humble to solve that for ourselves first. Now we want it to work for anyone who's spent their life adapting to tools that weren't built with them in mind — a product you belong in as you are, not one you have to learn to cope with.
Accessibility claims get used loosely across the education sector. We don't want ours to be another one of those. This page sets out what we actually do, what it's based on, and where we still have work to do — updated as that work continues.
People with ADHD and other accessibility needs are involved while we design and test Humble, not brought in to check a finished product.
We follow a written set of interface rules aimed at reducing cognitive load — for example, one main task per screen, colour used only to show status, and nothing moving or resizing unless someone deliberately caused it. These come from published accessibility research, including participatory guidelines developed with autistic adults, not from internal opinion alone.
Every screen goes through a language review before release — sentence case, short sentences, no jargon left undefined, UK English throughout.
"Science-backed" describes the research we draw on to set our design rules, not a clinical study of Humble itself. We haven't run our own peer-reviewed trial yet. What we have done is build our interface guidelines on published accessibility and neurodivergence research, and reviewed them against real usage. As that evidence base grows — including any research on Humble specifically — we'll update this page and add citations to the principles below.
These are the specific problems we build against, and how we approach each one. We're compiling the published research behind them so they're checkable, not just asserted — that work is ongoing. For visual accessibility specifically, we build to the Web Content Accessibility Guidelines (WCAG) AA standard throughout.
Working memory is the bit of the mind that holds what you're doing right now — a due date, a half-finished sentence, the reason you opened a tab. It has a limited capacity, and for a lot of ADHD brains, it fills up faster and empties sooner. That's why a due date can vanish the second something else grabs attention. We design so nothing important depends on remembering it — the current step, and what's still open, stay visible on screen.
Time blindness means a sense of time that doesn't track clock time reliably — "later" and "in ten minutes" can feel the same, and an hour can vanish without registering. It isn't poor planning or not caring. We build in visible countdowns and clear due points, rather than expecting an internal sense of time to do that work.
Every extra thing you have to hold in your head — what you were doing, what tab you were on, what's next — is a cost. For a lot of ADHD and autistic brains, that cost is higher, and it adds up across a day. We design so the current step is always visible on screen, so you're never relying on memory to pick up where you left off.
Colour means one thing at a time in Humble — status, not decoration. We use a small, consistent palette and enough contrast to read easily, so a screen doesn't compete for your attention before you've even started reading it.
You shouldn't have to relearn how a screen works every time you open a new part of Humble. Buttons, layout and patterns stay consistent across the whole product, so you can rely on what you already know instead of memorising fresh rules for each area.
Most fields are optional unless we genuinely need them. We don't ask you to choose between options that don't matter, and we don't block you with a decision you could make later. Fewer required inputs means fewer moments where you have to stop and work out the "right" answer before you can carry on.
Read the standard we build to: WCAG guidelines →
Spotted a claim on this site that needs a source, or have research we should be citing? Email us →
