#4: Bring Back Idiomatic Design
I’m part of the desktop software generation. From Windows 95 to Windows 7, I grew using mostly-offline software on computers operated via mouse and keyboard, well before tablets and smartphones. Recently, I’ve been missing one particular part of that era: its consistency in design. I want to tell you about idiomatic design, emphasize the importance of homogeneous interfaces, and suggest that we’ve lost something important.
Design Idioms
Suppose you’re logging into a website, and it asks: “do you want to stay logged in?” There are many ways in which the website could ask you for an answer: for example, a text field where you can enter “Yes” or “No”, or a dropdown where you can select “Keep me logged in” or “Log me out when I close this window.” But in reality, it’ll always be a checkbox. Why is that?
The checkbox is a design idiom: it’s such a common design that as a user, you know how to use it without thinking about it, and if you were making a website and had to ask this question, you would also put in a checkbox without thinking about it. To builders and users alike, it is a standard design pattern that everyone can rely on.
Homogeneous Interfaces
A checkbox is also part of an interface. You’re using it to interact with a system by inputting data. Interfaces are better the less thinking they require: whether the interface is a steering wheel or an online form, if you have to spend any amount of time figuring out how to use it, that’s bad. As you interact with many things, you want homogeneous interfaces that give you consistent experiences. If you learn that Command + C is the keyboard shortcut for copy, you want that to work everywhere. You don’t want to have to remember to use CTRL + Shift + C in certain circumstances or right-click → copy in others, that’d be annoying.
But that’s where we’ve ended up. Software is on the internet now, and the interfaces aren’t homogeneous at all. There are hundreds of ways that different websites ask you to pick dates, enter your credit card number, or do any number of common tasks. Keyboard shortcuts differ from app to app. There are so many different ways of interaction that you can’t remember or learn them at all. Using web applications in 2023 is an exercise of “where do I find what I want to do?” over and over again.
The Desktop Software Era
By contrast, one of the strengths of the desktop software era was high consistency across interfaces by use of design idioms. Look at this picture from Windows 2000:
The visuals feel a little ugly and dated: it’s blocky, the font isn’t great, and the colors are dull. But the interface gets a couple of things really right:
The File, Edit, View… menu structure was standard. No matter whether you were in Adobe Photoshop or Microsoft Excel, you knew that save is under File, redo is under Edit, full-screen is under View, etc.
The menu is navigable by keyboard: there’s a little underline in each of the menu items, e.g. F in File and N in New, underneath. They indicate keyboard shortcuts. You can enter ALT+F to open the File menu, then hit N to open a new file. This caters to power-users while making the shortcuts easy to learn.
The status bar at the bottom tells you everything about the current state: page, column, word count, whether you’re tracking changes, in insert-mode, etc.
Menu items are clearly labeled. Words, not icons, are the primary interface to actions. Icons are used only where they are most obvious. The entire interface leaves little to the imagination. In the picture above, there’s no “I wonder what this does?”1 You know how to use it, even if you’ve never used it before.
Crucially, these design idioms were used not just in Microsoft Word, but throughout the entire Windows ecosystem. Take a look at this Windows XP logout screen:
Every single button is clearly visually a button and says exactly what it does. And each one has a little underline to indicate its keyboard shortcut. Isn’t that nice?
The desktop software era was one of homogeneous interfaces, perhaps because the operating system and its GUI libraries dictated broad swaths of design,2 and those constraints guided developers toward conforming patterns.
The Browser Software Era
The browser software era is one of heterogeneous interfaces. Take a look at these screenshots from two of my favorite web applications:3 Figma and Linear.
These are probably the two best pieces of enterprise software available today. And though they have many of the same features — team settings, abstract item hierarchies, collaborative comments, etc. — they don’t share a single icon. They have no design idioms in common. They have different keyboard shortcuts. Both are very well-designed from first principles, but do not conform to what other interfaces the user might be familiar with.
We are in an era of individually well-designed, useful web applications, and they’re all unique.4 Even in products by the same company, the experiences are heterogeneous: using GMail is nothing like using GSuites is nothing like using Google Docs. In aggregate, this is very frustrating. The lack of homogeneous interfaces means that I spend most of my digital time not in a state of productive flow, but hunting and pecking all over the screen, asking myself “Can I click that? Does this open in a new tab? Will the browser's back button let me go back?” Awful!
This lack of homogeneity is for two reasons:
(1) The Transition to Mobile
All the patterns in designing for mouse-and-keyboard applications had to be reinvented with the advent of the touchscreen. Most web applications have to enable both a mobile and desktop experience, and those interaction forms are very different. Therefore, most user experiences have since then been stuck in an awkward middle, e.g. hamburger menus intended for mobile apps also used for desktop apps, etc. Consequently, there are a ton of bad design patterns everywhere you look. Modern frontend development has a culture of copying and re-using modular components,5 so it’s easy to copy-paste bad design patterns and perpetuate the issue. After 10+ years of this, there has been a generationally corrosive effect on the quality of UI/UX design.
(2) Insufficient Idioms Beyond HTML
If everyone were to follow the same design idioms, then the interfaces would look pretty consistent. In the early days of the internet, there were strong design idioms: hyperlinks to other pages were underlined blue, and purple if you had already visited them. Great! Today, every website presents its own guessing game on how elements of the interface are styled. Is that a link? Maybe!6
It may be surprising that modern web design is so unidiomatic, because the HTML/CSS standards are very prescriptive.7 The issue is that even though there are standards for writing HTML, no-one writes HTML anymore.8 People write React in TypeScript or the latest framework. They import countless npm packages. All that goes through a complex build process to output something that runs in the browser.
Frontend developers aren’t wrong to do this. Browsers today are extremely powerful and offer general-purpose APIs that can let you do pretty much anything if you are creative about it.9 For example, Figma doesn't follow any HTML design idioms because there is no HTML. It's written in web assembly; they are on the cutting edge of implementing desktop-style software in the browser. Of course that breaks the HTML-webpage-as-document model.10 The browser’s back button, keyboard shortcuts, etc. fall by the wayside while a human-computer interaction paradigm is rebuilt.
In short, there are few web design idioms because front-end development is moving too quickly. Engineers are concerned with what is possible more than with questions of polish, and rightfully so. Multi-user, real-time collaboration is much more valuable than power-user keyboard shortcuts. There are both endless frontend packages and interaction formats to deploy them into, so instituting one-size-fits-all idioms on a space so large is very difficult.11 It will take time for the cutting edge to cool down, and for the most successful patterns to become apparent and eventually idiomatic.
The Success of Idiomatic Design
And yet, some of the most successful product organizations of today aggressively pursue their own design idioms and achieve some homogeneity in their interfaces.
Apple is a great example. We’ve talked about Microsoft of the past, but Apple today drives a highly opinionated design system. Apple’s general library of fonts, buttons, colors, etc. and its consistency across all of Apple’s native applications and devices have created a powerful conforming effect for third-party applications. Even when using a third-party app on your iPhone, interacting via the keyboard, pinch-to-zoom, etc. is all controlled by iOS. This is a big part of Apple’s it-just-works effect. Strong, tasteful, idiomatic design is at the core of Apple’s success.
What’s interesting about the it-just-works effect is that it makes users trust the defaults and avoid customization. You see a similar dynamic on platforms like Substack, where as an author I don’t have any ability to select the font or even underline text. But the constraining defaults are tastefully set, and it works great. Substack’s and Apple’s design principles gain adoption as those products succeed, since designers look to them as successful examples. Those designs eventually become idioms by (1) people converging on them as good designs and (2) frequency of use in the community.
What is One To Do?
As a product builder, you want to follow design idioms as closely as practically possible, because it makes your software easier to use and it maximizes compatibility across devices/browsers. I follow these rules of thumb and break them only rarely:
Study and follow HTML/CSS idioms whenever possible. For example, a link should be underlined, colorful, pointer on mouseover, and written as an
<a>tag.Avoid JavaScript reimplementations of HTML basics, e.g. React Button components instead of styled
<button>elements.Study and follow browser idioms whenever possible. The back button should always work. Copy-pasting the URL should bring you to the same interface. CTRL-clicking a navigational element should open it in a new tab.
If you deviate from general idioms, make sure that your designs are fully internally consistent and at least “idiomatic” within your organization.
Prefer words to icons. Use only icons that are universally understood.
If in doubt, make visual elements look obvious. There should never be confusion about whether something is a button or a tab.
Prefer what’s easy to understand over what’s visually beautiful.
If at an impasse, refer to two types of resource to assist in your judgment:
The best-designed websites that you know;
Books on interface design from decades past. Most interface design problems of today are not new, but repeats of history, with solved analogies in the past.
I dream of the day when every datepicker or credit card form on the internet is exactly the same: when after thirty years of iterative development and millions of attempts, we’ve finally converged on the best one. I dream of a future where in every web app, CTRL-Click opens the thing in a new tab. It would be nice…
Maybe you don’t know what the REC, TRK, OVR labels in the status bar mean. Then you would benefit from another standard pattern: tooltips on mouseover that tell you more about what that thing is or does.
It should also be mentioned that for the past decades, Microsoft has always published several-hundred-page, highly prescriptive guides on how to design idiomatic applications along with their Windows operating system releases. You can view a recent example here.
There are other common web applications like Facebook, Twitter, etc. but in this article I’ve decided to stick to utility enterprise software to avoid comparing what might look like apples and oranges.
Notwithstanding that, there are fashion cycles in visual design. We had skeuomorphic design in the late 2000s and early 2010s, material design in the mid 2010s, those colorful 2D vector illustrations in the late 2010s, etc.
The great irony is that modular components are meant to enable idiomatic design! Let the community design lots of date pickers, and then let the best one win! Developers will be able to easily integrate the very best design modules! So the theory goes. In reality, there are just hundreds of competing design libraries and no definitive guidance that will hold long-term.
Worse, even on a technical level, correct idioms are often missed by developers racing to the finish line. I’ve seen <span> elements with onclick events instead of <a> elements in open-source codebases. This is chaos, and it breaks screen readers and other accessibility features.
Except contrarian dinosaurs like yours truly, of course.
There’s a joke that you can always fully implement in the browser what was possible on the desktop X years ago. For example, there are often novelty implementations of popular back-in-the-day video games (e.g. Diablo 2, AOE 2) in the browser.
In other words: many challenges of contemporary web design stem from the fact that HTML/CSS and the browser more generally were built on a webpage-as-document model, which engineers have always been trying to stretch as far as possible. A “document” is simply no longer a good analogy for a webpage in 2023. Even the notion of a “webpage” is suspect here: the modern frontend developer really wants a browser tab to act as a universal sandboxed execution environment.
Concretely, it seems a lot more difficult than in the desktop software environment of yesteryear, when the degrees of freedom were so much smaller. No touchscreens, only a few display sizes, and so on.