Touchless Elevators: How to Change the Way You Think About a Problem
I’m currently facilitating a series of workshops about UX at UBC through the UBC UX Hub. The first workshop focused on introducing UX and dove into the first step of the design process — defining the problem.
When we see a problem, our natural instinct is to find a solution. It started back in kindergarten math where we had to solve 1 + 1 = 2. And in my case, continued through to university, where I explored how to make a sorting algorithm more efficient at its job. The aim of the game has always been to provide an answer.
What we haven’t been trained for is designing solutions to subjective problems. Sometimes, there isn’t just one right solution.
During our first UX workshop, Joey Limmena and I asked our audience to explore the idea of how a person with a physical disability (e.g. a person with no arms, or someone who’s blind) would use an elevator. We got everything from pressure-sensitive floor mapping, to voice-activated elevators. But what we didn’t get were questions about the current experiences of the target user.
We didn’t get a question on whether there was enough evidence suggesting that an alternate solution needed to be designed. Or whether the current design of the elevator is frustrating or inadequate for these users. Or whether that user would prefer a pressure-sensitive solution to a voice-activated one.
As user-experience designers, we cannot fall into the trap of making assumptions and creating solutions when we haven’t explored the problem space.
We hypothesized that a person with a physical disability may have some struggles with an elevator. But does there exist an actual problem?
Before jumping to conclusions and addressing those presumed struggles, we have to empathize with our user and gain insight into their experience to first validate the problem. Then, using those insights, come up with a problem statement.
So how can we do that?
Without going into too much detail, taking the time to observe and/or interview your user and performing a task analysis of their current user-experience is crucial to both understanding and validating that the problem exists.
During the workshop, I walked through the process of performing a task analysis, determining requirements, and finally, defining the problem statement.
Through the task analysis process, we can identify the pain points — the sub-task(s) that are inefficient, frustrating, or the most troublesome for the user. Then those pain points can be turned into a list of requirements and prioritized into what the design solution must include, should include, and cannot include.
We can then define a problem statement.
A template I use for this is: _____ is a problem for _____ because _____.
Breaking it down compels you to answer 3 questions: What is the problem? Who’s the target user? Why does this problem exist?
While the attendees of our workshop weren’t able to go out and talk to the users, by performing a task analysis and prioritizing our requirements we were able to define the problem statement for the elevator scenario by the end of the workshop.
“Selecting which floor to go to is a problem for a person with a physical disability because they currently have to ask for help in order to complete the task.”