Case Study

Shaping an AI Experience Vision Through System-Level Exploration

Vision
Strategy

Overview

Shaping an AI experience vision at a system level before any solutions existed.

This work happened upstream of any interface or feature definition. The goal was to give teams a shared-experience lens before they committed to building anything, and to ensure the questions being asked were the right ones.

My Role

Principal Experience Designer | 2025 — 2026

My contribution was not to design features, but to shape how the organization reasoned about AI experience before features existed.

That meant four things:

Synthesizing applied research across agentic AI, decision-support tools, and trust patterns into principles that teams could actually use to evaluate concepts.
Designing the system journey framing that mapped inventory, pricing, vendor performance, and logistics as a single interconnected system, shifting conversations from individual features to system behavior.
Writing and facilitating experience scenarios that gave teams a safe space to explore failure modes, decision boundaries, and human-AI handoffs before anything was built.
Establishing experience principles that functioned as a lightweight maturity guardrail, every AI concept was expected to declare its role in the broader system and explain how it would earn trust.

The Challenge

AI exploration was fragmented across teams, with no shared experience framing to guide trust, decision-making, or long-term direction.

The organization was actively experimenting with AI, but each team did so in isolation. There was no shared vocabulary, no common criteria for evaluating concepts, and no agreed-upon view of how AI should behave across the system. The result was a set of well-intentioned but disconnected ideas that optimized individual moments while risking the coherence of the overall experience.

The gap wasn’t a lack of ideas.
It was a gap in the questions being asked.

Teams asked questions like:

“Can AI do this?”
“Should this be an assistant?”
“Where does automation fit?”

What was missing were questions like:

“How should this system behave over time?”
“What decisions should AI support versus automate?”
“How do trust, transparency, and control show up across workflows?”

Without a shared-experience lens, the organization risked investing in disconnected AI features instead of a cohesive, reliable system.

This created the risk of inconsistent trust signals, duplicated effort, and AI behaviors that were difficult to govern or scale across the enterprise, all indicators of low AI UX maturity.

What this work had to enable

The objective wasn’t to slow teams down, but to raise the quality of the decisions they were already making. That meant operating at a level above any specific solution:

Translating complex AI behaviors into narratives that teams could debate.
Establishing principles before patterns were defined.
Helping the organization think about AI as an interconnected system rather than a collection of features.

Specifically, the work needed to:

Give teams a way to talk about AI behavior, failure modes, and decision boundaries in concrete terms, not just capabilities.

Clarify the distinction between AI that supports human decision-making and AI that replaces it, and establish criteria for knowing the difference.

Shift reasoning from isolated touchpoints to end-to-end system behavior. e.g., How does a decision made in pricing affect what’s possible in logistics six steps later?

Establish shared principles early enough to influence what got built, not just how it got built.

Areas of Research

Before any principles were written, we needed to understand what mature AI experience actually looked like in practice, not in theory. That meant looking outward and inward at the same time.

Research covered four areas that kept surfacing as the highest-risk dimensions of AI UX at scale.

Conversational and agent-based interfaces: How users calibrate trust with systems that take initiative, and where that trust breaks down.

AI-assisted creation and decision-support tools: The line between augmentation and automation, and what happens when that line is unclear.

Automation embedded within existing workflows: How AI behaves when it’s invisible, and the governance challenges that it creates.

Trust, control, and transparency patterns: The signals users rely on to understand what AI is doing, why, and what they can override.

This included market scans, emerging agent platforms, AI interaction pattern libraries, and internal stakeholder conversations to understand how AI was already being explored across the organization.

Trust, control, and orchestration emerged as the central risks; not because AI could not do things, but because organizations were not yet equipped to govern what AI was doing on their behalf.

Experience Framing Principles

The research didn’t produce a feature list. It produced a set of principles that became the test for every AI concept we evaluated.

The question wasn’t “Is this technically feasible?”
It was “Does this concept hold up when you run it through these four lenses?”

Favor system-level solutions over isolated assistants.

Frame AI around user intent and outcomes rather than technical capability.

Treat trust and transparency as core requirements.

Avoid defining UI patterns before system behavior is understood.

