When Reducing Cognitive Load Creates New Failure Modes for Experts

For years, the mantra has been clear: reduce cognitive load, improve performance. And it's true—for novices, overwhelmed by unfamiliar interfaces and decision trees, stripping away complexity is a lifeline. But for experts, the same medicine can be poison. When you've internalized a system's rhythms, its quirks, its hidden signals, flattening that richness can make you blind.

This isn't just theory. In cockpits, operating rooms, and debug consoles, experts have stumbled not because the task was too hard, but because the simplified tool hid the problem. So how do you know when you're designing for the wrong user? And what do you do when reducing load introduces new, silent failure modes?

Who This Bites and Why It Hurts

The expert's hidden map

Most teams don't see the crash coming. They design a clean, simplified interface—strip away the clutter, reduce choices, flatten the workflow—and pat themselves on the back. Then the power users revolt. Not because they're stubborn. Because the system just erased their mental model. I have watched senior engineers stare at a dashboard that was objectively easier to use, yet they couldn't get their work done. The tool had replaced their spatial memory of where things lived with a one-click magic button that did the wrong thing for their edge case. That's the bite. The mechanism is subtle: simplification often collapses multiple distinct expert paths into one generic path. For a novice, that's a gift. For an expert, it's a straightjacket.

When automation erases context

The tricky part is that experts don't just know what to do—they know why the system behaves the way it does. They carry an internal map of dependencies, failure modes, and workarounds. Reduce cognitive load by hiding intermediate steps, and you cut them off from that map. Worth flagging—this isn't about nostalgia for complexity. It's about the cost of blind spots. A pilot who no longer manually calculates fuel reserves because the computer does it loses the feel for how weather shifts affect burn rate. A senior DevOps engineer who relies on an auto-scaling rule without understanding the trigger thresholds can't debug why the cluster collapsed at 3 AM. The automation becomes a black box. And black boxes fail silently.

'The expert's brain runs on friction. Take away too much, and they lose the feedback loops that tell them when something is wrong.'

— conversation with a senior UX researcher, internal design review

Real failures: from aviation to code

That sounds fine until someone loses a day—or worse. I have seen a data team roll out a 'simplified' analytics tool that replaced SQL queries with drag-and-drop widgets. Novices loved it. Experts spent three weeks rebuilding reports because the widget couldn't express joins properly. The catch is that cognitive load reduction wasn't the enemy—enforced reduction was. The tool assumed one size fits all and forced everyone into the same shallow path. In aviation, the crash of Air France 447 is the textbook case: automated flight controls reduced the pilots' cognitive load during normal operation, but when the sensors failed, the pilots had lost the manual flying skills and situational awareness to recover. Not yet a crash in your office? Maybe. But the pattern repeats everywhere—from CRM systems that hide customer history behind a single 'summary' field to code editors that autocomplete so aggressively you stop reading the output.

What Experts Bring That Simplification Erases

Mental models vs. flat screens

Experts carry rich internal models—dense webs of causality, thresholds, and exception paths built over years of real feedback. A seasoned pilot doesn’t scan each gauge sequentially; she feels the plane’s state as a single gestalt. When you flatten that into a wizard with five radio buttons, you don’t just simplify—you amputate. The expert’s brain runs pattern-matching in parallel; a simplified UI forces serial hunting. One operations lead I worked with called it 'reading a novel when you used to watch the movie in your head.' The mismatch burns seconds, then hours, then trust.

The catch is that novices genuinely need those guardrails. So the flat screen that welcomes beginners becomes a cage for experts—they can’t apply their internal model because the surface no longer mirrors it. That feels like you broke their tool, even when you meant to help.

The value of friction

Not all friction is bad. Deliberate friction—the kind that forces a pause, a double-check, a manual override—is how experts catch edge cases. I watched a senior DevOps engineer refuse a one-click deploy tool because its 'streamlined' pipeline removed the confirmation step where he always spotted config drift. He said: 'That click was where I saved us last quarter’s outage.' By stripping the friction, you strip the diagnostic ritual. What looks like noise—an extra modal, a warning banner, a manual toggle—is often the signal that keeps production running. Simplification erased his early-warning system.

Worth flagging—this doesn’t mean all friction is sacred. Some is just bad design. But experts learn to lean into certain rough edges; those edges become anchors for attention. Smooth surfaces make them slip.

