All perspectives

Reflection · Experience

Trust, intent, and escalation: the enduring questions behind AI Product strategy

A financial assistant had to understand what a customer was trying to accomplish without overreaching when context, permission, confidence, or consequence made automated action unsafe.

The cases below show how the work changed my point of view and how I apply it now.

What I did

The work behind the question.

Inside Wells Fargo Innovation Group, I served as Lead UX Designer for The Virtual Assistant across personas, customer goals, interaction models, omnichannel continuity, prototype directions, and the boundary between assistant behavior and human escalation. I also created the group's R&D intake and output mechanism for moving emerging work toward a useful receiving-team decision.

How my view changed

The shift in my thinking.

Conversation was only one part of the Product. Trust depended on intent, visible action, context, confirmation, recovery, continuity across channels, and a handoff that did not force the customer to start again.

Cases behind the view

Work that shaped or complicated my thinking.

Leadership lesson

What I carried forward.

Designing intelligent assistance means allocating responsibility, not only designing dialogue. The Product must make clear what the system can explain, prepare, propose, confirm, execute, or transfer to a person.

My point of view

AI Experience strategy designs the human–AI–workflow system through which intent becomes a successful, governable outcome—not merely the surface where a person prompts a model.

The technology has changed dramatically, but the Product questions endure. Modern LLM and agent capabilities are not projected backward; the continuity is in trust, intent, authority, escalation, and Experience—not technical capability.

Adaptive, probabilistic, and increasingly agentic systems change more than interface behavior. They allocate sensing, interpretation, generation, action, verification, exception handling, and accountability among people and machines. The experience includes backstage workflow, policy, service, organizational ownership, and the consequences of action.

People need calibrated reliance rather than manufactured trust. They need to understand what the system knows, what it may do, where evidence comes from, when uncertainty matters, who can intervene, and how work can be corrected or recovered.

  1. 01

    Design the outcome system

    Treat the interface, workflow, service, information, policy, and organizational dependencies as one lived experience.

    Leadership implication
    A coherent conversational surface cannot repair fragmented ownership or a broken fulfillment path.

  2. 02

    Allocate by competence and consequence

    Assign work using capability, consequence, reversibility, observability, verification burden, and legitimate authority—not an ideological preference for either automation or human review.

    Leadership implication
    Oversight must route evidence and exceptions to someone able to detect and act on the problem.

  3. 03

    Make control and recovery part of the architecture

    Plans, previews, permissions, confirmation, inspectable artifacts, stop, edit, escalation, and recovery should scale with the system's agency and consequence.

    Leadership implication
    Stable interaction grammar can coexist with adaptive assistance; conversation is not the best form for every kind of work.

In practice now

How I am applying the point of view.

Evidence and approval as Product behavior

The operating Product treats source support, review, and customer authority as part of the workflow rather than as a disclaimer after generation.

Current state
Implemented principle; enforcement coverage and measured failure prevention remain open.

Structured artifacts beyond conversation

Current portfolio and Product work favors inspectable state, comparisons, decisions, and revision paths when conversation alone would hide precision or control.

Current state
Emerging practice; current work is improving reliance, escalation, and recovery.

Questions in practice

What I’m still working through.

  1. How should an AI Product expose uncertainty without shifting verification burden unfairly to the customer?
  2. Which consequential actions need preview, confirmation, dual control, or retained human authority?
  3. How should memory remain useful, correctable, permissioned, and disposable across a long-lived relationship?