The fourth post in this series introduced the Context-to-Behavior Framework. Four modes describing what AI can be doing at any given moment. Five conditional dimensions determining which mode applies. Together they are the mechanics of the framework, what it specifies and how the specifications get made.

This post takes the next step. The framework’s mechanics are not what makes it useful in practice. What makes it useful is a set of design principles that govern how the mechanics get applied. The mechanics are the parts. The principles are the operating logic.

There are five principles in total: restraint as a feature, persona-conditional behavior, phase-dependent fit, provenance preservation, and lower downstream signal intensity as a design success metric. Several of them have appeared as through-lines across the series already. None of them has been treated as a principle in its own right, with its own internal logic and its own design implications. That is purpose of this post.

Before diving in, a brief note on what makes these principles rather than something else. Rules describe what to do. Heuristics describe what often works. Principles describe what design decisions to make and why. Each of the framework’s principles names a structural design judgment that applies across domains, products, and personas. They are not domain-specific. They are not feature-level. They are the operating commitments that make the framework usable in real work.

Restraint as a feature

The principle that has been most consistently teased across this series may be counterintuitive to product teams accustomed to maximizing capability deployment. An AI’s most valuable behavior may sometimes be deliberate inaction.

Refusing to recommend on incomplete evidence. Preserving human authorship on routine work where AI assistance would add latency without value. Stopping short of taking actions that affect organizational authority such as adjusting policy, closing high-stakes work, or escalating outside the user’s chain of accountability. These are not feature gaps. They are deliberate design choices that earn user trust over time precisely because the AI does not act when acting would be wrong.

The principle works for three reasons that are worth naming separately.

The first is that trust calibration depends on consistent reliability. An AI that acts confidently on incomplete evidence and is wrong once will not be trusted on subsequent correct outputs. The user has learned that the AI cannot be relied on for the judgment call about when to act. An AI that visibly declines to act under uncertain conditions earns trust as a structural property. The user knows that when the AI does act, it has assessed the conditions and judged them appropriate. Restraint, paradoxically, is what makes confident action more trustworthy.

The second is that authorship preservation matters for adoption. Users who feel their judgment has been replaced rather than supported retreat from the system. They route around it. They produce work outside it. They use it for the minimum necessary and trust their own judgment for everything else. Restraint on routine work signals to the user that the AI knows when its participation would be value-additive and when it would just add noise. That signal is what makes users comfortable letting the AI participate in work that actually matters.

The third is that authority preservation matters for governance. AI that quietly takes actions affecting policy, organizational structure, or chain-of-command accountability erodes the human authority structures that make organizations governable. Restraint at these boundaries is what keeps the framework deployable in regulated environments and accountable organizations. The AI participates where it has been authorized to participate and stops short where it has not.

The framework supports restraint structurally. The conditional dimensions determine when the AI should operate in fewer modes than its capabilities would permit. Restraint is not the absence of capability. It is capability deliberately withheld at the right moments, for the right reasons, based on the right contextual signals.

One final clarification before moving on. Restraint is not the same as being conservative or under-deploying AI. A restrained AI is fully deployed across the right touchpoints and deliberately silent across the wrong ones. The distinction matters because teams may confuse restraint with timidity. The framework treats it as the opposite. Restraint is precision about where AI belongs and where it does not. It requires more judgment than blanket deployment, not less.

Persona-conditional behavior

The second principle has been established across posts #2 and #4. Different personas have different relationships to AI: autonomy preferences, trust calibration patterns, risk tolerances, AI literacy, and domain expertise relative to the system. The framework specifies different mode defaults, recommendation densities, escalation thresholds, and reasoning surfaces for each persona. The same underlying AI Layer behaves differently depending on who is using it.

It is worth calling out that persona-conditional behavior is what makes the framework portable across domains.

A cybersecurity workflow with a decision-quality persona and a throughput persona. A clinical workflow with the same dimensional pair. A legal workflow with the same pair. A financial research workflow with the same pair. The framework adapts across these domains not because it knows the domain but because the personas adapt. The framework is domain-agnostic precisely because persona is the primary dimension. The domain shows up through the personas, and the framework reads the personas.

This is a stronger claim than the persona section in post #4 made. It is also the claim that determines how the framework gets adopted in practice. A team applying the framework in a new domain does not need to rebuild the framework. They need to do the persona work properly. The framework reads the work that was already required by good UX practice.

The design implication follows directly. Teams adopting the framework should invest in persona depth before mode specification. Thin personas produce uniform AI behavior even when the framework specifies differentiation, because the framework has no basis to differentiate. The principle works as well as the persona work that grounds it. Bad personas produce a framework that looks operational but isn’t. Good personas produce a framework that adapts in the ways the work actually requires.

Phase-dependent fit

The third principle has been covered in posts #3 and #4. The same capability can be appropriate in one phase of a workflow and inappropriate in another. Capabilities that interrupt judgment formation are inappropriate during phases where judgment is still forming. Capabilities that accelerate execution may be inappropriate during phases where the user is investigating, validating, or deciding.

The angle worth noting here is the connection to restraint. Phase-dependent fit operationalizes restraint. The two principles depend on each other.

Restraint without phase awareness is just inconsistent AI behavior. Sometimes the AI acts. Sometimes it does not. The user cannot tell why, and the inconsistency erodes the trust calibration that restraint is supposed to produce. Phase-dependent fit is what gives restraint its rationale. The AI declines to recommend not because of timidity but because the phase is judgment-formation rather than execution. The phase tells the framework when the capability should be withheld, and the user can see that the withholding has a logic to it.

Phase-dependent fit without restraint is the inverse problem. The framework is capable of producing different mode densities at different phases, but the team has not made the design call to restrict capabilities during specific phases. The result is an AI that participates everywhere it can, with no phase-aware deliberateness. The phases get mapped. The fit decisions get made. The restraint never gets implemented. Phase-dependent fit becomes a description rather than a discipline.

The principles together produce deliberate, defensible AI behavior across the workflow. Restraint without phase is arbitrary. Phase-dependent fit without restraint is unused capacity. Together they make AI behavior tangible to the user, which is what promotes adoption.

The design implication is that teams should map AI fit not at the workflow level but at the phase level. Same workflow, different fit per phase. The service blueprint from post #3 is the artifact that records these phase-level decisions, and the framework’s mechanics from post #4 are how the decisions get translated into specifications. The principles are how teams know what to specify.

Provenance preservation

The fourth principle has been covered in post #3, where I argued that flattening provenance produces structural automation bias and that provenance preservation is the structural mechanism for trust calibration in mixed-confidence workflows.

But what makes this a design principle rather than a UX best practice?

UX best practices live at the interface level. They describe how to present information to users (e.g., labeling AI-generated content, indicating confidence levels, showing the source of a recommendation.) These are real and valuable, and the framework benefits from interfaces that follow them. But they are not the same as a design principle.

Design principles reside at the system level. They describe what the system must structurally maintain regardless of how any given interface is built. Provenance preservation is not about whether a label says “AI suggested.” It is about whether the system tracks the lineage of every piece of content across every handoff in the workflow, and surfaces that lineage at moments when trust calibration matters. That structural commitment is what makes provenance a principle of the framework rather than a recommendation about the interface.

The distinction matters in two ways. First, it raises the bar for what gets to be a principle in this framework. The other four principles meet the same standard. Restraint is structural, not interface-level. Persona-conditional behavior is structural, not interface-level. Phase-dependent fit is structural. Signal intensity, which I will cover next, is structural. Each principle names a system-level commitment that constrains design decisions across the product.

