Interface Design: "User Friendliness" is a trap

Designing an interface for user friendliness first and foremost is kneecapping the productivity of its users in the long term.

Consider the file explorer, with its nice skeuomorphic "folders" and an easy point-and-click interface. Sure, it seems easy to use at first, but once you've learned how to use the cd, ls, mv, rm, cp and mkdir commands and've installed a shell with good tab completion, you'll be able to traverse your system an order of magnitude faster.

Consider the simple text editor, like VSCode. Sure, navigating around a file by clicking seems easy at first, but once you've internalized Vim's text motion and modal editing facilities, trying to use a "normal" editor feels like trying to wash an 18-wheeler with a toothbrush.

Consider the What You See Is What You Get "word processor", like Google Docs or Microsoft Word. Sure, being able to apply any style to any text and put any image anywhere seems freeing at first, but once you've learned how to use TeX's macro system and learned how to use all the plugins that add in all the nonstandard functionality you want,¹ you'll be able to easily churn out masterpieces of typography, and you won't have to worry about inconsistent styling or your document's layout being clobbered by moving images around ever again.

Consider the real-time collaborative editor, like Google Docs again or one of its many clones. Sure, the collaboration model seems easy at first, "everything you type is available to everyone else instantly", but if you ever need to work on anything with more than ~2 people at a time, learning Git and replacing the proprietary file format with something open and plaintext (like TeX) completely blows it out of the water.

Consider passwords as authentication system. Sure, it seems simple at first, "just remember this string of characters so we know who you are", but once you've used public/private key cryptography with, say, SSH, having to copy passwords from your password manager to log in to websites feels more like banging rocks together than using a computer.

Consider the floating window manager. Sure, manually positioning windows with your mouse seems simple at first, but a tiling WM lifts the burden of window positioning off of your mind completely; your attention is less fragmented when using one.

Consider the mouse cursor in general, actually. Sure, it seems nice to be able to interact with things with just one button, but keybinds are nearly always strictly faster; they minimize hand movement, the main bottleneck when transferring your intent into your computer's CPU.

If you want to truly impart productivity onto your users, you must design an interface with a non-trivial² learning curve. An "intuitive" interface is just one that reinforces the user's misconceptions about the most efficient way to perform a task.

retrospective from 2026-04-26: this blog post is bad.

i wrote this blog post in hopes of articulating why vim/command line interfaces/tiling window managers are designed the way they are, why more things should be designed like them, why they confer so much productivity unto their users, and why their learning curves really are worth it. instead of doing any of that, the post meanders around for 7 paragraphs, deftly avoiding making any arguments and instead opting for a rote list of unsubstantiated examples. it makes me seem as if i think i'm better than the reader, as if i'm implicitly communicating "the things i'm saying are so obvious that they don't even need explanation", a style of argumentation i (evidently) can't pull off well, and probably isn't something i should want to do well. i definitely still stand by the underlying idea, but it was poorly argued.

in terms of writing style, the "trying to wash an 18-wheeler with a toothbrush" line is overwrought and smells LLM-y. i like "reinforces the user's misconceptions about the most efficient way to perform a task" and "transferring your intent into your computer's CPU" though; they're punchy and clear while still being interestingly structured, which is exactly the sort of sentence i want to write more of.

i now write this retrospective because i seem to only find the flaws in the things i make right after i publish them, and i'd much prefer to find the flaws before that. also, i'm really not comfortable letting something bad exist under my name without making it clear that i know it's bad.