Mental Models Matter: Why UX Mockups Shouldn’t Be the Primary Focus When Talking About New Software Product Features

I get it… We all like something we can point at and that’s why most discussions about new software products and features tend to focus upon UX mockups of those features.

I guess it’s natural. Mockups are the first visual representation of the feature and how it might be used. They facilitate discussion about it. They are tangible and we can point at them, which helps immensely, particularly if the feature is at all complex.

I’ve talked before about why I believe UX mockups need validating against underlying data, but I’d go further and say that UX shouldn’t drive product discussions at all.

Why?

I believe UX-led products risk being inconsistent, unintuitive, confusing to users and harder to build upon.

But let me explain…

I believe strongly that feature discussions should be driven by the user’s mental model as they use the product, and the abstract concepts those models are built upon.

These are unfortunately much harder to discuss, harder to draw, harder to point at and therefore to focus upon, but following this approach results in products that users are more likely to understand and to just “get”

UX should be built upon the abstract concepts that define the product feature, driven by the way a user will understand it and the data we will model those concepts with. UX is a view on those concepts, how they are surfaced externally and how we allow a user to interact with them.

UX should be driven by mental models and abstract concepts, not vice versa.

Why does this matter? In my experience, it is rare that UX-led product discussions result in logical and coherent mental models that align with the way the software actually works… across all features.

If developers build UX-led features, the abstractions they derive can often be inconsistent between different parts of the product. Often those concepts don’t even represent real things that the user would have in their mental model. So users find it hard to understand the product, to see consistency between features and to align their thinking with them… which is what makes products usable.

If we drive UX on those concepts and mental models, the entire UX for the product will consistently represent the ideas the user will approach the product with in their heads… across all features.

So how do we talk about abstract concepts and mental models?

• Real Things Only — Ensure the concepts we discuss represent real things and ideas, not random technical abstractions. These should be things the user would understand: accounts, payments, real-world objects or ideas people might talk about outside of our software engineering world.
• Naming — Name them consistently. When we talk about them, we all need to call an abstract thing by the same name, so we know what we’re referring to. Keep a list of terminology and stick to it.
• Draw & Visualise — Draw diagrams and pictures showing how they relate. In the user’s head, what is a feature expected to do for them? What information and concepts does it use?
• Discuss — Discuss features in terms of how they create, change and use those concepts, but without a UI. How would a user imagine the feature working in abstract terms? What information and data would they expect? Do we have (or can we obtain or derive) that data?
• Concept-led UX — Build UX upon that discussion and it will naturally form a coherent representation of the mental model a user has when using the product.
• For every discussion and every new feature, return to the concepts and discuss it in those terms first, then move on to the UX.

Leading with mental models means the abstractions the product is built upon will be consistent, will logically be surfaced in the UX and will be closer to the way the user expects the product to work. UX will more meaningfully represent a view on concepts the user understands, not just arbitrary abstractions that a developer constructed in an attempt to infer and build a feature from the UX.

Drive everything from the mental model the user will approach the product with, not just from UX, and I believe the product will be more usable, more compelling and, perhaps, even more successful.