The intent was for these principles to function as a lightweight maturity guardrail, a way to pressure-test any AI concept against experience and governance criteria before it moved forward, rather than after.

System Journey Framing

Understanding how AI supports decisions across interconnected workflows over time.

One of the core problems with isolated AI thinking is that it ignores downstream effects. A pricing recommendation affects not just pricing; it also influences vendor relationships, inventory decisions, and logistics planning.

To make that visible, we:

mapped inventory, pricing, vendor performance, and logistics as parts of a single dynamic system,
identified where AI should sense signals, recommend actions, or automate responses across the workflow, and
translated abstract discussions into tangible, end-to-end operational workflows

This shifted the conversation from “What features can we build?” to “How should this system behave when conditions change?”, and enabled clearer decisions about AI boundaries, responsibilities, and human–AI handoffs.

Customer Base

Click images to enlarge

Experience Scenarios

Principles and journey maps can only take a team so far. At some point, abstract system thinking has to become a concrete story, specific enough that people can disagree about it, stress-test it, and make real decisions based on it. That’s what the experience scenarios were for.

Each scenario was built around:

A specific customer context – enterprise, SMB, or consumer
Named participants with defined goals and constraints
A use-case flow mapping both the AI’s actions and the human’s experience at each stage

Six scenarios were developed in total, covering supply disruptions, pricing volatility, vendor anomalies, and complex self-serve configuration.

These weren’t meant to be final answers. They were thinking tools, a way to make AI behavior concrete enough to pressure-test before any engineering commitment was made. What they produced wasn’t a roadmap. It was better questions: about trust boundaries, orchestration complexity, and where human judgment needed to stay in the loop.

How we used the Scenarios

1

Stress-test how AI behavior would scale under supply disruptions, pricing volatility, and vendor anomalies

2

Surface trust, control, and transparency concerns across workflows.

3

Evaluate orchestration challenges between multiple agents and existing systems, which informed platform-level decisions.

Outcome

Clearer reasoning about AI experiences
Experience narratives made abstract AI concepts tangible, helping teams evaluate system behavior and decision-making trade-offs more effectively and consistently.

Stronger cross-functional alignment
A shared experience vocabulary around trust, orchestration, and decision roles enabled more productive conversations across design, product, engineering, and leadership.

Influence beyond the initial effort
The experience framing and insights developed through this work informed subsequent AI-related exploration and platform-level thinking, giving teams a reusable maturity lens for future concepts.

Concept Videos

From enterprises to individuals, AI enhances every experience with intelligence and foresight

Shared Approach

Together, these outcomes shifted AI exploration from speculative, feature‑led ideas to a more grounded, system‑level experience-reasoning approach that supports long‑term AI maturity.

Why it Matters

Most AI projects fail not because the technology does not work, but because the organization wasn’t ready to govern it. Features get built before behaviors are defined. Trust gets broken before anyone agrees on what trust is supposed to look like. This work was an attempt to get ahead of that, to give a large enterprise the experience, vocabulary, and reasoning tools it needed before construction began.

That’s the role a principal designer can play at the frontier of AI: not just designing what AI looks like, but shaping how an organization thinks about what AI should be.

Reflections & What I’d do differently

What I learned

Working upstream of any deliverable is uncomfortable in ways that shipped product work is not — there’s no before/after, no usability test result to point to, no conversion metric. The validation is slower and harder to see.

What I learned is that the output of this kind of work isn’t an artifact, but a change in how a room full of smart people think about a problem. That’s harder to measure, but it’s real.

What I would push further

Two things I’d do differently. First, I would introduce a scoring framework earlier — not to make prioritization mechanical, but to make trade-offs explicit. When teams can see that Concept A scores high on user control but low on governance scalability, the conversation gets more productive faster.

Second, I would involve operational stakeholders sooner. The most important trust and constraint signals in enterprise AI do not come from design reviews; they come from the people who have to explain system behavior to customers when something goes wrong. Getting them in the room earlier would have sharpened the scenarios considerably.

This is the kind of work that’s hard to show and easy to underestimate. If you want to talk through the decisions behind it, or what I would do differently next time, I would welcome that conversation.