Conceptual Models: The Missing Link Between Research and Design

You've finished your user research. You understand your users' needs. You're ready to design. So naturally, your next step is to open Figma and start sketching wireframes, right?

Wrong.

If you jump straight into wireframing, you've skipped the most critical step in the design process — one that separates intuitive products from confusing ones. You've skipped designing your conceptual model.

What Is a Conceptual Model?

Think about it this way: When someone says "I know how to use Photoshop," they're not talking about where the buttons are. They're referring to something deeper — an understanding of what Photoshop is and how it works.

A conceptual model is a high-level description of how your system is organized and what users can do with it. It's the structure that sits between user research and interface design — the blueprint that defines what your product is before you decide what it looks like.

Here's what it includes:

• Core objects users will work with (emails, appointments, photos)

• Actions users can perform on those objects (send, schedule, edit)

• Relationships between objects (folders contain emails, calendars contain appointments)

• Attributes of each object (email has a subject, date, sender)

Notice what's missing? Any mention of buttons, screens, colors, or layouts. A conceptual model exists independently of the interface.

Why Mental Models Matter

Before users even touch your product, they already have expectations about how it should work. These expectations are called mental models — internal representations based on:

• Previous experience with similar products

• Understanding of the real-world task

• Assumptions and intuitions

• Things they've heard from others

Your job as a designer isn't to change users' mental models (that's expensive and frustrating for everyone). Your job is to design a conceptual model that matches them.

When your product's conceptual model aligns with users' mental models, the interface feels intuitive. When there's a mismatch, users struggle — no matter how beautiful your UI is.

A Real Example: The Reading App

Imagine you're designing an e-book reading app. Users come with a simple mental model from physical books: "I open a book, read pages, and use a bookmark to save my place."

But what if your app's conceptual model is built around "documents" that need to be "imported" into "libraries" before you can "launch a reading session"? 

Users expect to simply tap a book and start reading. Instead, they're confronted with unfamiliar concepts: What's the difference between my library and my bookshelf? Why do I need to import something I already purchased? What's a "reading session"?

The interface might look beautiful, but users struggle because the conceptual model doesn't match their mental model of reading a book.

Conceptual Models vs. Everything Else

Let's clear up some confusion. A conceptual model is NOT:

Not the user interface. It doesn't mention buttons, screens, colors, or layouts. It only describes what users can do and what concepts they need to understand.

Not users' mental models. You can't directly access what's in users' heads. But you can design a conceptual model that makes sense based on their understanding of the task domain.

Not use cases. Use cases describe task flows — the steps users take. The conceptual model describes the system structure that enables those tasks.

Not the implementation architecture. Your database structure, API endpoints, and code classes are invisible to users and shouldn't appear in your conceptual model.

How to Build a Conceptual Model

Step 1: Identify the Core Objects

What are the main "things" users will work with? Use language familiar to your users and avoid technical jargon.

For an email app:

• Messages

• Folders

• Contacts

• Attachments

For a recipe app:

• Recipes

• Ingredients

• Shopping lists

Step 2: Define Actions and Attributes

Once you've identified objects, assign actions and attributes based on how users will interact with them.

For a recipe:

• Actions: save, share, rate, cook

• Attributes: cooking time, serving size, difficulty, ingredients list

Step 3: Map Relationships

How do objects connect to each other?

• Hierarchical: Folders contain messages

• Associative: Recipes include ingredients

• Sequential: Steps follow an order

Step 4: Keep It Simple

Use consistent terminology throughout. If you call something an "appointment" on one screen, don't call it a "meeting" on another.

The golden rule: Less is more. Every new concept you add increases complexity exponentially, not linearly. Each concept potentially interacts with every other concept in your system.

Visualizing Your Conceptual Model

Lists and paragraphs aren't efficient for describing structure. Visual concept maps are much clearer.

A visual conceptual model shows:

• Objects as nodes — the main things users work with

• Relationships as connecting lines — how objects relate to each other

• Actions as annotations — what users can do with each object

• Attributes as details — properties of each object

For example, in an email app:

• Message node connects to Folder (relationship: "contained in")

• Message node connects to Contact (relationship: "sent to/from")

• Message node connects to Attachment (relationship: "can include")

This visual structure makes it easy to spot missing connections, unnecessary complexity, or opportunities to simplify.

A Practical Example: Alarm Clock

Let's look at a simple alarm clock to see conceptual modeling in action.

The conceptual model includes:

• Current Time

• Continuously updates

• Can be displayed

• Can be set by user

• Alarm Time

• Can be set by user

• Can be enabled/disabled

• Triggers when it matches current time

Notice this model could describe a digital travel clock, an analog clock, an iPhone alarm, or an Android alarm. The conceptual model stays the same even though the presentations differ completely.

Why This Matters for Your Design Process

When you start with a conceptual model, everything else flows more smoothly:

1. Consistent terminology across your product Your team has a shared vocabulary. No more "is this a 'task' or a 'to-do'?" debates.

2. Clearer task scenarios You can write use cases using only concepts from your model, testing whether it supports user goals before building anything.

3. Focused interface design Your UI translates abstract concepts into concrete presentations. You know exactly what needs to be visible and interactive.

4. Better documentation Technical writers know which concepts need explanation and what to call them.

5. Aligned development Engineers understand which objects and actions need to exist in the code.

Common Mistakes to Avoid

Mistake #1: Exposing implementation details

Bad: Users see "Create Record" to log work hours Good: Users see "Log Hours"

One time-tracking app showed "Success: new row inserted" after users logged hours. When someone tried to log the same week twice, it displayed "ORA-00001: unique constraint violated" instead of simply saying "You've already logged hours for this week."

Mistake #2: Inconsistent terminology

Calling the same thing "cancel," "delete," and "remove" in different places forces users to wonder if these are different actions.

Mistake #3: Trying to support contradictory models

Some design decisions require clear choices:

• Is your website a flat collection of linked pages, or a hierarchy with a clear structure?

• Are user comments organized as threaded discussions or a simple chronological list?

These decisions matter. They determine how users think about your product, what actions they can take, and how successful they'll be. You must make a clear choice. If you try to support multiple contradictory models simultaneously (for example, treating your site as both a flat collection AND a strict hierarchy), users will get confused about how the system actually works.

The Design Process with Conceptual Models

The design process isn’t perfectly linear. As you move from the conceptual model to the user interface and then to implementation, you’ll almost always uncover gaps or contradictions in your original thinking. That’s normal — and it’s exactly why the model exists.

Here’s how the process typically unfolds:

1. Start with the conceptual model — Define the core objects, actions, and relationships.

2. Write task scenarios — See whether the model truly supports users’ goals.

3. Design the interface — Translate the abstract concepts into concrete UI patterns.

4. Build and test — Validate assumptions and reveal what works and what doesn’t.

5. Refine the model — Update it based on what you learn.

6. Update everything else — Align the UI, code, and documentation with the improved model.

The important part is to keep your conceptual model documented and up-to-date. Don’t let it freeze after the initial design phase — it should remain a living, shared reference throughout development.

The Bottom Line

Conceptual models help you step into users’ shoes and design products that feel intuitive from the start. They give developers a clearer foundation for building use cases and help UI designers create interfaces that align with how people naturally think.

Most importantly, they encourage you to address critical design questions early—long before those decisions become costly to change.

So before you sketch the first screen, take a moment to design what you’re actually designing. Get the underlying structure right, then build everything else on top of it.

Your users — and your future self — will thank you.