ACE Journal

Progressive disclosure of AI reasoning steps in decision support UI

Expected context: front-end engineers and product designers building professional decision support tools (clinical, financial, legal, operational) where an AI model generates recommendations and a human bears accountability for the final call. Some familiarity with React or a comparable component model will help you follow the code sketch; the concepts apply to any component-based UI. Familiarity with explainable AI concepts is useful but not required. This article does not cover model training or interpretability; it covers the interface layer above the model.

The analyst who gets too much, and the one who gets too little

Picture two analysts using the same AI-assisted contract review tool.

The first opens a flagged clause. The tool shows: “HIGH RISK - non-standard indemnification.” Below that, a list of twenty-three contributing factors, each with a numeric weight, most of them referencing internal model features she has no direct way to interpret. She reads the first five, stops, clicks approve, moves to the next clause. The recommendation was probably right. She will never know, and neither will the audit trail.

The second analyst works in a different deployment of the same model, at a firm that took the minimalist path. He sees only the recommendation label. There is no expand affordance. He disagrees with the flag but has nothing to push back against, no contributing factors to identify as inapplicable, no way to make his override legible. He overrides anyway. His manager later asks why. He cannot say.

Both failures come from the same root cause: the interface did not meet the user where they are. Progressive disclosure is the pattern that threads between them.

What progressive disclosure of reasoning actually means

Progressive disclosure is a Nielsen-era information architecture principle [1]: expose detail in response to user intent rather than all at once. Applied to AI reasoning, it means organizing the explanation into distinct depth levels, each revealed only when the user signals they want more.

A three-level model covers most professional decision support contexts:

Figure 1 shows this as a state machine. The transition arrows are user-initiated, not automatic.

stateDiagram-v2
    [*] --> Summary : recommendation arrives
    Summary --> Evidence : user expands
    Evidence --> Summary : user collapses
    Evidence --> FullTrace : user requests full reasoning
    FullTrace --> Evidence : user collapses
    FullTrace --> [*] : user acts (approve / override / escalate)
    Summary --> [*] : user acts on summary alone

Figure 1. Disclosure level state machine. Each transition is user-initiated; the system never auto-expands. Note that acting is available at every level: the user does not have to read deeper to make a decision.

The state machine is simple. The hard design work is in what lives at each level and how the transitions feel.

Anchoring: why the order of disclosure matters as much as the content

Displaying the recommendation before the evidence is the most common mistake in decision support UI, and it has a specific cognitive cost: anchoring bias. When a user sees “HIGH RISK” before reading the contributing factors, they read the factors as justification, not evidence. Factors that support the label feel confirmatory; factors that cut against it get discounted.

The interaction design mitigation is to invert the order at Level 1. Present the top contributing factors first, in the order a trained expert would naturally review them. Let the user form a preliminary judgment. Then reveal the synthesized recommendation. This is not about hiding the model’s conclusion; it is about not letting the conclusion corrupt the evidence evaluation.

This display-order effect is documented in clinical decision support literature on “alert fatigue” and recommendation override behavior [2]. The same pattern applies in financial underwriting interfaces, where showing a credit score before the application details reliably reduces auditor engagement with the application data.

There is a practical tension: users under time pressure want the recommendation fast. One resolution is to show the recommendation immediately at Level 0 but make Level 1 factor-first. The user who expands is signaling they want to think, not just confirm.

A component model for disclosure levels

Here is a React component sketch for a three-level disclosure panel. The goal is to show the structure, not a production-ready implementation; prop types and styling are omitted for clarity.

// ReasoningPanel.jsx
import { useState } from "react";
import { FactorList } from "./FactorList";
import { FullTrace } from "./FullTrace";
import { ConfidenceRing } from "./ConfidenceRing";

// Expected prop shapes:
//   factors: [{ id, label, direction: "increases" | "reduces", description }]
//   trace:   [{ stepIndex, text, sourceRef? }]
const LEVELS = { SUMMARY: 0, EVIDENCE: 1, TRACE: 2 };

export function ReasoningPanel({ recommendation, factors, trace, confidence }) {
  const [level, setLevel] = useState(LEVELS.SUMMARY);

  return (
    <div className="reasoning-panel" data-level={level}>
      <header>
        <ConfidenceRing value={confidence} interactive />
        <span className="recommendation-label">{recommendation.label}</span>
        {level === LEVELS.SUMMARY && (
          <button onClick={() => setLevel(LEVELS.EVIDENCE)}>
            See {factors.length} contributing factors
          </button>
        )}
      </header>

      {level >= LEVELS.EVIDENCE && (
        <FactorList
          factors={factors}
          factorFirst={true}
          onRequestTrace={() => setLevel(LEVELS.TRACE)}
          onCollapse={() => setLevel(LEVELS.SUMMARY)}
        />
      )}

      {level === LEVELS.TRACE && (
        <FullTrace
          steps={trace}
          onCollapse={() => setLevel(LEVELS.EVIDENCE)}
        />
      )}
    </div>
  );
}

