You sell accounts payable software to mid-sized finance teams. The product does everything buyers asked for in the sales cycle: approval chains, multi-entity coding, exception handling, audit trails. Then a new customer’s AP clerk sits down on the second day of month-end close with 300 invoices in the queue, and the invoice screen asks her to hold a vendor ID from one tab, a GL code from a spreadsheet and an approval rule from memory while she types. By the third day she is exporting to Excel and doing the work there.
That is a cognitive load problem. Cognitive load is the amount of mental effort a task demands from a person’s working memory, the small mental space people use to hold and compare information in the moment. When a screen asks for more than that space can hold, people slow down, make mistakes and look for workarounds. The good news for product teams is that a large share of the load in complex software comes from the design, not the work itself, which means you can remove it without removing features.
The Three Types of Cognitive Load
Cognitive load theory came out of educational psychology, through research led by John Sweller on how people learn complex material. It splits mental effort into three types, and the split is useful because each type calls for a different response from a product team.
Intrinsic load: the difficulty of the work itself
Intrinsic load comes from the task. Setting permission rules across five user roles is hard because each rule interacts with the others. The more pieces someone has to consider at the same time, the higher the load. You cannot design this away without removing the task, but you can manage it by breaking work into steps where each step settles one dependency, and ordering steps so earlier answers narrow later options.
Intrinsic load also depends on what the person already knows. Experienced users have built mental patterns that let them treat a cluster of details as a single idea. A veteran controller sees “an intercompany mismatch.” Someone in their first week sees six fields, two warnings and a status code that means nothing yet.
Extraneous load: effort the design adds
Extraneous load is effort that does nothing to help the user finish the job. Vague labels, inconsistent button placement, information scattered across tabs and screens crowded with options that rarely matter all add to it. This is the type product teams control most directly, and it is usually where the fastest gains are.
A blunt test works well in reviews. For each element on a screen, ask whether the people doing this task would notice if it disappeared. If the answer is no, the element is competing for attention without paying for it.
Germane load: effort that builds skill
Germane load is the effort people spend learning patterns that make the next session easier. You want this kind of effort, because it turns a hesitant new user into a confident one. The trap is assuming more help always means more learning. Tooltips on every field, compulsory product tours and pop-up tips feel helpful in a design review, but in use they interrupt the work and add extraneous load of their own.
Signs Cognitive Load Is Hurting Adoption
Users rarely say “the cognitive load is too high.” They say the product is confusing, slow or “not intuitive,” or they stop using it and say nothing at all. The behavior shows up first in your data.
Exports and side spreadsheets. When people regularly export data to finish a task elsewhere, the product is failing to show them what they need in one place. Ask customers what they do with exported files and you often find the missing view.
Long pauses and wandering cursors. In session recordings, look for people stopping before a decision, scrolling up and down a form or hovering between options. Those pauses usually mark the screen where someone is trying to remember or compare something the interface could have shown them.
Repeated errors on the same step. If validation errors cluster on one field, the field is probably asking for something users have to look up or recall.
Support questions about things the product already does. “Can it do X?” tickets for features that exist suggest the feature is buried, mislabeled or shown at the wrong moment.
Workarounds by experts. Power users who keep personal cheat sheets, sticky notes or bookmarked URLs are compensating for memory demands the product should carry.
Remember that many B2B users arrive already stretched. They switch between email, chat, a CRM and two other tools, and they are often interrupted mid-task. Design for the distracted person on a busy afternoon rather than the focused participant in a test session. A think-aloud usability testing process is one of the best ways to see where reasoning breaks down and why.
Which Effort Should Stay?
Some mental effort is the point of the product. A finance lead approving a large payment should stop and check the details. A clinician reviewing a medication change should weigh it. Removing that effort makes the product less safe.
The useful distinction is between effort that belongs to the decision and effort that belongs to the interface. Judgment the user is responsible for, such as approving, diagnosing or committing money, should stay, and the screen should make it as easy as possible to focus on. Finding, decoding, re-entering and cross-referencing information should go. In regulated products, keep checkpoints visible and explained, then strip the friction around them so attention lands on the risk rather than on hunting for the right tab.
Design Changes That Reduce Cognitive Load
The techniques below share one aim: lower what a person has to hold in their head at any moment, while keeping every capability reachable.
Show recognition, not recall
Recognizing something is far easier than remembering it. If a field needs a cost center, show a searchable list of cost centers with names, not a blank box that expects a code. Show recently used items first. Autofill values the system already knows, such as the vendor’s default payment terms. On the AP screen from the opening scenario, simply showing the purchase order details next to the invoice being coded would remove most of the tab switching.
Reveal advanced options on request
Progressive disclosure shows the common path first and keeps less common settings one obvious step away. A report builder can open with date range and metric, then offer “More filters” for segment logic and custom formulas. The key is to keep the reveal easy to find and in the same place every time, and to remember when a user prefers the advanced panel open. Experts lose nothing, and new users see a screen they can take in quickly.
Group related items and make hierarchy visible
People handle grouped information as a single unit. A settings page divided into clear sections with space between them is far easier to scan than one long column of toggles. Use size, weight and spacing to show what matters most, and keep the number of type styles small so emphasis still means something. The grouping principles in Gestalt psychology in design explain why proximity and similarity do so much of this work.
Put guidance next to the thing it explains
When help text lives in a side panel and the field it describes lives in the main form, the user has to combine the two in their head. Researchers call this the split-attention effect. Place short instructions beside the control, show errors next to the field with a clear fix, and show units and formats inside or beside inputs. The opposite mistake is repeating the same message in a label, a tooltip and a paragraph underneath. Say it once, in the right place.
Keep patterns consistent
Consistency lets people reuse what they already learned. When the primary action is always in the same place, with the same style and similar wording, nobody spends effort finding it. This gets harder as more teams ship features, which is one of the strongest arguments for shared components and design systems for scaling digital products.
Choose sensible defaults and say they can change
Every decision costs effort. Preselect the option most customers choose, explain in a few words why, and make it obvious how to change it later. People commit faster when they know a choice is reversible.
If your product has grown feature by feature and new customers are struggling to adopt it, an M7 UX audit maps where mental effort piles up across your key workflows, using heuristic review, analytics and user testing, and gives you prioritized fixes with wireframes.
Designing for Novices and Experts at the Same Time
The hardest part of simplifying B2B software is that the same screen serves people with very different levels of experience. A few principles from learning research help.
Match density to role and frequency
Dense screens are only a problem when they are dense for the wrong person. An analyst who reviews hundreds of records a day wants compact tables, keyboard shortcuts and bulk actions. A manager who checks in once a week wants a summary and a clear next step. Map each role against how often it performs each task. Daily tasks for experienced roles can carry more detail. Quarterly tasks need more structure even for experts, because nobody remembers a workflow they do four times a year.
Teach with worked examples
Beginners learn faster from a completed example than from a blank page. In a product, that means sample projects, prefilled templates and demo data that show what a finished setup looks like. Pair those with a short guided first task built around real work, so people learn the pattern while doing something they needed to do anyway.
Fade the help as skill grows
Guidance that helps a beginner gets in an expert’s way. Researchers call this the expertise reversal effect. Retire tips once someone has completed a task a few times, let people turn hints back on when they want them, and let experienced users skip setup wizards entirely. AI assistants can surface help at the right moment, but they need clear limits on what they suggest and tracking of whether they reduce errors. Our piece on enterprise AI UX strategy covers how to keep that kind of support trustworthy.
How to Test Whether a Redesign Reduced the Load
No single number captures cognitive load, so combine what people report with what they do.
After each task in a test session, ask participants to rate how much mental effort it took on a simple scale. Then compare those ratings with observed measures: task success, time on task, errors and how often they needed help. The two sets of numbers catch different problems. A redesign can feel easier while producing more errors, or speed people up while feeling more stressful.
Test novices and experienced users separately on the same workflows. A cleaner layout can help newcomers and slow down experts who depended on the old density, and you only see that trade-off when the groups are compared side by side. Include a full setup task, a common daily task and a rare but high-stakes task. Where you can, retest newcomers a week later to see whether what they learned stuck.
Then rank fixes by user risk, frequency and business impact. A confusing label on a screen every customer uses daily matters more than an awkward setting that a handful of admins touch once a year. In healthcare and financial products, anything that could lead to a harmful error goes to the top regardless of frequency.
Keep the Power, Lose the Strain
Complex products win deals because they handle complex work. They lose renewals when that complexity lands on the user’s memory instead of staying in the system. The aim is a product where people spend their attention on decisions, while the interface takes care of finding, remembering and cross-checking.
At M7, our designers and engineers work on the same team, so the simplifications we test with users are the ones that ship, from progressive disclosure to role-based views. If your product has outgrown its interface, explore how M7 can help with UX design and product engineering that keeps every capability within reach.
Frequently Asked Questions
Does reducing cognitive load mean removing features?
No. It means showing the right features at the right moment. Before moving anything, check usage by role: a setting most people never touch may be essential to one admin once a quarter, so tucking it behind a clear menu is usually safer than cutting it.
Is a minimal interface always lower in cognitive load?
Not always. Hiding labels behind icons or burying controls in menus can raise the load, because people have to remember where things are and what symbols mean. Clear labels and visible options often beat a sparse screen.
How is cognitive load different from usability?
Usability is the broader question of whether people can use a product effectively and with satisfaction. Cognitive load is one major cause of poor usability, focused on mental effort. A product can have a fast, accessible interface and still overload people with information they have to hold in their heads.
Can you measure cognitive load in production, not just in tests?
Partly. You cannot measure mental effort directly from analytics, but you can track proxies such as time on task, error rates, help article views, support tickets per workflow and export frequency. Changes in those numbers after a release are a reasonable signal, best confirmed with a few user sessions.