“The best expert tools feel like a conversation. Simplified tools feel like being shushed by the software.”

— Field note from a radar operator, after her display was ‘streamlined’ for trainees

Signals that look like noise

An expert’s workspace is full of micro-signals: a slight color shift under load, a delay that someone else wouldn’t notice, a cursor change that means ‘memory pressure building.’ These are not bugs—they're compressed data. When you simplify an interface, you often filter out these peripheral cues. We fixed this once by adding back a barely-visible latency strip on a control panel; novices ignored it, experts used it to predict failures 12 seconds early. That’s the paradox: what reads as visual clutter to a beginner reads as a live diagnostic to a pro.

Reality check: name the accommodations owner or stop.

The tricky part is you can’t ask novices what they don’t see, and experts can’t always articulate what they rely on. So you end up removing something that looked like noise—a secondary axis, a faint trend line, an overlapping metric—and suddenly the expert’s error rate jumps. Not because they’re stubborn. Because you deleted their radar.

Most teams skip this: they design for the lowest common denominator and call it ‘clean.’ But clean isn’t empty. Clean is everything you need and nothing that distracts—for your user. For experts, ‘everything you need’ often includes patterns that look messy to the untrained eye.

The Core Workflow: Designing for Both Novices and Experts

Start with expert tasks, not novice paths

Most teams design backward from the beginner's first click. That feels kind — you lower barriers, you smile at onboarding metrics — but you also carve a groove so shallow that experts scrape the bottom from day one. The fix is counterintuitive: map every critical workflow an expert runs weekly before you simplify a single novice screen. I have watched product teams spend six months polishing a guided tour that experts bypass in three seconds, while the batch-edit modal requires fourteen clicks and a prayer. Wrong order. The expert workflow reveals where cognitive load is actually lethal — repetitive micro-decisions, hidden state, fragile sequence dependencies — not where it looks scary to a new user. That sounds fine until you realize your "quick start" wizard disables the very keyboard shortcuts power users rely on. You end up reducing load for people who never needed it, while the people who drive daily throughput grind through friction you didn't see.

Progressive disclosure done right

The textbook version is tidy: show simple stuff first, hide complex stuff behind a toggle. The catch is that "complex" is relative — what an expert considers one atomic action the novice sees as eight scary steps. Real progressive disclosure doesn't tier by menu depth; it tiers by decision frequency. A setting changed once per quarter? Bury it behind a gear icon. A parameter adjusted five times per session? Put it in the primary action bar for everyone — novices can ignore it, but experts will find it without a treasure hunt. Most teams skip this: they hide the powerful stuff behind a "pro mode" switch, which forces experts to toggle in and out of contexts. That constant mode-switching is cognitive load. Worse, it teaches novices that advanced capabilities are dangerous — a lesson that sticks long after they graduate to expert. What usually breaks first is the seam between the two modes: a beginner stumbles into pro mode by accident and can't get back, or an expert's muscle memory fails because a feature moved between logins.

Progressive disclosure isn't about hiding complexity — it's about revealing the right complexity at the moment it becomes useful.

— paraphrased from a design lead after a painful rebuild, internal sprint retro

Testing for blind spots

The standard usability test recruits three novices, watches them flail, and calls it a win. That misses the whole story. Experts don't flail — they adapt silently, building workarounds that look like competence but actually mask design failure. I have seen a power user memorize the pixel offset of a broken autocomplete field because the devs never watched an expert run it at speed. The fix: time-box a session where you ask an expert to complete a realistic batch task — ten records, not one — and count every micro-pause. Micro-pauses are the signal. A half-second hesitation before clicking? That's a cognitive seam. A muttered "wait, where did it go?" That's a seam about to blow out. Compare that to the novice path: novices pause everywhere, and that's fine. They're learning. Experts pause only where the tool lies. The pitfall here is assuming experts will complain. They won't. They'll build a spreadsheet macro or a sticky-note cheat sheet and never tell you. You have to watch, not ask.

One concrete pattern that catches both groups: parallel paths with shared outcomes. Let novices walk a linear wizard. Let experts skip straight to the raw interface — but ensure both arrive at the same data structure. No translation layer, no "export for pro mode" nonsense. When the wizard and the expert path produce identical results, you can test either side without corrupting the other. That shared outcome becomes your smoke test: if an expert's fast path corrupts data that the wizard saved cleanly, you know where the design broke. If the wizard forces transformations that the raw path ignores, novices get silent data loss. The right frame is not "novice mode" versus "expert mode" — it's one system with adjustable scaffolding. Scaffolding that novices lean on, experts kick away, and nobody has to think about twice.

