A conceptual model is the simplified, user-centric representation of a SaaS platform.

It’s a way to structure the complexity of your software.

Creating a conceptual model involves grouping all features into intuitive modules.

Note that a conceptual model doesn’t always reflect the technical structure of your software. In some cases, it’s a fictional way of organizing the platform for better understanding.

We’ll talk more about it later in the article.

If done correctly, this approach helps leads understand and navigate the platform more easily.

When assimilating new information, people need a clear structure.

They won’t make sense of things when confronted with a mass of disjoint features.

They’ll experience confusion and have less interest in exploring the software. Without a clear structure, people can’t form mental anchors that will guide them in figuring out how the platform works.

When interacting with a SaaS for the first time, people need a zoom-out overview of the platform. Only after that will they feel comfortable zooming in and exploring further.

It’s like learning a new language

This is how I approached learning Thai.

First, I needed a general overview of how Thai works.

What’s the writing system? How many consonants and vowels does it have? Why is there no space between words?  What does it mean for a language to be tonal? Does it assign gender to nouns? Does it use declensions? How do verb tenses work?

Learning about the writing system, phonology, grammar rules, and syntax allowed me to gain a high-level overview of ภาษาไทย

After this exercise, I felt comfortable focusing on the nitty-gritty. And that’s how my painful journey of learning the Thai alphabet started. But that’s a different story.

The same happens when discovering a new SaaS platform. First, people seek to understand the software’s structure. And then, they can go into details, such as features.

A conceptual model helps leads and users understand a software’s structure. As a result, they can:

• Predict how different parts of the software work and how they relate to each other.
• Don’t have to process all the details at once. They can create ‘mental buckets’ and categorize new information accordingly. This simplifies learning.
• Know where to search for and find specific features.
• Retain what the software is all about.

That’s especially relevant when people engage with complex software.

A conceptual model mitigates software complexity

SaaS platforms vary in complexity. Some have low complexity levels, while others have high complexity levels. Software with low complexity may offer:

• One solution to a problem
• A small number of features
• One or two workflows / processes
• Concise documentation

For example, Fathom Analytics, a GA alternative, is low in complexity. The platform offers a small set of features to track website performance.

This type of SaaS can build messaging around the one problem it solves. The small list of features won’t overwhelm leads and users. The software structure is simple and it translates into clear, straightforward messaging.

Things are different when it comes to SaaS platforms with high levels of complexity. Here are some of their characteristics:

• A wide range of solutions covering multiple problems
• A large number of features and capabilities
• Countless workflows and processes
• Large documentation

Think about HubSpot and its wide variety of functionalities and capabilities.

How does a conceptual model translate into messaging?

A robust conceptual model allows teams to create straightforward messages. Messages that allow people to mentally map the software and make sense of it.

Imagine an HR software website with countless, random features that lack any order.

These features include automated job posting, resume screening, and AI-generated work policies. The website also lists training programs, checklists for new hires, and compensation tracking. And it’s not ending here, as the list goes on with dozens of features.

Without a conceptual model, teams lack a structured framework to organize information.

This makes it difficult to guide leads and users through a logical flow. As a result, messaging will feel clunky, confusing, and inconsistent. People may feel overwhelmed. They won't be able to understand where each feature fits within the overall structure.

Creating a conceptual model based on modules

Luckily, you can avoid transferring software complexity into messaging. You can do that by grouping features into categories that follow a specific logic.

I call them modules. Each module includes multiple features. Subsequently, these features involve different actions.

Let’s define each term:

• Modules refer to distinct, self-contained software segments that provide specific functionality and capabilities.
• Features are the specific functions that the software provides within each module.
• Actions are tasks or operations that users can perform within those features.

In other words, modules contain features, and features are based on actions users can take.

Modules allow you to organize your features in a coherent, yet non-overwhelming way.

Let’s take the HR platform as an example again.

Instead of just listing countless features, the team could group them into modules. These modules may include:

• Hiring solution, containing all features and actions related to hiring new employees
• Onboarding solution, focusing on all features and actions for training new employees
• Payroll solution, listing all features and actions for managing compensation
• The list goes on

The software itself may lack these modules, as the dashboard contains all the features together. However, this conceptual model—mostly fictional—allows people to progressively discover the platform. It also helps to make sense of where features fit in the bigger picture.

This conceptual model—sometimes fictional—allows people to progressively discover the platform. It also helps make sense of where features fit in the bigger picture.

You can use different principles to group your features into modules. Here are some of them:

• By functionality, based on the specific operations they perform (e.g.: data management)
• By purpose, based on the goals features help users achieve (e.g.: user engagement)
• By workflow, based on specific processes (e.g.: plan, review)
• By role, based on different types of users within the software (e.g.: administrator)
• By technical components, based on specific technical aspects (e.g.: API, security)
• By framework, based on specific methodologies (e.g.: Six Sigma, Agile tools)
• The list goes on

Regardless of what grouping principle you choose, you must use consistent logic. And don’t forget that the goal is to make your software structure easy to understand and navigate.