How to Design Intuitive Software? Match the User's Mind

Software feels intuitive when it works the way the user already expects, which means intuitive design is fundamentally about matching the user’s existing mental model, not about clever interfaces or your own sense of what is obvious. The single biggest obstacle to this is the curse of knowledge: because you designed and built the software, you have a complete mental model of how it works, so every control and flow feels self-evident to you, while the user, who lacks that model, is often lost by the same design. This is why designers who rely on their own intuition produce software that is intuitive to them and confusing to everyone else. To design intuitively, you have to get out of your own head and into the user’s: understand the mental model they actually bring, match the interface to it through familiar conventions and clear affordances, and then test with real users, because you can never fully shed your own expert knowledge. The thesis names the move: to design well you must temporarily replace your own mental model with the user’s messier, unoptimized one. The Build First Brain lens frames it as designing to fit the user’s knowledge graph rather than forcing them to adapt to yours. Here is how to design intuitive software.

What makes software intuitive?

It matches the user’s existing mental model, so it behaves the way they already expect. Usability, the ease with which people can use a tool to achieve their goals, depends heavily on whether the design aligns with the user’s mental model, their internal understanding of how something works. When the software matches that model, it feels intuitive, because users can predict what will happen and where to find things; when it violates the model, even a logical design feels confusing.

So intuitive is not an absolute property of an interface; it is a relationship between the design and the user’s expectations. This reframes the whole task: you are not designing the objectively best interface, you are designing the interface that fits how your users already think, which requires knowing how they think. Intuitiveness lives in that match, which is why understanding the user’s mental model is the foundation of intuitive design, not a nice-to-have.

Why is the curse of knowledge the main obstacle?

Because once you understand how the software works, you cannot easily imagine not understanding it, so you misjudge what is obvious. The curse of knowledge is the cognitive bias where, once you know something, you find it hard to imagine not knowing it, and it is devastating for design: the designer’s complete mental model makes confusing flows feel clear, hidden features feel discoverable, and jargon feel plain, none of which is true for the user.

The obstacle and the response:

Designer’s trap (curse of knowledge)	Intuitive-design response
It is obvious to me, so it is obvious	Study the user’s actual mental model
Users will figure it out	Match conventions they already know
My logic is the right logic	Fit their expectations, not yours
I tested it on myself	Test with real, representative users

This is why designing from your own intuition fails, and why the thesis says you must temporarily overwrite your own model with the user’s: you have to deliberately set aside what you know and reason from the user’s far less complete and more chaotic understanding. But the curse of knowledge can never be fully escaped, which is the single most important practical consequence: you cannot reliably judge your own design’s intuitiveness, so you must test it with real users, the heart of user-centered design.

How do you actually design intuitively?

By understanding the user’s model, matching the interface to it, and validating with testing. The practical program: first, research and understand your users’ existing mental models, what they expect, what they already know, how they think about the task, since you are designing to fit that. Second, match the interface to it, primarily by using established conventions, because users carry expectations from other software, so following familiar patterns makes your design intuitive by leveraging models they already hold, while novel patterns force them to learn. Third, make actions and possibilities visible through clear affordances, design cues that signal how something can be used, so the interface communicates what to do without instruction.

Then, crucially, test. Because the curse of knowledge means you cannot trust your own sense of what is obvious, usability testing, watching real users attempt real tasks, is how you discover where your mental model diverged from theirs, and it routinely reveals confusions the designer could never have predicted. Testing is not optional polish; it is the mechanism that corrects for the curse of knowledge you cannot remove on your own.

How does a First Brain make this clearer?

By framing intuitive design as matching the software to the user’s knowledge graph rather than your own. Every user approaches your software with a biological knowledge graph, an existing set of mental models, conventions, and expectations, and intuitive design means fitting your interface into that existing structure so it connects to what they already know, rather than requiring them to build a new structure to use you. The curse of knowledge is precisely the gap between your richly-built graph of the software and the user’s sparse one, and good design bridges it from their side.

This is First Brain before Second Brain applied to design: the goal is to fit the tool to the mind, not force the mind to adapt to the tool, which requires modeling the user’s mind, an act of empathy and perspective-taking like re-mapping your communication to a listener in charisma as graph agility and transferring a model in how to communicate complex ideas faster. The designer’s skill is partly the ability to hold the user’s different, messier mental model alongside their own, which is a kind of cognitive flexibility, related to holding other perspectives generally. The method for building the flexible, empathetic modeling capacity that great design depends on is supported by Building Your First Brain, free for the first 1,000 readers, alongside the discipline of testing with real users.