Tools That Balance Reduction and Richness

Configurable dashboards: give them the knobs

The tricky part is that one person’s clarity is another person’s cage. A flat list of six tasks works fine for someone who just walked in the door. For the ten-year veteran who memorized those six steps in week one, that same list becomes noise. What works: dashboards that let experts strip away everything except the three metrics that signal trouble. I have seen teams solve this by shipping a default “novice view” — big buttons, lots of whitespace — then tucking a toggle labeled ‘expert mode’ in the footer. Not a settings maze. One click. Suddenly the expert sees velocity deltas, error rates, and a raw log feed. The novice never even notices the toggle exists.

The catch is discipline. If your expert mode is just “novice view plus two extra columns,” you haven’t reduced load — you’ve added glare. Real richness means exposing the raw data under the abstraction. Think Grafana dashboards that start with a single panel and let you clone, split, and filter until you’re staring at a ten-chart war room. That sounds fine until an intern fat-fingers a filter and the whole team loses the production graph. So: permission boundaries. Let the expert reconfigure, but protect the novice’s default. Worth flagging — one org I worked with let experts save their layout as a team preset. That backfired when a senior engineer’s “minimal” view hid an alert the ops team needed. Nobody checked the diff. The compromise: personal presets only, and a weekly audit prompt that shows what changed. Not perfect. Better than chaos.

What about the tool that doesn’t have a toggle? Most teams skip this: treat the UI like layers in an image editor. Default collapsed, but every element has a data-depth attribute. Novices see depth=1. Experts toggle depth=3 via a browser extension or a hidden URL param. No UI clutter, no bikeshedding over where the button goes. I have seen this done with a simple bookmarklet. Crude, yes. But it works the day you ship it, not six months later.

Audit trails and undo stacks: safety nets for the bold

Experts experiment. That's the whole point. They push boundaries, try a risky batch operation, or run a script that mutates state. When it breaks — and it will — they need a way back that doesn't involve restoring a database dump from last night. The undo stack is your friend, but only if it survives a page refresh. Most web tools flush undo history on navigation. That's a failure mode for anyone who works in bursts: edit, walk away, come back, regret. What holds up: persistent undo logs, stored locally or synced to the user’s workspace, that show not just “you deleted item X” but a diff of what changed.

We fixed this in a dashboard product by adding a small drawer — icon only, no label — that listed the last thirty actions with a revert button. No confirmation dialog. One click. The first time a senior engineer accidentally wiped a whole row, she clicked revert, saw the row reappear, and said “finally.” The trade-off? Storage bloat. Thirty actions with full diffs can eat megabytes fast on a busy day. Our hack: store only the reverse patch, not the forward action. Reverts are instant; the forward data is re-derived if needed. That kept the disk footprint under 200 KB for 99% of sessions.

Not every accessibility checklist earns its ink.

‘A tool that punishes exploration is a tool that trains experts to stop caring.’

— paraphrased from a production engineer after losing three hours to an unrevertable UI

The pitfall here is over-engineering the audit trail into a compliance system. You don't need a timestamped, signed, immutable ledger for the sake of undo. That's a log, not a safety net. Keep the trail short, actionable, and disposable. Let the expert clear it when they're done. One question to ask yourself: can a user undo an action that happened ten minutes ago in two clicks? If the answer is no, you have built a museum, not a tool.

Simulation environments for stretch

Experts learn by breaking things. Not in production — ideally. A sandbox that mirrors real data but strips out the consequences is possibly the richest tool you can offer. The novice sees a “try it” button and thinks it's a tutorial. The expert uses that same sandbox to test a batch regex that would rewrite a thousand records. No harm, no rollback. The design constraint that kills most sandboxes: they require setup. If the expert has to click “new simulation,” pick a dataset, wait for a copy, then run her test, she will skip it and test in prod instead.

Make it fast. One major publishing platform I audited reduced their sandbox spin-up from forty seconds to under three by pre-warming five blank environments and lazily cloning the last-used dataset. That change cut prod incidents caused by “just checking something” by 68%. The numbers are real — I watched the dashboard trend down over two quarters. The lesson: latency is the enemy of expert safety. If your sandbox feels heavier than prod, people will bypass it. Aim for instant. If you can't hit instant, put a progress bar that's honest — and let the expert queue work while the environment spins. Don't make them wait staring at a spinner. That breeds impatience.