Second, it shapes how teams adopt the framework. Provenance preservation cannot be retrofit at the interface stage. By the time the interface design is happening, the system either tracks provenance or it does not. If the back-end has been built without lineage tracking, or if AI-generated and human-validated content get mixed into the same fields in the same data structures, there is no interface treatment that can rebuild what was lost. The principle has to be specified at the blueprint stage, the data architecture stage, the system design stage. The interface inherits what the system preserves.

The design implication is direct. Teams should specify provenance requirements at the blueprint stage, before any interface design happens, and they should treat provenance as a non-negotiable property of the data flow through the system. Compressing for readability is fine. Collapsing provenance is the failure mode.

Lower downstream signal intensity as a design success metric

The fifth principle is the one that has not appeared in this series yet, and it is perhaps the most impactful of the five from a UX perspective. When the framework is working well, downstream phases of a workflow are quiet.

Lower cognitive load. Lower decision pressure. Fewer high-stakes interventions. Fewer escalations. The quietness is not the absence of work or evidence that the phase is unimportant. It is evidence of upstream design success.

Most teams measure AI effectiveness by what the AI is doing visibly. Recommendations made. Actions taken. Escalations surfaced. Suggestions accepted. These are activity measures, and they are the measures that AI product teams default to because they are the measures their dashboards naturally produce. The signal intensity principle measures something different. It measures how much judgment work the user is having to do at any given phase. If upstream phases work well (e.g., clean handoffs, preserved provenance, persona-appropriate mode density, well-tuned restraint,) then downstream phases inherit good context and require less judgment work. The cognitive, risk, and emotional signals downstream are low not because the work is less important but because the upstream design did its job.

The principle becomes diagnostic in the inverse. High downstream signal intensity is evidence of upstream failure. A phase with high cognitive load that should be quiet is telling the team something has gone wrong earlier in the workflow.

A few concrete examples make the diagnostic value clear. If the handoff to a coordinator is producing high cognitive load on every finding, the provenance got flattened. The coordinator is having to re-derive context that should have been preserved. If the validation phase is producing high risk signals on every closure, the AI is over-acting upstream or restraint failed. Work is reaching validation that should not have arrived without more confidence. If the routine execution phase is producing emotional load (e.g., frustration, second-guessing, repeated rework,) the persona-conditional behavior failed for the throughput persona who is getting mode density appropriate for a different persona entirely.

In each case, the signal intensity at the downstream phase is not a problem to be solved at that phase. It is a read-out of design quality upstream. Adding more AI features to the downstream phase will not fix it. Going back and fixing the upstream design will.

The design implication is important. Teams using the framework should measure success not just at the AI’s touchpoints but in the absence of stress in the phases that follow. This is a different kind of evaluation than most AI products do. It requires instrumenting the workflow, not just the AI features. It requires tracking signal intensity at phases where the AI is not even acting, because the absence of signal is the success metric.

This is also the principle that lets a team know whether the other four are actually working. Restraint at the right moments, with persona-conditional behavior at the right depth, phase-dependent fit with the right discipline, and provenance preserved across the right handoffs. The evidence that all four are operating correctly shows up downstream as quiet phases doing competent work. Lower downstream signal intensity is the evaluative principle that closes the loop on the operational ones.

Closing

These principles are not independent of each other. They reinforce each other in ways that matter for using the framework well. Restraint depends on phase-dependent fit for its rationale. Phase-dependent fit depends on restraint for its implementation. Persona-conditional behavior depends on persona depth, which depends on the contextual inquiry work from earlier in the series. Provenance preservation depends on blueprint-stage design discipline, which depends on the structural work from post #3. Signal intensity as a success metric depends on all four of the others functioning, because what it evaluates is whether the operational principles are doing their job.

The framework’s operating logic comes from the principles working together, not from any one of them in isolation. This is part of why the series has built up to them across four prior posts. Each prior post laid the methodological ground that makes one or more of these principles viable. Contextual inquiry made personas possible. Personas made AI-aware persona work possible. Journey mapping made phase awareness possible. Service blueprints made structural commitments like provenance possible. The framework’s mechanics made mode-level specification possible. The principles are what make those mechanics produce defensible, sustainable AI behavior in real product work.

The pattern that has run through the series so far applies here too. Traditional UX methods retain their value in the AI era. The methods do not change. The demands on the findings do.

The fifth principle points naturally toward what comes next. Lower downstream signal intensity is an evaluative principle, and the framework needs an evaluation methodology to make it operational. The next post in this series will go deeper on measurement. Specifically, it will address how to instrument AI behavior across the framework’s dimensions, what to measure, what to count as success, and how to read signal intensity as a read-out of design quality. The framework specifies how AI should behave. Measurement is how teams know whether the behavior is producing the outcomes that matter.

Subscribe now

The third post in this series closed with a specific tease - service blueprints are the artifact that records AI behavior decisions. The framework is the structured way of making them.

This post introduces that framework. I have been calling it the Context-to-Behavior Framework, because what it does is translate context - who the user is, where they are in the work, what is at stake, what they are actually doing in the moment - into specific behavior choices for an AI system. The framework is what gets you from “we want AI to participate here” to “this is how AI should behave at this specific touchpoint for this specific user under these specific conditions.”

The post covers two things. First, the four modes that describe how AI can behave at any given moment. Second, the five conditional dimensions that determine which mode applies. Together they form the operating logic of the framework. The framework also has design principles - restraint as a feature, persona-conditional behavior, provenance preservation, and others that have appeared across the series. Those principles deserve their own treatment, and the next post in this series will go deeper on them. This post establishes the modes and the conditional logic that make the principles operational.

The problem the framework addresses

Before introducing the framework, it is worth being specific about what it is responding to. Three failure patterns motivate it.

The first is uniform AI behavior across heterogeneous users. Products often deploy a single AI behavior model using the same recommendation density, same confidence presentation, and same defaults across all users. The result is predictable in retrospect and frustrating in practice. Users with deep expertise and skepticism find the AI too noisy and retreat to manual workflows. Users with high operational velocity find it too cautious, or accept its recommendations too quickly. Both trust failures are real. Neither is addressable without AI behavior that adapts to who is using it.

The second is capability-driven feature deployment. When a product team adds AI to a workflow, the question they too often ask is “what can the AI do here?” That question optimizes for capability deployment. The right question, as I argued in the second post in this series, is “is AI of benefit here, and if so, how should it behave at this moment… in this workflow… for this user?” That question produces different and often better answers, including the answer that AI should not act here at all.

The third is provenance flattening. I covered this in the third post, so a brief recap is enough. When AI-generated content mixes with human-validated content in a single output, and the system flattens the distinction for readability, downstream users cannot calibrate their trust appropriately. Automation bias becomes structural rather than behavioral. The framework treats provenance as a first-class concern that the design must specify, not as a UX detail to be sorted out at the end.

The framework’s central claim is that AI behavior should be deliberately shaped by context, not uniformly applied. The rest of this post lays out how.

The four modes

The framework specifies AI behavior through four modes. Each mode describes what the AI is doing at a given moment, and what the user is doing in response. The same underlying AI capability (e.g., suggesting a remediation approach) can appear in any of the four modes depending on how the system surfaces it. The choice of mode is a design decision, not a property of the capability.

The modes are not mutually exclusive across a session. They shift moment to moment. They are mutually exclusive for any single AI interaction at any single moment: an AI cannot simultaneously be asking and acting on the same content.

Ask

In Ask mode, the AI surfaces a question or prompt for the user to answer. It does not propose a path forward. It clarifies what is needed before proceeding. Ask is appropriate when ambiguity is present, when multiple paths exist that the AI cannot reasonably choose between, or when user input is required for the AI to proceed effectively. The user provides clarification, makes a choice, or confirms an interpretation.

Ask mode is the one many product teams underuse. The instinct when AI is capable of generating a response is to generate one and let the user correct it after the fact. But the cost of a confident wrong answer is often higher than the cost of a brief clarifying question, especially in high-stakes work.

