Essay / Software Engineering
Good Interfaces Reduce Thinking, Not Just Clicking
Fewer clicks can still mean more confusion. A practical argument for interfaces that expose state, explain choices and reduce the memory a task requires.
A navigation menu can contain only three items and still leave someone wondering where to go. Conversely, a screen with several clearly labelled choices can make the next step obvious. Counting controls tells us little about the work a person must do to interpret them.
That distinction became a useful lens for revisions to this website. Writing, Topics, Archive and Search all provide access to articles, but they answer different questions. Treating them as redundant because their destinations overlap would remove useful ways of finding information. Keeping every link equally prominent would create a different problem: a reader would need to understand the whole navigation system before choosing a path.
The expensive part of an interface is often the thinking between two clicks.
This is a design argument, not a measured result from a usability study of this site. It changes what I inspect when a page feels unnecessarily difficult.
What decision does this screen require?
Imagine arriving at a publication after following a link to an article about software architecture. You finish reading and want something related. A Topics link makes sense because your interest is conceptual. If you remember a particular title, Search fits better. If you want to see what was published recently, the chronological Archive is useful.
These intentions share a content collection but need different presentations. The internal data structure does not determine the reader’s mental model. A developer sees a collection of Markdown files with frontmatter. A visitor sees questions, subjects and things worth returning to.
For this site, keeping discovery routes distinct is a reasonable response to those intentions. It does not prove that every label is optimal. The next useful check would be to ask a reader to find a specific piece and observe where they hesitate, rather than ask whether they like the menu.
This also changes how I think about removing sections. A repeated block should earn its place by helping a decision at that point in the journey. If it merely repeats the same claims without providing a useful route forward, it creates another thing to scan.
Recognition reduces the memory bill
Nielsen’s usability heuristics identify recognition, visible system status and consistency as useful design principles. They are broad evaluation heuristics, not numerical laws or guarantees that a particular interface will succeed.
Consider a topic selector. Showing the available subjects allows a reader to recognize a familiar idea. Requiring the reader to invent the exact term used by the publication shifts work into memory and guessing. Search remains valuable, but it should not be the only route to content whose vocabulary the visitor has not learned yet.
The same issue appears inside a form. A field labelled Value may be technically accurate in the underlying model while leaving the person to recall what kind of value the previous screen requested. A specific label and a visible unit prevent that detour. The extra words can make the interface easier to use even though they increase its visible density.
Recognition has limits. Displaying every possible option can overwhelm the screen. A useful compromise is to expose the choices relevant to the current task while keeping less common paths discoverable. The question is which information must be present for a sound decision, not how much information can be hidden.
Consistency gives a number a meaning
Article numbering offers a small, concrete example. If an essay appears as 01 on Writing and 07 in Archive, a reader has to infer whether those numbers mean sequence, rank or position within a category. The code may simply be counting cards inside each component. That implementation detail has become an interface ambiguity.
A global editorial sequence fixes the meaning: the oldest published article receives the first number, and each article carries the same number across contexts. Featured status remains a separate label. Filtering the collection does not renumber its members.
This is a local design decision, not a universal requirement for publications. Omitting numbers entirely could also be reasonable. Once numbers are visible, however, their meaning should survive movement between pages. A repeated visual element becomes useful when readers can rely on it without reinterpreting it.
The broader lesson applies to buttons, status labels and error messages. If “Published” means one thing in a list and another in a detail view, visual consistency alone will not help. The underlying state model needs to agree with the language.
Feedback should answer the current uncertainty
A reader scrolling through a long article may lose track of its structure. An active entry in the table of contents answers a narrow question: where am I in this argument? It should follow the actual headings, update when scrolling backwards and reflect an anchor opened directly from another page.
That feedback should remain subordinate to reading. An orange state and modest weight change can convey position without a notification, animation or separate explanation. Keyboard focus still has its own job: it identifies the element being operated, which is different from the section currently in view.
A search interface has another uncertainty to resolve. After entering a query, the reader needs to know whether the search is running, whether it found results and what happened if it could not complete. An empty region alone cannot distinguish those states.
Feedback is useful when it closes the gap between an action and its meaning.
Adding movement everywhere may create more visual activity while answering none of those questions. A quiet, accurate status can be more helpful than an elaborate transition.
Fewer steps can hide a harder decision
Suppose an import tool combines file selection, field mapping and publication into one button. It has reduced the click count. It has also removed the moment when someone could notice that the price column was mapped to the wrong destination.
A review step increases interaction cost while reducing uncertainty about a consequential action. Whether that trade-off is worthwhile depends on the task. Publishing a large catalogue deserves different safeguards from expanding an article’s contents list.
This is why I resist making “one click” a design objective without describing what the person must know at that click. A single ambiguous commitment can be harder than several small, reversible steps. Conversely, repeatedly confirming a harmless action can teach people to dismiss confirmation dialogs without reading them.
The useful unit of analysis is the complete task, including preparation, correction and recovery. A fast path that produces avoidable mistakes may simply move effort to a later screen. A testable requirement should describe the outcome and relevant conditions rather than assume that fewer interactions necessarily produce it.
Inspect the gaps, then test the interpretation
A practical review can begin with one concrete task and a small set of observations. Where does the interface require remembering information from another view? Which label depends on knowledge of the implementation? What happens after an action? Can the person recover from a wrong choice without starting again?
For this website, I can inspect navigation hierarchy, visible active states and the relationship between discovery pages. Those inspections establish that particular behaviors exist. They do not establish that visitors understand them or that reading engagement improved. Those would require appropriate observation and evidence.
A simple session could ask someone to find a piece they remember approximately, then find a different article on the same subject. Watching the route they choose would be more informative than presenting the navigation and asking whether it looks clear. Hesitation, repeated backtracking and unexpected interpretations would suggest where to investigate.
I would also check the same task using a keyboard and at a narrow viewport. If the layout removes context on mobile, the desktop explanation no longer applies. Accessibility review and usability observation answer overlapping but distinct questions; neither should stand in for the other.
Less UI is useful only when it also means less uncertainty. That is the standard I want to use when simplifying a page. Remove what asks the reader to interpret the website instead of reading it. Keep the labels, feedback and recovery paths that help them act with confidence. The best evidence of a good interface may be how little attention its mechanics require.