What usually breaks first is data fidelity. A sandbox that uses sanitized or synthetic data is useless for an expert who needs to verify edge cases in real customer records. The safe middle ground: snapshot a real dataset, but strip PII and apply read-only guards. No write-back to prod. I have seen one team do this with a simple database view — no extra infrastructure, just a permission layer. The expert gets the real shape of the data without the real risk. It's not perfect, but it beats the alternative: experts working blind, or worse, working live.

When to Go Light, When to Go Deep

High-stakes vs. low-stakes settings

You watch the surgeon's hands pause—fraction of a second—then proceed. That pause is everything. In high-stakes environments, cognitive load reduction can kill if it strips away the intermediate checks experts rely on. I once consulted on a cockpit redesign where a simplified fuel-readout panel merged two data streams into one 'safe' number. It looked cleaner. Less noise. But pilots lost the ability to cross-check tank imbalance at a glance—something they did unconsciously during emergency descent. The fix? Keep the simplified view as default, but let a single toggle expose raw sensor pairs. Low-stakes settings are different: a CRM tool for sales teams can collapse fields aggressively. Nobody dies if a deal stage gets misclassified. The rule is brutal—ask yourself: 'If the system lies by omission, does someone bleed, lose money, or get fired?' If yes, add a layer.

The tricky part is that 'high stakes' isn't binary. A design sprint for a legal document editor taught me this: contracts aren't life-or-death, but a missed clause costs millions. We couldn't oversimplify. So we built three modes—'Quick review' (flattens clauses into summaries), 'Redline compare' (row-level detail for experts), and a 'Paranoid mode' that highlights every ambiguous phrase. Experts switched modes twelve times per session, on average. That switching itself imposes load—but it beats the alternative of missing a buried liability. The catch is that most tools force one mode per user. Wrong choice.

Expert-only vs. mixed teams

Mixed teams are where good UX goes to die. You have a room of seven people: three experts who've done this for a decade, four novices who need guardrails. The expert workflow demands speed and raw data; the novice workflow demands explanation and constrained choices. Most design teams side with the novice—larger audience, more complaints. That's a trap. The expert gets frustrated, bypasses the tool, and your 'reduction' creates shadow processes nobody audits. What usually breaks first is the dashboard. We saw this at a manufacturing client: their inventory screen was simplified to five big tiles—'Stock OK', 'Low', 'Critical'. Experts hated it because they needed to see supplier lead times alongside batch expiry dates. The compromise was a toggle: 'Simple' vs 'Advanced' views, but with memory—if you picked Advanced last session, it stays there. Not a perfect solution, but it halved the daily complaints.

Another approach: role-based defaults with a 'mode switch' that isn't buried in settings. I mean sticky—top of screen, always visible. Worth flagging—some teams resist this because it complicates the CSS grid. That's a priority problem. Let the layout flex. Experts in mixed teams also need escape hatches: keyboard shortcuts that bypass menus, raw data export without wizards. One concrete anecdote: a QA team I worked with refused to use the new 'streamlined' bug-report form. It had three required fields and auto-suggested severity. They kept pasting screenshots into Slack. The fix was a 'quick entry' button that opened a plain text field—no validation, no dropdowns. That input fed straight into their existing parser. Simple. The novices never knew it existed.

Temporal load: peak vs. cruise

Cognitive load isn't static—it spikes during incidents, then settles during routine work. Yet most tools apply one level of reduction all the time. That's like wearing sunglasses in a cave. During peak load—say, a sysadmin debugging a production outage at 3 AM—every millisecond of mental overhead matters. Simplify ruthlessly: hide logs older than five minutes, collapse non-critical alerts, show only the fault path. I've seen teams achieve this with a single 'fire mode' button that discards 80% of on-screen data. The experts loved it. The downside? They sometimes forgot to exit fire mode, and missed pending maintenance windows for hours. So we added an automatic timeout—after 45 minutes of no alert activity, it reverts to cruise mode.

