Last spring I watched a researcher spend forty minutes helping a man with early-stage dementia tap a single button on a tablet. The button was labelled Continue. He kept pressing the grey area just outside it, and the app closed. Again. And again. Nobody in that room was surprised except the developer, who had tested the flow on his own phone and pronounced it "obvious".
That scene is the whole argument for inclusive technology design for dementia research in miniature. The software wasn't broken. It was designed for a brain that wasn't in the room. And when you're running a study with people living with dementia, a design failure isn't an inconvenience — it's a data integrity problem, a consent problem, and, frankly, a dignity problem.
Below is what I've learned about doing this properly: co-designing with participants rather than for them, applying cognitive accessibility standards that already exist but rarely get used in research settings, and handling the ethics that nobody puts in the slide deck.
Key takeaways
- Co-design with people living with dementia is not a focus group bolted onto the end — it changes the protocol, the consent process, and the tool itself.
- Cognitive accessibility frameworks (WCAG's simpler conformance levels, universal design principles) are written down already. Most research tools ignore them.
- Consent in dementia research needs to be treated as a process you revisit, not a form you sign once.
- Digital exclusion will quietly bias your sample toward wealthier, more educated, less impaired participants unless you plan against it.
- Report your usage metrics and drop-out rates honestly. Silent attrition is where inclusive design claims go to die.
Why inclusive design changes the research, not just the interface
There's a comfortable assumption that accessibility is a layer you add at the end — bigger fonts, higher contrast, done. For dementia research that assumption collapses fast, because the tool is usually the measurement instrument. If a participant can't complete the task, you don't have a frustrated user. You have a missing data point, and the person most likely to be missing is the one with the most significant impairment.
Think about what that does to your findings. A memory study where the app is too fiddly for moderate-stage participants ends up describing mild-stage participants only. The headline says "people with dementia", the reality says "people with dementia who can operate a mid-range Android tablet". That gap gets published. It gets cited. It shapes what the next team assumes is true.
The hidden attrition problem
In my own experience running a small pilot with twelve participants, four never completed the baseline session — and all four dropped for interface reasons, not health reasons. That's a third of the sample gone before the study properly began. We only knew because we logged every abandoned session with a timestamp and a screenshot. Without that logging, we'd have reported "eight participants enrolled" and quietly moved on.
So the first design decision isn't visual at all. It's instrumenting the tool to record failure, not just success. Where do people stop? How long do they hover before giving up? Which screens produce a back-navigation within two seconds? Those signals are your real accessibility audit, and they're also your ethics committee's best evidence that you're looking after participants.
How do you co-design with people living with dementia?
You ask them. Then you believe the answer when it's inconvenient.
The co-design literature on dementia is not thin — the Dementia Engagement and Empowerment Project in the UK, the work around the European Working Group of People with Dementia, and years of participatory design papers have all pushed the same direction: people with dementia are experts on their own experience and can contribute meaningfully to design decisions when the process is adapted to them. What's thin is practice. Teams still run a single consultation session near the end, call it participatory, and ship whatever they'd already built.
What adapted co-design actually looks like
Some of what has worked, in my own projects and in teams I've worked alongside:
- Short sessions. Forty-five minutes maximum, with a break, and never more than one conceptual task per session.
- Two facilitators — one to run the session, one to watch for signs of fatigue or distress and to step in without ceremony.
- Physical props over abstract mockups. A printed screen on card, a foam button, a paper prototype that can be pointed at and moved. Screens on glass are slippery to talk about.
- Involve carers as partners in logistics, not as proxy voices. A carer can tell you the person is tired; they cannot tell you what the person prefers.
- Pay people for their time. It's work. Treat it like work.
And here's the part teams find hardest: sometimes the co-design answer is "this shouldn't be a screen at all". We redesigned one recall task from a tap-the-tile interface to a physical card-sorting exercise paired with a single yes/no button, and completion went from roughly half to nearly all of the pilot group. The technology shrank. The study got better.
What about consent in co-design?
Consent is where inclusive design for dementia research stops being a UX conversation and becomes a legal and ethical one. Capacity to consent can fluctuate — it may be present in the morning and absent after a poor night's sleep, and it can change over the course of a study. That means consent is a process: accessible information sheets, a check of understanding in plain language, agreement revisited at each session, and a clear route for a participant to withdraw without penalty or awkwardness. Many jurisdictions allow for consultee or proxy arrangements where capacity is absent, but the detail varies enormously — check your local rules and your ethics board, not a blog post.
The practical design implication: build withdrawal into the interface, not just the paperwork. A single, always-visible, calmly-labelled exit is not a threat to your completion rate. It's the condition under which the rest of your data is trustworthy.
Which accessibility frameworks apply to research tools?
More than most research teams realise, and they're not all about vision.
The Web Content Accessibility Guidelines are the obvious starting point, but the useful part for dementia work isn't the checkbox list — it's the underlying principles of perceivable, operable, understandable, robust content. The understandable principle is where dementia-specific work concentrates: predictable navigation, no surprise modals, plain language, error messages that say what to do next rather than what went wrong. Universal design principles, long championed in ageing research, add the useful reframing that designing for the edges improves the experience for everyone.
A practical comparison of design approaches
Here's how the common approaches stack up when the participant group includes people with cognitive impairment.
| Approach | What it prioritises | Where it falls short for dementia research |
|---|---|---|
| Standard WCAG conformance | Technical accessibility of web content | Silent on cognitive load, fatigue, and session duration |
| Universal design | Usability across the widest range of people | Broad by design; needs dementia-specific detailing |
| Participatory co-design | Lived experience shaping decisions | Demands time, training, and budget most grants don't include |
| Assistive technology retrofit | Adapting existing tools for individual users | Hard to standardise across a study cohort |
None of these is sufficient alone. In my view the strongest combination is universal design as the baseline, co-design to catch what the frameworks miss, and WCAG conformance as a floor you don't argue your way below.
The ethics and data protection questions nobody wants to answer
Research technology with cognitively vulnerable participants generates data that is unusually sensitive: location traces, interaction timings, sometimes audio or video. Add remote monitoring and you've built, in effect, a surveillance system that a person may not fully grasp even after a careful consent conversation.
The catch is that capacity to understand a research protocol and capacity to understand what data a sensor collects over six months are not the same thing. The second is harder. In practice, that pushes you toward data minimisation — collect the interaction events you need for the analysis and nothing more — and toward a plain-language data sheet reviewed by participants or their carers. Under the UK GDPR and the EU GDPR, research purposes do offer some flexibility, but they do not suspend the principles of purpose limitation and transparency.
What practical barriers stop teams getting this right?
Three, consistently.
- Digital exclusion. Participants without home broadband, or who have never used a tablet, will decline or fail for reasons unrelated to cognition. Provide devices and connectivity, and train on the study tool itself.
- Cost and time. A co-design process with ten participants across four sessions is real money. Budget it at proposal stage, not from the underspend.
- Researcher skills. Most of us were trained in methods, not in facilitating sessions with people who may become distressed. That's a trainable skill and it should be a line item.
And there's a fourth that teams rarely admit: the study design itself. A protocol that requires ninety minutes in one sitting is inaccessible by construction, no matter how clean the interface.
What good evidence would actually look like
Here's my honest frustration. The field has strong principles and thin outcome data. I can tell you what good inclusive design for dementia research looks like in practice, and I can show you a pilot where completion rates went from half to nearly all — but I can't point you to a robust body of comparative studies showing which design decisions change clinical or research outcomes, because that body isn't there yet.
What would fix it is unglamorous. Publish your task completion rates. Publish your attrition, split by cause. Report the time-to-abandon curves. Describe your co-design sessions honestly, including the ones that went badly and what you changed. If you build a tool and only the easy half of your cohort can use it, say so in the limitations section rather than burying it.
Because the man at that tablet wasn't a design problem to be solved. He was a participant who had agreed to give his time to research that was supposed to be about him — and the least we can do is build the thing so he can actually take part. If your interface requires a researcher to sit beside every participant for forty minutes, you haven't designed an inclusive study tool. You've designed a supervised one, and you've accidentally measured your own patience instead of his memory.
