Details have been generalized and data anonymized to protect client confidentiality.
Case Study · Identity & Access Management
Designing Better Access Decisions
Enterprise access governance depends on managers making informed decisions about sensitive permissions at scale. Research showed the product made careful decisions unnecessarily difficult and quietly encouraged the opposite behavior.
CompanyMajor Financial Institution
FocusIdentity & Access Management
My RoleLead UX Designer
Research30+ interviews · Personas · Journey Mapping · Behavioral Synthesis
StatusStrategic concepts and experience direction delivered to inform product planning.
Team
UX Researcher, Product Partners, Engineering, Business Stakeholders
My Contributions
Co-developed the research strategy with our UX researcher
Planned and conducted stakeholder and user interviews
Synthesized research into behavioral models, personas, archetypes, workflows, and journey maps
Led experience strategy and interaction design
Developed and iterated concepts through multiple rounds of user validation
Process
Research
Behavioral Analysis
Personas & Archetypes
Task Mapping
Concept Development
Interaction Design
Prototype
User Validation & Iteration
Research and validation continued throughout the project rather than ending after discovery.
Understanding the Problem
At a major financial institution, managers were required to periodically certify the access their direct reports held. The expectation was careful evaluation. The behavior observed across the organization was rubber-stamping: select all, approve, done.
The easy explanation was disengagement. The more useful question was what the experience was actually asking managers to do, and whether it was giving them what they needed to do it.
Q1 Manager Access CertificationTina S. · 27 entitlements · Status 4% complete
Application
Entitlement
% of Team
Alex Morrison
Jordan Farley
Chris Elbers
Sam Ramos
CORP
Domain Users
100%
?
?
?
?
Access Bundle
Role 4821: GWM Client Access Standards
100%
✓
✓
✓
✓
Access Bundle
Role 5614: Operations Workflow Group
100%
?
?
?
?
BOSS
JOB CATEGORY CODE: MGR_OPS_STANDARD
100%
?
✓
?
?
MLIF
MLIF Access SEG_Desktop_Standard
50%
?
?
· · · 22 more items
Representative reconstruction · Legacy ART certification view
High-volume reviews gave managers little help distinguishing routine access from decisions that deserved attention. Technical terminology, limited context, and no signal of what had changed made careful review disproportionately difficult. At scale, bulk approval became a rational response.
Research Findings
30+
Stakeholder interviews across departments and business lines
6
Distinct user groups with different IAM relationships and responsibilities
5
Behavioral personas synthesized from interview findings
2
Cross-role archetypes that cut across job titles and departments
100+
Access-management tasks inventoried, rated by importance and friction
10+
IAM products and portals mapped across the existing ecosystem
Over several months, our team interviewed managers, access specialists, governance staff, operational coordinators, and end users with different relationships to IAM work. We also mapped current-state architecture across the tool ecosystem, inventoried tasks by importance and friction, and traced how users felt as they moved through access workflows.
Research wasn't confined to discovery. We met with participants throughout the project, returning to evolving concepts multiple times to validate assumptions, gather feedback, and refine the experience before implementation. The same patterns appeared across roles and business lines from the start.
Careful decisions were harder than careless ones.
The review experience gave managers high volumes of access information with no prioritization signal. At scale, meaningful review became functionally impossible. With no grouping, no change indicators, and no way to distinguish a newly granted sensitive entitlement from an unchanged routine permission, the interface treated everything as equally important. In practice, nothing got real attention.
Work moved outside the product.
When the system couldn't explain itself, people built their own scaffolding. Work moved to informal experts, personal spreadsheets, and undocumented workarounds. One participant discovered a critical dependency between two access requests only through trial and error and a call to the tool owner. The product was outsourcing its own clarity to the people using it.
Problems surfaced at the moment of failure.
There were no expiration warnings, no proactive notifications when provisioning changed. Access worked silently until it didn't. One participant described wanting to know before a user was blocked from doing their job, while there was still time to act.
Together, these patterns pointed to a different design problem: the product needed to prioritize decisions and carry the context that careful judgment requires.
Current-State Journey Map
Research revealed a consistent emotional arc across the access review experience: users started the task focused and ended it frustrated. Mapping the journey by stage showed exactly where the product failed them, and where the strongest design opportunities sat.
Prepare
Interpret
Decide
Complete
Follow Up
User Action
Receives certification notice. Opens the tool. Tries to understand scope and what needs attention.
Reads entitlement names and descriptions. Tries to understand what each permission grants before acting.
Approves, revokes, or bulk-approves items across the queue.
Submits decisions. May batch-approve remaining items under time pressure.
Returns to primary work. No structured follow-up process.
Need
Know what to focus on first and how much time this will reasonably take.
Understand what access actually does in plain language before making a decision.
Make a confident, defensible decision for each item that deserves attention.
Know the review is done and that decisions are recorded accurately.
Know who was affected, what changed, and when the next review is.
Pain Point
No scope summary. All items load at equal priority. Volume is immediately overwhelming.
Technical names lack plain-language context. No indication of what changed or why access was originally granted.
No risk signals, no change indicators, no usage data. Bulk approval is the only practical path at scale.
No confirmation of what was reviewed vs. bulk-approved. No record visible for future reference.
No post-review visibility. No alerts when access changes take effect or when new issues arise.
Opportunity
Show scope before review begins - items needing attention, items that are routine, items that are new.
Plain-language descriptions with request history, original justification, and last-used date inline.
Decision summary distinguishing individually reviewed items from batch-confirmed ones.
Post-review summary with downstream impact. Proactive alerts for upcoming certifications.
Current-state journey · Access review experience from notice to follow-up
Observed behavior
System condition
Product direction
Managers approved access in bulk without reviewing individual items
→
Everything appeared equally important. Volume without prioritization made careful review disproportionately difficult.
→
Surface changed and new access first. Make routine confirmation efficient without making it the default path for everything.
People moved difficult tasks to informal experts, personal notes, and workarounds
→
Context and process knowledge lived with people, not in the product. The system expected users to know what it couldn't explain.
→
Carry decision context inside the experience: why access exists, what it allows, request history, dependencies.
Access problems were discovered when work stopped, not before
→
The system communicated through failure. Expirations and provisioning changes were silent until they became blockers.
→
Surface upcoming expirations, pending decisions, and access changes before they interrupt work.
Behavioral synthesis · From observed patterns to design direction
Building a Picture of Users
Rather than designing around job titles, we synthesized interview findings into personas that reflected how people actually related to IAM work. One of the clearest cross-cutting themes: highly competent professionals often struggled with IAM. The struggle had little to do with ability; IAM expertise varies independently from professional expertise.
A manager who understood their team's work deeply might still be unable to parse a technical entitlement name, understand why access existed, or know which tool to use. The system required specialized knowledge it never provided.
N
Nora
Assistant Manager, Consumer & Small Business
“I'm qualified in my field, but this access stuff makes me feel like a beginner”
Personal
Age:32
Gender:Female
Location:San Diego, CA
Professional
Years at Bank:<1
IAM Load:0–10 tasks/month
Direct Reports:0
Review Types:Self review
Tools:ARM
Biography
Nora is qualified in her field but new to the bank's IAM systems. She's eager to contribute and work independently but often feels slowed down by unclear processes and technical jargon. Without clear guidance, she relies on peers to help navigate access requests.
Complete IAM tasks efficiently - minimize steps and time spent
Understand entitlements clearly - know what access means before requesting
Stay compliant with less stress - feel secure that actions align with policy
Stay focused on core responsibilities - IAM shouldn't distract from daily work
Frustrations
Complex, technical language in ARM
No simple way to identify the right access
Waiting on others or support to complete requests
Lack of step-by-step guidance
Personality
Introvert
Extrovert
Analytical
Creative
Loyal
Fickle
Passive
Active
Technology Adoption
Late Majority
Hesitant to try new tools but will adopt once widely proven.
M
Mark
Managing Director, Business Strategy & Initiatives
“I want to see updates only since the last review, not all information”
Personal
Age:57
Gender:Male
Location:Newark, NJ
Professional
Years at Bank:13
IAM Load:200–300 tasks/month
Direct Reports:30
Review Types:Dormancy review, SOX
Tools:ARM, ART
Biography
Mark has 35 years of banking experience in client management and business planning. He oversees 140 locations including 92 sales offices. IAM volume is extremely high - reviews frequently spill outside working hours.
Goals
Minimize time spent on access reviews
Prioritize accuracy and compliance
Quickly identify and address exceptions
Avoid work that could be automated
Keep managers focused on revenue-generating activities
Frustrations
The volume kills you - I try to get it done during the day but often take it home
If entitlement descriptions aren't clear, I can't confidently approve or reject
There's no role-based intelligence - it's all manual
Redundant reviews make me feel like I'm doing the same work twice
Personality
Introvert
Extrovert
Analytical
Creative
Loyal
Fickle
Passive
Active
Technology Adoption
Late Majority
Hesitant to try new tools but will adopt once widely proven.
O
Oyvind
Senior Tech Manager, Apps
“I don't understand the IAM Ecosystem”
Personal
Age:43
Gender:Male
Location:Charlotte, NC
Professional
Years at Bank:<10
IAM Load:2–20 tasks/month
Direct Reports:>1
Review Types:Peer review
Tools:ARM, ART, PCAT, RISE
Biography
Oyvind knows his business and application domain very well, but is not confident about IAM. He manages applications and primarily focuses on supporting business functions related to IAM tasks. His domain expertise doesn't transfer to navigating IAM systems.
Goals
Complete IAM tasks efficiently - minimize steps and time spent
Understand entitlements clearly - know what each access description means
Quickly understand the process and know what to do next
Frustrations
Complex, technical language in IAM
No simple way to identify the right requirements
No single place to manage all IAM-related tasks
Lack of step-by-step guidance in applications
Personality
Introvert
Extrovert
Analytical
Creative
Loyal
Fickle
Passive
Active
Technology Adoption
Early Adopters
Likes to try new tools and adopt them when released.
S
Sam
Business Control Manager
“IAM always feels reactive. The systems make the work harder than it should be.”
Sam represents experienced professionals who act as SPOCs for access and identity management within their lines of business. Responsibilities include submitting and validating access requests, managing access bundles, performing quarterly certifications, onboarding and offboarding associates, and troubleshooting access issues. IAM is typically a side job alongside core responsibilities.
Goals
Ensure accurate and timely access provisioning
Maintain compliance with IAM standards and regulatory requirements
Simplify access bundle management and quarterly certifications
Reduce approval delays and improve visibility into request status
Automate routine onboarding and revocation processes
Improve risk-tiering to avoid unnecessary audits for low-risk apps
Frustrations
Heavy reliance on SharePoint, spreadsheets, and tribal knowledge
Tool fragmentation: ARM, ART, Guardian, PCAT with poor integration
ARM ticket types and entitlement names are unclear; finding correct forms is difficult
Approval bottlenecks from secondary approvers
Review fatigue: quarterly audits for routine apps feel excessive
No easy way to track historical approvals or changes
Automation gaps: bundles and provisioning rules fail for certain apps
Personality
Introvert
Extrovert
Analytical
Creative
Loyal
Fickle
Passive
Active
Technology Adoption
Early Adopter
Wants to be first to try new tools to give their team the best chance at efficiency.
L
Laura
COO Business Support Manager
“IAM isn't my world. I just need visibility so I can hold the right people accountable.”
Personal
Age:49
Gender:Female
Location:Denver, CO
Professional
Years at Bank:16
IAM Load:1–10 tasks/month
Direct Reports:12
Review Types:Oversight and escalations
Tools:SharePoint
Biography
Laura represents professionals in COO roles supporting finance organizations and global markets teams. They focus on governance, reporting, policy management, and operational support. They use tools like SharePoint, ARM, ART, and PCAT but are not deeply involved in IAM beyond their own access needs and team oversight.
Goals
Disseminate information and support tasks for their teams in a timely manner
Ensure smooth onboarding for new team members with clear instructions
Maintain operational efficiency in governance, reporting, and policy management
Provide help and support during projects and initiatives
Keep access processes straightforward with clear ARM request steps
Frustrations
Pulling ARM requests is challenging and critical for timely access
ART system is hard to navigate and not user-friendly
Lack of visibility into required access for new team members
No centralized document or tool repository for onboarding processes
Occasional delays when access requests are rejected without clear guidance
Personality
Introvert
Extrovert
Analytical
Creative
Loyal
Fickle
Passive
Active
Technology Adoption
Early Majority
Adopts proven tools once reliability and usability are evaluated.
B
Bruno
Supervision Manager
“It helps to have a dashboard that shows the access bundle and who has access to it.”
Personal
Age:44
Gender:Male
Location:Philadelphia, PA
Professional
Years at Bank:14
IAM Load:2–20 tasks/month
Direct Reports:8
Review Types:Quarterly access reviews
Tools:ARM, ART, Guardian
Biography
Bruno represents professionals in Global Information Security (GIS) and Line of Business (LOB) roles with extensive tenure (9–30 years). They serve as BISOs, governance managers, and regional security officers. Their work includes ERP exception processes, governance, risk documentation, IAM, and supporting customer-facing units.
Goals
Achieve ease of use and timeliness in access provisioning and onboarding
Maintain risk governance and compliance for IAM processes
Improve visibility into access levels and entitlement details
Drive automation and modernization in IAM processes
Efficiently manage exceptions and service accounts
Frustrations
Entitlements are not intuitive - names are confusing and lack user-friendly clarity
ARM experience is poor - status tracking and messaging are unclear, causing delays
Onboarding delays: access provisioning can take 30–60 days
Manual, time-consuming tasks: entitlement investigation and exception handling
Lack of visibility into who has access to what - dashboards are fragmented
Overwhelmed by too many tools and links without proper guidance
Frustration with limited automation and outdated onboarding/governance processes
Personality
Introvert
Extrovert
Analytical
Creative
Loyal
Fickle
Passive
Active
Technology Adoption
Early Majority
Adopts tools that support governance and visibility, but expects structured integration and clear value before committing.
Recreated research deliverables · 6 personas synthesized from 30+ interviews · All identifiers anonymized
Roles Didn't Predict Behavior
Individual personas captured behavioral detail, but titles and seniority weren't reliable predictors of what people needed from the product. We synthesized the personas into two higher-order archetypes that cut across departments, business lines, and roles. These became the organizing lens for information architecture and design decisions.
Archetype 01 · Account Management Portal
The Account Manager
Employees responsible for initiating, reviewing, and approving access across the IAM lifecycle. They span roles from new joiners to people managers, navigating fragmented tools, unclear entitlement structures, and inconsistent workflows. Their experience is marked by high friction, invisible work, and limited confidence in the system. Regardless of experience level, they share a desire to complete access tasks quickly, confidently, and without friction.
“I'm qualified in my field, but the access stuff makes me feel like a beginner.” “I don't have time to decode every permission - just show me what changed.”
Behavioral Patterns
Frequently relies on tribal knowledge and familiar procedures to complete IAM tasks
Defaults to approving access they don't fully understand
Uses external tools (e.g. Excel) to make sense of entitlement data
Submits access requests with minimal context or guidance
Avoids revoking access unless explicitly directed
Seeks help from peers rather than system documentation
Challenges
Onboarding delays from unclear guidance
Difficulty locating the correct IAM tool or entry point
Unclear entitlement names and permission descriptions
Redundant or manual workflows with limited visibility across request and review stages
Lack of confidence in approval decisions without visibility into past decisions
Inconsistent communication from IAM and business teams
Mindset
Task-Oriented: Focused on completing access actions quickly to keep moving.
Risk-Aware: Conscious of compliance implications but unsure how to assess them confidently.
Procedural: Follows steps as instructed even when the rationale is unclear.
Hesitant: Avoids making changes (like revoking access) without explicit direction.
Resourceful: Builds workarounds outside the system to interpret and manage access.
Disconnected: Feels IAM is separate from core responsibilities, yet still accountable for it.
Goals
Complete access reviews and approvals quickly with enough context to feel confident
Keep work moving for self and team
Ensure team members have timely access to required tools
Minimize risk while maintaining productivity
Avoid errors or compliance issues tied to access decisions
Jobs to Be Done
Normal Users
Request access with clear labeling
View current access and expiration dates
Track request status in real time
Self-service security management (password, MFA)
Managers
View team access at a glance
Approve/deny quickly with role context
Receive alerts for unusual access requests
Review historical access changes for compliance
ARTARM
Archetype 02 · Resource Management Portal
The Resource Manager
A cross-functional enabler who bridges operations, governance, and infrastructure while navigating the complexity of IAM. They keep teams productive by requesting, reviewing, granting, and troubleshooting access across fragmented systems. Often juggling IAM as a secondary responsibility, they work in roles like BISOs, COOs, and SPOCs. Success hinges on clarity, speed, and visibility - yet they face persistent challenges such as unclear entitlements, opaque workflows, manual workarounds, and high accountability.
“IAM isn't my primary domain - but I'm accountable for the decisions that come out of it.” “I want to see who has what, why, and what needs to happen next - in one place.”
Behavioral Patterns
Regularly switches between ARM, ART, Bundles, PCAT, Guardian, SharePoint to complete a single workflow
Relies on internal POCs or centralized support rather than system guidance
Performs batch activities around quarterly certifications and periodic reviews
Validates request justifications, checks user history and violations, confirms duration and routing
Maintains “cheat sheets,” saved paths, and prior tickets as reference
Mixed adoption style: some are early adopters, but all value stable step-by-step instructions
Challenges
Fragmented ecosystem - no single place to see who has what, why, and what's next
Review & Certify - risk-tiered queues with plain-language context
Track Status & Ownership - single view of status, owner, and next action
Service Accounts & Governance - reliable metadata and audit trails
Knowledge & Guidance - embedded step-by-step guidance when using tools infrequently
ARMARTPCATSAMBundles
Recreated research deliverables · Behavioral archetypes synthesized across personas · All identifiers anonymized
Additional Behavioral User Types
Access Seeker
“I just need to get access so I can do my job”
The Access Explorer
“I'm trying to understand what access I have - and what it means”
The Team Enabler
“I'm helping others get access - not just myself”
The Access Maintainer
“I keep things running - managing access over time”
Primary Behavior
Request new access for themselves
Viewing existing access
Request or manage access for teammates
Handling access lifecycle
Frustrations
Finding what they need access to, understanding choices, access delays
Unclear explanation of access, no clear classification, overwhelmed by information
Complexity of IAM, manual aspects of ARM, complexity of setting up the right access
Manual processes, lack of automation, complexity of setting up the right access
Needs
Quickly understand what access they need to be able to request it
Easily understand what they have access to
The ability to create a rush button / bundle
Cumulative data representation to perform actions
Top Tasks
Figure out what access is needed
Request new access
Track status of request
May not know what ARM is
View and manage existing access
Compare access between roles
Compliance-driven
Request/approve access for others
Support requests
Perform delegated tasks (proxy access)
The informal person colleagues go to for access: not the manager, but a team lead
Manage access lifecycle
Approve/revoke requests
Enforce policies
Manager, Design Ops. Bridges the gap between requestors and applications
Tool
ARM
ARMART
ARMART
ARMART
Behavioral user type matrix · Four modes of IAM engagement across the organization
Titles Didn't Predict Needs
Synthesizing archetypes across job titles revealed a clearer pattern. Titles and departments predicted little. The stronger signal was each person's relationship to access decisions.
We began to think about IAM needs through a different lens:
Need access → Enable access → Decide on access → Govern access
Someone who needs access primarily wants status and expiration visibility. Someone who enables access for others needs workflow clarity and request tools. Someone deciding on access needs context, prioritization, and decision support. Someone governing access needs patterns and broader visibility across teams.
Operational scale and IAM expertise vary independently across all of these. A person deciding on access might be reviewing five items or seventy-five. That difference shapes what the experience needs to do as much as the relationship itself.
Need access
What access do I have?
What's pending?
What's expiring?
How do I request something?
Enable access
Workflow clarity
Request entry and tracking
Dependencies and ownership
Status across handoffs
Decide on access
What requires attention?
What changed?
Why does this access exist?
Approve, revoke, escalate
Govern access
Patterns across teams
Broader risk signals
Governance status
Oversight visibility
Operational scale
5 decisions / cycle50–75+ items / cycle
IAM expertise
Occasional, relies on specialistsSelf-sufficient, high familiarity
Scale and expertise vary independently of where someone sits on the relationship spectrum. Title alone predicts neither.
Behavioral synthesis · Need → Enable → Decide → Govern as the organizing model
Prioritizing What Matters
Before deciding what to design, the team needed to understand which tasks actually mattered and where friction concentrated. Every access-management task surfaced in research was mapped across four dimensions: importance, observed friction, the emotional state people described while doing it, and which source system currently owned that task.
The pattern was consistent: the highest-importance tasks carried the highest friction. Reviewing team access, approving requests, and understanding current access were the moments where the product mattered most and helped least. Friction in a low-importance task is annoying. Friction in a high-importance task with governance consequences is a design failure.
Manage Access
FrictionHigh
😀Authentication & MFA
😔View current access
😔Notifications on expiring access
😐Onboarding tools
Requests & Approvals
FrictionHigh
😩View / cancel request status
😔Approve / reject access requests
🙂Assign temporary access
😁Approve role changes
Access Oversight (Manager)
FrictionHigh
😩Review team access periodically
😔View team access
🙂Monitor compliance status
Reports & History
FrictionMedium
😔Self review of access
😐Track request history
Task mapping · Importance, friction, and emotional state across access-management work
From Research to Product Strategy
The behavioral evidence pointed to specific interaction problems. Each concept below traces directly from a research finding to a design response to an interface direction.
Research Finding
Managers couldn't distinguish items requiring their judgment from items the system had already processed automatically. The interface treated everything as equally important, making careful review disproportionately difficult at scale.
Design Response
Lead reviews with changed and new access first. Surface plain-language descriptions, request history, and last-used data inline. Let unchanged access be confirmed efficiently below, without making bulk confirmation the default path for everything.
Change-focused access review
access-review.corp · Q3 Certification · 17 items · Due Oct 15
Home›My Reviews›Q3 2025 Manager Review
3Require attention
1New this cycle
2Changed
14Unchanged
Requires Attention3 items
Risk Analytics Platform: Executive ViewNew
Allows read access to aggregated risk dashboards and executive reporting. Includes view access to firm-wide exposure summaries. Does not allow editing or data export.
GrantedSep 3, 2025 (this cycle)
Requested byEmployee (self-requested)
Last usedNot yet accessed
Request history
Sep 3, 2025Access granted following approval from application owner. Requested to support Q4 planning work.
Sep 2, 2025Request submitted by employee. Justification: "Need visibility into firm-wide risk exposure for Q4 planning process."
Financial Reporting: Write AccessChanged
Allows creating, editing, and submitting financial reports. Access level was elevated from Read-Only to Write in August 2025.
ChangedAug 18, 2025 · read → write
Last usedOct 2, 2025
Unchanged Access (14 items)
ACG Portal: Read Only
ACG Portal · Group access
✓ Certify
Data Lake: Query Execution
Data Lake · Service role
✓ Certify
+ 12 more unchanged itemsShow all
Concept direction · Change-focused access review
Changed and new access leads the review; unchanged access is confirmed separately below
Plain-language descriptions make system terminology understandable in the context of each decision
Request history and last-used data expand inline; no modal required
Approve, revoke, and flag for follow-up available per item; unchanged access can be confirmed in bulk
Action-required items are visually distinct from pre-processed items in both hierarchy and contrast
Research Finding
Resource owners had no single view of what they were responsible for. Ownership, status, and required actions were scattered across multiple systems. Governance alerts arrived by email or were missed entirely. Expert users built elaborate workarounds around the fragmentation rather than through it.
Design Response
Bring resource ownership into a single view organized by type. Surface action-required states immediately, without navigation. Consolidate governance messages into a persistent panel. Let users toggle between resource-type and application-oriented views - two mental models that surfaced in research.
Resource Management Portal
iam.corp.com / resource-management-portal
Resource Management Portal
My ResourcesGroup by: Resource Type
Service Accounts
Action Required
10
Total
● 5 pending tasks
View Details ›
Permissions
Action Required
8
Total
● 1 pending task
View Details ›
Collaboration Sites
1
Total
✓ No tasks required at this time
View Details ›
Applications (AIT)
1
Total
✓ No tasks required at this time
View Details ›
Messages
●
Consider vaulting these service accounts...Go to Vault
●
Consider vaulting these service accounts...Go to Vault
●
Consider vaulting these service accounts...Go to Vault
Helpful Links
Service Account Management (SAM)Resource Owner Dashboard (RODB)Collaboration Resources
Concept direction · Resource Management Portal
Action Required status surfaces immediately, with no navigation needed to identify what needs attention
Messages panel consolidates governance alerts previously scattered across systems or delivered by email
Group by controls let users toggle between Resource Type and Applications - two distinct mental models from research
Design Principles
Four principles emerged from the research that connected behavioral findings to interface decisions across both concept directions.
01
Prioritize attention
Surface what changed before what stayed the same. Not everything in a review queue deserves equal weight, and the interface should make that obvious.
02
Carry context
Put the information required to make decisions inside the workflow. If users are calling colleagues or checking spreadsheets to interpret what they're reviewing, the product has failed.
03
Design for varying expertise
Expertise in a business domain doesn't imply expertise in IAM. The experience should allow people to complete consequential work without requiring specialized system knowledge.
04
Support judgment
Help users make informed decisions instead of optimizing for speed alone. Governance cannot depend on guessing - careful decisions need to be easier than careless ones.
Reflection
The outcome of this work wasn't a single redesigned screen. It was a research-backed framework for organizing IAM experiences around user behavior instead of internal product boundaries. The concepts established a shared direction for future product planning and demonstrated how interaction design could better support judgment, not just compliance.
This work shifted the program away from optimizing individual screens toward redesigning how IAM work was structured around users. Through research with more than 30 people across the organization, the team identified behavioral structures that the tool-based ecosystem had never been designed around: different relationships to access decisions, different levels of IAM expertise, and different scales of operational responsibility, none of which mapped cleanly to org chart titles.
If this work continued, I'd focus on measuring whether these concepts improved decision confidence, review accuracy, and completion time during certification cycles while continuing to validate them with resource owners working at different operational scales.
Enterprise ResearchBehavioral SynthesisPersona DevelopmentJourney MappingInformation ArchitectureProduct StrategyInteraction DesignGovernance Systems