Recommend

In Recommend mode, the AI proposes a specific action, choice, or interpretation with supporting reasoning, and awaits the user’s response. It does not act. Recommend is appropriate when a pattern is recognized, evidence is available, and the decision is the user’s to make. The user reviews the recommendation, accepts it, modifies it, or rejects it.

Recommend is the most familiar of the four modes. Most current AI products operate primarily in this mode. The design choices that matter within Recommend are how reasoning is surfaced (foregrounded for evidence-driven users, condensed for velocity-driven users), how confidence is communicated, and how easy it is for the user to interrogate the recommendation before accepting it.

Act

In Act mode, the AI takes an action on the user’s behalf, within bounded conditions. Actions may be logged for review and may be reversible by default. Act is appropriate for low-risk, repetitive, high-confidence, reversible operations where user attention is better spent elsewhere. The user reviews actions taken, often after the fact, and reverses or escalates if needed.

The hardest design judgment in Act mode is defining the boundaries. An AI that can act broadly creates efficiency at the cost of accountability. An AI that can act narrowly preserves accountability at the cost of efficiency. The framework does not prescribe where the bounds belong; it requires that they be specified.

Escalate

In Escalate mode, the AI surfaces a condition requiring different or higher human attention. It may refuse to proceed. It may route to another role. Escalate is appropriate when risk is high, confidence is low, novel patterns appear, conditions exceed policy thresholds, or actual outcomes diverge from expected ones. The user receiving the escalation makes a judgment call about whether and how to proceed.

Escalate is the most underspecified mode in most AI products. Teams often assume that the AI will escalate when needed without defining what “when needed” means. The framework requires explicit specification: what triggers escalation, to whom, with what context preserved.

Three boundaries that shape how the framework is used

The four modes are clean as a list, but the boundaries between them matter when applying the framework to design.

The boundary between Recommend and Act is not capability but accountability. A capable AI can both recommend a path and execute it. The mode determines who is accountable for the outcome. In Recommend, the user. In Act, the system, within policy bounds the user has accepted. Choosing between Recommend and Act for a given touchpoint is a choice about where accountability resides.

The boundary between Ask and Escalate is more subtle. Both surface human-required input, but they differ in posture. Ask treats the current user as the appropriate decision-maker who needs more information to proceed. Escalate treats the situation as exceeding the current user’s authority or the AI’s confidence. The human attention required may need to come from a different user entirely.

The third boundary is one I want to call out explicitly because it has been a through-line across this series. Restraint is not a mode. It is a deliberate decision to operate in fewer modes than capability would permit. An AI in restraint state may still be in Recommend mode for some content while deliberately not Recommending other content. Restraint is a property of mode selection, not a fifth mode alongside the four. The framework treats it as one of the design principles, which the next post will cover. For now it is enough to note that the framework supports restraint structurally. The modes specify what the AI does, and the conditional dimensions specify when the AI should do less than its capabilities would allow.

The conditional dimensions

Mode selection is not arbitrary. It is determined by the intersection of several contextual dimensions. Each dimension shifts which modes are appropriate. Their combination produces the specific AI behavior at any given moment.

Five dimensions are foundational.

Persona

Persona is the primary dimension. Most decisions begin here. Different personas have different relationships to AI, captured through the AI-aware persona dimensions I discussed in the second post in this series: autonomy preference, trust calibration, and risk tolerance.

A persona with low autonomy preference, evidence-driven trust calibration, and high risk sensitivity (typical of senior expert users) requires more Recommend density with strong reasoning surfacing, restrained Act, and frequent Escalate. A persona with higher autonomy preference, velocity-driven trust calibration, and moderate risk tolerance (typical of operations or execution users) requires condensed Recommend, more permissive Act in bounded conditions, and context-sensitive Escalate. The same underlying AI Layer behaves differently for each. The framework specifies how.

Workflow phase

AI fit is phase-dependent. I covered this in the third post, so I will keep the framework-level treatment brief. The same capability can be appropriate in one phase and inappropriate in another. Capabilities that interrupt judgment formation are inappropriate during phases where judgment is still forming. Capabilities that accelerate execution may be inappropriate during phases where the user is investigating, validating, or deciding.

Phase awareness is what makes restraint possible as a deliberate design choice rather than a feature gap. The AI is capable of acting. The phase says it should not.

Risk tier

Higher-risk content warrants tighter mode behavior. Higher Escalate sensitivity. Lower Act tolerance. Stricter Recommend confidence thresholds. Lower-risk content permits more Act, less Escalate, and looser Recommend thresholds.

Risk tier interacts with persona rather than overriding it. A risk-tolerant persona working on high-risk content still warrants tighter mode behavior than the same persona on low-risk content. Persona sets the baseline. Risk tier modulates it.

Signal profile

The fourth dimension is signal profile, which I introduced in the second post in this series through AI journey mapping. Four signal types apply: efficiency signals like time and throughput pressure, cognitive signals like synthesis burden and decision integration, risk signals like consequences of being wrong, and emotional signals like stress, accountability, professional credibility.

Each phase of a workflow has a dominant signal profile, and mode appropriateness shifts with it. High cognitive load argues for Ask and Recommend with reasoning surfaced, while it argues against Act. High efficiency pressure argues for Recommend in condensed form and bounded Act, while it argues against frequent Ask that would slow the user down. High risk argues for Escalate sensitivity. High emotional load argues for restraint and visible provenance, because users under emotional load are more vulnerable to both under-utilization and automation bias, depending on their persona.

Observed user behavior

The fifth dimension is the one I have not yet introduced in this series, and it is the one that does the most work in keeping the framework from collapsing into a rigid state machine.

Workflow phases describe typical behavior. Observed user behavior describes actual behavior. The AI should respond to actual behaviors, not to typical.

A senior analyst whose role is decision-quality may, on a particular day, be working in execution mode. They are handling routine work for a colleague who is unavailable. The phase the system assumes they are in is investigation. The behavior they are actually showing is execution. If the framework forces the AI into investigation-mode behavior because of the persona’s typical profile, the AI will be too noisy for the work the user is actually doing.

A junior specialist whose role is throughput may, on a particular day, be deep in investigation of an unusual finding. The phase the system assumes is coordination. The behavior they are showing is investigation. If the framework forces execution-mode behavior, the AI will be too action-oriented for the work the user is actually trying to do.

Observed behavior overrides phase assumptions when they conflict. The framework reads the user’s actual activity (e.g., depth of inspection, time spent on evidence, pace of action) and adjusts mode density accordingly. This dimension is what makes the framework adaptive rather than reactive.

How the dimensions combine

Persona sets the baseline mode tendencies. Phase shifts which capabilities are appropriate. Risk tier modulates mode strictness. Signal profile shapes mode emphasis. Observed behavior overrides phase assumptions when they conflict.

Together, the five dimensions specify the AI’s behavior at any given moment. None of them alone is sufficient. The combination is what makes the framework work.

A worked example

A concrete scenario helps the framework move from abstract to usable.

Imagine a research analyst and a junior associate working a multi-stage investigation. The analyst’s role is decision-quality. They form the analytical view, interpret the evidence, and make the recommendation. The associate’s role is throughput. They execute on the analyst’s direction, coordinate with downstream stakeholders, and prepare materials.

In the early phases (gathering evidence, evaluating sources, forming the analytical view,) the analyst is doing investigation work. The signal profile is cognitive-heavy. The AI’s appropriate mode is Recommend with reasoning forward, Ask when ambiguity surfaces in the evidence, and restrained Act. Even though the AI may be capable of suggesting an early conclusion, that capability is inappropriate at this phase for this persona. The framework calls for restraint.

