The Button Should Know What It Is
When interfaces become ambiguous, clarity stops being cosmetic and starts becoming an ethic.
There is a particular kind of frustration that arrives when a thing looks simple and then refuses to be simple.
A door with a handle that should be pulled, except the door needs to be pushed. A form field that accepts your answer, except not in the format you used. A button that appears to promise one action, except the action is actually hidden behind a modal, a confirmation, a spinner, and finally a quiet failure you are expected to diagnose yourself.
We usually treat these as annoyances. Bad design. A rough edge. Something for the backlog, perhaps, once the roadmap has a little breathing room. Yet the more of life we move into software, the less convincing that answer becomes. A confusing interface is not merely an aesthetic failure. It is a small transfer of burden from the people who made the system to the people who have to live inside it.
The button should know what it is.
The Moral Weight of Clarity
Don Norman's The Design of Everyday Things is famous for making ordinary objects feel suddenly legible. Doors, stoves, switches, faucets, all the quiet machinery of daily life, become lessons in whether an object tells the truth about itself. Norman gave designers a vocabulary for affordances and signifiers, for the relationship between what an object can do and what it appears to invite us to do.
That may sound technical, but it is also moral. When an object tells you how to use it, it is offering a form of hospitality. It is saying: you belong here enough that you should not need secret knowledge to proceed.
When it does the opposite, when it hides its rules or punishes reasonable guesses, it makes the user feel foolish. This is one of the more common indignities of modern software. The system fails to explain itself, and somehow the person becomes the one who feels embarrassed.
Anyone who has helped a parent navigate a banking portal or watched a colleague share their screen while apologizing for not finding the right setting knows this moment. The human being starts narrating their own inadequacy: sorry, I know this should be obvious; sorry, I am bad at this; sorry, give me one second. The software has created the confusion, but the person absorbs the shame.
That is not neutral.
Power Hides in the Defaults
Most digital tools are built by people who live comfortably inside digital tools. That sounds obvious until you notice how much damage it does. The makers know where the settings are. They know which icons are meaningful, which errors can be ignored, which steps are reversible, and which button is the real one. They have internalized the map so deeply that they forget it is a map at all.
Then the rest of us arrive.
Sara Hendren, in What Can a Body Do?, writes about disability not as a defect located simply inside a person, but as a mismatch between bodies and worlds. A curb creates one kind of world. A ramp creates another. A lectern built for one assumed body tells other bodies, quietly but unmistakably, that they were not imagined.
Software does this too. It assumes a user with perfect vision, fast hands, uninterrupted attention, technical vocabulary, emotional patience, and enough institutional confidence to click without fear. It assumes someone who is not exhausted. Someone who is not anxious about making a mistake. Someone who knows that the gear icon means configuration and that configuration means the place where the actual thing they need might be hiding.
Of course no product team writes this down as a requirement. Nobody opens a planning document and says, let us only serve the calm, fluent, able, confident user. The assumption lives deeper than that. It appears in what gets tested, what gets dismissed as edge case, what gets labeled user error, and what gets deferred because the team has more ambitious things to build.
Ambition is not the problem. The problem is ambition without attention to the ordinary human being at the other end.
The Fantasy of the Smarter System
There is a tempting answer to all of this: make the system smarter. If the interface is too complicated, add an assistant. If the settings are too buried, let a model find them. If users struggle to operate the tool, give them a conversational layer that can operate it on their behalf.
Sometimes that will help. There is nothing sacred about making people click through badly organized menus when a machine can take care of the errand. A good assistant can reduce friction, translate jargon, and spare people from needless procedural memory.
But there is a danger in using intelligence as a bandage for neglect. If a tool needs a second tool to explain the first tool, we should at least pause before calling that progress. We may simply be adding a concierge to a building whose doors still do not open properly.
The deeper question is not whether software can become more powerful. It plainly can. The deeper question is whether power will make our tools more accountable to human life, or merely more capable of concealing their confusion.
A conversational assistant can make a broken system feel polite. It can say, I understand what you are trying to do. It can summarize the error in warmer language. It can route around the awkward parts. Yet if the underlying product remains hostile, opaque, or careless, the assistant becomes a cushion over the same hard surface.
That may be useful. It is not the same as repair.
Before You Add Magic
There is an old Jewish legal principle called lifnei iver, often translated from Leviticus as the prohibition against placing a stumbling block before the blind. Rabbinic tradition expands it beyond the literal case. The command is not only about physical obstruction. It is about not exploiting another person's vulnerability, confusion, or lack of information.
That feels like an unexpectedly precise software ethic.
Do not place a stumbling block before the person who cannot see what you can see. Do not design a path that depends on knowledge you have withheld. Do not create a flow where the cost of confusion is paid by someone with less power than you. Do not make people apologize to a machine.
Good design, in this frame, is not about elegance alone. It is about refusing to make other people carry unnecessary bewilderment.
This does not mean every product must be simple in the same way. Some tools are complex because the work is complex. Professional instruments often require learning, discipline, and practice. A cockpit should not pretend to be a toaster. A database migration tool should not behave like a children's toy. Serious work deserves serious instruments.
But there is a difference between complexity that respects the work and confusion that protects the maker from doing harder thinking. The first asks the user to grow in skill. The second asks the user to compensate for our failure to make decisions.
Before adding magic, perhaps we should ask a plainer set of questions.
Does the button do what it appears to do? Does the error tell the person what happened and what they can do next? Does the interface work for someone tired, interrupted, nervous, or new? Can a person recover from a mistake without panic? Have we made the common path humane before polishing the impressive path?
These are not small questions. They are questions about who bears the cost of our cleverness.
The Kindness of Obvious Things
We live in a culture that rewards novelty more readily than care. The demo that astonishes gets shared. The quiet repair rarely does. A tool that becomes less confusing may not look revolutionary on stage, but it changes the felt experience of being a person inside a system.
There is kindness in obvious things.
A label that says what it means. A button that performs the action it promises. A setting placed where a person would reasonably look. A warning written in human language. A disabled state that explains itself. A flow that remembers the user is probably trying to get back to the rest of their life.
These details do not feel grand. They do not announce themselves as ethics. Yet much of ethics is ordinary. It is the shape of the room before the guest arrives. It is whether the chair fits the person who sits in it. It is whether the path has been cleared before someone trips and is told to be more careful next time.
The future of software will almost certainly be filled with agents, models, automation, and systems that can act with increasing independence. Fine. Let them come. But if they arrive in a world where the humble button still cannot be trusted to know what it is, then our problem was never a lack of intelligence.
It was a lack of care.