Guide
Where this started
Checking a route should not take longer than the trip
Guide is a navigation app for wheelchair users. It finds routes that meet ADA requirements, warns people about obstacles and crowds before they get there, and shows where the nearest elevators, ramps and accessible restrooms are. I built it so someone can find out whether a route will work before they leave the house.
Why I built it
My brothers used wheelchairs, and every trip out had to be planned
Two of my brothers, Nate and Jake, used wheelchairs. They had epidermolysis bullosa, a condition that makes skin fragile and causes blisters, so going out took planning. Someone in my family had to find out beforehand where the ramps were, which door worked, and whether there would be a crowd.
I thought about building this app for years before I had the skills to do it. Most people can leave the house without checking whether they will be able to get through the door. I wanted wheelchair users to be able to do the same.
How do you tell someone a route will work before they leave the house, traveling on their own?
Finding out about an obstacle when you arrive is too late
- 01
Decide which obstacles actually stop a wheelchair, and leave the rest off the map.
- 02
Show that an elevator is ahead without making the user stop and read.
- 03
Design for someone who is moving and cannot look at their phone for long.
Four out of five people had never seen accessibility info in a map
I ran a survey with over 20 responses and interviewed people who use a wheelchair or travel with someone who does. Two problems came up every time: the path was not usable for people in wheelchairs, and there was no way of knowing that before going on the route. I built the app to tell people about both before they leave.
The survey showed me how common the problem was. The interviews showed me what it is like to plan every trip around it. If I could only run one of the two, I would run the interviews.
What interviewees had to say
“Electric doors not always functioning properly, or not being in place. Elevators being in very inconvenient places”
“Not every space has ADA accessible entrances which can be difficult for such users.”
“With too many ppl in a crowded space it is hard to manage a wheelchair without hitting people especially when you’re in a rush”
The survey results
Every percentage below is measured from my own survey responses. Hover a segment to see its share.
Knowledge
- 80%No
- 20%Yes
"Have you ever used an app, map or website that included accessibility information about a public space?"
Confidence Level
- 58%Not Very Confident
- 32%Somewhat Confident
- 10%Other
"If a friend/family member asked you for advice about which public spaces are accessible, how confident would you feel giving them accurate info?"
Grouping the answers into themes
I put every survey answer and interview note on a board and grouped the ones that said the same thing. Five themes came out of it: physical barriers in public, gaps in the information people are given, maintenance that is not kept up, low confidence recommending a place to someone else, and the features people asked for.
Four key insights
What the research came down to
- 01
The problems people hit most often
- Lack of ramps
- Broken elevators
- Poor signage
- Crowded spaces
- 02
Confidence giving accessibility information is low
Most people did not feel confident telling someone with a disability whether a place would be accessible.
- 03
People want real time data
Respondents wanted to know whether a route is accessible right now, not whether it was accessible once.
- 04
People who go out more have seen the problems
Respondents who visit public spaces often had run into these accessibility problems themselves.
The personas showed me what frustrated each group
I built personas for wheelchair users and for the people who travel with them. The personas helped me write down the pain points and what frustrated each person. My first versions matched the app I already wanted to build, so I rewrote them using what people told me in the interviews.
The user flow
Three versions of the route screen, and why I picked the third
Option 1 drew the route and the obstacles, but it had no way to end the trip and no key for the icons, so you had to learn the map before you could use it. Option 3 labeled the symbols and added an End button without adding a step. I picked Option 3 because it works when you only have one hand free, even though it is not the best looking of the three.
When I put three options side by side, I pick the best looking one and find reasons for it afterwards. So now I write down what the screen has to let someone do before I lay the options out, and I score each option against that list. If I only compare the options to each other, one of them looks best even when all three are bad.
I picked the version with a Call button over the better looking one
Option 1 looked clean because it left out the address and the opening hours. I picked Option 3, which puts the most important information first and gives you one obvious thing to do next. In testing, the Call button was what got people through the task. People on that screen want to know whether someone can confirm the place will work when they arrive.
Five things people wanted to know before going on a route
Everything people told me came down to five things worth marking on a route: elevators, ramps, crowds, accessible restrooms, and a way to report something broken. I started with a longer list, and cutting it down was most of the work. Five markers is as many as someone can read quickly while they are moving. I kept the report marker because it is what keeps the map accurate after I stop updating it.
- Elevators
- Ramps
- Crowds
- Bathrooms
- Report
A route is only reliable if someone checked it recently
The app gives one route, the most accessible one with the fewest detours. It favors paths that are maintained, marked and confirmed by someone recently. You can open the route to see elevator status, ramp condition, and anything that has been reported.
People plan their day around an accessibility map. I think launching one and then not updating it is worse than never launching it, because the person who finds out it is wrong is already standing outside a door that does not open.
- Elevator Status
- Ramp Conditions
- Reported Obstacles
The finished prototype
The design kit
How it turned out, and what I would change
Designing for someone who is already moving made me cut the route screen down to five markers and one action, which is far less than I started with.
I ran every stage of this myself, from the first survey response to the prototype. I never went back to the people I interviewed to test the finished screens on them, and that is the part I did not finish. It is the first thing I would do if I worked on this again.
What I took from this is a habit I use on everything now. Before I draw anything I ask what the person is doing with their hands, their attention and their time while they use it. Guide had to work for someone pushing a wheelchair through a crowd, with one hand free and about two seconds to look. Once I ask that, most of what I wanted to put on the screen has to come off.
This one was harder to work on than I expected. My brothers are the reason it exists, so I was slower and more careful with it than I am with other projects, because I did not want to build something that looked like it helped and did not. The part I am still uneasy about is that I made an accessibility app without putting it in front of a single wheelchair user. I know why I did not manage it in four weeks. I still think that was the wrong decision.
How I would change this today with AI
The problem I never solved was keeping the map current. A map of ramps and elevators goes out of date within months, and I was relying on users to report every change themselves. Today I would have a model look at the photo somebody submits and confirm that the ramp or the elevator is there and working, so a report gets checked in seconds instead of sitting in a queue. I would also use a model to pull accessibility details out of sources that already exist, like business websites, city inspection records and reviews, so the map has something on it the day it launches instead of being empty.
I would not put any of that on the map without saying where it came from. A wrong accessibility claim is worse than no claim, because somebody plans their day around it. Anything a model produced would be marked as unconfirmed until a person checked it, and the route the app recommends would still only use paths a person has confirmed.