When the analyst transitions from investigation to drafting the recommendation, the framework shifts. The same Recommend capability that was deliberately withheld becomes appropriate. The AI can now suggest structure, surface comparable prior analyses, and identify gaps in the argument. Risk tier modulates how confident those suggestions are. The conclusion is high-stakes; the threshold for the AI’s recommendations is correspondingly higher.

The handoff to the associate is where the framework does its most distinctive work. The same AI Layer that has been operating in evidence-forward, restrained-Act mode for the analyst shifts to action-oriented, bounded-Act mode for the associate. Same underlying capabilities. Different defaults. The Recommend density compresses, because the associate is operating at throughput and does not need the full reasoning surface. The bounds on Act loosen slightly for routine coordination work but stay tight for anything stakeholder-facing. Escalate becomes more context-sensitive, because the associate needs prompting on warranting conditions but not on every routine decision.

Observed behavior matters here. If the analyst, on a particular day, is moving quickly through routine work, the framework reads that and condenses the Recommend surface accordingly. If the associate, on a particular finding, is spending significant time on evidence inspection rather than execution, the framework reads that and expands the reasoning surface. The dimensions interact continuously, not just at phase boundaries.

This is what the framework produces in practice. Not a list of features. A specification of behavior, conditioned on who the user is, where they are in the work, what is at stake, what signals dominate the phase, and what the user is actually doing in the moment.

A note on framework and application

The Context-to-Behavior Framework is implementable today. It does not require runtime infrastructure that does not yet exist. Persona-conditional defaults, phase-aware mode selection, risk-tier modulation, and signal-driven emphasis can all be implemented through normal product engineering - feature flags, conditional rendering, rules engines, persona-keyed configuration. The framework specifies what the design decisions should be. The team implements them through standard practice.

What the framework does not yet have, and what would extend its reach significantly, is a runtime application that observes user behavior in real time and adapts the AI’s mode selection continuously. That kind of behavior-driven adaptation, the kind that picks up when a decision-quality persona is working in execution mode on a particular day and adjusts accordingly, sits beyond what static and rules-driven implementations can reach. It is a logical extension of the framework rather than a precondition for any of it. Teams adopting the framework today can capture most of its value through framework guidance alone. The runtime extension is methodology in progress.

Closing

The Context-to-Behavior Framework is the structured way of answering a question that AI product teams cannot avoid: how should the AI behave at this touchpoint, for this user, under these conditions? Four modes describe what the AI can be doing. Five conditional dimensions determine which mode applies. The combination produces behavior that adapts to context rather than imposing the same defaults across every user and every moment.

The pattern that has run through the series so far holds here too. Traditional UX methods retain their value in the AI era. The blueprint is still the artifact that records design decisions. The framework is the methodology that produces them. The methods do not change. The demands on the findings do.

The framework also rests on a set of design principles — restraint as a feature, persona-conditional behavior, provenance preservation, phase-dependent fit, and lower downstream signal intensity as a design success metric. Several of these have appeared across the series already. None of them has been treated in its own right as a framework principle. The next post in this series will do that — going deeper on the principles that make the framework’s operating logic operational in real product work.

Subscribe now

In the second post in this series, I argued that AI design decisions are only as defensible as the sequence of understanding that produced them. The path runs from contextual inquiry through AI-aware personas and journey maps, through risk and consequence framing, into service blueprints with human–AI orchestration, and then into behavior specification, prototyping, and measurement.

That post focused on the parallel pair: AI-aware personas and AI journey maps. The teases at the end were specific. Service blueprints are where human–AI orchestration becomes explicit. They are where provenance flow becomes load-bearing. They are where the structural answers to “who does what, with what information, and who is accountable when it fails” finally come together.

This post pays off those promises. The argument I want to make is that service blueprints in the AI era are structurally different from traditional blueprints. The traditional bones still carry. But AI introduces a fundamentally new kind of actor into the system, one that is neither human nor traditional software, and the blueprint has to learn to map it. That requires new structural layers, a behavioral overlay that traditional blueprints never had to specify, and a through-line of provenance that holds the whole thing together.

I’ll lay out the structural extensions first, then the behavioral overlay, then provenance.

What the blueprint has always done

Service blueprints have been part of design practice for decades. They emerged from service design and operations research, and were popularized in UX through the work of practitioners trying to make complex service systems visible to the teams that build and maintain them.

A traditional blueprint maps a service across several layers. User actions sit at the top. The line of interaction separates user activity from the front-stage, which is the parts of the system the user encounters directly. The line of visibility separates front-stage from back-stage, which is the internal staff actions and processes the user does not see. Support processes sit below the line of internal interaction, capturing the systems and infrastructure that enable the rest. Read together, the layers show how a service actually delivers value, where work moves between people and systems, and where the seams are.

The value of blueprints has always been that they make structure explicit. They force teams to specify accountability across handoffs. They surface where work actually fails, which is often not where the interface confuses but where the back-stage and support processes break down. They are the artifact that makes complex services governable.

The pattern of extension from the previous post applies here too. Traditional blueprint structure remains valid for AI-enabled services. The user actions layer still matters. The line of visibility still matters. Back-stage and support processes still matter. What AI changes is what the blueprint must capture inside that structure, because AI is not just another component to map.

The fundamental shift: AI as a probabilistic actor

Traditional blueprints have always assumed two kinds of actors in the system. Humans bring judgment, intention, and accountability. They make decisions that can be challenged and explained. They can be held responsible. Traditional software is deterministic. Given the same inputs, it produces the same outputs. Its failure modes are knowable in advance. When it breaks, the failure is usually a defect in the code or the data, not in the system’s reasoning.

AI is neither of those things.

An AI Layer in a product is non-deterministic. It produces different outputs for the same inputs. It fails in ways that traditional software does not. It can hallucinate context that doesn’t exist. It can drift in tone or behavior over time. It can refuse to act when the request looks suspicious, succeed spectacularly on one input, and fail inexplicably on a near-identical one. It participates in work that previously required human judgment, but it does not have the accountability structure that humans bring to that work.

This is not a refinement to the blueprint. It is a new kind of actor, and the blueprint has to learn to map it.

Three consequences follow. First, the structural layers of the blueprint must extend to accommodate AI as a distinct actor type. Not folded into front-stage software. Not hidden in support processes. Represented in ways that make its probabilistic nature visible. Second, the blueprint must specify how AI behaves at each touchpoint where it participates, because behavior is not given by the specification the way it is with traditional software. Third, the blueprint must track provenance, meaning what information came from where, what was generated by AI, and what was validated by humans, because mixed-confidence workflows are now the norm rather than the exception.

The rest of this post takes those three consequences in turn.

Extending the traditional structure

Each layer of the traditional blueprint requires extension when AI joins the system.

Front-stage extensions

The front-stage captures what the user sees and interacts with. AI changes this layer in three ways that the blueprint needs to make explicit.

AI limitations need to appear as mapped friction points, not as edge cases. Latency in token generation. Hallucinated content that the user might accept at face value. Mismatches between what the user intended and what the AI inferred. These are not bugs to be fixed away. They are inherent properties of the actor. The blueprint should show where they will appear and how the system handles them.

Handoff lines need to be specified, not assumed. Where does the AI hand off to a human? What triggers that handoff? Confidence thresholds. Risk tier. User-initiated escalation. Failure to make progress. Each of these is a design choice that the blueprint should capture explicitly, because handoffs are where AI behavior most often goes wrong.

Transparency about AI involvement is a front-stage design decision. When does the system disclose to the user that they are interacting with an AI rather than a human or a deterministic interface? The answer is rarely “always” or “never.” It depends on stakes, context, and user expectations. The blueprint is where those decisions are recorded.

Back-stage extensions

The back-stage captures internal processes that support front-stage actions. AI introduces highly specialized operational layers here that traditional blueprints did not have to map.