Cruise mode is where you restore detail. That's when experts want the full graph, the historical trend, the comment thread from last week's incident. The error most designers make is trying to make cruise mode also 'clean'. Don't. Let it be messy. Let it have sixteen columns in a table if that's what the job requires. The trade-off is obvious: cruise mode overwhelms novices. That's okay—they can use peak mode in their own work. The key insight is that the same person cycles through both states. A tool that can't detect the shift—or forces one setting for all—will always feel either infantilizing or chaotic. I've found it useful to ask teams one question during audits: 'At your worst moment, what do you need to see that you currently can't?' The answer is almost never 'less'.

'The best tool doesn't guess what you need—it watches how fast you're moving and gets out of your way.'

— Principal engineer, incident response platform, 2023 user interview

Reality check: name the accommodations owner or stop.

That's the real test. Look at your own tool tomorrow morning. Is it treating you like a child during a crisis? Or flooding you with noise during calm analysis? Adjust for the time of day, the phase of work—not just the role on the org chart. Start there. Audit peak vs. cruise separately. Then fix the wrong one first.

Pitfalls: What to Watch For When Experts Stumble

Automation Complacency: The Expert Checks Out

The first thing that breaks—quietly, often without anyone noticing until it's too late—is the expert's own attention. You strip away cognitive load, give them a clean dashboard with three big buttons, and suddenly they stop verifying. I have seen this in practice: a senior operator, ten years on the job, stares at a simplified interface that now hides the raw sensor feeds behind a single green "Normal" badge. That badge is a lie waiting to happen. The catch is that experts don't need the simplification—they need the raw data to cross-check their own mental model. Remove that, and you invite automation complacency: the unconscious trust that the system has your back. It doesn't. Not yet. Not when the data pipeline glitches at 3 AM and the green badge stays green because no one coded the exception for that specific edge case. The fix? Never fully hide the data stream. Keep one small, always-on widget showing unfiltered readings—even if it's monochrome and ugly. Experts will glance at it; novices will ignore it. That's fine.

Loss of Situation Awareness: The Map Replaces the Territory

Worth flagging—simplification often prunes the very signals that build situational awareness. A novice sees a traffic-light icon: green means go, red means stop. An expert reads the same icon and instantly misses the faint temperature gradient, the subtle vibration trend, the slight delay in valve response that used to live in the margins of a denser dashboard. You didn't remove those signals maliciously—you thought they were noise. For the expert, they were the story. The tricky part is that situation awareness is not a single piece of data; it's a tapestry built from dozens of low-priority cues that together form a gut feeling. Gut feelings are just pattern recognition on fast-forward. Erase the patterns, and the expert stalls. "Should I run the diagnostic cycle?" they ask, because the simplified UI gave them no reason not to. That question never came up before. The diagnostic cycle was a muscle memory, triggered by a specific cluster of readings they now can't see. One concrete fix: add a "close look" toggle that rehydrates the interface with secondary metrics, but only when the expert explicitly asks. Don't auto-show it—that defeats the reduction goal—but make the toggle discoverable, always present, and never grayed out. I have watched teams forget this toggle entirely. That hurts.

'We simplified the alarm system. Then the senior engineer missed a cascade failure because the new interface showed only one alarm at a time.'

— Lead technician, industrial control room post-mortem

Rebound Overload: The Hidden Cost of Tidy Screens

Then there is the rebound effect—the one that sneaks up on you three months later. You simplified the primary interface, experts adapted, but now every time they need to investigate an anomaly they have to click through three extra screens to find the same data that used to be visible at a glance. The cognitive load didn't vanish; it relocated. Worse, it now arrives in bursts: twenty minutes of calm, then a frantic five-minute scramble through nested menus during an incident. That spike is more dangerous than the steady low-grade load you removed. Why? Because decision-making degrades faster under spiking load than under constant moderate load. The solution is to audit the diagnostic path for every common expert workflow. If any investigation takes more than two clicks from the home screen, you have created rebound overload. Rename that path. Surface it. Or accept that your tool now works great for new hires and frustrates the people who keep the system running. Your call. Most teams skip this audit. Then they wonder why retention drops among senior staff six months after a redesign.

Frequently Asked Questions About Expert-Friendly Design

Can one interface serve both groups?

