Understand
Attribution
Why did the system make this decision?
Shows the top factors behind a decision in plain language, and whether each one helped or hurt the outcome.
- Evidence: research-based (Lundberg & Lee 2017, Ribeiro et al. 2016)
- Tested: concept only, mock data
Overview
Why it matters
Without reasons, every decision looks arbitrary.
After a declined application, a flagged post or a risk score, the first question is always why. Without an answer, people can't judge whether the reasoning was sound, whether their data was read correctly, or whether they could do anything about it.
Attribution is the foundational pattern. It doesn't expose model internals. It answers a human question in human terms: these are the things that mattered most.
What does it look like?
Applicant reviewing a declined decision
Applicant reviewing a declined decision
- User sees the decision summary: "Application declined."
- Below the decision, a compact "Why?" section shows the top 3 factors with direction indicators.
- User clicks "See all factors."
- Full diverging bar chart expands with 8 factors, positive and negative.
- User hovers on "Employment history": tooltip explains: "Gaps in employment over the past 2 years reduced the score."
- User understands the primary reason and navigates to the Recourse section.
Caseworker reviewing a model recommendation
Caseworker reviewing a model recommendation
- Caseworker opens a case with an AI recommendation to decline.
- Attribution panel shows top 5 factors with plain-language labels and direction.
- Caseworker notices "Address stability" is flagged as negative, but knows the applicant recently relocated for work.
- Caseworker overrides the decision with a documented justification.
Auditor reviewing a historical decision
Auditor reviewing a historical decision
- Auditor accesses a past case from the audit log.
- Attribution panel shows the factors at the time of the original decision, frozen from the model version used.
- Auditor compares attribution across several similar cases for consistency.
When does it fit?
Use it when
- The system makes or supports a consequential decision about a person
- People need to judge whether the reasoning fits their situation
- Several factors contributed and their weight matters
Skip it when
- The model is too unstable to attribute reliably
- The factors would reveal sensitive attributes
- The system is generative: use Retrieved Source Attribution or Grounding indicators instead
Design
How do I apply it?
-
Use plain language.
The model says debt_to_income_ratio_12mo. The interface says "Debt compared to income".
-
Show direction, not just weight.
Knowing a factor mattered is less useful than knowing whether it helped or hurt.
-
Start with the top three to five.
More overwhelms most people. Keep the full list one step away.
-
Never present it as cause.
"Associated with this recommendation" is honest. "Caused this decision" is not.
-
Show what helped, too.
Especially after an adverse decision, people need the full picture.
-
Pair it with a way forward.
On its own, attribution reads like a verdict. Link to Actionable Recourse or Counterfactual Explanation.
For your technical team
Feature importance methods such as SHAP or LIME are approximations. They show contribution within the model, not verified causes in the world. Check that attributions are stable for similar inputs before showing them; an unstable model makes attribution misleading.
How can I show it?
Top 3 summary
The three strongest factors, with "see all".
A compact default state showing only the top 3 contributing factors with a "see all factors" expansion. Reduces cognitive load for users who need a quick read.
Caveat microcopy
A short note: associations, not proven causes.
A short, non-dismissive note explaining that factors shown are the most influential associations the model identified, not confirmed causes. Essential for preventing misinterpretation.
Ranked factor list
An ordered list of factors in plain words.
A simpler alternative to a chart: a numbered or ordered list of factors with brief plain-language descriptions. Appropriate when the number of factors is small (3–5) and the audience needs speed over precision.
Factor cards
One card per factor, with direction and detail.
Individual cards per factor, each containing: a plain-language label, a short explanation of what it means, the direction of influence (helped / hurt), and an optional "learn more" expansion. Supports progressive disclosure.
Contribution bar chart (diverging)
Bars to the left hurt, bars to the right helped.
The most common and readable format. Factors are shown as horizontal bars extending left (negative impact, hurt the outcome) or right (positive impact, helped). Bar length represents relative importance. Labels use plain language, not feature variable names.
Input highlight
Marks the fields in the person's own data that mattered.
For interfaces where the original input is visible (a form, a document, an image), highlight or annotate the specific fields or regions that were most influential. Grounds the explanation in the user's own data.
Contrastive explanation ("why not X?")
Why this outcome instead of another one.
A variant of attribution that answers not "why did this happen?" but "why did this happen instead of a specific alternative?" For example: "Why was I declined rather than referred?" Show only the factors that distinguish the actual outcome from the named alternative, not every factor that influenced it. Connect to Counterfactual Explanation for the inverse question: what would have changed the outcome.
Further left for applicants and quick reviews, further right for caseworkers and auditors.
What does it cost?
Clarity vs. accuracy
A clean bar chart can imply more certainty than the model has. Use caveats on purpose.
Transparency vs. gaming
Visible factors can be optimized without real change. Where that's a risk, show direction, not weights.
Model reasoning vs. human reasoning
If a caseworker overrode the model, say whose reasoning is being shown.
Connections
Which patterns work with it?
Counterfactual Explanation
What would have changed the outcome?
Attribution answers "what mattered." Counterfactuals answer "what would have changed it." Together they form a complete explanation of a decision.
Actionable Recourse
What can I do to change this outcome?
Attribution without recourse is a verdict. Recourse tells users what they can do about the factors that hurt them.
Example-Based Explanation
What similar cases influenced this result?
Some users understand attribution better through comparison to similar cases than through abstract factor lists.
Role-Based Explanations
Is this explanation appropriate for me?
The appropriate depth and format of attribution varies by user role. A caseworker needs more detail than an applicant; an auditor needs version-specific details.
Confidence & Uncertainty
How certain is the system?
Attribution should be accompanied by uncertainty signals when the model's confidence is low: high uncertainty can undermine the reliability of the attribution itself.
Sources (4)
Sources (4)
Doshi-Velez & Kim (2017) — Towards a Rigorous Science of Interpretable Machine Learning
establishes the foundational framework for measuring interpretability in human terms rather than model terms. Directly motivates designing attribution for user understanding rather than technical accuracy
Lundberg & Lee (2017) — A Unified Approach to Interpreting Model Predictions (SHAP)
introduces SHAP values as the technical foundation for feature attribution in production systems. Understanding SHAP's assumptions and approximations is essential for designing honest attribution interfaces
Ribeiro et al. (2016) — "Why Should I Trust You?": Explaining the Predictions of Any Classifier (LIME)
introduces LIME as a local approximation method. The paper's framing ("why should I trust you?") positions attribution as a trust-building mechanism, directly relevant to the UX goal of this pattern
Haque et al. (2023) — Explainable Artificial Intelligence (XAI) from a user perspective: A synthesis of prior literature and problematizing avenues for future research
reviews the gap between technical explainability methods and actual user needs; finds that most XAI implementations fail to address the specific questions real users ask. Motivates the human-question-first approach of this pattern library
People say your decisions feel arbitrary.
Or a regulator has asked what drove a specific outcome. That's where this pattern starts. Let's look at your interface together.
Work with me