Evaluation layers and guardrails are now back-stage actors in their own right. Content moderation, safety filters, output validation, and refusal logic process AI responses before they reach the user. They are not implementation details. They shape what the user experiences as much as the AI itself does, and the blueprint should make them visible.

Retrieval-augmented generation and the data orchestration that supports it deserve explicit treatment. Where does the AI fetch real-time information? Which internal knowledge systems does it draw on? How does the orchestration layer route between models or sources? These connections matter because they determine what the AI knows and what it fabricates.

Processing latency is a structural property worth mapping. Token generation takes time. Different model sizes have different latency profiles. The blueprint should make latency visible so that the front-stage knows where to build in waiting states, progress indicators, or asynchronous fallbacks.

A new swimlane: data and infrastructure

Traditional blueprints have a support processes layer for relational databases, internal systems, and infrastructure. AI requires extending that layer into its own dedicated swimlane.

Data flow and provenance live here. Where does user data travel? Where is it stored? Is it used for downstream model training? Are personally identifiable data masked or redacted? These are not compliance afterthoughts. They are structural properties of the service that affect trust and adoption.

System dependencies live here too. AI-enabled products often depend on external foundation model providers. The blueprint should document those dependencies and their fallback protocols. What happens if the primary model provider has an outage? Does the system degrade gracefully or fail completely?

Vector databases, embedding pipelines, and real-time data orchestration belong in this layer. They are infrastructure, not features. The blueprint is the place where they become legible to the people responsible for the service as-a-whole.

Line of visibility, redefined

The line of visibility traditionally separates what the user sees from what happens behind the scenes. AI blurs this line because back-stage data and processing heavily shape front-stage behavior in ways the user cannot see and may not understand.

The blueprint needs to differentiate visually between autonomous AI actions and co-pilot assistance to human staff. An AI agent interacting directly with a customer is a different kind of actor from an AI tool helping a human draft a response. Both are valuable. Both have different accountability profiles, different failure modes, and different design requirements. Collapsing them into a single “AI” label hides the structural decision that actually matters.

The behavioral overlay

Structural extensions are necessary but not sufficient. Once the blueprint has mapped where AI participates in the service, it must also specify how AI behaves at each of those touchpoints. Behavior is not given by the specification the way it is with traditional software. It is a design choice that the blueprint has to record.

Three behavioral considerations matter most.

Persona-conditional behavior

The same AI Layer should not behave the same way for every user. Different users come to the system with different orientations to AI. Different autonomy preferences. Different trust calibration patterns. Different risk tolerances. Different operating tempos.

In the previous post, I introduced two personas that I have been developing in companion work. Jordan is a decision-quality persona whose primary need from AI is to augment judgment with evidence and transparency. Priya is a throughput persona whose primary need is to accelerate workflow without breaking trust. These two personas represent opposite trust-failure modes. Under-utilization or abandonment in Jordan’s case if the AI is too aggressive. Automation bias in Priya’s case if the AI is too confident.

The blueprint is where the design implication becomes specifiable. Same underlying AI Layer. Different defaults for different personas. Different recommendation density. Different willingness to act versus recommend. Different escalation thresholds. The handoff between personas, most often Jordan to Priya when investigation moves into coordination, is the moment where the AI’s behavioral mode must shift. Same system. Different behavior. The blueprint makes the shift visible.

Phase-conditional behavior

The same AI capability can be appropriate at one step in the workflow and inappropriate at another.

Prioritization recommendations offer a clean example. Early in an investigation, while a human is still forming a risk judgment, an AI recommendation to prioritize one finding over another can undermine that judgment formation process. The user reads the recommendation, defers to it, and stops forming their own view. The trust calibration that the rest of the workflow depends on gets damaged. Later in the same workflow, once the user’s judgment has been applied, the same recommendation accelerates the work without harming the judgment.

Standard discussions of AI fit pair capabilities with tasks. This is the right frame for AI journey mapping, as I argued in the previous post. The blueprint adds a second pairing: capabilities with workflow phase. The AI’s behavior at any given step depends not just on what it could do, but on whether doing it supports or undermines what the user is trying to accomplish at that point in the work.

Restraint as a feature

The most counterintuitive of the three is that the AI’s most valuable behavior is sometimes deliberate inaction.

Refusing to recommend on incomplete evidence. Preserving human authorship on routine communications where AI assistance would add latency without value. Stopping short of taking actions that affect organizational authority, such as adjusting policy, closing high-stakes work, or escalating outside the user’s chain of accountability. These are not feature gaps. They are deliberate design choices that the blueprint specifies, and they earn user trust over time precisely because the AI does not act when acting would be wrong.

There is a more complete framework for specifying these behavioral choices. When AI should ask, recommend, act, escalate, or stay silent, and how those modes should vary by persona, phase, risk, and confidence. I’ll come back to that framework in a future post in this series. For now, the relevant point is that the blueprint is the artifact that records the behavioral choices, and that those choices include silence as much as they include action.

Provenance flow: the through-line

The structural extensions and the behavioral overlay only work if the blueprint also tracks where information came from and how it transformed as it moved through the system.

This is what provenance flow does. Provenance flow is the through-line that holds an AI-era service blueprint together, because without it, the trust calibration that the rest of the design depends on collapses.

Here is the failure mode. AI-generated content and human-validated content get mixed together in the same artifact: a summary, a recommendation, a handoff package. A downstream user receives that artifact and cannot tell which is which. They treat AI-generated inferences with the same weight as human judgments. Automation bias becomes structural, not behavioral. It is built into the artifact rather than introduced by the user.

This matters most at handoffs. When work transfers from one actor to another, whether human to AI, AI to human, AI to AI, or human to human via AI-mediated channels, the blueprint must track what was AI-generated, what was human-validated, what was AI-suggested and then human-confirmed, and what is system-derived. Each of these has different trust implications. Collapsing them is the failure mode.

A concrete example. A senior analyst investigates a finding, validates the AI’s suggested correlation against environmental knowledge, and adds their own risk judgment to the package that hands off to a coordinator downstream. The handoff package contains AI-generated context (the initial correlation, the criticality inference, the suggested remediation path), human-validated context (the corrections the analyst made), and AI-suggested-and-then-human-confirmed context (the recommendations the analyst reviewed and accepted). If the package presents all of these in the same voice, the coordinator inherits a flattened artifact and cannot calibrate their own trust appropriately. If the package preserves the provenance of each element, by tagging what came from where and what was confirmed by whom, the coordinator can move quickly on the parts they should trust and look more carefully at the parts that warrant scrutiny.

Compressing for readability is fine. Collapsing provenance is the failure mode. Provenance preservation is the load-bearing mechanism for trust calibration in mixed-confidence workflows. It is a structural property of the blueprint, not a UX detail.

Closing

Service blueprints have always made system structure explicit. In the AI era, the structure is more complex than blueprints have traditionally had to map. AI is a different kind of actor: non-deterministic, persona-sensitive, phase-aware, and sometimes deliberately restrained. The blueprint has to extend to accommodate that actor, and the extension is not cosmetic.

The traditional structure carries forward. The front-stage, the line of visibility, the back-stage, and the support processes are all still load-bearing. What changes is what we ask the blueprint to capture inside that structure. New layers to map AI as a structural actor. A behavioral overlay to specify how AI acts, varies, and refrains. Provenance flow as the through-line that makes trust calibration possible across mixed-confidence work.

The pattern that has run through the entire series so far holds here too. Traditional UX methods retain their value in the AI era. The methods don’t change. The demands on the findings do.

In the next post in this series, I want to introduce the behavioral framework I have been working toward: the question of how AI should act at each touchpoint where it participates, and how those choices should vary by persona, phase, risk, and confidence. The blueprint is the artifact that records those decisions. The framework is the structured way of making them.

