A mobile app that helps wheelchair users and people with mobility impairments find, verify, and share accessible spaces in Lisbon — before they arrive at the door to find out it isn't.
Portugal has accessibility regulations — Decreto-Lei 163/2006 mandates ramps, accessible toilets, and specific clearance widths in public buildings. Lisbon signed up to them. The problem is that the regulations exist on paper, and the streets are made of 18th-century cobblestone.
Most accessibility apps treat this as an information problem: map the ramps, mark the lifts, done. But after speaking with wheelchair users, I learned the real problem is trust. Information about accessibility is often wrong, out of date, or missing entirely. The consequences of getting it wrong aren't inconvenience — they're humiliation and physical danger.
Accessibility in architecture isn't just a checkbox. I know what a compliant ramp gradient looks like (1:20 slope, 1.5m turning radius at base), what a legal accessible toilet needs (1.5m × 1.8m clear floor area, grab bars at specific heights), what "accessible door width" actually means (900mm clear). This fluency let me evaluate claimed accessibility with technical precision — and recognise when spaces that called themselves accessible weren't. It also gave me credibility with users who'd been burned by bad data before.
I conducted 6 semi-structured interviews. Three participants were wheelchair users. Two were caregivers — one a family member of a person with MS, one a professional support worker. One was a physiotherapist who regularly scouted venues for clients. No one I spoke to trusted any existing tool.
"I've been to places rated 'fully accessible' on Google and found four steps at the entrance. You know what that means when you're alone in a wheelchair at 8pm?"
It aggregates crowd-sourced accessibility data — but with no verification standard. A business owner can mark their own venue accessible. Users add ratings without understanding what accessibility requirements actually are. There's no way to know if the information reflects reality or someone's well-meaning but uninformed opinion.
Wheelmap (the leading dedicated accessibility app) uses a traffic-light system: green/yellow/red. It's intuitive, but wildly imprecise. "Partially accessible" tells you nothing about whether the bathroom works, whether the lift is in service, or whether the accessible entrance is at the back through a car park. It answers the wrong question.
| Feature | Google Maps | Wheelmap | AccessMap (designed) |
|---|---|---|---|
| Accessibility data | Crowd-sourced, unverified | Crowd-sourced, traffic-light only | Verified by community + architect check |
| Granularity | Yes/No only | 3-level rating | Per-feature (entrance, toilet, lift, parking) |
| Caregiver view | None | None | Separate planning mode with route preview |
| Last verified date | Not shown | Not shown | Always visible, flaggable if outdated |
| Photo evidence | General photos only | None | Accessibility-specific photo prompts |
| Offline access | Partial | None | Full route saved for offline use |
Every participant had been burned by inaccurate accessibility information. Many had stopped using apps entirely and relied instead on personal networks.
Nobody wants to explore spontaneously. The primary task is pre-trip verification — not discovery while out.
Caregivers scout on behalf of someone else. They need route information, not just venue ratings — drop-off points, lift locations, accessible toilet distance from entrance.
Became a wheelchair user at 24 following a cycling accident. Has rebuilt his social life since, but navigating Lisbon remains daily mental labour. Goes nowhere without researching it first.
Cares for her mother, 84, who uses a walker and has early-stage dementia. Plans every outing meticulously. Her mother's confidence and safety depend on Helena having done her homework.
People with mobility impairments in Lisbon need a way to trust accessibility information before leaving home — because current tools are either too generic to be useful or too unverified to be reliable.
HMW make accessibility verification feel credible — not just crowd-sourced opinion?
HMW serve caregivers who are planning for someone else's needs, not their own?
HMW show the right amount of detail without overwhelming users who just need a quick answer?
The insight from research was that ratings weren't the problem — trust in ratings was. So I stopped thinking about how to build a better star system and started thinking about how to make each data point verifiable.
Each accessibility feature is rated independently (entrance, toilet, lift, parking, seating). Ratings show a confidence score based on: number of reports, recency, photo evidence, and whether any report came from a verified accessibility professional. An architect or OT badge raises confidence significantly.
Crucially: the date of last verification is always visible. Users can flag outdated information. Flagged items drop in confidence score immediately.
A toggle switches from "I'm going" to "I'm planning for someone." In caregiver mode, results surfaces different information: drop-off proximity, lift wait times, quiet hours, and the ability to save a full route — not just a destination — with accessibility notes at each waypoint.
This wasn't a feature from research. It emerged from noticing that Helena talked about planning differently from Diogo. She was doing logistics, not wayfinding.
I used Portuguese and EU accessibility standards (DL 163/2006, EN 17210) to define what each feature category actually means. "Accessible entrance" in AccessMap means: level threshold or ramp ≤ 1:20, minimum 900mm clear door width, no step exceeding 20mm. This isn't arbitrary — it's the legal standard. Users can see the criteria behind each rating, which builds trust precisely because it's specific.
I started with paper sketches to explore the information hierarchy — how much detail to show at the list level vs. the venue detail level. The breakthrough was separating "can I get in?" from "what's it like inside?" These needed different screens because they were different questions at different moments in the journey.
The app itself had to be accessible. I designed for: minimum 4.5:1 contrast ratio on all body text (checked against --bg2 backgrounds), 44×44pt minimum touch targets throughout, no reliance on colour alone to communicate status (icons + text labels always accompany colour coding), and screen-reader-friendly label order so the confidence score reads before the venue name. These weren't afterthoughts — they were built into the component design from the start.
Round 1 was moderated, remote. Round 2 was moderated, in-person — I specifically recruited a wheelchair user and a caregiver so I could observe real motor interactions with the prototype, not just verbal think-aloud.
4 of 5 participants didn't understand what the percentage confidence meant. They assumed it was a satisfaction rating, like a restaurant review. Fix: replaced "87% confidence" with "Verified recently · 14 reports · 2 professional checks" — concrete, not abstract.
Only 1 of 5 participants found the caregiver toggle without being prompted. It was buried in settings. Fix: moved to the home screen as a primary choice: "I'm going" / "I'm planning for someone" — a mode selection, not a setting.
The "add a photo" CTA didn't tell users what to photograph. Result: participants uploaded general venue photos. Fix: specific prompts — "Photo of the entrance," "Photo of the toilet door width" — with an outline guide showing what to capture.
After saving a route, users weren't sure it had been saved for offline use. Fix: added a brief confirmation state with an offline indicator and the file size of the saved route.
"The last verified date is the thing I'd actually use. I don't care if 50 people said it was accessible two years ago. Things change."
The final design is built around one principle: show your work. Every rating has a date, a number of reports, and a breakdown by feature. Every photo is attached to a specific feature category. The confidence score is expressed as a trust narrative, not a number.
Instead of "this place is accessible," AccessMap says: "The entrance was verified 3 days ago by 4 people. The toilet was last reported 6 weeks ago and has been flagged as potentially changed." Users get the information they need to decide whether to trust it — not a number that hides all of that away.
The app opens with a mode choice. This frames the session: are you going yourself, or planning for someone? Everything after adapts — the information shown, the level of detail, what gets saved. This was the change users responded to most strongly in round 2 testing.
I ran a post-design WCAG audit using Figma's contrast checker and Axe. Results: all text passed AA contrast (most passed AAA). All interactive elements met 44pt minimum. Colour was never used as the only indicator — every status used both colour and a text label. Screen reader order was validated by mapping out tab sequences manually.
Designing for disability is designing for trust. Every decision that erodes trust — a rating with no source, a date that isn't shown — costs real-world safety. Research made this viscerally clear in a way no brief could.
My architecture background was genuinely useful here — not just as a credential but as a tool. Knowing what a compliant ramp actually requires meant I could build verification criteria that actually mean something. Domain knowledge isn't separate from UX work; it shapes what questions you ask.
The caregiver mode came from listening carefully to someone who wasn't my primary persona. If I'd designed only for Diogo, I'd have built a good tool for him and missed Helena entirely. The lesson: recruit beyond your assumptions about who the user is.
In-person testing with a wheelchair user in round 2 revealed interaction patterns I couldn't have predicted. The phone mount angle, one-handed use, screen glare outdoors — none of this came up in remote testing. Proximity to the real use context matters.
Next case study
RenoFlow — Home Renovation Planner →