A few things are worth noting in this sketch. The data-level attribute on the root div makes the current disclosure depth queryable from analytics and testing. The ConfidenceRing is marked interactive: it is not a decorative badge; clicking or hovering it is a natural entry point to Level 1 for users who want to understand what the confidence score means. The factorFirst prop to FactorList enforces the order inversion described above; it is a named signal in the code, not a magic CSS trick.

The FullTrace component is where streaming reasoning fits in if the model supports it. Rather than rendering the trace as a static dump, it can stream reasoning steps as they arrive, letting the user follow the model’s logic in real time and interrupt if a step is wrong before a final recommendation commits.

Calibrated confidence display

Confidence scores are not optional decoration. A bare recommendation label without a confidence signal forces the user to treat every output as equally certain, which it is not. But a raw probability number (“0.847 confident”) is worse than useless for most domain experts: it implies false precision and gives no frame for what 0.847 means in this context.

Two patterns work better than raw probabilities:

  1. Ordinal bands with calibration disclosure: label confidence as Low / Moderate / High, and document in the UI what the model’s historical accuracy rate is within each band on held-out cases from a representative distribution. This is honest about the model’s actual reliability without implying spurious precision.

  2. Comparative framing: “This case scores higher risk than 91% of cases we’ve processed in this category.” Domain experts often reason comparatively rather than in absolute terms; comparative framing maps onto their existing mental models.

Figure 2 illustrates how the three disclosure levels map against the information available at each depth.

graph TB
    subgraph Level0["Level 0 - Summary"]
        A[Recommendation label]
        B[Confidence band]
    end
    subgraph Level1["Level 1 - Evidence"]
        C[Top 3-5 factors, natural language]
        D[Factor directionality]
        E[Source document snippets]
    end
    subgraph Level2["Level 2 - Full trace"]
        F[All factors with weights]
        G[Chain-of-thought steps]
        H[Raw retrieved passages]
    end
    Level0 --> Level1
    Level1 --> Level2

Figure 2. Information available at each disclosure level. The boundary between Level 1 and Level 2 is where cognitive load risk increases sharply; most users should be able to make well-informed decisions from Level 1 without needing Level 2.

The component model above surfaces the confidence ring at Level 0. At Level 1, the confidence band should be accompanied by a brief calibration note, something like “In similar cases, HIGH risk flags are confirmed on further review at a rate we observe in our validation set.” That note requires the team to have actually done the validation work. If it has not been done, show less rather than fabricate a number.

The hard part: over-disclosure and post-hoc rationalization

Two failure modes are more dangerous than giving users too little.

Over-disclosure breeds rubber-stamping. When the Level 1 or Level 2 view is overwhelming (too many factors, jargon-heavy, numerically dense), users who expand quickly learn that expanding is not worth the effort. They stop reading the evidence view and treat the summary as authoritative, which is worse than a system that only shows summaries, because they still feel they have done due diligence. Research on “automation complacency” in decision support consistently finds that the presence of a justification, even an unread one, increases agreement with the recommendation [3].

This means the evidence view must be designed as a reading experience for the intended user role, not as a model debugging console that was made technically accessible to end users. Each contributing factor at Level 1 should have a natural-language description written for a domain expert, not a feature importance score from an internal model.

Chain-of-thought traces may not be faithful. The Level 2 trace view is most valuable when the trace reflects how the model actually arrived at the recommendation. For large language models producing chain-of-thought reasoning, this assumption is uncertain. There is a documented concern in the interpretability literature that chain-of-thought may be post-hoc: the model produces a plausible-sounding reasoning path that is consistent with its output, but that path may not reflect the actual computational route [4]. A model can produce a wrong conclusion and a well-structured, internally consistent justification for it.

The practical implication for UI design: do not present the Level 2 trace as “how the model decided.” Present it as “what the model reported.” Subtle wording, but it matters for calibrating user trust. An annotation like “This is the model’s self-reported reasoning, not a guaranteed account of its computation” at the top of the trace view is honest and, for expert users, appreciated.

Streaming reasoning as temporal disclosure

