03. Whose common sense is it?
The question: A screen nobody calls strange
The projector comes on in the meeting room, and the product designer brings up the new checkout screen. The button sits in the lower right. The address fields are arranged in a single row. When something goes wrong, a red message appears. Everyone nods. "That flow feels intuitive." The developer has built similar screens many times before. The product brief calls it a "standard user experience."
After launch, the support requests begin to pile up. Some users cannot find where to enter the verification code. Others do not know how to distinguish a building name from a street address. Users with low vision cannot read the error message. People connecting from other countries give up when the order of dates and names does not match what they expect. What counted as common sense in the meeting room was an obstacle for someone else.
Common sense usually goes unexplained. It is knowledge people assume everyone shares without being told. That is precisely why it becomes such a powerful design rule. Explicit requirements can be reviewed, but common sense slips into code, screens, and operating procedures without being examined.
The philosophical point: Is common sense neutral?
Philosophy asks where the word "obvious" comes from. Common sense is not a pure intuition rising from nature. It is a bundle of expectations shared by people who have spent a long time within particular environments, languages, institutions, and technologies. This is why phenomenology has taken everyday experience seriously. We do not analyze the world from scratch every time; we understand it through a familiar background. We do not look for an instruction manual whenever we see a door handle.
The problem is that this background is not the same for everyone. One organization's common sense may feel strange in another, and the convenience of the majority may rest on extra labor imposed on a minority. The statement "Users enter an email address when they log in" assumes people who can reliably access email and keep using one account over time. The statement "Administrators should be able to download data freely" places an operator's convenience ahead of the rights of the people represented in that data and of internal controls.
Questioning common sense does not mean throwing out every convention. Common sense is also compressed knowledge that makes collaboration possible. No team could function if it had to agree from scratch each time on where a button belongs or what a log means. The point is not to eliminate common sense, but to reveal who was excluded before a particular assumption became common sense. Once an implicit premise is brought into a sentence, it can finally be reviewed and changed.
An engineering case: One default creates a user population
Suppose you are designing a sign-up system. You split the name field into two boxes for given name and family name, require a mobile phone number, and tell users that their password must contain a special character. Most test accounts pass without trouble. But the design does not adequately imagine people whose naming systems work differently, people who cannot provide a phone number, or people who rely on a password manager.
Consider a hiring AI as another example. Suppose a model trained on historical hiring data gives high scores to applicants from certain universities, with certain career formats, and with a particular style of personal statement. You might say that the model did not invent the bias; it only learned patterns present in the data. But when yesterday's common sense is automatically copied into tomorrow's standard, the system becomes a machine for judging common sense. The code decides what counts as ability and which gaps in a career history deserve an opportunity to be explained.
The engineering response cannot stop at a declaration to "watch out for bias." Record why each input was made mandatory. Check whose work a default makes easier and whose work it makes harder. Test errors and edge cases with the voices of actual users. Do not populate the test suite only with an "average user"; include people whose lives do not fit the system's assumptions. Accessibility is not a feature added at the end. It is the process of turning common sense into an explicit design specification.
The same applies when an AI assistant interprets a user's request. From "Schedule a meeting," a model may infer working hours, time zones, relationships among attendees, and travel time. The faster those inferences are made, the more convenient the system may appear, but the greater the risk that a mistaken assumption will be carried out with confidence. A good system is not one that asks about everything. It is one that knows when to pause before an assumption with costly consequences, and makes its assumptions visible to the user.
Counterpoint and tension: Can we design for every difference?
There is a practical objection. If we try to account for every culture, physical condition, and way of living, products may become more complicated, development schedules may grow, and the interface may stop feeling intuitive to anyone. The question remains whether it is fair to sacrifice the usability of the majority for a minority of cases.
The tension is real. But "simplicity for the majority" is not always neutral. An extra input field that is a minor inconvenience for one person can become a wall that keeps someone else from using the service at all. Inclusive design does not necessarily increase complexity either. Clear error messages, keyboard access, generous time limits, and undo functions help many kinds of users while improving usability overall. The point is not to add exceptions without end. It is to stop treating one default as if it were a law of nature.
Common sense can be a starting point, but it should not be the destination. When a team says, "Everyone does it this way," the designer should pause. Who is everyone? Whose time does "this way" save, and whose time does it consume? That brief pause is necessary.
A question to leave with
What kind of person do the requirements and test code you wrote today take for granted? Whose experience does the convenient default turn into the standard, and what explanations and choices remain for people outside that standard? Perhaps engineering's first responsibility is not to preserve common sense, but to make common sense visible.