In the first post in this series, I argued that contextual inquiry deserves a central role again in the AI era, not because it had been forgotten, but because AI raises the stakes of context. When software begins to recommend, summarize, decide, and act, shallow understanding of the work it participates in becomes a trust risk, an adoption risk, and sometimes a business risk.

If that argument rings true, the natural next question is: what comes after contextual inquiry? How does observed work in context translate into AI design decisions?

This post is about that translation. My contention is that the sequence matters. That there is a defensible order of dependency from observed work to AI behavior, and that teams that skip steps or run them out of order produce design decisions they cannot defend. The sequence isn’t a strict pipeline. It’s a layered set of dependencies, and the order of those dependencies is what gives downstream AI behavior decisions their grounding.

The sequence at-a-glance

Before going deeper, here is the path I am proposing, end-to-end. Contextual inquiry surfaces how work happens. From that data, two activities run in parallel: extending personas to be AI-aware, and journey mapping to understand where AI should and should not appear in the workflow. Those parallel outputs feed an explicit framing of risk and consequence. What is at stake when each step fails and who absorbs it? That framing in turn enables service blueprinting with human–AI orchestration, which makes the multi-actor structure of the work explicit. The blueprint enables behavior specification. How AI should actually behave at each chosen touchpoint. Storyboards and prototypes make that behavior tangible and testable before build. Measurement closes the loop and feeds learning back into earlier steps.

That is seven layers, not seven sequential gates. Personas and contextual inquiry often iterate; risk framing can prompt a return to the journey map; measurement reshapes everything upstream. But the order of dependency remains: you cannot responsibly specify how AI should behave without first understanding the work, the people doing it, and the stakes when something fails.

This post focuses on the second layer, the parallel pair of AI-aware personas and AI journey mapping. They do the most translation work, and they are the steps where the most defensible AI design positions either get grounded or hollowed out. I will name the bridge into service blueprints (risk and consequence framing) and tease the remaining layers, but the depth in this post lives in the pair.

AI-aware personas: extend, don’t replace

Personas have been part of UX practice long enough that most enterprise teams already have them. They’ve been vetted, debated, and refined over years. The first question I keep hearing from research and design leaders in the AI era is whether those personas need to be thrown out and rebuilt for AI products.

My position, supported by extensive conversations with colleagues working on AI-enabled products, is that a well-vetted persona stays valid. The domain role, goals, pain points, workflow context, tooling preferences, and organizational dynamics that the original persona captured don’t lose their relevance because AI entered the product. What changes is that those personas now need to answer additional questions: how this person prefers to work with AI, where they want control, where they will trust automation, where they will verify, and how they relate to risk and accountability when AI is involved in their work.

The clearest precedent is the shift to mobile. The basic persona attributes still applied when products moved to mobile. What changed was the need to capture platform-specific aspects: context of use, interruption patterns, input constraints, expectations of immediacy. The personas extended; they didn’t get replaced. AI is the same kind of evolution, just on a larger scale and extending into the behavior of the product itself rather than only its form factor.

What needs to be added

The AI-aware extension typically covers a handful of dimensions: autonomy preference (how much do they want to do themselves versus delegate), trust calibration (how do they decide whether to trust AI output), risk tolerance (how do they weigh the consequences of being wrong), AI literacy (what do they understand about how the system works), and domain expertise relative to the AI (where is their judgment stronger than the system’s, and where is the inverse true). These dimensions are not exhaustive, but they cover most of what an AI-aware extension needs to surface.

If existing personas feel too thin to extend, that’s a vetting problem, not an AI problem

This point deserves to be made sharply, because it reframes a common AI-era complaint. When I hear teams say their personas don’t account for AI and therefore need to be rebuilt, I usually find that the personas were thin to begin with. Often, they were one-pagers built from a workshop rather than from research, or that they had not been revisited since the product moved into new contexts. The AI era doesn’t create the problem; it exposes a vetting gap that has always been there.

This has been true with every major product context shift. Mobile exposed thin personas. Enterprise expansion exposed thin personas. Entry into regulated industries exposed thin personas. AI is exposing them again. The right response is not, “we need new AI personas.” It is, “we need to do the persona work properly, and then extend for AI.”

Calibrating depth: a backward reference to contextual inquiry

Here is where the parallel pair argument actually starts to hold together: the depth and emphasis of the AI-aware extension is not uniform across personas or products. It scales with what contextual inquiry surfaced.

If CI reveals a workflow with light AI involvement (a few assistive features at the edges, low judgment friction, minimal handoffs between human and AI,) the personas need a light AI-aware layer. If CI reveals heavy AI involvement (frequent handoffs, contested trust, high judgment friction, AI participating in consequential decisions,) the personas need substantial depth across the dimensions named above.

This is what I have started calling AI involvement depth. It is a property of the workflow, surfaced by CI, that calibrates how much extension your personas actually need. It is also a useful corrective against two failure modes. The first is teams bolting-on a generic AI persona template regardless of context - too much extension, often in the wrong dimensions. The second is teams skipping the AI extension entirely because their existing personas “seem fine” - too little extension, with the gaps only surfacing once AI behavior starts going wrong in front of users.

The non-AI corollary

There is an important corollary that I want to emphasize, because it ties back to the first post in this series.

When contextual inquiry indicates that a non-AI solution is the right answer (clearer information architecture, better permissions, a workflow redesign, a policy clarification,) the traditional content of the persona becomes more important, not less. The AI-aware extension is a calibration tool. It tells you how to design for AI when AI is the right answer. It is not a replacement for the full persona; it is an additional lens that becomes more or less prominent depending on what the work actually requires.

This is worth noting because a common tendency in AI product organizations is to overweight the AI dimensions of everything. A persona with rich AI-aware content but thin domain-role and workflow content is a persona that will fail you precisely when CI points toward a non-AI fix. As the first post argued, this happens more often than the AI hype cycle suggests.

We will see this same pattern of extension and asymmetric adaptation when we turn to journey maps next.

AI journey mapping: extending the traditional model

Journey maps are doing different work than personas. Personas translate observed people into design-actionable archetypes. Journey maps translate observed work into AI-placement decisions. They run in parallel because they are working the same contextual inquiry data from two different angles, the people and the work, and each angle needs both kinds of translation to be useful.

The same pattern of extension applies. Traditional journey maps remain valid in the AI era. What changes is the depth and emphasis certain components require, and one component evolves more substantively than the others.

I’ll state plainly that the right shape of AI-era journey maps is still an open methodological question. What follows is my working position, rather than a settled framework.

Six traditional components, with asymmetric extension

A traditional journey map carries six components: user actions, thoughts, emotions, touchpoints, goals, and opportunities. Each is doing a specific job, and the AI era does not change the value of each evenly.

User actions and goals carry through largely unchanged. What the user is doing and what they are trying to achieve remain stable across the AI shift. If anything, the actions lane becomes more useful in AI-era maps because it makes the division of labor between human and AI legible. Once you can see what the user is doing at a given step, you can ask the parallel question of what the system is doing, and the gap between those two answers is often where the most interesting design work lives.

Thoughts and emotions need substantial extension. Thoughts in a traditional map often capture relatively shallow cognition (what the user is wondering, considering, or evaluating.) In the AI era, thoughts are also where trust calibration, source-checking instincts, verification behavior, and judgment friction live. Capturing them at sufficient depth is hard, and it is often the lane that benefits most from the contextual inquiry work upstream. Emotions, similarly, need a more granular vocabulary in the AI era. Traditional happy / neutral / frustrated characterizations are coarse for what actually shows up when users interact with AI: trust, doubt, surprise, resignation, vigilance, relief. These are emotional dimensions that directly affect adoption, and a map that flattens them into a smile or a frown is missing the data.