LLMs that expose chain-of-thought reasoning produce steps sequentially. This creates a variant of progressive disclosure that is temporal rather than user-initiated: the reasoning unfolds in time, and the conclusion follows when the trace completes.

Temporal disclosure has a real advantage in professional contexts. A user following a live reasoning stream can spot a factual error or a misread premise early, before the model commits to a conclusion, and interrupt or redirect. This is qualitatively different from reading a finished trace and then overriding.

The implementation challenge is readable streaming rate. LLM output arrives faster than a domain expert reads domain text. Buffering to a word-by-word display helps; chunking by sentence works better for complex reasoning. The model’s reasoning trace also needs to be presented in a visual container that is distinct from the final recommendation, so the user understands they are watching a process, not reading a conclusion.

One important constraint: token budget limits on reasoning chains affect how much reasoning is visible. A truncated reasoning stream that ends mid-argument is worse than no stream, because the user may incorrectly infer the full path from a fragment. If the reasoning is truncated, the UI should say so explicitly rather than presenting a partial trace as complete.

Integration and day-to-day workflow fit

Progressive disclosure must fit the actual decision workflow, not a generalized UX spec.

For frontline reviewers handling volume, the default view should be Level 0. The expand affordance should be visually salient enough to discover but not so prominent that it reads as an instruction to click it every time. A “factors” count with a chevron works well because it quantifies what the user is trading effort for; a generic “see more” link does not.

For senior auditors reviewing escalations or edge cases, consider defaulting to Level 1. Their workflow is precisely the cases where summary is not enough, and requiring an extra click every time trains them to skip it.

For regulatory review over batches of decisions, neither Level 0 nor Level 1 is the right unit. Regulators typically want aggregate views: what factors drove the high-risk flags in this batch, how consistent is the model across similar cases. This is a different interface problem, but it is downstream of the per-decision disclosure architecture: if the factors at Level 1 are consistently structured data rather than unstructured text dumps, building aggregate views over them is tractable.

Figure 3 shows how per-decision disclosure levels map to the three user roles.

graph LR
    A[Frontline reviewer] --> B[Default: Level 0<br/>Expand on exception]
    C[Senior auditor] --> D[Default: Level 1<br/>Trace on appeal]
    E[Regulator] --> F[Aggregate view<br/>over Level 1 factors]
    B --> G[Decision recorded]
    D --> G
    F --> H[Batch report]

Figure 3. Default disclosure level by user role. The key insight is that role determines the default, not a global system setting; the same underlying disclosure model serves all three by calibrating the starting depth.

The explainable AI (XAI) research literature is deep and largely focused on the model side: LIME, SHAP, attention visualization, concept activation vectors [5]. These techniques generate explanations; progressive disclosure is about how to serve those explanations through an interface. The two are complementary but distinct. An XAI system that generates excellent local feature attributions still fails users if those attributions are surfaced in a wall of text at initial load.

The decision support literature, particularly in clinical informatics, has examined alert fatigue and override behavior in some depth [2]. The consistent finding is that the quality and positioning of alerts and explanations determines whether clinical decision support improves or degrades decision quality, not the accuracy of the underlying model.

Trust calibration research distinguishes appropriate trust (confidence tracks reliability) from overtrust (confidence exceeds reliability) and undertrust (confidence is below reliability) [6]. Progressive disclosure can support appropriate trust calibration by giving users enough information to update their confidence in the model’s output, but only if the information at each level is accurate and interpretable by the intended user.

The EU AI Act’s transparency obligations for high-risk AI systems (as of its phased implementation schedule) are broadly consistent with the progressive disclosure approach: systems must be able to provide explanations of decisions, and those explanations must be appropriate to the role and context of the human in the loop [7]. Disclosure level design is one concrete implementation of that obligation.

Where it breaks

Anchoring on the confidence score, not just the recommendation. Even if the recommendation label is shown last, a confidence ring displayed at Level 0 can anchor the user before they see the factors. A High confidence band makes disconfirming factors harder to weight correctly. There is no perfect solution here; the practical mitigation is to make the confidence score expandable (clicking it opens the calibration explanation) rather than treating it as a standalone signal.

Inconsistent factor structure breaks aggregation. If the factors surfaced at Level 1 vary in format, granularity, or vocabulary between cases or model versions, building consistent workflows around them is hard. Auditors cannot scan for patterns across decisions. Regulators cannot aggregate. This requires treating the factor output as a structured data schema, not a freeform text generation task.

