A person enters a hospital looking for help.
Imagine being greeted with a wall of department names, acronyms, and internal procedures, then being asked to decide which technical system should receive the problem.
The institution may be brilliantly organized from the inside. From the doorway, it has forgotten the person.
In the week of September 21, we revisited a familiar product mistake: allowing the language of construction to determine the language of use.
A problem before a product
People rarely wake up wanting to learn an organization's taxonomy.
They want to find work, care for someone, make a difficult decision, build something beautiful, organize a group, or repair a situation that has gone wrong.
The needs are specific. The tools required to answer them may be numerous.
An application that begins with twenty features has handed the user a map of its own internal arrangement. An application that begins with the person's purpose can decide which capabilities matter once it understands enough of the situation.
This is a more demanding kind of simplicity.
The technology must do more of the organizing so the person can do less.
One doorway, many forms of work
A single entrance does not require every task to look the same.
A musician may need a page where the music is heard. An organizer may need a timeline and a clear next move. A parent may need one careful answer. A professional may need a complete record of an approved decision.
The doorway can remain familiar while the workspace takes a shape appropriate to the work.
The interface should follow the intention. The person should not have to follow the interface.
This principle matters beyond software. Think of government forms, insurance systems, libraries, and public services. Many of them are organized around the structure of the institution rather than the question in the citizen's mind.
Changing the entrance does not solve every institutional problem. It can make the distance between need and help shorter.
A test worth making
Ask someone who has never used your product to describe what they are trying to accomplish.
Do not teach them your categories yet. Watch where they search, which words confuse them, and which decisions they are forced to make before receiving useful help.
The moment they ask, "Which part of this system am I supposed to use?" is evidence worth collecting.
Good tools should make their own complexity disappear at the moment it has no value to the user.
An excellent doorway is rarely the most elaborate part of a building. It is the part that lets people enter.