Understand
Role-Based Explanations
Is this explanation appropriate for me?
Adapts the depth, language, and available actions of an explanation to who is reading it and what they may do.
- Evidence: research-based (Ehsan & Riedl 2020, Miller 2019)
- Tested: concept only, mock data
Overview
Why it matters
One decision, three readers, three explanations.
A credit decision concerns the applicant, the caseworker and the auditor, each with a different question and different authority. One explanation designed for one of them fails the others.
Explainability isn’t a property of a decision. It’s a relationship between a decision and a person. Explanation Layering manages depth. This pattern also changes framing, language, content and available actions.
What does it look like?
Applicant view
Applicant view
- Applicant logs in and sees their declined decision.
- Interface shows plain-language summary, top reason, and a clear “What can I do?” section.
- No model scores or technical attribution are shown by default.
- Applicant clicks “Request review”: a form opens with pre-filled context about their case.
Caseworker review
Caseworker review
- Caseworker opens the same case.
- Interface shows: AI recommendation, full attribution chart, data quality indicators, confidence band, and override controls.
- Caseworker sees a flag: “Employment data: self-reported, unverified.”
- Caseworker requests additional documentation before making a decision.
Auditor investigation
Auditor investigation
- Auditor accesses a past case.
- Full audit view shows: decision timeline, model version at time of decision, data snapshot, caseworker override note, and a documentation export button.
- Auditor can compare this case to similar cases in the same time period.
When does it fit?
Use it when
- Several roles look at the same decision
- Roles have different authority: who decides, who audits
- What helps one role overwhelms or fails another
Skip it when
- There is really only one type of user
- Differences are small enough for Explanation Layering alone
- Roles aren’t stable or clearly defined
Design
How do I apply it?
-
Define roles before views.
Who’s reading, what they ask, what they may decide, what they need to do.
-
Frame the same data differently.
“Why your application was declined” for the applicant, “Key drivers” for the caseworker.
-
Make other views visible.
A caseworker previewing the applicant’s view understands the conversation better.
-
Don’t give applicants less by default.
They have a right to understand. Give them the right form, not less.
-
Test each role separately.
A view that works for caseworkers can fail applicants completely.
How can I show it?
Role-specific language layer
The same explanation in each role’s language.
The same underlying explanation rendered in different language registers: - Plain language for applicants: “Your application was declined mainly because of gaps in your employment history.” - Professional language for caseworkers: “Attribution: employment continuity (−0.34), income ratio (−0.21), address stability (−0.08).” - Technical language for auditors: full SHAP values, model version, feature vector hash.
Role-aware default view
A different starting view per role.
A different default state for each role: - Applicant view: plain language, decision + primary reason + recourse - Caseworker view: decision + full attribution + data quality + override controls - Auditor view: full timeline + model version + data snapshot + documentation export
Contextual action sets
The actions each role can actually take.
Different available actions per role: - Applicant: request review, submit new documentation, contact support - Caseworker: override, flag, request documents, escalate - Auditor: export, compare, annotate, flag for compliance
Permission-gated detail
Some details visible only to some roles, by policy.
Some information is visible only to specific roles, not hidden as a UX decision, but restricted as a policy decision. Caseworkers see data quality flags; applicants do not see the exact model thresholds. The distinction between “not shown by default” and “not authorized” should be clear.
Role selector / view toggle
A visible switch between role views.
An explicit control allowing users to switch between role views, or an automatic role assignment based on authentication. When roles are explicit, a visible toggle helps users understand that other views exist.
What does it cost?
Consistency vs. adaptation
Different views can confuse when roles talk to each other. Design for those moments.
Access control vs. transparency
Showing applicants less can violate their rights. Say what’s withheld and why.
Maintenance
Every role view has to be kept up to date. Plan for it.
Connections
Which patterns work with it?
Explanation Layering
How much detail do I need?
Layering manages depth within a role. Role-based explanations manage framing and content across roles. They are complementary and often used together.
Human-in-the-Loop
Who can review or override this decision?
Override authority is role-specific. The HITL pattern defines the override mechanism; role-based explanations determine who sees and can use it.
Audit Trail & Logging
What is the complete record of this decision?
Auditor views are a specialized role view. The full audit trail should be accessible to the auditor role by default, not buried behind expansions.
Sources (3)
Sources (3)
Ehsan & Riedl (2020) — Human-Centered Explainable AI: Towards a Reflective Sociotechnical Approach
proposes HCXAI as a framework that centers the social and organizational context of explanation. Directly motivates designing explanations for specific roles rather than abstract users
Miller (2019) — Explanation in Artificial Intelligence: Insights from the Social Sciences
reviews the social science literature on explanation, finding that what counts as a satisfying explanation depends heavily on the questioner’s role, goals, and prior knowledge. The foundational paper for the role-sensitivity of explanation
Amershi et al. (2019) — Guidelines for Human-AI Interaction
proposes 18 design guidelines for human-AI interaction based on a synthesis of research and practitioner experience. Guideline G4 (show contextually relevant information) and G5 (match relevant social norms) directly support role-adaptive explanation
You built one explanation, and it works for nobody.
Too technical for applicants, too shallow for caseworkers, useless for auditors. That’s where this pattern starts. Let’s look at your interface together.
Work with me