Users do not discover the expand affordance. Progressive disclosure only works if users know more is available. Affordance design is non-trivial; a “2 factors” count with a chevron outperforms a plain “details” link, but neither is self-evident on first use. Onboarding flows and contextual tooltips for the expand path are worth investing in, particularly for high-stakes decisions where the cost of missing context is high.

Streaming traces mislead when interrupted. As noted above, a truncated reasoning stream implies a complete argument. This is a reliability problem that the streaming implementation must solve explicitly: show a clear “reasoning truncated at token limit” label, and consider not streaming at all if the budget is too small to produce a useful partial trace.

Disclosure adds latency. Generating factor explanations, retrieving source passages, and streaming chain-of-thought all add time to the user’s wait before they can act. In high-volume workflows, latency compounds. Prefetching Level 1 content while the user reads Level 0 is a partial mitigation; so is progressive loading (show the first two factors immediately, lazy-load the rest). But if the model and retrieval pipeline are slow, disclosure depth costs real time.

Over-riding without documentation. Users who override at Level 1 or Level 2 should be prompted to record their reasoning: which factor they found inapplicable, what alternative interpretation they are acting on. Without structured override capture, the audit trail shows a human overrode the AI but not why, which makes model improvement and compliance review harder than it needs to be.

Further reading

Start with Nielsen’s foundational article on progressive disclosure [1] for the design lineage. The clinical decision support literature on alert fatigue is the most rigorous empirical body of work on what happens when decision support is poorly designed [2]. Doshi-Velez and Kim’s 2017 paper on rigorous evaluation of interpretability [8] is the right place to understand how explanation quality is measured. The explainability toolkit documentation for SHAP [9] and LIME [10] covers the model-side tools that generate factors for the Level 1 view. For the chain-of-thought faithfulness concern, Turpin et al. [4] is the core reference. The EU AI Act transparency requirements [7] are the relevant regulatory framing for high-risk deployment contexts. Parasuraman and Riley’s taxonomy of automation-related human error [3] is the foundational source for over-reliance and complacency effects. Lee and See’s trust in automation framework [6] is the standard reference for appropriate trust calibration.

Written with AI assistance, editorially reviewed.

References

[1] J. Nielsen, “Progressive Disclosure,” Nielsen Norman Group, 2006. https://www.nngroup.com/articles/progressive-disclosure/

[2] J. S. Ash, M. Berg, and E. Coiera, “Some unintended consequences of information technology in health care: the nature of patient care information system-related errors,” Journal of the American Medical Informatics Association, vol. 11, no. 2, pp. 104-112, 2004. https://doi.org/10.1197/jamia.M1471

[3] R. Parasuraman and V. Riley, “Humans and automation: Use, misuse, disuse, abuse,” Human Factors, vol. 39, no. 2, pp. 230-253, 1997. https://doi.org/10.1518/001872097778543886

[4] M. Turpin, J. Michael, E. Perez, and S. Bowman, “Language models don’t always say what they think: Unfaithful explanations in chain-of-thought prompting,” in Advances in Neural Information Processing Systems, 2023. https://arxiv.org/abs/2305.04388

[5] Z. C. Lipton, “The mythos of model interpretability,” ACM Queue, vol. 16, no. 3, 2018. https://dl.acm.org/doi/10.1145/3236386.3241340

[6] J. D. Lee and K. A. See, “Trust in automation: Designing for appropriate reliance,” Human Factors, vol. 46, no. 1, pp. 50-80, 2004. https://doi.org/10.1518/hfes.46.1.50.30392

[7] European Parliament and Council, “Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act),” 2024. https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=OJ:L_202401689

[8] F. Doshi-Velez and B. Kim, “Towards a rigorous science of interpretable machine learning,” arXiv preprint arXiv:1702.08608, 2017. https://arxiv.org/abs/1702.08608

[9] S. M. Lundberg and S.-I. Lee, “A unified approach to interpreting model predictions,” in Advances in Neural Information Processing Systems, 2017. https://shap.readthedocs.io/en/latest/

[10] M. T. Ribeiro, S. Singh, and C. Guestrin, “‘Why should I trust you?’: Explaining the predictions of any classifier,” in Proceedings of the 22nd ACM SIGKDD, 2016. https://github.com/marcotcr/lime

[11] B. Shneiderman, Designing the User Interface: Strategies for Effective Human-Computer Interaction, 5th ed. Addison-Wesley, 2010. https://www.cs.umd.edu/~ben/

[12] A. Caliskan, J. J. Bryson, and A. Narayanan, “Semantics derived automatically from language corpora contain human-like biases,” Science, vol. 356, no. 6334, pp. 183-186, 2017. https://doi.org/10.1126/science.aal4230