Touchpoints need rethinking. Traditional touchpoints are channels and interfaces (the email, the dashboard, the phone call, the form.) AI introduces a different kind of touchpoint: moments where the system itself produces output, makes a recommendation, or acts on the user’s behalf. Whether AI touchpoints should be treated as a paired lane alongside traditional touchpoints, or as a property tagged onto existing touchpoints, is an open practitioner question. I have seen both approaches work. What does not work is treating an AI output as just another interface element. It is a different kind of artifact, with different trust implications, and the map should reflect that.

Opportunities is the component that evolves most substantively. In a traditional map, opportunities is where the team identifies what could improve (better tooling, better information, better handoffs.) In an AI-era map, opportunities becomes a sharper artifact: fit decisions. The opportunities lane stops asking “what could improve here” in the abstract and starts asking “should AI be involved at this step, and if so, in what way.” That shift is what makes the journey map decision-ready rather than just diagnostic.

From signal to fit decision

The mechanism that turns the opportunities lane into fit decisions is signal analysis. Each step in the workflow carries a signal profile drawn from the contextual inquiry data - efficiency signals (time loss, repetition), cognitive signals (low confidence, synthesis burden), and risk signals (consequence of being wrong, compliance exposure). The combination of signals at each step suggests how AI might or might not contribute.

A worked example helps. Consider an enterprise IT issue-resolution workflow with steps that include identifying the affected system, searching for relevant information, interpreting what was found, applying a fix, validating that it worked, and escalating when needed.

The system identification step often surfaces an efficiency signal - users spend disproportionate time before resolution even begins, frequently because system metadata is incomplete or inconsistent. The instinct is to point an AI at it. But the underlying problem is not interpretation; it is visibility. The signal profile points to a non-AI fit: the better solution is improved metadata, structured system visibility, and accessibility improvements, not a model. Surfacing this is a positive outcome of the journey map work, not a failure to find an AI opportunity.

The interpretation step looks different. Users must combine multiple inputs (documentation, telemetry, prior tickets, partial context from colleagues) under uncertainty. The signal profile is low confidence plus synthesis burden, and the consequence of mis-interpretation is moderate. This is a strong AI fit: synthesis and ranking are exactly what current AI systems do well, and the human retains the decision. The journey map points toward an AI recommendation surface, not full automation.

Other steps in the same workflow would surface conditional or hybrid fits, places where AI can contribute under specific constraints, or where AI supports a human-led process rather than driving it. The details of how to specify those cases is part of the deeper journey map methodology, which I’ll come back to in a future post.

The “is AI even right here” payoff

This is where the question raised in the first post, “is AI even right here?” gets a methodological home. Identifying non-AI fits is not a failure of the AI journey map; it is one of its most valuable outputs. Teams that approach journey mapping with a feature-intent mindset (”where can we put AI?”) will systematically miss this. Teams that approach it with a signal-profile mindset (”what does the work actually need?”) will find non-AI opportunities reliably and will make stronger AI placement decisions when AI is the right answer.

AI fit emerges from the signal profile of the work, not from feature intent. That is the essence of the journey map stage.

Risk and consequence: the bridge into blueprints

Once you have AI-aware personas and an AI journey map with fit decisions, there is one more step before you can responsibly start specifying how the AI should behave. You need to look at each touchpoint where AI is a candidate and ask: what is at stake when this goes wrong?

Reversibility — can the action be undone? Severity — what is the magnitude of consequence when it fails? Who absorbs the consequence — the user, the user’s organization, a third party, the public? Who carries accountability when something goes wrong? What evidence is required to justify the action after the fact?

This is a distinct step, not a subsection of journey mapping or behavior specification. I have seen too many teams skip directly from “the AI fits here” to “let’s have the AI act on the user’s behalf” because action feels efficient and the team did not pause to examine the stakes. Then a high-consequence, irreversible step turns out to have been quietly automated, and the team discovers the gap only after the failure mode shows up in production.

Risk and consequence framing is what the service blueprint stage has to answer. Blueprints are where multi-actor flow becomes explicit - who does what, who hands off to whom, and crucially, where information came from and how it transformed as it moved through the system. Those structural answers cannot be made without the risk framing that comes before them.

What comes next

The remaining steps in the sequence each deserve their own treatment, and several will get one in later posts in this series.

Service blueprints with human–AI orchestration. The blueprint is where the multi-actor structure of AI-enabled work becomes explicit, and where provenance flow becomes load-bearing (not just who did what, but where information came from, how it transformed, and who carries accountability for it as it moves between human and AI actors.) Provenance is critical in any high-consequence multi-persona workflow, and the blueprint is the artifact that makes it visible. I’ll go deeper on this in the next post.

Behavior specification. Once the blueprint exists, the question becomes how the AI should actually behave at each chosen touchpoint - when to ask a clarifying question, when to recommend, when to act, when to escalate, when to stay silent. There is a framework I have been developing for this, and I’ll introduce it in a dedicated post later in the series.

Storyboards and prototypes. Behavior specification is necessary but not sufficient. AI behavior decisions need to be made tangible and testable before build, because AI failure modes are often invisible in specs and only surface when you watch the behavior unfold in context. Storyboards and lightweight prototypes are how you get the specification into a form that can be evaluated.

Measurement and learning. Finally, the loop closes. Measuring AI experience health is not the same as measuring traditional UX outcomes. It requires attention to behavioral reliability, system consistency, and organizational capability alongside more familiar dimensions. What measurement reveals feeds back into research, personas, journey maps, risk framing, and behavior specification. A future post will dig into the measurement framework I’ve been developing.

Closing

The argument of this post is that AI design decisions are only as defensible as the sequence of understanding that produced them. Behavior depends on the blueprint. The blueprint depends on risk framing. Risk framing depends on the journey map and personas. The journey map and personas depend on contextual inquiry. Skip a step and you don’t save time; you just defer failure, usually until it shows up in production where the cost is highest.

The pattern that runs through the whole sequence is the one we saw in both personas and journey maps: traditional UX methods retain their value in the AI era. What changes is what we ask them to reveal, and how much depth each method requires given what the work actually involves. The methods don’t change. The demands on the findings do.

In the next post in this series, I’ll dig into service blueprints, where human–AI orchestration becomes explicit, where provenance flow becomes load-bearing, and where the structural answers to “who does what, with what information, and who is accountable when it fails” finally come together.

Subscribe now

For years, much of digital product design has been organized around tasks. Search for something. Submit a form. Approve a request. Complete a workflow. Generate a report. UX research helped teams understand whether people could complete those tasks efficiently and confidently, and whether the interface supported them well along the way.

AI changes the question.

In AI-enabled products, we are no longer only asking whether users can complete a task. We are asking when software should interpret, recommend, decide, draft, summarize, escalate, or act on a user’s behalf. That is a fundamentally different design problem, and it raises the stakes of context in ways that our existing research practices have not always kept pace with.

This is the first in a series of posts about designing AI behavior for products. I want to start with a methodological argument, because I think we are missing something foundational. The argument is this: contextual inquiry, one of UX research’s oldest and most powerful exploratory methods, deserves a central role again - not because it has been forgotten, but because AI has changed what is at stake when we get context wrong.

What contextual inquiry has always provided

Contextual inquiry studies people in the real environments where work happens. Not in the abstract. Not only through recall. Not only through a scripted usability task. But in the messy reality of tools, interruptions, workarounds, handoffs, constraints, and tacit judgment.

Its strength is that it surfaces things people do not think to mention in an interview, because those behaviors have become invisible to them. The spreadsheet they maintain alongside the official system. The Slack message they send to a colleague before approving something. The screenshot they paste into a ticket because the export function does not include the field they need. The pause they take before clicking a button, because they are mentally checking three other things first.

