Daniel sent us this prompt about UI conventions — those things that nobody ever announces but everybody expects. Control O for open, Control N for new, Control G to group things in a design tool. And his question is, does this phenomenon have a name? Is there a reference for what these standard expectations are? And what happens when you break them?
It does have a name. And before we dive in — DeepSeek V four Pro is writing today's script. There we go.
There it is. Alright, so what are we calling this thing?
The broadest term is "design conventions." That's the umbrella. But the specific phenomenon Daniel's describing — where users carry expectations from one app to another without being told — that's Jakob's Law. Named after Jakob Nielsen, who codified it back in two thousand. The exact phrasing is, "Users spend most of their time on other sites." Which sounds almost too obvious to be useful, but the implication is profound. Users form mental models from the aggregate of everything they've used before, and they bring those models to your product. If your product violates those models, it feels broken.
It's not just about being consistent within your own app. It's about being consistent with the entire ecosystem of apps your user has ever touched.
And the keyboard shortcut example Daniel brought up is the purest version of this. There's a concept called "affordance" — that's the property of an object that suggests how you use it. A door handle affords pulling, a flat plate affords pushing. But keyboard shortcuts have no visual affordance at all. You can't look at a screen and know Control G groups things. It's entirely learned. And once learned across dozens of apps, it becomes what Don Norman would call a "convention" rather than an affordance — it's culturally transmitted, not physically suggested.
Don Norman, the guy who wrote The Design of Everyday Things.
And he makes this distinction that's crucial here. Real affordances are about physical properties. Perceived affordances are what the user thinks they can do. Conventions are entirely about shared cultural knowledge. And when you violate a convention, the user doesn't think "oh, this app has a different philosophy." They think "this app is broken.
Which is exactly what Daniel said. "Wait, what's wrong with this app?
There's fascinating research backing this up. I was looking at a study from the Nielsen Norman Group — they found that users spend something like ninety percent of their digital time on other people's products. Your app is a tiny blip in their experience. So the mental model they bring is overwhelmingly shaped by everything they've used before you. If your file menu doesn't behave like every other file menu they've ever encountered, you're not being innovative. You're being confusing.
That's the name — conventions, Jakob's Law. But Daniel also asked if there's an actual reference. Like, if I'm building a wireframing tool and I want to know what shortcuts users expect, is there a document I can look at?
There are several, and this is where it gets practical. The big ones are platform-specific human interface guidelines. Apple has their H. — the Human Interface Guidelines — which are remarkably detailed. Microsoft has the Fluent Design guidelines. Google has Material Design. And each of these documents includes standard keyboard shortcut mappings, expected behaviors for common UI patterns, the works.
Those are platform-level. What about application-level conventions? If I'm building a design tool, Figma and Sketch and Adobe X. have collectively established what users expect. Is there a central repository for that?
Not a single authoritative one, which is part of the problem. But there are some excellent resources. There's a project called Keyboard Shortcuts for Designers that catalogs shortcuts across all the major tools. There's also what interaction designers call "design patterns" — Christopher Alexander originally coined that term for architecture, but in software, it refers to recurring solutions to common problems. And patterns libraries like UI Patterns dot com or the Yahoo Design Pattern Library document these. The tricky thing is, they're descriptive, not prescriptive. They document what exists, not necessarily what you should do.
You'd have to synthesize across multiple sources.
But here's the thing — and this is where I think Daniel's intuition is spot-on — the most important conventions aren't in any document. They're the ones that are so deeply baked in that nobody thinks to write them down. Control Z for undo. Control C for copy. Control V for paste. These are so universal across operating systems and applications that they've become what cognitive scientists call "procedural knowledge" — things you know how to do without being able to explain how you know them.
It's muscle memory at that point. If I have to think about where Control Z is, something's wrong.
That's the test. The moment a user has to think about a keyboard shortcut, you've failed. The shortcut should be transparent. The user should be thinking about their task, not about your interface.
Let's talk about what happens when you break these conventions. Daniel mentioned that if shortcuts have "weird mappings," it's not going to work in your favor. I think that's actually understating the problem.
Oh, it's much worse than that. Breaking conventions doesn't just annoy users. It creates what researchers call a "cognitive load penalty." Every time a user has to consciously process something that should be automatic, it drains cognitive resources from their actual task. They're not thinking about their design anymore. They're thinking about why Control G isn't working.
The first impression cost is enormous. There's research on this.
The classic finding is from a study by Gitte Lindgaard and her colleagues at Carleton University — they found that users form aesthetic judgments about a website within fifty milliseconds. That's faster than conscious thought. But the more relevant research for Daniel's question comes from tractability studies on first-use experience. If a user encounters friction in the first sixty seconds of using your app, the abandonment rate is dramatically higher. And a broken keyboard shortcut is exactly that kind of friction.
Because it's not just that the shortcut doesn't work. It's that the user immediately loses trust. If you got Control G wrong, what else did you get wrong?
That's what's called the "halo effect" in reverse. A single broken convention casts doubt on the entire product. Users don't think "this shortcut is wrong." They think "this app is poorly built." And they're not wrong to think that, because getting conventions right is table stakes. It's not a feature. It's the minimum requirement for being taken seriously.
Alright, so we've named the thing — conventions, Jakob's Law, design patterns. We've talked about why breaking them is catastrophic. But I want to push on something. Are there cases where breaking a convention is actually the right move?
And the answer is yes, but with a massive caveat. You can break a convention when you're replacing it with something genuinely better and you're willing to invest in teaching users the new thing. But — and this is the critical part — this only works if the improvement is substantial enough to justify the cognitive cost of retraining.
Give me an example.
The classic case is pinch-to-zoom on the iPhone. Before the iPhone, zooming in on something meant tapping a magnifying glass icon or using a slider. Pinch-to-zoom broke that convention completely. But it was so intuitive — it mapped so naturally to a physical gesture — that the learning cost was essentially zero. More importantly, it was a direct manipulation that felt like manipulating a physical object. It wasn't just a different way to do the same thing. It was a categorically better interaction.
The bar is, you need a paradigm shift, not just a preference.
If you're just rearranging shortcuts because you think your mapping is more logical, you're going to lose. Users don't want logical. They want familiar. The time they'd spend learning your logical mapping is time they're not spending doing their actual work.
This connects to something Daniel said that I think is worth pulling out. He mentioned that if you're trying to show users you're a "new good app worth their time compared to a standard industry tool," getting the shortcuts wrong is fatal. Because the comparison isn't neutral. You're not being evaluated in a vacuum. You're being evaluated against Figma, or Sketch, or whatever the incumbent is. And the incumbent has already trained the user.
This is what's called "switching cost" in economics, but applied to user experience. Every time you force a user to learn something new, you're adding to the switching cost. And if your product is otherwise similar to the incumbent, why would anyone pay that cost? The only way to justify it is if your product is so much better in some other dimension that the learning cost is worth it. But keyboard shortcuts are such a fundamental part of the interaction that getting them wrong poisons the well before the user ever gets to your differentiating features.
Practically, if Daniel or someone like him is building a wireframing tool and wants to get this right, what's the process? How do you actually research what conventions users expect?
There's a structured approach. Step one is competitive analysis, but not the way most people do it. Don't just look at one competitor. Look at three to five of the dominant tools in your space and map every keyboard shortcut they share in common. The ones that are identical across all of them? Those are non-negotiable. You must implement those exactly.
The ones where they differ?
That's where you have a choice, but you should still default to the most common mapping unless you have a compelling reason not to. And "compelling" doesn't mean "I like mine better." It means "the most common mapping creates a conflict with a core feature of my product that can't be resolved any other way.
What's step two?
Step two is understanding the platform conventions. If you're building for macOS, you follow Apple's H. If you're building for Windows, you follow Microsoft's. If you're building for the web, you follow the W. guidelines and the de facto standards that browsers have established. And here's a specific thing Daniel should know — on macOS, the Command key is the primary modifier. On Windows, it's Control. If you're building a cross-platform tool and you map everything to Control on both platforms, your Mac users will revolt.
Because Mac users expect Command C, not Control C.
And this is a perfect example of a platform convention that isn't documented in any application-specific guide. It's so fundamental that nobody thinks to mention it. But if you get it wrong, every Mac user who tries your app will immediately think it's broken.
Step three is user testing, but specifically for conventions. This is different from usability testing where you watch users try to complete tasks. For conventions testing, you give users a blank canvas and say "group these two elements." Don't tell them how. Just watch what they try. If they instinctively reach for Control G and nothing happens, you've found a problem. If they try multiple shortcuts and none of them work, you've found a bigger problem. And if they immediately go to the menu bar because they assume the shortcut won't work? You've lost their trust entirely.
That's a great methodology. And I'd add a step zero, which is: before you do any of this, acknowledge that your own intuition about what's "logical" is probably wrong.
That's the hardest part for most developers. You've spent months or years building this thing. You know exactly how it works. Your mental model is complete and coherent. And from inside that mental model, your shortcut mappings make perfect sense. But your user doesn't have your mental model. They have the mental model they've built from every other app they've ever used. And those two models are going to collide unless you actively work to align them.
There's a term for what you're describing. Cognitive entrenchment, right?
Erik Dane's research in twenty ten. He studied experts and found something counterintuitive — the more expertise someone has in a domain, the harder it is for them to see that domain from a novice's perspective. Their knowledge is so deeply embedded that it becomes invisible to them. They literally can't remember what it was like not to know the thing. And that's exactly what happens to developers building tools. They can't imagine not knowing that Control Shift G ungroups things, because to them it's obvious.
The cure for cognitive entrenchment is systematic competitive analysis and user testing. You have to externalize the knowledge because you can't trust your own brain.
And this is why design systems exist. When a company like Apple or Google or Adobe creates a design system, they're essentially encoding all these conventions into a reusable framework so that individual developers don't have to rediscover them. The design system is the institutional memory of what users expect.
Let's talk about some specific conventions that Daniel should know about if he's building a wireframing tool. Beyond the obvious Control G for grouping.
Alright, let me run through the ones that are nearly universal across design tools. Control D for duplicate. That's a big one. In some tools it's Control D, in others it's Command D, but the D is consistent. Holding Shift while resizing to maintain aspect ratio. Holding Alt or Option while dragging to duplicate. Spacebar to temporarily switch to the hand tool for panning. Control plus and minus for zoom. Control zero to fit to screen. Control A to select all. Delete or Backspace to delete selected elements. Control Z for undo, Control Shift Z for redo — though on macOS it's Command Shift Z or Command Y depending on the app, which is a whole other conversation.
The redo shortcut is surprisingly inconsistent across tools, actually.
And that's a case where you have to pick your poison. But the principle is, you should know that it's inconsistent, and you should make a deliberate choice rather than just mapping it to whatever feels right in the moment.
What about alignment shortcuts?
Those are less standardized, but there are emerging conventions. In Figma, Alt A is align left, Alt D is align right, Alt W is align top, Alt S is align bottom. In Sketch, it's different. In Adobe tools, it's different again. So alignment is an area where you have more freedom, but you should still look at what the market leader does and have a good reason if you deviate.
The market leader right now in design tools is Figma.
By a significant margin. So if you're building a new design tool and you're trying to attract Figma users, matching Figma's shortcuts is the safest bet. Unless you think Figma's shortcuts are actively bad, in which case you need to be so much better in other ways that users will forgive the learning curve. But again, that's a very high bar.
I want to circle back to something Daniel mentioned about "fonts and color schemes and wireframing." He said it's easy to miss these convention issues when you're deep in the visual design. And I think that points to a broader problem in how products get built.
There's a tendency to obsess over the visible surface of a product — how it looks — while neglecting how it behaves. But from a user's perspective, behavior is usually more important than appearance. A beautiful app with broken shortcuts is a bad app. An ugly app with perfect shortcuts is at least functional.
The shortcuts are invisible by definition. You can't see them in a mockup. You can't evaluate them in a design review. They only exist in the actual running software. So they're easy to overlook until the very end of the development process, at which point changing them is painful.
That's why the smart approach is to define your shortcut mappings early, before you write any code. Treat them as a design deliverable, just like your wireframes and your style guide. Actually create a document that lists every shortcut, organized by category, and review it against your competitive analysis. Get it right before you build it.
If you realize halfway through development that you got something wrong?
Even if it's painful. Even if you've already built muscle memory for your own broken shortcuts. Because your muscle memory doesn't matter. Your users' muscle memory matters. And if you ship with broken conventions, you're asking every single user to pay the cost of your mistake.
That's a hard pill to swallow for a lot of developers. You've been using your own tool for months. You're fast with your custom shortcuts. And now you have to retrain yourself to match the industry standard.
It's hard, but it's not optional. This is one of those things where being right isn't enough. You have to be conventional. Because conventions exist for a reason — they reduce cognitive load, they increase efficiency, and they signal to the user that your product is trustworthy. Breaking them without a paradigm-shifting reason is just arrogance.
Let's talk about the other side of this. Daniel mentioned that if you get the shortcuts right, it works in your favor. But I think there's actually a deeper benefit than just avoiding user frustration.
Getting conventions right creates what's called "perceived usability." Users judge how easy something is to use partly based on whether it behaves the way they expect. If everything works exactly as they predict, they conclude the product is intuitive, even if they've never used it before. It's a kind of confirmation bias that works in your favor. Every time they try something and it works, their confidence in your product increases.
It's not just about removing friction. It's about building trust through predictability.
And trust is the foundation of adoption. Nobody switches to a new tool unless they trust it to work. Conventions are one of the primary ways you signal trustworthiness in the first few minutes of use.
I want to ask about a specific edge case. What about web-based tools versus desktop tools? Are the conventions the same?
Mostly, but there are browser-specific complications. Control W closes a tab in every browser. If your web app uses Control W for something else, you're fighting the browser. Control T opens a new tab. Control R refreshes the page. These are browser-level conventions that your web app cannot override without causing serious confusion. So web-based design tools often have to work around these constraints, which sometimes means using different shortcuts than their desktop counterparts.
That's a case where breaking the application convention is actually correct because the platform convention takes priority.
The hierarchy is: platform conventions first, then application category conventions, then your own product conventions. You only break a higher-level convention when a lower-level one would create a direct conflict.
If I'm building a web-based wireframing tool, and the standard design tool convention for something is Control W, I need to find an alternative because Control W already means "close tab" in the browser.
And you should document that alternative clearly, and ideally provide a way for users to customize shortcuts if they disagree with your choice.
Customizable shortcuts — is that a solution to the convention problem or a cop-out?
It's both. On one hand, giving users the ability to remap shortcuts is valuable, especially for power users who are coming from a specific tool and want to preserve their muscle memory. On the other hand, it can be a way for developers to avoid doing the hard work of picking good defaults. "Just customize it" is not an acceptable answer for a new user who's evaluating your product for the first time. Defaults matter enormously, because most users never change them.
There's research on that, isn't there?
The classic example is organ donation rates. Countries with opt-out systems have dramatically higher donation rates than countries with opt-in systems, even though the actual choice is the same. The default is sticky. In software, something like ninety-five percent of users never change any settings from the default. So your default shortcuts are effectively the only shortcuts that most of your users will ever experience.
Which means you can't outsource the convention problem to a preferences panel. You have to get the defaults right.
You absolutely have to. The preferences panel is for edge cases and power users. The defaults are for everyone.
Alright, let's broaden this out. Daniel's prompt is specifically about keyboard shortcuts, but the underlying principle applies to much more than that. What other kinds of conventions should someone building a design tool be aware of?
There's a whole category of interaction conventions. Double-click to edit text on a canvas. Drag to select multiple elements with a marquee. Click and drag to move an element. Shift-click to add to a selection. These are so universal that they feel like laws of nature, but they're entirely learned conventions. If you double-click something and it doesn't enter edit mode, it feels wrong.
Right-click context menus.
Right-click should always produce a context-sensitive menu. If your app doesn't support right-click, or if the menu that appears is empty or irrelevant, users will feel like they're using a broken product. This is such a strong convention that violating it creates what's called a "pop-out effect" in attention research — the absence of the expected behavior is more noticeable than the presence of an unexpected one.
What about visual conventions? Things like the hamburger menu, the gear icon for settings, the magnifying glass for search?
Those are iconographic conventions, and they're just as powerful as interaction conventions. The floppy disk icon for save is the classic example. Nobody uses floppy disks anymore. Most people under twenty-five have never even seen one. But the icon persists because the convention is stronger than the physical referent. If you replaced it with something more modern, users would be confused.
That gets at something important about conventions. They're not rational. They're historical. Control V for paste doesn't make any logical sense — it's not the first letter of "paste." It's next to Control C on a QWERTY keyboard, and it's what Xerox PARC chose in the nineteen seventies. We're all still living with that decision because the convention is now unchangeable.
Larry Tesler and Tim Mott at Xerox PARC. They invented cut, copy, and paste as we know it. And the specific key mappings — Z, X, C, V — those were chosen partly because they're on the bottom row of the keyboard where they're easy to reach with the left hand while the right hand stays on the mouse, and partly because they're next to the Control key. But the letters themselves are arbitrary. Undo is Z, not U. Cut is X, not T. Copy is C, which happens to be mnemonic. Paste is V, which is not. And yet these are now among the most deeply entrenched conventions in all of computing.
If you're building a new tool and you think Control Y makes more sense for paste because it's next to T for cut or something, you're wrong. Not because your logic is bad, but because the convention is too strong to fight.
This is where the "beautiful new paradigm" exception really matters. You can't just have a slightly better mapping. You need a completely different interaction model that makes the old mapping irrelevant. Pinch-to-zoom didn't just remap the zoom function. It changed the entire way users think about zooming. If you're not operating at that level, stick with the conventions.
Daniel's prompt also touches on something I think is worth exploring — the idea that these conventions are "baked in" and "don't come announced." There's an implicitness to them that makes them hard to learn except through experience. How does someone new to UI design actually acquire this knowledge?
Unfortunately, mostly through making mistakes and getting user feedback. But there are better ways. The Nielsen Norman Group publishes articles and reports specifically about interaction conventions. There are books — Don Norman's The Design of Everyday Things is the foundational text. There's also About Face by Alan Cooper, which is more practically focused on interaction design patterns. And there's a book called Designing with the Mind in Mind by Jeff Johnson that goes deep into the cognitive psychology underlying these conventions.
None of those are going to tell you "here's the list of shortcuts your wireframing tool needs.
No, and that's the gap. The specific application-level conventions are mostly tribal knowledge. They're passed from designer to designer, documented in scattered blog posts and pattern libraries, but not collected in any single authoritative source. Which is why the competitive analysis process I described is so important. You have to do the synthesis yourself.
Or you hire someone who's already done it. This is one of the arguments for hiring experienced UI designers rather than trying to figure it out yourself. They've already internalized these conventions.
An experienced designer doesn't need to look up whether Control G is the standard for grouping. They know it. They've been using it for years. They've seen what happens when an app gets it wrong. That tacit knowledge is enormously valuable and very hard to acquire from documentation alone.
Let's talk about the other side of this coin. When does adherence to conventions become a straitjacket? Is there a risk of over-conforming?
There is, but it's a much smaller risk than under-conforming. The danger is what's sometimes called "cargo cult design" — copying conventions without understanding why they exist. If you implement Control G for grouping because Figma does it, but you don't understand the underlying principle that users expect common operations to have keyboard shortcuts, you're going to miss other shortcuts that Figma doesn't happen to have but that your users still expect.
You need to understand the principle, not just copy the surface.
The principle is: reduce friction for common operations. Keyboard shortcuts are one way to do that. But the deeper question is, what are the common operations in your specific tool, and are you making them as efficient as possible? Sometimes that means following conventions. Sometimes it means inventing new shortcuts for operations that are unique to your tool. But even when you invent new ones, they should feel consistent with the existing conventions. Use the same modifier keys in the same ways. Don't make Control G mean "group" in one context and "ungroup" in another.
Consistency within your own product is its own kind of convention.
And there's a whole body of research on what's called "internal consistency" versus "external consistency." External consistency is matching other products. Internal consistency is matching yourself. Both matter, but external consistency usually matters more because users spend more time in other products than in yours.
I want to go back to something Daniel said about the first thing users encounter. He's right that keyboard shortcuts are often the very first interaction that reveals whether your app is "real" or not. But I think there's an even earlier test.
What's that?
The installer or sign-up flow. If your app is a desktop tool, the installation process has conventions. If it's a web tool, the sign-up and onboarding has conventions. And those conventions are often platform-specific and invisible to the developer until someone complains.
On macOS, users expect drag-and-drop installation from a disk image. On Windows, they expect an installer wizard. On the web, they expect email and password, or increasingly, social login. These are conventions too, and they're just as deeply baked in as keyboard shortcuts.
The same rule applies. If you break them, users don't think "this is innovative." They think "this is sketchy.
Especially with installation. If your macOS app comes as a zip file instead of a disk image, or if it doesn't follow the standard application bundle structure, power users will immediately be suspicious. They'll wonder if you actually know what you're doing. And that suspicion will color everything else they experience in your product.
The conventions start even before the app launches.
They start with the first moment a user becomes aware of your product. The website, the app store listing, the documentation — all of these have conventions. And users are evaluating you against those conventions constantly, mostly unconsciously.
Let's bring this back to practical advice for Daniel. He's building things. He's thinking about UI and UX. He wants to know what these invisible expectations are called and where to find them. What's the one-sentence summary?
They're called design conventions, they're governed by Jakob's Law, and the best way to learn them is systematic competitive analysis of the dominant tools in your space combined with platform-specific human interface guidelines.
The one thing not to do?
Don't trust your intuition. Your intuition has been corrupted by building the tool. You know too much. You can't simulate what a new user will expect. You have to observe actual users or at minimum study what the market leaders have already established.
Which is humbling, but necessary.
All of good design is humbling. The user is always right, not because they're smarter than you, but because they're the one who decides whether to use your product. You can be right about what's logical and still be wrong about what works.
Now — Hilbert's daily fun fact.
Hilbert: The average cumulus cloud weighs approximately one point one million pounds.
...that's a lot of water.
Just floating up there. If you want to dig deeper into this stuff, the Nielsen Norman Group's website is a goldmine. Don Norman's book is essential reading. And if you're building something, do the competitive analysis. Actually create the spreadsheet. It's tedious but it'll save you from the kind of mistakes that make users bounce in the first sixty seconds. This has been My Weird Prompts. Our producer is Hilbert Flumingtop. Find us at myweirdprompts dot com. We'll be back next time.
