ConceptIntermediateDesigning for Uncertainty & Trust / Onboarding users to probabilistic products / #6
Describe progressive disclosure for a complex AI feature.
SPARK the product is PulseGuard, an AI risk-monitoring dashboard for compressor and pump systems at a bottling plant
Picture a screen that shows exactly one number: a risk score between zero and a hundred, and nothing else. Femi Okonkwo checks fourteen of these numbers every morning before the first bottling run starts.
The direct answer
Show the score first, and nothing else, by default. One tap reveals the two or three factors driving that score. A second tap, only for someone who wants it, reveals the raw sensor trend behind those factors. And critically, the score itself has to carry its own recent history, not just its current value, or a slow-building risk can hide inside "medium" for weeks.
Do this, in order
Show a single risk score by default, nothing more.Why: fourteen dashboards full of raw sensor data is not something anyone can scan in a morning.
Always show the score's recent trend alongside its current value, never the value alone.Why: a score that creeps up slowly can sit in "medium" for weeks without ever tripping an alert.
Put the top contributing factors one tap away, not buried behind a settings menu.Why: the moment someone wants to know why, they shouldn't have to hunt for it.
Keep raw sensor data available, but never the default view.Why: it's real depth for the rare case that needs it, not something every glance should have to wade through.
Don't skip building the escalation layer for genuinely critical scores.Why: progressive disclosure still needs a floor where the system pages a human instead of waiting to be asked.
How to answer this, stage by stage
A student who reads only this section should be able to answer the question cold, in their own words.
Stage 1
Scope it to one real screen
Say it like this
"I'll answer this for PulseGuard, a risk-monitoring dashboard for compressor and pump systems at a bottling plant, and for Femi, who checks fourteen of these every morning."
Why this works
Turns an abstract design term into one screen a real person looks at daily.
Stage 2
Say your structure out loud
Say it like this
"I'll use SPARK. Situation, what Femi's morning looks like today. Payoff, the habit I want. Anchor, the layered design itself. Risk, what breaks it. Keep out, what stays hidden by default."
Why this works
Shows a plan before diving into layers, so the structure of the answer is visible.
Stage 3
Reframe the question
Say it like this
"Progressive disclosure isn't about hiding complexity. It's about deciding which of the fourteen glances this morning need a full explanation, and making sure the other thirteen don't cost Femi anything extra."
Why this works
Separates a real design answer from a definition copied out of a textbook.
Stage 4
Give the one decision
Say it like this
"Layer one is the score, with its trend line, always visible. Layer two, one tap away, is the top two or three factors driving it. Layer three, another tap, is the raw sensor data behind those factors, for the rare morning that actually needs it."
Why this works
Concrete and testable, and it matches the direct answer.
Stage 5
Prove it with a failure
Say it like this
"A sister plant's compressor sat at a 'medium' risk score for eight straight weeks while it crept from 20 to 68, and nobody noticed, because the dashboard only ever showed that morning's number, never the shape of the last two months."
Why this works
Shows the real cost of disclosure done without a trend view, not a hypothetical.
Stage 6
Say what you'd measure
Say it like this
"I'd track how often operators actually tap into layer two or three. If nobody ever does, either the top layer is already good enough, or people have stopped trusting the score enough to dig deeper. I'd want to know which."
Why this works
Shows you'd verify the design is actually being used as intended, not just shipped.
Stage 7
Say what you'd leave alone
Say it like this
"For a sudden vibration spike, urgent and simple to explain, I wouldn't make Femi tap through three layers. That case should surface everything at once and page a technician directly."
Why this works
Shows judgment: not every alert should be layered the same way.
Stage 8
Close on the one line
Say it like this
"Score with its trend by default, top factors one tap away, raw data one tap further. That's progressive disclosure done right for this screen."
Why this works
Restates the layered decision in one breath.
Let's learn
Picture a screen that shows exactly one number: a risk score between zero and a hundred, and nothing else. That's PulseGuard's default view, one score per machine, fourteen machines, checked once each morning before the first bottling run.
Before PulseGuard, a maintenance planner walked the floor and listened, felt for unusual heat, and logged anything odd by hand, roughly ninety minutes across fourteen systems. PulseGuard replaced that walk with a ten-minute glance at fourteen numbers.
The ten minutes were never the problem. The problem was what a flat number can quietly hide.
One compressor's risk score, week by week
Every one of these eight readings, taken alone, looked fine: comfortably inside "medium." The shape of the line is the only thing that was ever wrong.
Knowledge spark: what's progressive disclosure?
Showing the simplest version of something first, and letting a person ask for more detail only when they need it. Done well, it protects attention. Done badly, it hides the one detail, like a trend, that would have made the risk obvious.
At its worst: a sister plant's near-identical compressor followed almost the same climbing line, and because the dashboard there only ever showed that day's number, nobody connected eight separate "medium" mornings into one climbing risk. The compressor failed mid-shift, a repair and four hours of downtime that a trend line would have flagged in week three.
The dashboard was never lying. Every single number it showed was true. It just never showed the one thing, the shape of the line, that would have made the truth obvious three weeks sooner.
The decision I would take back
We showed only the current risk score, never its history, because a single number was simpler to build and simpler to read at launch. That was fine while risk scores moved fast enough that a bad one stood out immediately. It stopped making sense the day a risk could creep for two months without ever leaving the medium band.
What I would leave alone: a sudden vibration spike is urgent and simple to explain in one line. That case shouldn't get buried behind three tap-throughs, it should surface everything at once and page a technician directly.
The lesson: progressive disclosure isn't really about layers of detail. It's about deciding which single piece of information, if missing from the top layer, turns a true number into a misleading one.
Now here is the same thing as a story
The short version above is the design case. This one is how Femi's plant actually found the gap.
Every morning before the first bottling run, Femi Okonkwo checks one number on his tablet, for each of fourteen compressor and pump systems that keep the line running. It's the first thing he does after unlocking the control room.
The branch that matters most is the second one. A rising-but-medium score is exactly the case a flat number hides best.
For two years, PulseGuard's dashboard showed exactly this: fourteen numbers, refreshed overnight, nothing else unless you dug into a separate maintenance log most people never opened.
Same fourteen numbers, same morning. The only difference is whether the screen remembers what last week looked like.
Then word came through from a sister plant two states over, running the same PulseGuard system on nearly identical equipment. Their line 6 compressor had failed mid-shift, four hours of downtime, a full rebuild. When their team pulled the history afterward, the risk score had been climbing steadily for two months, medium the entire time, never crossing into the range that triggers an alert.
Layer two, the top factors, is the one that used to require digging through a separate log nobody opened on a normal morning.
Femi pulled his own plant's history that week, the first time anyone had looked at eight weeks of numbers side by side instead of one morning at a time. One of his fourteen systems showed the exact same climbing shape.
The top left corner is where progressive disclosure earns its keep: not urgent yet, but genuinely hard to explain in one number.
We didn't have a broken model. We had a true number, every single morning, that never once said which direction it was heading.
Four layers, and the fourth one only fires for the cases urgent enough that layering would just slow someone down.
It took someone else's four-hour outage, not Femi's own dashboard, to surface a gap that had been sitting quietly on his own line the whole time.
Now the score never appears alone. A small trend line sits under every one of the fourteen numbers by default, and a single tap opens the top two or three factors driving it. A second tap, only for the rare morning that needs it, opens the raw sensor data underneath those factors.
I built the flat single-number view because it was fast to scan and easy to defend as simple design. It took a sister plant's four-hour outage, not a failure on my own line, to see that "simple" and "safe" aren't the same claim.
SPARK, the three layersNot a menu of detail levels. SPARK is what forces the layering to survive the one case it's most tempting to skip.
S
Situation. Femi's morning, without the redesign.
Fourteen numbers, checked once, with no sense of which ones are moving in a direction worth watching.
Grounds the design in one real ten-minute habit, not an abstract dashboard.
P
Payoff. The habit worth building.
Femi learns to trust the top layer for most systems, and drill into layer two only for the ones actually worth the extra ninety seconds.
Names the habit as the real product: calibrated attention, not blanket vigilance.
A
Anchor. The layered design itself.
Score-with-trend by default, top factors one tap away, raw sensor data a second tap further, escalation for anything critical.
Concrete enough to build, and the direct answer to the question.
R
Risk. What breaks the anchor.
A risk that creeps slowly enough to stay inside one band for weeks, invisible without the trend line specifically.
Names the exact failure mode a flat top layer would have hidden.
K
Keep out. What stays hidden by default.
Raw sensor firehose data for all fourteen systems, all the time. Real depth, but not a default view anyone needs each morning.
Shows restraint: not everything belongs on the first screen.
Correct root-cause identification, by dashboard design
Nearly double the correct root-cause rate, from the same underlying model, just by letting operators reach the layer that actually explains the number.
The recap, one line per letter: situation is fourteen flat numbers checked once a morning, payoff is calibrated attention instead of blanket vigilance, anchor is the three-layer design plus a trend line, risk is a slow creep hiding inside one band, and keep out is the raw sensor firehose staying opt-in.
And if you want to be sure it really works, try it somewhere elseSame five letters, a ski resort's snow-making equipment instead of a bottling line. Here the complex factor is the weather, not a sensor trend.
Marit Skogland runs equipment operations at Pinecrest Basin, a ski resort, where SnowPulse monitors pressure and temperature across the snow-making system overnight, when the machines run unattended.
Mapped onto SPARK: situation is Marit's early-morning check of the system's overall health before lifts open. Payoff is trusting a single status light for most mornings, and only drilling into machine-by-machine pressure readings when something looks genuinely off. Anchor is the same three-layer shape: a status light by default, a short note on which machine and factor is driving any yellow or red status one tap away, and raw pressure and temperature logs a second tap further. Risk is a slow pressure drop across one line that a flat status light would keep reading "fine" until it wasn't. Keep out is a full weather-model overlay, useful for planning but not something every 5am check needs to load.
The second callout, trend since morning, is doing the exact job the missing trend line did back at the bottling plant.
Swap the trigger and it still runs.
Speed: an interviewer caps you at sixty seconds. Say "score with trend by default, factors one tap away, raw data a tap further," and stop.
Cost: there's no budget to build a full trend visualization this quarter. Say so honestly, and start with a simple up-or-down arrow next to each score, since even a crude trend signal beats none.
The model gets better, for real: if PulseGuard's overall prediction accuracy improves, that's still not a reason to remove the trend line, a rarer slow-creep case is still exactly the kind a flat number would hide.
Where people run it wrong.
They treat progressive disclosure as only about hiding complexity, and forget that the top layer still has to carry enough information to be honest on its own.
They bury every alert behind the same number of taps, regardless of how urgent or how simple the explanation actually is.
They build the raw-data layer and stop, assuming operators will dig in on their own, without ever checking whether anyone actually does.
How to use it live. When someone asks you to describe progressive disclosure, ask yourself one question first: what's the one piece of information that, if missing from the simplest view, would make that view actively misleading. Name that piece before you talk about layers at all.
Flashcards (tap any card to flip it)
1 · THE FRAMEWORK
What framework fits "describe progressive disclosure for a complex AI feature"?
Tap to flip
ANSWER
SPARK: situation, payoff, anchor, risk, keep out. The anchor is the layered design; the risk step is what forces the layering to actually hold up.
2 · THE PERSON
Who is this answer about?
Tap to flip
ANSWER
Femi Okonkwo, a maintenance planner who checks fourteen PulseGuard risk scores every morning at a bottling plant.
3 · THE HABIT
What did the flat dashboard fail to build in Femi?
Tap to flip
ANSWER
The habit of noticing direction, not just level. A score sitting in "medium" for eight weeks straight never once prompted a closer look.
4 · THE ANCHOR
What's the concrete design decision this answer commits to?
Tap to flip
ANSWER
A risk score with its trend, shown by default. Top factors one tap away. Raw sensor data a second tap further, for the rare morning that needs it.
5 · THE OLD DECISION
What decision would you take back?
Tap to flip
ANSWER
Showing only the current risk score, never its history, which made sense while scores moved fast enough to notice, and stopped making sense once a slow creep could hide for months.
6 · THE NUMBER
Fill in the blank: the sister plant's compressor risk score climbed from 20 to ___ over eight weeks without ever triggering an alert.
Tap to flip
ANSWER
68. It stayed inside the medium band the entire time, which never crosses the alert threshold.
7 · THE REPLAY
Same climbing risk, redesigned dashboard. What changes?
Tap to flip
ANSWER
The trend line makes the creep visible within the first few weeks, instead of the flat number hiding it for two months until a failure forces the issue.
8 · CROSS PRODUCT TRANSFER
Section 4 answers this again for a different product. Which product, and what's the complex factor there?
Tap to flip
ANSWER
SnowPulse at a ski resort's snow-making system. There, the complex factor is weather and overnight pressure trends, not a sensor drift pattern.
Check yourself Score: 0 / 0
True or false
1. True or false: this answer's fix was to remove the single risk score and always show full raw sensor data instead.
True
False
Show hint
Look at the direct answer and the "keep out" step.
Show answer
False. The score stays the default view. The fix adds a trend line to it and keeps raw data as an optional, deeper layer.
Multiple choice
2. Why did the climbing risk score go unnoticed for eight weeks?
A. PulseGuard's model was inaccurate.
B. The dashboard only ever showed that morning's number, with no trend, so a slow climb never looked different from a stable "medium" reading.
C. Femi stopped checking the dashboard entirely.
D. The alert threshold was set too high on purpose.
Show hint
Look at the line chart of the risk score over eight weeks.
Show answer
B. Every single reading was true and stayed inside the medium band. Only the shape of the line over time revealed the real risk.
Fill in the blank
3. Fill in the blank: with the full three-layer dashboard, operators correctly identified the true root cause ___ percent of the time, versus 41 percent with a score-only view.
Show hint
Look at the grouped bar chart comparing dashboard designs.
Show answer
79 percent. Nearly double the score-only rate, from the exact same underlying model.
Short answer, where it wouldn't matter
4. Name a kind of alert where this layered design should NOT apply, and why.
Show hint
Look at "what I would leave alone" and the quadrant diagram.
Show answer
Model answer: A sudden vibration or temperature spike. It's urgent and simple to explain, so it should surface everything at once and page a technician, not wait for someone to tap through layers.
Short answer, apply it yourself
5. Pick an app you use that shows a single summary number or status. What detail is hidden behind it, and would you ever want to see it without digging for it?
Show hint
Think of a health app's daily score, a credit score, or a weather app's simple icon.
Show answer
Model answer: Many people can name a summary score that hides a trend, a fitness app's daily "readiness" number that doesn't show whether it's been declining, which is the exact same gap this answer is about.
Before you close the answer
Why this works
Tests whether you understand progressive disclosure as a decision about which single fact makes the top layer honest, not just a general instinct to hide complexity behind taps.
Follow-up traps
"Why not just lower the alert threshold instead of adding a trend line?" Response: a lower threshold creates more false alarms on genuinely stable systems; a trend line catches the specific creeping case without touching the threshold at all.
"Doesn't showing a trend line by default undo the whole point of progressive disclosure?" Response: no, the trend line isn't extra detail, it's the one piece of context the top layer needs to be honest. Real depth, the raw sensor data, still stays behind a tap.
If pressed
PulseGuard's real fix also flags the rate of change itself as a separate signal from the absolute score, so a system climbing fast from a low baseline gets noticed even before it reaches the medium band at all.
From U2xAI Academy
From answering questions to owning outcomes.
A live workshop where you ship a working AI agent, defend a launch decision, and walk away with a portfolio recruiters can't wave off, not just more questions to study.