That has always been the value of the method. It reveals friction and opportunity that other methods cannot reliably see.

Why it became less common

Contextual inquiry did not become less valuable. It became less common.

The reasons are practical. It is time-intensive. It can be expensive. It is harder to scale than interviews, surveys, analytics, or unmoderated testing. Many product teams became more comfortable optimizing known digital workflows where the work patterns were already broadly understood. The pandemic disrupted on-site observation and accelerated remote research habits. Product development pressure often favored faster, narrower methods.

These were understandable tradeoffs. In most cases, teams were not being negligent. They were making reasonable choices about where to invest research effort given the constraints they faced and the nature of the products they were building.

But AI is changing the cost of those tradeoffs.

Why AI raises the stakes of context

When software is mostly there to support task completion, insufficient understanding of context produces usability problems. Confusing labels. Awkward flows. Missed edge cases. These are real costs, but they are largely correctable through iteration.

When software begins to recommend, summarize, decide, and act, insufficient understanding of context produces something more serious. It produces AI that behaves badly in ways that erode trust, create risk, and sometimes cause harm. An AI that summarizes a clinical note without preserving the right uncertainty. An AI that recommends a remediation without understanding compensating controls. An AI that auto-drafts a customer response without recognizing that this customer is in escalation. An AI that acts when it should have asked.

These are not interface problems. They are context problems. And they cannot be solved by ideating features from a backlog or by testing screens with users who are removed from the conditions under which the AI will actually operate.

From task friction to judgment friction

I have been thinking of this as judgment friction, to distinguish it from the task friction that has been our traditional focus.

Task friction shows up when users cannot complete a task efficiently. They get stuck. They hesitate. They make errors. The interface slows them down. We have built robust methods for finding and fixing task friction, and we have largely succeeded at it.

Judgment friction shows up somewhere else. It shows up when users have to decide what matters, what to trust, what to prioritize, what requires escalation, what evidence is sufficient, and what action is safe. It is the friction of weighing, verifying, deferring, and committing. It is invisible in click-stream data. It is often invisible in interviews, because users have integrated it so deeply into their work that they no longer narrate it.

A few examples:

In a cybersecurity workflow, the issue may not be whether an analyst can click “assign remediation.” The harder question is whether the system understands enough about exploitability, business criticality, compensating controls, ownership, SLA pressure, and confidence to recommend the right next action — or whether it should recommend at all.

In a healthcare workflow, the issue may not be whether a clinician can read an AI-generated summary. The harder question is whether the summary preserves the right uncertainty, the right evidence, and the right accountability for what was included and what was left out.

In a customer support workflow, the issue may not be whether an agent can generate a response. The harder question is whether the AI knows when tone, policy, customer history, exception handling, or escalation should shape that response — and when the agent’s own judgment should override the draft entirely.

In each case, the design question is no longer only “Can the user complete this?” It is “Should the AI participate here, and if so, how?” That is a judgment friction question, and it cannot be answered without context.

What contextual inquiry reveals for AI design

When you observe real work in real environments with AI design in mind, you see specific things that other methods miss.

Hidden decision points. The moments where users pause, verify, ask someone else, compare sources, or delay action. These are the moments where AI either earns trust or loses it.

Informal workarounds. The spreadsheets, side chats, copied notes, screenshots, personal checklists, and individual systems that official workflows ignore. These workarounds are signals. They tell you where the formal system is failing, and they often point directly to where AI assistance could help, or conversely, where a non-AI solution would be more appropriate.

Trust boundaries. Where users are comfortable with automation, where they want recommendations they can review, where they need evidence before acting, and where they require explicit control. These boundaries are not uniform across users, tasks, or organizations.

Handoffs and accountability. Who owns the next step. Who approves. Who gets blamed when something goes wrong. Who needs to be notified. What has to be documented for compliance, audit, or institutional memory. AI that disrupts these patterns without understanding them creates organizational friction that no interface polish can fix.

Where AI is not the answer. Sometimes what looks like an AI opportunity is actually a clearer information architecture problem. Or a permissions problem. Or a workflow redesign problem. Or a policy clarification problem. Or a communication problem. Contextual inquiry helps teams see this, and it is a meaningful corrective against the reflex to add AI to everything.

Contextual inquiry is foundational, not sufficient

I am not arguing that contextual inquiry is the only method that matters for AI product design, or that it is sufficient on its own. It is not.

My position is more specific: contextual inquiry is the most powerful exploratory method we have for understanding situated work, and it deserves to anchor exploratory research for AI products. The other exploratory methods complement it. They do not replace it.

Diary studies reveal behavior, sentiment, and patterns over time. Surveys add breadth and validate whether what we observed in depth holds across a wider population. Analytics show existing usage patterns. Interviews help unpack meaning, perception, and intent. Participatory design helps users and teams imagine new AI-enabled workflows together. Wizard-of-Oz testing lets us evaluate AI concepts before the system fully exists. Longitudinal studies help us understand how trust, adoption, and behavior change once an AI product is in use.

Each of these is valuable. None of them, on their own, substitutes for the situated understanding that contextual inquiry provides. The point is not to choose between methods. The point is to restore contextual inquiry to a foundational role when we are designing systems that will participate in real work, and then to build on that foundation with the methods that extend it.

Designing AI behavior depends on context

For AI products, the central research question is not only “What should the interface look like?” It is “How should the system behave?”

A useful way to frame that behavior question is along four modes: should the AI ask a clarifying question, recommend a next step, act on the user’s behalf, or escalate to a human? (And sometimes the answer is to do nothing.) I will explore a framework I have been calling the AI Interaction System in more depth in future posts. For now, the relevant point is that these behavior choices cannot be made responsibly from a feature backlog alone.

They depend on risk. On the system’s confidence. On the reversibility of the action. On the user’s authority to act. On the consequences of error. On organizational policy. On what the user is actually doing in the moment.

All of those factors are contextual. They cannot be inferred from screens or specs. They have to be observed, understood, and built into the design of how the AI behaves.

What this means for UX and product leadership

If the argument so far is right, a few practical things follow.

Start AI discovery with workflow observation, not feature ideation. Before asking “Where can we add AI?”, observe where work actually breaks down. The places where users pause, verify, escalate, work around, or hand off are the places worth investigating first.

Map judgment friction, not only task friction. Look for the moments of uncertainty, verification, exception handling, and trust-building that traditional usability research has not required specific focus. These are the moments where AI behavior will be evaluated by users, whether or not we designed for them.

Match AI behavior to context. Ask, recommend, act, escalate, or stay silent based on risk, confidence, reversibility, and consequence. Do not assume the default behavior should be the same across features, users, or tasks.

Use contextual inquiry to find non-AI solutions too. The goal is not more AI. The goal is better outcomes. Sometimes the most valuable thing contextual inquiry reveals is that an AI solution is the wrong fit for the problem.

Pair contextual depth with scalable methods. Use diary studies, surveys, analytics, and longitudinal research to validate, extend, and continuously refine what contextual inquiry reveals. Depth without scale is anecdote. Scale without depth is noise. The combination is what produces durable design decisions.

Closing

Contextual inquiry has always helped UX teams understand work as it really happens. AI makes that understanding more consequential. When software begins to recommend, summarize, decide, and act, insufficient understanding of context is no longer just a usability risk. It becomes a trust risk, an adoption risk, and sometimes a business risk.

The future of AI product design will not be won by teams that simply add AI to interfaces. It will be shaped by teams that understand the human work deeply enough to know when intelligence should appear, how it should behave, and when it should stay out of the way.

The more software begins to act on our behalf, the more dangerous it becomes to design without understanding the context in which that action takes place.

In the next post in this series, I want to dig into the sequencing question. Specifically, how exploratory research, AI behavior modeling, and design work fit together in a way that does not collapse back into feature-first thinking.