필사 모드: A Screen Is Written With Ten Letters — The One Question to Ask Before Building a Custom Widget

• One sentence from a design review
• Twenty-six letters and ten elements
• The ranking itself is information
• What you actually throw away when you build a new widget
• Four common ways to break the contract
• Why windows and pointers were left off the list
• What an evidence-backed rule actually looks like
• What you can do this week — attach a letter to your component inventory
• Summary and sources

One sentence from a design review

A new screen mockup contains an interaction unit nobody has seen before. It looks like a card, clicking it selects it, selection draws a border, and several can be chosen at once. Ask the person who made it what it is and the answer is usually this: a selection card.

The question that should come out at this moment is not whether it looks good. It is this. Is this a checkbox, or a tab, or something else entirely? Why that question is useful is the content of this post.

Twenty-six letters and ten elements

The post about GUI elements that Jakob Nielsen published on 29 July 2026 opens with a single analogy. Just as twenty-six letters of the alphabet let you write every English word, about ten elements let you assemble almost every user interface produced so far. And he lays out those ten together with 86 evidence-based guidelines.

The list runs like this. Buttons, input fields and forms, menus, links, dialog boxes, notifications and error messages, icons, checkboxes and radio buttons, tabs, search.

At first glance it feels trivial. It feels trivial because you have never built anything outside this list. And yet if you pull out your own design system component inventory and count, you usually land somewhere between forty and eighty. You should be able to explain why a text written with a ten-letter alphabet needed eighty letters.

The ranking itself is information

Nielsen does not simply enumerate the ten; he orders them. The criterion is how much of a user's everyday interaction hangs on each one. So buttons rank first and search ranks tenth.

That order can be used as a priority table in practice. Team time is finite, and it usually pours into new components. But what users touch most over the course of a day is always buttons and input fields. Expressing button states, explaining why something is disabled, touch target size, the placement of form error messages — these are the work that corresponds to ranks one and two.

Put the other way round: if you spend three days polishing your newly built card-style selection widget while nowhere in the product does it say why a disabled button is disabled, those three days were spent at the bottom of the ranking.

What you actually throw away when you build a new widget

The cost of a new widget is not implementation time. Implementation usually takes a day. The real cost is giving up a contract the user had already learned.

A checkbox carries a contract on which the user has finished their training. Several can be chosen, pressing again clears it, clicking the label toggles it, keyboard tab focus plus space turns it on, and screen readers announce the selection state. This contract is not something we made; it came about because thousands of products behaved the same way for decades.

Build a new card-style selection widget and this contract is reset in full. Whether pressing again clears it, the user does not know. Whether it is reachable by keyboard is something we have to build separately. And if we do not build it, it is silently absent. In other words, the true cost of a new widget is not the one day of implementation but the entire cost of rebuilding the discarded contract with our own hands.

That is why the earlier question matters. If this is a checkbox, implement it as a checkbox and change only the appearance to a card. The contract stays intact.

Four common ways to break the contract

Even after deciding which of the ten letters something is, half-breaking that letter's contract happens often. The shapes you see most are these.

• Looks like a link but is a button: you middle-click the underlined blue text to open it in a new tab and nothing happens. The difference between a link and a button is not appearance but navigation versus execution.
• Looks like a button but is a radio: press one of three buttons sitting side by side and the others switch off. That is radio button behaviour, and a user who expected something to be executed on press stumbles for a beat.
• Is a tab but changes the page: a tab is a device for changing the visible face inside the same context. If pressing a tab piles up back-button history, the user model breaks.
• Is a notification but demands an action: a notification is a thing you may let pass; a dialog box is a thing you must answer. If the only undo button lives inside a toast that disappears after a few seconds, that undo is close to being built to be missed.

The four share a common structure. They promise one thing by appearance and give another by behaviour. The user believes the appearance.

Why windows and pointers were left off the list

Nielsen does not put windows and pointers among the ten in the main body; he covers them separately as a bonus. He states that the reason is that these two have now largely become the operating system's job.

The reason that distinction is useful in practice is that it tells us what not to build. The moment you implement window management yourself inside a web app, that window starts behaving differently from operating system windows. There is no minimize, or the drag region differs, or the stacking order differs. The user forms expectations against the operating system side of the contract.

Pointers are the same. Changing the cursor shape is a powerful way to signal state, but the moment you replace the cursor itself with a graphic, the latency becomes visible. When you rebuild a layer the platform already owns, you have to beat every existing contract of that layer.

What an evidence-backed rule actually looks like

Let us look at one example of what kind of evidence is meant when Nielsen calls his post evidence-based. One of the things it cites is Fitts's law from 1954: the experimental result that the time to point at a target is determined by the distance to it and by its size. Farther takes longer, bigger goes faster.

So telling you to draw buttons large is not a matter of taste but a consequence of a measured fact. And a more practically usable corollary comes out of it. The corners and edges of a screen behave like infinitely large targets, because no matter how hard you throw the mouse it does not leave the screen. Pin frequently used controls to the edges and, at the same size, they are reached faster.

The post cites another kind of evidence too. The figure that roughly one in twelve men has red-green colour vision deficiency is one such. That is where the answer lies to why a screen that distinguishes state by colour alone is dangerous. It also introduces a case in which removing a single form field alone produced an improvement on the order of 12 million dollars a year. I have not chased that case back to its original source; I record it as what Nielsen's post reports.

What you can do this week — attach a letter to your component inventory

There is an exercise that takes an hour.

1. Copy your design system component inventory into a table as-is.
2. Next to each item, write which of the ten letters it is. Button, input, menu, link, dialog box, notification, icon, checkbox and radio, tab, search.
3. Mark the items where you cannot write a letter.
4. For each marked item, answer in one line: which contract did this newly create, and are we actually keeping that contract in documentation and accessibility implementation?

In most teams, two or three items remain at step 3. Those two or three are usually the ones truly needed, and the rest are existing letters in different clothes. The moment you reflect that they are different clothes in the code, accessibility and keyboard operation follow for free.

Summary and sources

The value of the list is not in telling you what to build. It is in telling you that if the thing you newly built is a letter not in the alphabet, you will have to teach that letter from scratch.

• 10 GUI Design Elements Build Every User Interface — Jakob Nielsen, 29 July 2026. The list of ten and the ranking criterion, the 86 guidelines, the reason windows and pointers are handled separately, Fitts's law and the colour vision figure, and the form field case all come from this post.
• The order of the ten, the ranking criterion, the alphabet analogy, and the number of guidelines were confirmed directly in that post. The four contract-violation examples and the component labelling exercise in the body are not proposed by that post; they are my own transfer of its perspective into practice.