What are the honest caveats?

Several, to keep this grounded in real practice. First, intuitive is relative, not absolute: what feels intuitive depends on the user’s background and prior experience, conventions are learned rather than innate, and nothing is universally intuitive, so design for your actual users rather than a mythical universal one. Second, the curse of knowledge cannot be fully escaped, so the overwrite-your-model framing is aspirational, and the real safeguard is testing with representative users, which is why no amount of empathy replaces it. Third, intuitiveness sometimes trades off against power: deep, professional tools may legitimately require learning, so the goal is appropriate ease for the audience and task, not maximal simplicity at the cost of capability. Fourth, accessibility is part of intuitive design, since an interface that ignores users with different abilities is not truly usable, and good design accounts for the full range of users. The durable point holds: software is intuitive when it matches the user’s existing mental model, the main obstacle is the curse of knowledge that makes your design feel obvious only to you, and you design intuitively by understanding the user’s model, matching it with familiar conventions and clear affordances, and testing with real users, which is designing to fit the user’s mind rather than forcing it to fit your software.

Key takeaways: how to design intuitive software

Software is intuitive when it matches the user’s existing mental model, so it works the way they already expect; intuitiveness is a relationship between design and user expectations, not an absolute property. The central obstacle is the curse of knowledge: because you built it, the design feels obvious to you while the user, lacking your model, gets lost. So you design intuitively by understanding the user’s mental model, matching the interface to it through familiar conventions and clear affordances, and crucially testing with real users, since you cannot fully escape your own expert knowledge. This is the Build First Brain lens: fit the tool to the user’s mind. The honest limit: intuitive is relative to the user, the curse of knowledge makes testing essential, ease can trade off against power, and accessibility is part of real usability.

Frequently asked questions

How do you design intuitive software?

By matching the design to the user’s existing mental model so it works the way they already expect. First, research and understand how your users think about the task and what they already know. Second, match the interface to that model, primarily by using established conventions users carry from other software, since familiar patterns leverage models they already hold. Third, make actions visible through clear affordances so the interface communicates what to do. Finally, test with real users, because the curse of knowledge means you cannot trust your own sense of what is obvious, and testing reveals where your model diverged from theirs.

Why does my software feel obvious to me but confuse users?

Because of the curse of knowledge, the bias where once you understand something you cannot easily imagine not understanding it. As the designer, you have a complete mental model of how the software works, so confusing flows feel clear, hidden features feel discoverable, and jargon feels plain, none of which is true for users who lack that model. This is why designing from your own intuition produces software intuitive only to you. The fix is to study the user’s actual mental model and, because you cannot fully escape your own knowledge, to test with real users who reveal the confusions you cannot predict.

What makes an interface intuitive?

A match between the interface and the user’s existing expectations and mental model, so they can predict what will happen and where to find things. Intuitive is not an absolute quality of a design but a relationship: the same interface can feel intuitive to one user and confusing to another depending on what models and conventions they bring. This is why following established conventions makes software feel intuitive, since it leverages expectations users already hold from other tools, while novel patterns force them to learn a new model, which feels unintuitive even if the design is logical.

Why is user testing so important for intuitive design?

Because the curse of knowledge cannot be fully escaped, so you cannot reliably judge your own design’s intuitiveness. Your complete mental model of the software makes you a poor judge of what a first-time user will find clear, so your own sense that something is obvious is untrustworthy. Usability testing, watching real, representative users attempt real tasks, is the mechanism that corrects for this, revealing where your mental model diverged from theirs and surfacing confusions you could never have predicted. Testing is therefore not optional polish but the core safeguard of intuitive design.

Is any software universally intuitive?

No, because intuitiveness is relative to the user’s background and prior experience. What feels intuitive depends on the conventions and mental models a person already holds, which are learned rather than innate and vary across users, so nothing is intuitive to everyone. An interface that follows conventions familiar to its target users will feel intuitive to them while potentially confusing others. This is why you design for your actual users rather than a mythical universal user, and why understanding your specific audience’s existing expectations is the foundation of designing software that feels intuitive to them.