Approach
A research-driven framework for AI product decisions
Explore the Context-to-Behavior Framework and how research can guide AI product decisions.
UX Research & AI Experience Leadership
I help teams turn UX research into better AI product behavior.
UX research and AI experience leadership for teams designing products where context, judgment, risk, and behavior matter.
Start here
Explore the work behind better AI product behavior.
Selected Work
Real projects. Research to impact.
See product strategy narratives showing how research shaped decisions, systems, and outcomes.
Ideas
Perspectives on AI, UX, and product behavior
Read perspectives on AI UX, judgment friction, research systems, and responsible product behavior.
What I help teams do
Designing AI-enabled products requires more than adding intelligence to an interface.
It requires understanding the user's context, the decisions they are trying to make, the risks of getting those decisions wrong, and the role AI should play in supporting human judgment.
Understand context
Uncover the realities, goals, and constraints that shape user and business needs.
Assess signals & risk
Evaluate information quality, ambiguity, and risk across people and systems.
Make better judgments
Bring human judgment to bear where it matters most.
Influence AI behavior
Design for reliable, transparent, and context-aware AI behavior.
The Context-to-Behavior Framework
Better AI behavior starts with better context and judgment.
The framework helps teams connect what they learn from users to the decisions that shape AI-enabled experiences: when AI should act, when it should ask, when it should explain, and when control should remain with the user.
Selected work
Recent case studies
Let's connect
Interested in AI UX, research strategy, or product behavior design?
Let's talk about how research can shape better AI-enabled products.
Get in touchApproach
The Context-to-Behavior Framework
A practical model for turning UX research into better AI product decisions; clarifying where AI should assist, how it should behave, and when human judgment should lead.
The end-to-end view
AI behavior is the result of a chain of decisions. Strengthen each link.
01
Context
Understand the situation, goals, users, and constraints.
02
Signals
Gather and interpret information that matters.
03
Risk
Assess uncertainty, impact, and trade-offs.
04
Judgment
Apply human judgment to prioritize and decide.
05
AI Behavior
Design and configure AI to act appropriately.
06
Decisions
Enable actions that create measurable outcomes.
Why this matters
Better outcomes come from better context, better judgment, and better alignment.
- Reduces risk in high-stakes decisions
- Improves reliability and transparency
- Aligns stakeholders around what matters
- Creates AI behavior people can trust
Inside each stage
What happens, and how research drives it.
1. Context
Establish the real-world context: user needs, business goals, environment, and constraints.
"What situation are we really designing for?"
2. Signals
Find and interpret what matters: behavioral data, feedback, and operational signals.
"What is the evidence actually telling us?"
3. Risk
Evaluate uncertainty, potential harm, bias, and compliance implications.
"What is the cost of getting this wrong?"
4. Judgment
Make and document key decisions: prioritize, accept trade-offs, defer or escalate.
"Where must a human stay in the loop?"
5. AI Behavior
Design the desired AI behavior: capabilities, guardrails, tone, and transparency.
"How should the system actually behave?"
6. Decisions
Enable the right human actions through recommendations, workflows, and feedback loops.
"What action does this make possible?"
Behavior decisions
The framework helps teams decide what AI should do — and what it should not do.
AI experience design is not only about generating the right output. It is about choosing the right role for the system in the user's context.
Assist
Recommend
Ask
Explain
Act
Escalate
Stay out
Put it into practice
Let's apply this framework to your AI product challenges.
I work with teams to connect research, judgment, and AI behavior, so you can build products people can trust.
Start the conversationSelected Work
Three product contexts. One research-to-behavior lens.
The work below spans an AI-era cybersecurity workflow, a pre-AI enterprise manufacturing platform, and a pre-AI consumer support application. Together, they show how UX research can shape product direction, workflow design, and measurable outcomes across very different contexts.
How to read these cases
AI changes the questions we ask of successful product work.
The cybersecurity case applies the Context-to-Behavior Framework directly to an AI-era workflow.
The GM and Dell cases are different. They are successful pre-AI product efforts with measurable outcomes. The AI-era reflections do not reframe them as AI projects; they examine how similar contexts would introduce new design questions today around signals, risk, judgment, automation, explanation, and escalation.
That distinction matters: the original impact remains, while the AI interpretation reflects current design thinking.
Featured Case Studies
Three product contexts. One way to connect research to product behavior.
These case studies are intentionally different: one AI-era cybersecurity workflow, one enterprise manufacturing system from the pre-AI era, and one consumer support application from the pre-AI era. Together, they show how research can inform product behavior across risk, workflow complexity, automation, trust, and human judgment.
The Context-to-Behavior Framework
Every case traces the same chain — from context to behavior.
See the research-driven framework that connects what teams learn from users to the decisions that shape AI product behavior.
Explore the framework
Back to all work
AI-era enterprise case study
Designing AI Behavior Across Cybersecurity Workflows
Cybersecurity · Vulnerability Management · AI UX
How an AI behavior model can help cybersecurity teams move from critical finding triage to remediation handoff while preserving human judgment, risk rationale, and data provenance.
Overview
An AI-era workflow where speed and accountability both matter.
Context
An AI-era enterprise workflow in vulnerability management, where security teams must move quickly from critical finding triage to remediation execution.
The Problem
AI assistance can increase operational risk when it ignores user role, data confidence, evidence provenance, or handoff context.
The Goal
Define how AI should behave across the workflow so it supports security teams without weakening human judgment, obscuring risk rationale, or blurring accountability.
The Outcome
An AI behavior model, core screen concepts, and system requirements that clarify when AI should assist, recommend, explain, structure, guide, monitor, or escalate.
Executive Summary
The question was not whether to add AI, but how its behavior should change.
Challenge
Security analysts and remediation specialists need different kinds of AI support during the same vulnerability workflow. A one-size-fits-all assistant risks false confidence, alert fatigue, or poorly supported action.
Approach
I modeled the workflow from critical finding intake through remediation closure, then applied the Context-to-Behavior Framework to define how AI behavior should shift by user role, task phase, evidence quality, and risk.
Design Output
Persona needs and workflow context translated into AI behavior requirements, provenance rules, confidence cues, and three core screen concepts: triage, handoff, and remediation execution.
Paradigm Shift
Not "How do we add AI to vulnerability management?" but "How should AI behavior change as responsibility moves from analyst judgment to remediation execution?"
Workflow & Dynamic AI Posture
As responsibility shifts, the AI's posture should shift with it.
A critical vulnerability workflow moves across roles, evidence sources, ownership boundaries, and decision points. The same AI behavior is not appropriate across the full workflow.
Workflow model
Finding Intake
Analyst Triage
Handoff Package
Remediation Coordination
Validation & Closure
AI behavior shift
Assist / Recommend
Structure / Explain
Guide / Monitor
Escalate
Jordan needs support for expert risk judgment. Priya needs support for execution, coordination, validation, and escalation.
Persona Guardrails Matrix
Two roles. Two very different jobs for the AI.
Jordan
Senior Cybersecurity AnalystResponsibility
Evaluates severity, exploitability, asset exposure, business context, and compensating controls to determine which vulnerabilities require urgent action.
AI needs
Synthesized signals, exposed uncertainty, evidence provenance, and risk rationale — not complex judgment collapsed into a single unexplained score.
AI should
- Synthesize threat intelligence
- Challenge assumptions
- Explain risk rationale
- Expose uncertainty
- Surface conflicting evidence
AI should not
- Decide on Jordan's behalf
- Hide contradictory signals
- Auto-advance remediation
- Present incomplete evidence as certain
Priya
Vulnerability Remediation SpecialistResponsibility
Receives handoffs, validates affected assets, coordinates mitigation, tracks blockers, and confirms vulnerabilities are mitigated or closed.
AI needs
Clear next steps, dependency visibility, validation requirements, and explicit automation boundaries.
AI should
- Guide execution
- Highlight dependencies
- Flag blockers
- Track progress
- Standardize validation
- Escalate ambiguity
AI should not
- Encourage blind acceptance
- Imply completion without evidence
- Hide missing context
- Overstate confidence
From Context to AI Behavior Requirements
Each framework stage maps to a concrete product implication.
| Framework Stage | Cybersecurity Application | Product / UI Implication |
|---|---|---|
| Context | Role, workflow stage, asset exposure, business criticality, ownership | Role-specific triage and remediation views |
| Signals | CVSS, exploitability, threat intelligence, SLA status, asset criticality | Provenance labels, confidence indicators, evidence panels |
| Risk | Operational impact, false confidence, missed escalation, delayed remediation | Uncertainty markers, conflict flags, escalation prompts |
| Judgment | Analyst validation, remediation readiness, approval boundaries | Manual confirmation gates and review checkpoints |
| AI Behavior | Assist, recommend, explain, structure, guide, monitor, escalate | AI posture shifts by screen and user responsibility |
| Product Decisions | Triage interface, handoff package, validation states, closure criteria | Screen concepts and behavior requirements |
Three Designed Moments
Where the behavior model becomes a screen.
Critical Finding Triage
Primary user: Jordan, Senior Cybersecurity Analyst
AI actions
Synthesizes threat intelligence, asset exposure, and SLA context; identifies affected asset clusters; highlights confidence, uncertainty, and conflicting evidence; explains why the finding is critical; recommends prioritization logic.
AI constraints
Does not auto-assign remediation ownership, suppress contradictory evidence, present incomplete evidence as certain, or reduce analyst judgment to a single unexplained score.
UI implications
Risk summary, evidence panel, confidence indicator, uncertainty markers, source provenance labels, affected asset clusters, analyst confirmation step.
At this stage, AI's role is to improve the speed and quality of analyst judgment, not replace it.
Handoff Package
Primary users: Jordan → Priya
AI actions
Packages risk rationale, affected assets, remediation path, and dependencies; preserves Jordan's validation and decision rationale; separates validated findings from AI-suggested guidance; labels unresolved questions; previews what Priya will receive.
AI constraints
Does not remove uncertainty labels, convert suggestions into instructions without review, imply Priya has the same context as Jordan, or treat the handoff as a generic task assignment.
UI implications
Risk rationale summary, affected asset list, recommended remediation path, dependency list, escalation notes, handoff preview, and provenance labels: Jordan validated / AI suggested / Priya confirmation required.
The handoff is not just a ticket assignment. It is a transfer of operational reasoning, accountability, and context.
Remediation Execution
Primary user: Priya, Vulnerability Remediation Specialist
AI actions
Translates the handoff into a step-by-step task sequence; shows owners, dependencies, due dates, and blockers; identifies what requires Priya confirmation; highlights risk-sensitive actions; monitors progress against SLA; escalates ambiguity or missing information.
AI constraints
Does not imply remediation is complete without evidence, encourage blind acceptance of prior recommendations, hide uncertainty behind confident task language, or close the loop without validation.
UI implications
Task sequence, owner and dependency visibility, confirmation checkpoints, validation status, blocker indicators, escalation prompts, AI guidance with confidence and provenance, closure criteria.
At this stage, AI's role shifts from risk reasoning to execution support; guiding action without weakening accountability.
Cross-Workflow Behavior Model
One model, three postures, clear human authority.
| Workflow Moment | Primary User | AI Role | Human Authority |
|---|---|---|---|
| Critical Finding Triage | Jordan | Assist, synthesize, recommend, explain | Jordan validates risk and priority |
| Handoff Package | Jordan → Priya | Structure, summarize, preserve provenance | Jordan approves handoff content |
| Remediation Execution | Priya | Guide, monitor, flag, escalate | Priya confirms action and closure |
Good AI UX is not only about the quality of model output. It is about matching system behavior to role, task, risk, confidence, and decision authority.
Core Design Principles for High-Risk AI
Five principles that travel beyond cybersecurity.
1
Preserve provenance
Users need to distinguish human-validated, AI-suggested, and still-unconfirmed information.
2
Match behavior to responsibility
The system should behave differently for the person assessing risk than for the person coordinating remediation.
3
Expose uncertainty
Confidence, missing context, and contradictory signals should remain visible rather than smoothed over.
4
Protect human judgment
AI should support complex work without obscuring who is accountable for decisions.
5
Design handoffs as reasoning transfers
In high-risk workflows, handoffs must preserve rationale, context, validation status, and escalation needs.
What This Work Produced
Artifacts that translate the framework into product design guidance.
- AI-aware cybersecurity personas
- Role-specific AI behavior profiles
- Critical finding triage screen concept
- Handoff package screen concept
- Remediation execution screen concept
- Behavior requirements by workflow stage
- Provenance and confidence labeling model
- Framework mapping across role, risk, and decision authority
This is a concept/prototype case rather than a shipped product, so its value is not in business outcomes; it is in showing how AI behavior can be modeled, specified, and translated into product design decisions.
Case Takeaway
How should AI behave — for whom, at what moment, with what confidence, and under whose authority?
This case applies the Context-to-Behavior Framework directly to an AI-era cybersecurity workflow, making AI UX decisions more precise, role-aware, and accountable.
More work
See the pre-AI cases and their AI-era reflections.
The GM and Dell cases show proven product impact, then examine how those contexts would change with AI today.
View all work
Back to all work
Pre-AI enterprise case study · AI-era reflection
Designing Change Management for High-Stakes Manufacturing Workflows
Manufacturing · Enterprise Systems · Operational Workflow Design
How contextual inquiry and role-based workflow design helped shape a global manufacturing change management platform and what that work reveals about AI UX in safety-critical enterprise systems.
Overview
A ground-up platform for global manufacturing change.
Context
General Motors needed a ground-up change management platform for global manufacturing operations.
The Problem
Change management in manufacturing is not just administrative. It involves engineers, safety teams, operational staff, plant-specific constraints, and decisions where errors carry significant operational cost.
The Goal
Design a role-aware platform supporting complex change workflows across environments while reducing friction, improving consistency, and protecting operational integrity.
My Role
Led UX design, conducted contextual inquiry across assembly plants, mapped role-based workflows, and designed interaction models for engineers, safety teams, and operational staff.
Original Case
Designing for operational complexity.
Change management was not simply a form, checklist, or approval queue. It was a workflow, coordination, and risk problem; supporting how change actually moved through a manufacturing environment: who initiated it, who reviewed it, what information mattered, how safety and operational concerns were evaluated, and where ambiguity created downstream consequences.
The challenge was to make the workflow clearer without oversimplifying the environment. Different roles needed different views of the same change, and the system needed to support both consistency across plants and the local realities of manufacturing work.
Research & Design Approach
Observe real work, then design for its consequences.
Observed real workflows
Contextual inquiry across multiple GM assembly plants revealed how change management happened in practice, not just how it appeared in documented process.
Mapped role-based needs
Identified how engineers, safety teams, and operational staff interacted with change workflows differently and what each needed to understand, decide, or act on.
Modeled system interactions
Mapped relationships between people, process steps, approval paths, operational dependencies, and system interactions.
Designed for consequences
The resulting interaction models supported role clarity, workflow continuity, and safer execution in a high-stakes environment.
Research-to-Product Decisions
What the research changed about the product.
Role-specific views
Different groups needed different detail, ownership, and decision support without fragmenting the workflow.
Change status visibility
Clearer visibility into where a change stood, what blocked progress, and who needed to act next.
Approval & handoff clarity
Made responsibility, sequence, and required approvals visible across operational boundaries.
Safety & operational context
Preserved the context behind a change, not simply routed it through a process.
Standardization across plants
Supported consistency across operations while accommodating local plant realities.
Original Product Impact
Measurable savings — and a model for complex enterprise systems.
~$15M
estimated annual operational savings attributed to the platform
Multi-plant
adopted across GM manufacturing operations worldwide
Beyond the savings, the work demonstrated how contextual inquiry and role-based workflow design can improve enterprise systems where operational complexity, safety considerations, and cross-functional coordination shape the experience.
The original GM project was not an AI project. Its value came from understanding real manufacturing workflows and translating that into a better enterprise system. The reflection below is current design analysis. It is not a claim that the project used AI.
AI-Era Reflection
What changes when AI enters this workflow?
A similar platform designed today with AI would not only route work or display status. It would need to decide what operational signals to surface, when to recommend action, when to flag risk, when to escalate, and where human authority must remain explicit. The same context that made the original system operationally complex would also make AI behavior highly sensitive.
Applying the Context-to-Behavior Framework
The same stages, asked as AI-era product questions.
| Framework Stage | Manufacturing Application | AI-Era Product Question |
|---|---|---|
| Context | Plant environment, user role, change type, operational dependencies | What does AI need to understand before making any recommendation? |
| Signals | Change status, impacted systems, safety constraints, approvals, blockers | Which signals indicate risk, delay, or required escalation? |
| Risk | Operational disruption, safety consequences, downstream cost | What could go wrong if AI recommends the wrong action or misses context? |
| Judgment | Engineer review, safety validation, operational approval | Which decisions require human expertise and accountability? |
| AI Behavior | Assist, flag, recommend, explain, escalate, stay out | What should AI do at each stage of the change workflow? |
| Product Decisions | Role-specific views, approval gates, escalation states, rationale capture | How should the interface preserve control, context, and responsibility? |
AI-Era Behavior Questions
Where AI helps — and where it must defer.
What should AI surface?
Operational dependencies, incomplete approvals, conflicting data, delayed handoffs, safety constraints, and unusual change patterns.
When should AI recommend?
When it has enough context to suggest next steps or routing — but not when judgment or safety validation is unresolved.
When should AI explain?
Whenever it flags risk, recommends escalation, prioritizes a change, or suggests a workflow is blocked.
When should AI escalate?
When safety context is unclear, approvals are missing, impact is high, or conflicting signals suggest the change should not proceed.
Where must human authority remain?
Safety validation, operational approval, change acceptance, exception handling, and final production-affecting decisions.
AI-Era Design Principles
Principles for safety-critical enterprise AI.
1
Preserve operational context
Don't separate a recommendation from the plant, role, dependency, or safety context that makes it meaningful.
2
Treat risk as situational
The same change can carry different implications depending on environment, timing, and downstream dependencies.
3
Keep human authority visible
AI may identify risk or recommend steps, but engineers and safety teams remain accountable for decisions.
4
Design escalation as a safety mechanism
Escalation should not feel like an exception state — it is part of responsible workflow design.
5
Support coordination, not blind automation
The most valuable AI behavior may be helping teams see what matters, not automating the change itself.
What This Case Demonstrates
Proven impact, and a careful AI-era lens.
First, the original work shows how contextual inquiry and role-based workflow design can produce measurable impact in a complex enterprise environment.
Second, the AI-era reflection shows how the same workflow would require careful AI behavior decisions today. AI should not simply make work move faster; it should help teams recognize risk, preserve context, coordinate action, and know when human judgment must lead.
Case Takeaway
In safety-critical systems, AI should not simply accelerate the workflow. It should help teams recognize risk, preserve context, and know when human judgment must remain in control.
More work
See the AI-era and consumer cases.
Compare this with the cybersecurity AI-era case and the Dell consumer support reflection.
View all work
Back to all work
Pre-AI consumer case study · AI-era reflection
Reducing Consumer Support Friction Through Research-Driven Design
Consumer Support · Hardware Diagnostics · Product Experience
How research into consumer support friction shaped product decisions that helped customers get support faster and what that work reveals about AI UX in consumer support today.
Overview
When a support call breaks down before it begins.
Context
Dell consumers often needed support for hardware issues, configuration questions, repeat problems, or uncertainty about whether a device actually required service.
The Problem
Long calls, repeated interactions, unnecessary returns of working hardware, and difficulty providing basic system information. One finding made it concrete: agents needed the service tag, which was often on a sticker behind a desktop, under a desk or in a cabinet, hard to reach during a call.
The Goal
Streamline the support experience by making system information, diagnostics, and resolution pathways easier for consumers and support teams to access.
My Role
Led research and design for the SupportAssist experience, identifying consumer friction points and translating them into product, software, and hardware-support decisions.
Original Case
Support friction was a product problem, not just a call-center problem.
Consumers were asked to participate in a technical troubleshooting process without always having the confidence, context, terminology, or physical access needed to do so smoothly. The experience depended on more than the software interface It depended on the customer's environment, the physical device, the information available to the agent, and whether the system was functioning at all.
That made the design challenge broader than improving an application. The work needed to reduce friction across the full support ecosystem: customer, device, application, diagnostic workflow, and support interaction.
Research & Design Approach
From friction patterns to a service-tag insight.
Identified recurring friction
Surfaced patterns behind long calls, repeated interactions, unnecessary returns, and difficulty communicating system-specific details.
Connected experience to workflow
Linked what consumers experienced at home with what agents needed to identify the system, understand configuration, diagnose issues, and guide resolution.
Designed for both system states
The service tag finding led to two complementary solutions: prominently displaying it inside SupportAssist when the system worked, and adding a forward-facing service-tag sticker so customers could locate it even when the system was inaccessible.
Translated into durable decisions
Shaped a support experience that reduced friction for consumers and improved the support team's ability to identify systems, diagnose issues, and resolve calls.
Research-to-Product Decisions
Design across software and hardware touchpoints.
Make system identity easy to access
The service tag needed to be available in software for normal scenarios and physically accessible for non-functioning desktops.
Reduce diagnostic burden
Help customers provide useful system information without requiring them to understand technical configuration details.
Shorten the path to resolution
Reduce time spent gathering context so interactions could focus on diagnosis and resolution.
Prevent unnecessary returns
Help identify whether a device had a true hardware issue, reducing returns of working hardware.
Treat support as an ecosystem
The service-tag decision showed that improving support required more than interface design. It shaped both the software and the physical product affordances.
Original Product Impact
Fewer calls, far shorter calls, and durable product impact.
−15%
reduction in consumer support call volume
−83%
reduction in support call duration
10+ yrs
SupportAssist still shipping on Dell consumer hardware worldwide
Beyond the metrics, the work showed how research-driven design can reduce consumer friction by connecting software experience, hardware realities, and support operations into a more coherent product ecosystem.
The original Dell SupportAssist work was not an AI project. Its value came from understanding consumer support friction and translating findings into better product and support decisions. The reflection below is current design analysis.
AI-Era Reflection
What changes when AI enters this support workflow?
A similar system today might diagnose issues, summarize device health, explain likely causes, recommend actions, or escalate to human support. But those capabilities would need to be shaped around consumer confidence, system state, evidence quality, and the risk of giving the wrong guidance.
The service-tag example is a useful reminder: even a simple support request can break down when the system does not account for the customer's physical context, device state, or technical confidence.
Applying the Context-to-Behavior Framework
From support reality to AI-era product questions.
| Framework Stage | Dell Support Application | AI-Era Product Question |
|---|---|---|
| Context | Consumer technical confidence, device state, physical access, support history | What does AI need to know about the situation before offering guidance? |
| Signals | Diagnostics, service tag, system configuration, error reports, call history | Which signals are reliable enough to diagnose or recommend next steps? |
| Risk | Incorrect diagnosis, unnecessary return, failed self-service, frustration | What could go wrong if AI gives the wrong reassurance or action? |
| Judgment | Customer decision, agent escalation, repair or return determination | When should AI defer to human support or request confirmation? |
| AI Behavior | Diagnose, explain, reassure, guide, escalate, defer | What should AI do when confidence is high, low, or incomplete? |
| Product Decisions | SupportAssist UI, identifier visibility, escalation flows, explanation patterns | How should the experience help consumers act without false confidence? |
AI-Era Behavior Questions
Diagnose, explain, reassure, escalate, defer.
What should AI diagnose?
Device health, common configuration issues, recurring error patterns, and likely causes when there is enough reliable evidence.
When should AI explain?
Whenever it suggests an action, rules out a hardware issue, recommends self-service, or escalates to support.
When should AI reassure?
When diagnostics indicate the system is functioning, no hardware issue is detected, or the concern can be resolved without service.
When should AI escalate?
When the device is non-functioning, evidence is incomplete, the issue repeats, confidence is low, or the cost of a wrong recommendation is high.
Where should AI defer?
When it lacks reliable device signals, the consumer can't verify required information, or the problem involves repair, warranty, return, or safety.
AI-Era Design Principles
Principles for consumer support AI.
1
Design for real-world context
Account for where the device is, whether it is functioning, and what the customer can realistically access.
2
Make confidence visible
Consumers should know whether AI is confident, uncertain, or missing evidence before following guidance.
3
Explain before asking for action
Don't just tell customers what to do. Explain why the step matters and what outcome to expect.
4
Escalate without blame
Human support should feel like a supported path, not a breakdown of self-service.
5
Treat support as an ecosystem
Consumer support spans software, hardware, documentation, agent workflow, and physical affordances.
What This Case Demonstrates
Durable impact, and a confidence-aware AI lens.
First, the original work shows how research-driven design can reduce consumer support friction and create durable product impact.
Second, the AI-era reflection shows how the same context would require careful AI behavior decisions today. In consumer support, AI should not only diagnose or recommend. It should account for confidence, explanation, escalation, and the customer's real-world ability to act on the guidance. The service-tag example is the clearest illustration.
Case Takeaway
In consumer support, AI should not simply diagnose faster. It should help customers understand what is happening, what evidence supports the recommendation, and when human support is the better path.
More work
See the other two case studies.
Compare this with the cybersecurity AI-era case and the GM manufacturing reflection.
View all workIdeas
Writing on AI UX, judgment, and product behavior.
A series of essays exploring how UX research can help teams design AI-enabled products with better context, clearer judgment, and more responsible system behavior.
Published Series
From context to behavior.
This series examines how AI changes the role of UX research and product design. The central argument: when software begins to recommend, summarize, decide, or act, teams need deeper contextual understanding and more explicit behavior design.
The progression
Task friction
Judgment friction
Contextual inquiry
Behavior sequencing
Service / workflow orchestration
From Task Friction to Judgment Friction
Why contextual inquiry deserves renewed attention in AI product design, and why AI UX must account for judgment friction, not only task friction.
Contextual InquiryJudgment FrictionAI UXResearch Methods
From Inquiry to Behavior
How contextual inquiry can translate into AI-aware personas, AI journey maps, risk framing, service blueprints, behavior specification, prototypes, and measurement.
AI-Aware PersonasJourney MappingRisk FramingBehavior Design
From Workflow to Behavior
How service blueprints can help teams model human-AI orchestration, clarify responsibility, and specify AI behavior across complex workflows.
Service BlueprintingHuman-AI OrchestrationWorkflow DesignAI Behavior
Why these ideas matter
AI product design needs stronger links between research, judgment, and system behavior.
Traditional UX work often focused on helping users complete tasks more efficiently. AI-enabled products add a different challenge: the system may summarize evidence, recommend action, explain risk, escalate uncertainty, or act on a user's behalf.
That changes what teams need from research. Understanding user goals is still essential, but it is no longer enough. Teams also need to understand the user's context, decision authority, trust boundaries, risk tolerance, and the consequences of getting the interaction wrong.
The essays on this page explore that shift and connect directly to the Context-to-Behavior Framework used throughout this portfolio.
Connected to the framework
The writing supports the same model used in the work.
The Context-to-Behavior Framework turns these ideas into a practical product lens: start with context, identify meaningful signals, evaluate risk, clarify human judgment, and then define how AI should behave.
Explore the frameworkAbout
UX Research leadership for teams designing complex, AI-enabled products.
I help teams connect user context, product strategy, and system behavior, especially in environments where decisions are complex, risk matters, and AI changes what the product is expected to do.
My work spans UX Research leadership, enterprise product strategy, AI experience design, ResearchOps, and the design of systems that help teams turn insight into better product decisions.
Career through-line
From research insight to product behavior.
Across enterprise software, consumer support, manufacturing systems, cybersecurity workflows, and AI-enabled product concepts, my work has focused on a consistent challenge: helping teams understand the real context behind user behavior and translate that understanding into better product decisions.
That work has included leading UX Research teams, building research practices, conducting contextual inquiry in complex environments, shaping product direction through evidence, and helping teams design experiences where workflow, judgment, trust, and operational impact all matter.
As AI becomes part of more product experiences, that same research foundation becomes even more important. AI changes the design question from "What does the user need to do?" to "How should the system behave in this context, with this evidence, for this user, under these conditions?"
Professional focus areas
Where I spend my time.
UX Research Leadership
Leading research teams and programs that connect user insight to product strategy, roadmap decisions, and measurable outcomes.
AI Experience Strategy
Helping teams define how AI should assist, recommend, explain, escalate, or defer based on user context, risk, and decision authority.
Complex Workflow Design
Working in environments where multiple roles, handoffs, dependencies, and operational consequences shape the product experience.
ResearchOps & Scalable Practice
Building systems, templates, methods, and practices that help research teams work more consistently and increase their organizational impact.
Research-to-Product Translation
Turning findings into product implications, design direction, behavior requirements, and stakeholder-ready deliverables.
Responsible AI adoption
Leading responsible AI adoption in research practice.
As a player/coach, I explored how AI tools could responsibly support research workflows while preparing my team for how AI would change the researcher's role.
The goal was not to let AI produce conclusions on its own. AI helped accelerate planning, synthesis, reporting, and design exploration, but experienced research judgment remained essential for interpreting findings, identifying product implications, and crafting deliverables stakeholders could trust.
At OpenText World in mid-November, my team conducted testing sessions across nine products. AI-supported synthesis helped us deliver insights before the holiday break and gave us enough capacity to analyze common findings across products, including patterns related to AI features. Those cross-product findings were incorporated into the design system, extending the impact from individual product teams to the broader portfolio of AI-enabled products.
This experience reinforced a core belief: AI can help research teams move faster and scale their influence, but only when paired with responsible use, human judgment, and a clear path from insight to product decision.
Responsible Use
AI was treated as a support tool, not a substitute for research expertise, interpretation, or accountability.
Faster Insight Delivery
AI helped accelerate planning, synthesis, and reporting so product teams could receive actionable insights more quickly.
Portfolio-Level Learning
AI-supported synthesis created capacity to identify common findings across products, including AI feature patterns that informed the design system.
Scaled Research Capability
AI helped the team extend its reach without abandoning the judgment, craft, and stakeholder sensitivity required for credible research.
Tools used with governance and judgment
The team used sanctioned tools and workflow-specific platforms where appropriate: Copilot as a thought partner for planning and report review, Dovetail for transcript synthesis support, AI features in Lyssna and SurveyMonkey for unmoderated research and survey workflows, and tools such as Google Stitch and UX Pilot to explore design alternatives that illustrated research-based recommendations.
We also began exploring Custom GPTs and Claude skills to streamline recurring research deliverables such as test scripts and reports.
How I work
Practical, evidence-based, and systems-oriented.
I tend to work best where research needs to do more than describe user needs. I like helping teams clarify what the findings mean, what decisions they should influence, and how those decisions should show up in the product experience.
My approach is practical and collaborative: understand the context, surface the risks, clarify the judgment required, and translate research into product direction that teams can act on.
Let's connect
Interested in AI UX, research strategy, or product behavior design?
I'm always glad to connect with teams and leaders working through complex product questions, especially where AI, research, workflow design, and human judgment intersect.
Get in touchContact
Let's talk about AI UX, research strategy, or product behavior design.
I'm interested in conversations with teams building AI-enabled products, leaders shaping research strategy, and organizations looking for better ways to connect user insight to product decisions.
Reach out directly for opportunities, collaborations, or conversations about AI UX and research strategy.
Connect on LinkedIn for professional updates, portfolio work, and ongoing writing.
Substack
Read the latest essays on AI UX, contextual inquiry, judgment friction, and product behavior.
Good reasons to connect
The best conversations usually involve complex products, research leadership, or AI behavior.
01AI UX strategy
02UX Research leadership
03Product behavior design
04ResearchOps & scalable research systems
05Enterprise workflow research
06Senior UX Research or AI UX opportunities
07Applying AI to UX Research
The best product decisions usually start with better questions. If you're working on something where research, AI, workflow, and judgment intersect, I'd be happy to talk.