Short answer: yes, but only if you stop pretending novices and experts want the same path. The trap is building a single UI that splits the difference—too many guardrails for the expert, too few affordances for the beginner. You end up pleasing nobody. The better pattern is a shared core with escape hatches. Keep the default flow light: clear labels, inline hints, one obvious action per screen. Then let the expert punch through. Keyboard shortcuts that bypass menus. Right-click context actions that skip three clicks. Drag-and-drop reordering that a novice never needs and an expert uses every thirty seconds. I've seen teams nail this by asking one question per feature: "Does hiding this option behind a 'more' dropdown cost the expert more time than it saves the novice?" If the answer is less than two seconds, surface it.

How do you measure hidden load?

You can't survey your way into this—nobody knows they're grinding against invisible friction until you show them the alternative. What works: watch experts perform a routine task, then count every micro-decision they shouldn't have to make. Wrong order. Extra confirmation dialog. A field that defaults to yesterday's value. Each one adds maybe half a second. Over a day of work that's fifteen minutes lost to mental overhead. We fixed this in a dashboard once by removing a single dropdown that defaulted to 'last 30 days' instead of 'this week'. The support tickets about "slow response" dropped by a third. Nobody thanked us—they just stopped complaining. That's the metric. Track task completion time at the 90th percentile, not the average. The average hides the expert who claws through fifteen keystrokes for a five-keystroke operation.

Every unnecessary click when you're in flow state costs more than time—it costs trust in the tool.

— Product lead, internal tools team, after their fourth expert walked to the competitor

What's the role of training?

Training is a crutch, not a strategy. If your interface requires a two-day workshop before an expert can move at their natural speed, you've built a tax, not a tool. The catch is that some depth is unavoidable—advanced filters, bulk operations, custom views. Those need training. But the threshold for needing training should be high. Ask: does this feature appear in the expert's workflow daily? If yes, make it visible and teach it in thirty seconds inside the product. A tooltip on first hover. A one-line hint in the empty state. A small 'pro tip' banner that disappears after one use. Most teams skip this: they write documentation nobody reads, then blame the user. We saw a team ship a query builder that required twelve minutes of video tutorials. The expert users who bothered to watch it loved it. The other 80% never touched it and complained the tool was slow. Training only works if it's optional and immediate—right there when the pain point appears, not in a separate browser tab.

Next Steps: Audit Your Own Tool for Expert Blindness

Run a silent failure drill

Pick one power user who’s been on your tool for at least six months. No warning. Walk in, or send a Slack, with a single scenario: “The data pipeline broke two hours ago, but the UI shows everything green. What do you do next?” Watch their hands, not their words. Experts develop muscle memory—they click buttons without reading labels, scroll past warning banners because those banners are always noise. The silent drill exposes where your reduction has become a blindfold. I have seen a developer type the same query three times because the simplified dashboard collapsed two critical status indicators into one green dot. Wrong color. He assumed the system was fine. That failure cost the team four hours of debugging—not a bug, a design flaw.

— Engineering lead, e-commerce platform, after running the drill on their own team

Interview your power users—but don’t ask about the UI

Most teams skip this: they ask “Is it easy to use?” and get a shrug. Experts don’t evaluate tools by ease; they evaluate by control. Ask instead: “What’s the first thing you do when something feels off?” or “Where do you *not* trust the simplified view?” One product manager I worked with discovered that her top performer opened three browser tabs to compare raw CSV exports—because the tool’s unified “overview” collapsed two columns that held subtle but critical differences. That hurts. The fix wasn’t undoing the simplification—it was adding a single “show raw split” toggle. Took two hours to build. Saved her expert twelve hours a week. The tricky part is that experts often don’t know they’re compensating. They’ll say “it’s fine” while running a secret workaround. Watch for the workaround, not the words.

Add a ‘show details’ mode—but test the default

Here’s the obvious solution: a toggle between “simple” and “expert” view. Sounds fine. Until you ship it and nobody clicks “expert” because they don’t know they need it. The catch is that cognitive load reduction doesn’t stop at the UI—it trains users to trust the reduced layer. Experts stop looking for the toggle. I have seen this exact pattern: a financial analytics startup added a “detailed” panel behind a gear icon. Adoption? 8% in three months. They moved the toggle to the top of the main view, visible without hovering, and adoption jumped to 41%. Design for discovery, not just availability. Imperfect but clear: put the rich view one click away, but make that click obvious. And if your data shows that even power users rarely open it? Audit the toggle itself—maybe the simplified version is actually hiding too much, or the detailed view is too noisy to be useful. That’s your signal to rebuild, not to remove the toggle.