The elevator button problem
Ever since I moved into a building with a lift, I have noticed the same thing at least once a day.
Someone standing on the ground floor sees the lift on the fifth floor and presses the down button. Someone on the eighth floor wants to go to the ground floor and presses the up button.
The buttons are not ambiguous in the conventional sense. Most people understand them immediately. But a significant number of people repeatedly get them wrong.
I have a theory about why. A person waiting for a lift may be thinking about calling the lift to their floor, rather than communicating the direction in which they intend to travel. If the lift is above them, they press down because they want it to come down. If it is below them, they press up because they want it to come up.
I don't know whether that is the actual reason. It is simply the best explanation I have come up with from watching people use the interface.
And that uncertainty is important. Recognising a problem does not mean you automatically know how to solve it.
The Someone Else’s Problem field
There is a wonderful idea in The Hitchhiker’s Guide to the Galaxy: a spaceship can be made effectively invisible by surrounding it with a “Someone Else’s Problem” field. It isn't actually invisible. People simply don't notice it because their minds automatically decide that it isn't their problem.
I think organisations can create the same field around usability problems.
A user keeps making the same mistake. The designer sees it. Product knows about it. Engineering knows about it. Customer support deals with the consequences. Management has other priorities.
And somehow, the problem belongs to everyone and therefore to nobody.
The most persistent problems in an organisation are sometimes not the ones nobody sees. They are the ones everybody sees but nobody owns.
This is where I think a designer has an important role. Not necessarily to declare, “I will fix this.” The designer may not have that authority. But to say, “I can see this problem, and I'm not going to pretend I can't.”
That is the difference between ownership of the solution and responsibility for the problem.
Knowing there is a problem is already a responsibility
I have thought about replacing the conventional symbols with something more explicit, such as “I want to go up” and “I want to go down”. But that immediately creates other problems. It requires more space. It asks people to read. It adds cognitive load. And it may not work equally well for people who cannot read.
In fact, some of the people I have seen making this mistake most often are domestic workers and other people who may not be comfortable reading English-language instructions.
So I don't have the solution.
But I do know that the problem exists.
A designer does not need to have the answer before they acknowledge that there is a problem worth solving.
This distinction matters because it is easy to confuse having no solution with having no responsibility.
A designer may investigate the problem and discover that every proposed solution introduces another problem. They may find that the cost of changing it is too high. They may discover a technical limitation. They may take the issue to management and be told that other priorities are more important.
All of those are legitimate reasons to make a decision.
What is not particularly useful is allowing the problem to disappear simply because everybody has become accustomed to it.
Not every interface should have the same learning curve
This becomes clearer when we compare an elevator with an enterprise application.
An enterprise application may be complicated. It may require training. It may have a learning curve.
That isn't automatically poor design.
The users are usually a defined group. They may use the application every day. Their organisation may provide training. The complexity may be justified by the complexity of the work they are doing.
An elevator is fundamentally different.
Anyone can become a user. There is no onboarding session. There is no training manual. You don't expect a visitor to study the interface before entering the building.
And yet we often accept the same principle: if people eventually learn how to use something, the design must be good enough.
But people can learn bad interfaces.
People can also become very good at working around bad design.
That doesn't necessarily make the design good. It may simply mean that humans are remarkably adaptable.
Don't mistake feature progress for interaction progress
Consider an intentionally exaggerated example.
Imagine buying a car without an intuitive steering wheel. Instead of fixing that fundamental interaction, the manufacturer keeps adding power windows, remote locking, Bluetooth connectivity and increasingly sophisticated entertainment features.
Those features might all be useful. But none of them compensates for a fundamental problem with controlling the car.
Adding more features is not the same thing as improving the experience.
The same principle applies to many products. Organisations can become very good at adding capabilities while leaving an old interaction problem untouched.
Sometimes that happens because the new feature is easier to justify. It has a specification, a launch date and a visible business owner. A recurring usability problem may have none of those things.
It simply sits there.
Users work around it. Experienced users teach new users. Documentation explains it. Support teams answer questions about it. And eventually everyone accepts it as part of the product.
The problem hasn't been solved. It has simply become normal.
The designer's role is not unlimited authority
This is where I think we sometimes misunderstand the role of a designer.
A designer cannot decide every product priority. A designer cannot override the business. A designer cannot make engineering capacity appear. And a designer certainly cannot guarantee that every usability problem will be solved.
But the designer is often the person closest to the user's experience.
That creates a responsibility.
If you know that users repeatedly make the same mistake, you should be curious about why.
If you have evidence that the interface is contributing to the mistake, you should investigate it.
If you don't have a solution, you should explore alternatives.
If your proposed solution creates another problem, you should acknowledge that.
If the organisation decides not to pursue the change, that may be a perfectly reasonable business decision.
But the designer should not quietly turn the problem into something that is simply accepted.
You may not be able to solve the problem. But you can refuse to stop seeing it.
When everyone has learned to live with it
This is perhaps the most dangerous stage for a usability problem.
It is no longer surprising. Users know how to work around it. Support teams know how to explain it. Designers know about it. Managers know about it.
Everyone has adapted.
And because everyone has adapted, nobody feels an urgent need to change anything.
This is where I think designers have a particularly important role.
Our job isn't only to create new things. It is also to notice the things that people have become accustomed to tolerating.
We should be willing to ask uncomfortable questions about familiar interactions.
Why do users keep making this mistake?
Why does this require training?
Why does the support team have to explain this repeatedly?
Why have we accepted this behaviour for so long?
And perhaps the most important question: if we were designing this today, knowing what we know now, would we design it the same way?
It is your job to clear the Someone Else’s Problem field
Perhaps the most important thing a designer can do when they discover a recurring problem is to make it visible again.
Not every problem can be solved. Not every problem should become the next item on the roadmap. And sometimes, after investigating it properly, we may conclude that the cost of fixing it is greater than the benefit.
But that decision should be made consciously.
The danger is when a problem disappears into the Someone Else’s Problem field. Everyone can see it, users continue to experience it, but nobody feels responsible for doing anything about it.
This is where the designer has a particular responsibility.
You may not own the product roadmap. You may not control the engineering team. You may not have the budget. You may not even know what the solution should look like.
But you can point at the problem.
You can bring the evidence. You can observe the users. You can ask why the same mistake keeps happening. You can explore possible solutions. You can test them. You can show what happens when the problem is left alone.
You don't have to own the solution to take responsibility for making the problem visible.
Sometimes that is all it takes for someone else to see it too.
The elevator problem may be a useful example. I still don't know what the perfect elevator button should look like. But I would rather say that honestly than convince myself that there is no problem simply because millions of people have learned how to use the existing buttons.
Perhaps that is one of the privileges of being a designer. We get to notice the things people have stopped noticing.
So when you find a recurring problem that everyone else has learned to ignore, don't necessarily promise that you will fix it.
Try to clear the field.
Point at the problem. Ask the question. Start the conversation. Look for a better answer.
And if everyone else is looking away, don't.
