The MUSe Framework: How to Measure the Functional Scale of a Digital Product

A practical method for comparing B2B products by their structure, unique components, and key user scenarios.

If you are planning to design or update a user interface for a B2B product and do not want to appear as an outsider in the eyes of the business, you need to identify the product’s objective complexity — or, more precisely, its functional scale.

This helps you estimate the time and resources required, justify those estimates, and decide which product to work on first when all other conditions are equal.

What does MUSe stand for?

MUSe is a lightweight framework for estimating the functional scale of a digital product.

Its quantitative part is the MUS score:

• M — Modules: the number of product sections;

• U — Unique components: the number of product-specific interaction components;

• S — Scenarios: the number of key user scenarios.

The lowercase e stands for experience. It is an additional qualitative layer used to discuss how understandable, coherent, and cognitively demanding the product is.

The quantitative result is written as an alphanumeric code, for example:

SX4-2, M6U2-2, L7U4-6

The MUS score estimates the product’s functional scale. The e layer complements it by describing the resulting user experience.

Why is counting screens not enough?

It may seem that all you need to do is count layouts or screenshots. The product with more layouts should then be considered larger.

But this approach is misleading.

In one product, every possible state may be covered by a separate layout at the customer’s request—or at the request of developers or testers. As a result, we may see dozens or even hundreds of layouts.

In some cases, the only way to distinguish them is to read the requirements or the task for which they were created. Perhaps the only difference in a list or table is a highlighted icon. Perhaps an error message contains different wording.

Is this important for understanding the scale of the product?

Obviously not.

Creating a separate layout for every possible state is often excessive. It may transfer responsibility, extend deadlines, and generate a large amount of work that does not contribute to a better understanding of the product.

In another product, states may be represented through components, typical layouts, and templates. This is usually more efficient and more appropriate.

We might therefore conclude that the second product is smaller. But in reality, both products may serve one or two key business scenarios of approximately the same complexity. In terms of functional scale, they may be essentially equal.

The basic idea

The MUSe Framework counts sections and forms with reference to user scenarios.

The important question is not how many elements are visible on a screen. The important questions are:

• How many entry points does the product have?

• How many steps are required to complete key tasks?

• How deeply are the product’s sections nested?

• How many unique interaction patterns need to be designed or implemented?

• How many key scenarios does the product support?

This makes it possible to compare products without confusing repeated visual states with genuinely different functionality.

How to calculate the MUS score

You can evaluate existing layouts, layouts that are still being planned, or the product itself.

Count only unique sections and forms. Do not count states, repetitions, notifications, or alternative messages as separate parts of the product.

1. Count the modules

Count the product’s sections, starting with the initial screen or entry point. Then choose the appropriate size category:

If you cannot find a suitable designation, you may never finish the product—or your team may have long forgotten what the product is for and who it serves.

2. Measure the maximum depth

Evaluate the nesting of each module, including tabs and forms, and record the maximum depth.

For example, suppose you have four root modules. One of them contains three tabs, and each tab allows users to open between one and four forms: create, view, edit, configure, use, or delete.

In this case, write down 7:

2 tabs + a maximum of 4 forms = 6

The resulting score might therefore begin with:

M6

The depth is not the average number of steps. It is the maximum structural depth found in the product.

3. Count unique components

Almost every product contains interaction components that are not part of the design system. These components have to be built from scratch, assembled from existing atoms, or implemented using third-party solutions.

Record their number after the letter U.

For example, suppose you have a chart that is developed specifically for this product and does not appear anywhere else. You would write:

U1

A repeated button, table, input field, or standard modal window should not be counted as a unique product component if it is already covered by the design system.

4. Count key scenarios

Record the number of key product scenarios for which the product was created.

A product without any scenarios raises an obvious question: what was it created for?

There are usually three or four key scenarios. The exception is an integration product that partially or completely incorporates the functionality of other products.

Write the number of scenarios at the end of the estimate, separated by a hyphen.

For example:

M6U1-2

This means:

• M — the product has a medium number of modules;

• 6 — the maximum structural depth is six;

• U1 — it contains one unique product component;

• 2 — it supports two key user scenarios.

The e layer: experience

The quantitative MUS score does not describe the quality of the user experience by itself.

Two products may have the same score but feel completely different to users. One may have a clear structure and predictable navigation. The other may be difficult to understand despite containing fewer modules and components.

The lowercase e in MUSe represents this qualitative layer.

It can be used to discuss:

• how easy the product is to understand;

• how predictable the navigation is;

• how much cognitive effort users need;

• whether similar functions are organized consistently;

• whether users can discover existing functionality;

• how much unnecessary complexity remains in the interface;

• whether the product’s structure corresponds to users’ mental models.

The e layer is not currently part of the alphanumeric score. It should not be confused with another numerical dimension until the team defines a separate and repeatable scale for evaluating experience.

This distinction is important:

A product can be large but easy to use.
A product can be small but confusing.

The MUS score describes the product’s functional scale. The e layer helps explain how that scale is experienced by users.

That’s it

In most cases, calculating the scale of a product should not take very long.

If you encounter difficulties, it may be worth reviewing and reorganizing the structure of your layouts.

If the estimate is very high, the product probably needs restructuring so that users do not get lost or ask for functionality that already exists somewhere in the product.

You are probably already thinking about that, aren’t you?

Advice, questions, and answers

The main advice: do not overcount

Do not count:

• confirmation forms;

• notifications;

• validation states;

• alternative error messages;

• repeated layouts;

• minor visual variations;

• different content inside the same component.

The goal is to identify meaningful differences in structure and functionality — not to document every possible state.

What about the amount of content in sections and forms?

Content density is more useful when estimating cognitive load. There are already several methods for doing that.

The MUS score is intended to estimate functional scale, not the amount of information users must process on each screen.

What should I do if the method does not work for my product?

Develop the method further — or look for a more suitable one.

The MUSe Framework is not intended to replace detailed product discovery, information architecture analysis, usability testing, or development estimation. It is a lightweight tool for creating a shared view of product scale.

My product does not have an initial section

But the product exists, right?

Then it has an entry point, even if that entry point is just a button, a link, or a trigger inside another product.

Use that entry point as the starting point for the calculation.

I got the result NNN. What should I do with it?

Record it, put it somewhere visible, and keep it up to date.

In addition to planning, the result can be useful in reports as an indicator of progress:

We started at SX4-1, and now we have grown all the way to M6U2-2!

Or:

We had XL32U9-8, but we removed obsolete functionality, introduced updates, restructured what remained, and now we have L7U4-6.

The score can also help compare several products and decide where design effort is likely to have the greatest impact.

Final note

The method may seem obvious — even boring. But there is nothing more important than discussing obvious things.

Imagine the color green. Now ask a colleague to do the same and point to it.

Just don’t fight.

MUSe gives the team a common language for discussing the scale of a digital product — without mistaking the number of screens for the complexity of the product itself.