Understand
Explanation Layering
How much detail do I need?
Structures an explanation in depth layers, so a quick answer comes first and the full basis stays one step away.
- Evidence: research-based (Shneiderman 2020, Kulesza et al. 2013)
- Tested: concept only, mock data
Overview
Why it matters
The right amount of detail depends on who’s asking.
Someone checking whether they were treated fairly needs a short summary. A lawyer needs the full basis. A caseworker needs enough to act on. This pattern structures one explanation into layers, so the first answers the main question and the deeper ones are one step away.
It’s not just “show more”. It’s designing the right stopping points.
What does it look like?
Applicant reviewing an adverse decision
Applicant reviewing an adverse decision
- User sees a decision summary with a one-sentence primary reason.
- User clicks “Why?”: the first expansion shows the top 3 contributing factors.
- User clicks on one factor: a short explanation of what it means and how it affected the score appears inline.
- User clicks “Full explanation”: a detailed panel shows all factors, data sources, and confidence level.
Caseworker in a high-volume workflow
Caseworker in a high-volume workflow
- Caseworker processes 40 cases per day. Default view shows decision + top factor only.
- For borderline cases, caseworker expands to the full panel.
- For straightforward cases, the first layer is sufficient: no expansion needed.
Expert audit
Expert audit
- Auditor reviewing historical decisions sets “Expert mode” on.
- Interface shifts to show full factor list, model version, data quality indicators, and confidence bands by default.
- Auditor can review all cases at this depth without extra interaction per case.
When does it fit?
Use it when
- The full explanation is too much for a single view
- Experts and non-experts use the same interface
- Audit-level detail has to sit next to everyday explanation
Skip it when
- The explanation already fits in one layer
- Layers would hide what people need for a high-stakes decision
Design
How do I apply it?
-
Make the first layer complete.
It should answer the main question on its own, not withhold what matters.
-
Name layers by what they answer.
“How this was calculated” beats “More detail”.
-
Test where people stop.
Most never open the second layer. Anything important belongs in the first.
-
Don’t layer instead of simplifying.
A confusing first layer isn’t fixed by adding a second.
-
Set the starting layer by role.
A caseworker may start where an applicant ends.
How can I show it?
Tooltip / hover detail
A short note on hover or tap.
Short additional context surfaced on hover or tap: the lightest-weight form of layering. Appropriate for supplementary context (what a term means, why a field matters) rather than primary explanation.
Learn more inline expansions
Explanations in place, without leaving the page.
Specific terms, factors, or decisions linked to short in-context explanations, not modal dialogs or new pages. Keeps the user in their current context while accessing detail.
Summary → detail expansion
The key point first, full detail on request.
A default collapsed state showing the most important signal (the decision, the top factor, a one-sentence explanation) with an expand control for full detail. The most basic and widely applicable form.
Tabbed explanation panels
One tab per question: why, how sure, what next.
Tabs organizing different types of explanation at the same depth level: “Why this happened” / “How confident is the system” / “What you can do.” Each tab addresses a different user question rather than a different depth.
Stepped explanation flow
A guided path from summary to technical detail.
A guided sequence: summary → key factors → deeper context → technical detail. Each step is a deliberate design decision about what the user needs before they can usefully process the next layer.
Expert mode toggle
Switch the whole view to a more detailed one.
An explicit toggle allowing users to shift the entire interface to a more detailed view. Appropriate for tools where users have clearly differentiated expertise levels.
Further left for supplementary detail, further right for differences in expertise.
What does it cost?
Accessibility vs. depth
Layers can hide things from people who don’t know to look. For high stakes, make the first layer fuller.
Consistency vs. role adaptation
Different starting layers per role can confuse. Document and test them.
Getting it wrong has a cost
Oversimplified explanations raise mental effort and lower trust. Test defaults with real users.
Connections
Which patterns work with it?
Role-Based Explanations
Is this explanation appropriate for me?
Layering defines the depths available; role-based explanations determine where different users start within those layers.
Inspection Dialogue
Can I ask the system follow-up questions?
Inspection dialogue allows users to navigate explanation depth through conversation rather than through structural layers. The two patterns offer complementary approaches to the same problem.
Attribution
Why did the system make this decision?
Attribution content is often the primary candidate for layering: show top 3 by default, show full factor list on expansion.
Confidence & Uncertainty
How certain is the system?
Uncertainty information is often placed in a secondary layer: visible to users who seek it, not intrusive for users who don’t.
Sources (4)
Sources (4)
Nielsen Norman Group (2018) — Progressive Disclosure
canonical UX reference establishing the principle of revealing information incrementally to reduce cognitive load. Foundational for the UX dimension of this pattern
Shneiderman (2020) — Human-Centered Artificial Intelligence: Reliable, Safe & Trustworthy
proposes a human-centered framework for AI design that emphasizes user control and appropriate information density across expertise levels. Directly supports the layering approach as a mechanism for maintaining user agency without overwhelming non-expert users. Published in International Journal of Human-Computer Interaction, 36(6)
Johnson (2020) — Designing with the Mind in Mind
covers cognitive load theory and the limits of working memory. Provides the psychological basis for why layering is necessary: humans can hold only a limited amount of explanation in working memory at once
Kulesza et al. (2013) — Too Much, Too Little, or Just Right? Ways Explanations Impact End Users’ Mental Models
empirical study varying the soundness and completeness of explanations. Found that completeness matters more than soundness for users’ mental models, and that oversimplified explanations increased mental demand and eroded trust in the explanations themselves. The direct empirical basis for treating layering depth as a functional design decision rather than a cosmetic one
Your explanations are too dense for some users and too thin for others.
It’s the most common failure in explanation interfaces. That’s where this pattern starts. Let’s look at your interface together.
Work with me