At Verizon, I watched something that stays with me.

Talented designers — people who cared deeply about their craft — were genuinely afraid that AI would erase their roles. Some resisted engaging with AI tools entirely. Others adopted them cautiously, waiting to see what would happen. The anxiety was real. It shaped how people showed up to work every day.

Then the organization restructured. I was among those let go — the person who had built the AI design systems, pushed out by the very forces I had been helping the team navigate. The irony was not lost on me.

But the lesson was clear, and it applies far beyond one company: the designers who thrived were not the ones who resisted AI or the ones who feared it. They were the ones who understood that the job had moved.

The Conversation Worth Having

There is a version of “AI will replace designers” worth discussing. And a version that is not.

The version that is not worth your time: Will AI generate UI faster than a human? Yes. Will AI write production-ready component code? Yes. Will AI synthesize research, draft copy, and produce design variations at a scale no human can match? Yes. These are facts. Arguing against them wastes oxygen.

The version worth your full attention: What does it mean to design well in a world where all of that is true?

I have been living inside that question for years. First at Verizon, building AI systems for a 42-person design organization. Now thinking about what comes next as AI moves from a tool designers use to a layer that designs alongside them.

Here is what I have come to believe.

The designer’s job did not disappear. It moved upstream.

Upstream Is Where the Decisions Live

Picture a river. Downstream, the water moves fast. Things get built, shipped, polished. Upstream, the current is slower — but this is where the river’s direction gets set. Change the course up here, and everything downstream follows.

In the old model, design was an execution discipline. You received a brief. Made artifacts. Handed them off. The value was in the craft — translating requirements into interfaces that were usable, coherent, visually resolved.

Craft still matters. But craft is no longer the primary scarcity.

What is scarce now — and increasingly so — is the ability to define the problem before anyone starts making things. To determine what kind of AI involvement is appropriate for a given interaction. To decide what should be automated, what should remain in human hands, and where the handoff between them should live. To design the rules that govern how an AI system behaves before a single interface gets built.

This is upstream work. It happens before Figma opens. It determines the quality of everything that comes after.

THE UPSTREAM SHIFT

THE UPSTREAM SHIFT

─────────────────────────────────────────

OLD SCARCITY: Craft execution

(translating briefs → interfaces)

NEW SCARCITY: Problem definition

(deciding what to build and why)

─────────────────────────────────────────

Downstream = Making things fast

Upstream = Making the right things

─────────────────────────────────────────

Shift 1: From Making Components to Writing Constitutions

In a generative UI world, the designer’s output is increasingly a set of rules — not a set of screens.

What can the AI generate? What can it not? What components are in scope? What combinations are prohibited? What does “consistent with the brand” mean in terms a machine can read?

This is design systems work at a different altitude. Not building a button library. Writing the constitution that governs how interfaces get assembled.

Think of it like city planning versus architecture. The architect designs one building. The city planner writes the zoning laws that determine what every building in the district can become. Generative AI needs city planners. It has plenty of architects already.

The designer who can write those rules fluently is the designer whose work stays relevant as AI takes over the execution layer.

Shift 2: From Solving User Problems to Solving Human-AI Problems

The interaction design problems that matter most right now are not “how does the user complete this task?”

They are questions that did not exist five years ago:

• How much should the AI do on its own, and when should it ask?

• How does the user understand what the AI is about to do — before it does it?

• What happens when the AI is wrong?

These require new frameworks. The Autonomy Dial. Intent Preview. Explainable Rationale. Confidence Signals. Action Audit. Escalation Pathway. I have written about each in detail earlier in this series. They are not polish on existing interaction patterns. They are genuinely new design problems — and they are now central to almost every product being built.

The designer who walks into a product review and says “this interaction is missing an escalation pathway, and here is what happens to user trust when that is absent” — that designer is operating at a level AI cannot replicate. Because the judgment required comes from understanding human psychology, organizational context, and product strategy simultaneously.

No single model holds all three. A designer can.

Shift 3: From Individual Contributor to Systems Conductor

The most significant shift is not in what designers make. It is in how they work.

Old model: one designer, one project, moving through phases in sequence. Emerging model: a designer who orchestrates multiple AI agents, synthesizes their outputs, applies judgment at the decision points that matter, and produces work at a scale that would have required a team of five.

This is the Conductor model. The designer is not playing every instrument. They are directing the ensemble.

THE CONDUCTOR MODEL

THE CONDUCTOR MODEL

─────────────────────────────────────────

DECOMPOSE Break the problem into

delegatable components

DELEGATE Assign each to the right

agent or human

EVALUATE Judge what comes back —

is it ready or does it

need human correction?

SYNTHESIZE Combine outputs into

coherent direction

─────────────────────────────────────────

This requires a fundamentally different skill than execution craft. The ability to decompose a problem into components that can be delegated. To evaluate quality of what comes back. To know when AI output needs human correction versus when it is ready to use.

This is also why I built Ren — a design thinking partner that does not just produce artifacts but participates in the thinking itself. Facilitating team conversations. Managing participation dynamics. Challenging assumptions before anyone opens Figma. Ren exists because the Conductor model is not just about directing agents that produce deliverables. It is about having AI participate at the level where direction gets set.

The designers who thrive in this model are not the ones who resist AI. Not the ones who hand everything to it. They are the ones who have developed a clear sense of what judgment is for — what decisions require a human, and why.

16 Interviews Revealed What Was Actually Broken

When I ran the interviews at Verizon — 16 designers, one hour each, mapping friction points — I expected complaints about tools.

What I found was more interesting. And more uncomfortable.

The friction was not in the execution layer. Designers could make things. The friction was in everything surrounding the making: finding context that should have been accessible, catching edge cases that should have been visible earlier, doing strategic thinking that kept getting squeezed out by the pressure to produce artifacts faster.

The AI systems I built — Master Brain for knowledge, Sally for validation, Justin for edge cases, WDS for strategic scaffolding — were not tools to make designers faster at their existing jobs. They were structural interventions designed to restore the parts of the design job that had been systematically squeezed out.

The result was not designers doing the same work faster. It was designers doing different work. More strategic. More considered. More defensible. Execution got faster as a side effect. The real change was in what the execution served.

This is what moving upstream looks like in practice. Not abandoning the craft. Recovering the thinking that the craft is supposed to express.

The Five Skills That Separate Upstream Designers

If the job moves upstream, the skills that matter are upstream skills.

UPSTREAM SKILL STACK

UPSTREAM SKILL STACK

─────────────────────────────────────────

1\. SYSTEMS THINKING

See how components interact. 

How changes propagate. How a decision

at one level affects everything

built on top of it. Always valuable.

Now essential.


2\. FRICTION DIAGNOSIS

Look at a workflow — human, org,

human-AI — and find the structural

failures. Not surface symptoms.

Root causes. Most designers have

never been taught to do this

systematically.


3\. AGENT DESIGN

Define a job for an AI agent with

enough specificity that it can be

done reliably. Input format. Process.

Output format. These are design

skills applied to a new artifact.

Harder than it looks.


4\. JUDGMENT CALIBRATION

Know what to delegate. Know what

to hold. Requires a clear model of

where AI fails predictably vs.

where it fails by surprise. Requires

having made enough mistakes to

feel the boundaries.


5\. CROSS-DISCIPLINE COMMUNICATION

Translate design thinking into terms

that matter in product strategy,

engineering architecture, and

leadership rooms. A multiplier

on everything else.

─────────────────────────────────────────

The Portfolio Nobody Knows How to Make Yet

The hardest practical implication of all this is the portfolio question.

If the job moves upstream, the portfolio has to show upstream thinking. Not just finished screens.

Concretely: document the diagnosis that preceded the design. Show the constraints you defined before the interface was built. Describe the agent architecture you designed and why you made the structural choices you made. Explain not just what you built but what framework you used to decide what to build.

This is a harder portfolio to make than a gallery of beautiful screens. It requires writing. Articulating reasoning that usually stays implicit. Being willing to show the messy process that led to the clean outcome.

It is also a much harder portfolio to fake.

Anyone can show polished UI. Not everyone can explain the systems thinking that made it the right UI.

The Title That Actually Describes the Work

I have started describing my work differently.

Not “UX designer.” Not “product designer.” The title I find most accurate is systems architect for human-AI collaboration.

What this means in practice: I design the structures within which humans and AI work together effectively. I map friction in existing workflows. I build knowledge infrastructure that gives AI systems useful context. I design agents that fill structural roles. I think about how the handoff between human judgment and AI execution should work.

This is design work. But it is design at a level of abstraction that the old titles do not capture.

Not everyone needs this title. But the question it implies — what system am I actually designing? — is one every designer should ask.

Because the answer has changed.

The interface is no longer the system. The interface is the visible surface of a system that includes AI agents, knowledge infrastructure, trust architecture, escalation pathways, and human judgment at the critical decision points.

THE REAL SYSTEM

THE REAL SYSTEM
─────────────────────────────────────────
        ┌─────────────────────┐
        │    The Interface     │  ← What users see
        └──────────┬──────────┘
                   │
   ┌───────────────┼───────────────┐
   │               │               │
┌──▼──┐    ┌──────▼──────┐   ┌───▼────┐
│ AI  │    │  Knowledge  │   │ Trust  │
│Agents│    │Infrastructure│   │  Arch  │
└──┬──┘    └──────┬──────┘   └───┬────┘
   │               │               │
   └───────────────┼───────────────┘
                   │
        ┌──────────▼──────────┐
        │   Human Judgment    │  ← What holds
        │  at Decision Points │     it together
        └─────────────────────┘
─────────────────────────────────────────

Designing that system well is the job. The pixels are just what the job produces.

A Direct Message to Designers Early in Their Careers

The future is not hostile to designers. It is hostile to a specific kind of designer.

The designer who is primarily valuable for execution speed — moving quickly in Figma, producing volumes of UI — will feel the pressure most. Not because execution does not matter. Because the execution layer is where AI has the clearest leverage.

The designer who is primarily valuable for judgment — knowing what to build, why, and for whom — will find that this moment expands what they can do. The execution that used to take a week now takes a day. The thinking that used to get squeezed out now has room to breathe.

The path from one kind of designer to the other is not mysterious. It is the same path it has always been. Deeper understanding of people. Systems. The problems worth solving.

The tools change. The fundamental discipline does not.

Move upstream. The work is there.

This is part of an ongoing series on AI-native design practice.

Previous pieces:

#010: Users Don’t Stop Trusting AI Suddenly. They Stop Trusting It the Same Six Ways, Every Time.

#007: Your Company Knows More Than It Thinks. It Just Cannot Access Any of It.

#011: The AI That Made My Team Argue More — and Decide Better.

Next: #013: AI Can Do the Job. But Should It? The Line Your Product Is Drawing Without Asking. →

————————

P.S. — Two years ago I would have told you the designer’s most important skill is taste. The ability to look at an interface and know what is wrong before you can articulate why. I still believe taste matters. But I have watched taste without systems thinking produce beautiful products that solve the wrong problem. And I have watched systems thinking without taste produce ugly products that transform organizations. If I had to choose one for the next decade, I would choose the one that changes what gets built — not just how it looks. Taste makes things right. Systems thinking makes the right things.

#UXDesign #AIDesign #DesignLeadership #FutureOfDesign #ProductDesign #SystemsThinking #CareerDevelopment

This article builds on two previous ones. You don’t need to read them first — this piece is self-contained — but if you want to go deeper:

• #009: “Every AI Product Makes a Hidden Decision About Autonomy. Almost None Make It Deliberately.” — Defines the Autonomy Dial’s four positions and design principles.

• #013: “AI Can Do the Job. But Should It? The Line Your Product Is Drawing Without Asking.” — Introduces the Autonomy Map diagnostic framework.

You Already Live Inside This Pattern

Netflix

Your Netflix homepage looks nothing like your friend’s.

Same movie. Different experience. You see the romance scene in the thumbnail. They see the action. Netflix has dozens of thumbnails ready for every title. For each one, it has already decided: which image will make you click?

80% of what you watch comes through recommendations. You choose only 20%.

You think you’re deciding. Netflix is deciding.

Amazon

Open Amazon right now. Every product on your homepage exists for you alone.

You’ve used “Buy Again.” Remember? Last month you ordered dog food. One click to reorder. Before that: search, scroll, find the right one, add to cart, confirm. Now: one click.

35% of Amazon’s revenue comes from this recommendation engine. It processes 150 billion data points a day. Predicting what you’ll buy next.

Spotify

Monday morning. You open Discover Weekly. Thirty songs. None of them songs you’ve heard before. All of them, somehow, exactly what you wanted to hear.

You listen to the first three and think: How did they know?

Spotify doesn’t have one taste profile for you. It has several. The music you listen to during a workout is different from the music you play on Sunday morning with coffee. So you get multiple Mixes — each one tuned to a different version of you.

The more you use it, the more accurate it gets.

This Pattern Has a Name

Three services. One shared structure.

What they’ve delegated for you:

Netflix  → Recommending what to watch
Amazon   → Reordering things you've bought before
Spotify  → Picking songs you don't know yet

What you still decide:

Netflix → Whether you actually watch it

Amazon → Whether you actually buy it

Spotify → Whether you keep listening or skip

The line between delegated and owned — that’s the Autonomy Map.

But even within the delegated side, there are levels:

Netflix → Changes your homepage on its own (high autonomy)

Amazon → Shows you “Buy Again,” but you press it (medium)

Spotify → Adds unfamiliar songs, but skipping is free (medium)

This spectrum — how much you’ve delegated — is the Autonomy Dial.

Map and Dial Are Not the Same Thing

AUTONOMY MAP vs. AUTONOMY DIAL

AUTONOMY MAP vs. AUTONOMY DIAL
─────────────────────────────────────────

  Delegate                    Own

  Information Gathering       Final Judgment
  - Search & Comparison       - Values-based Decisions
  - Pattern Learning          - Price Confirmation
                              - Send / Publish

  ← Autonomy Map →

Autonomy Map: where you draw the line. What gets delegated. What stays yours.

Autonomy Dial: once something is delegated, how autonomous should it be? Four positions:

Suggest      →  Confirm      →  Notify       →  Auto
─────────────────────────────────────────────────────
"Ready to      "Ready to      "I did this"    Done.
go with        confirm         (undo if       System handles
this?"         this?"          needed)        it completely.

You delegate the moment you use a tool. Open Google Maps? You’ve already delegated route calculation. That’s why you use it.

A map without a dial is pointless. A dial without a map is just permission requests all day long.

Naming Things Makes Invisible Patterns Visible

Netflix, Spotify, Amazon — they’re already doing this at scale. Spotify understands multiple versions of your taste. Netflix personalizes down to the thumbnail. Amazon generates 35% of revenue from its recommendation engine. Robo-advisors like Betterment run your entire portfolio on Auto.

Map and Dial aren’t inventions. They’re a language for patterns that already exist.

But here’s why naming matters. Once you have a language, you start seeing things that don’t exist yet.

The Dial Has a Ceiling. It Depends on the Domain.

Netflix released “Play Something” (later renamed “Surprise Me”) in 2021. AI picks the show. Starts playing. No input from you.

Usage dropped so fast they killed it two years later.

Why? In entertainment, choosing what to watch is part of the experience. Delegate the choosing and you break what makes it valuable.

But Amazon’s Smart Reorder works. Your detergent runs low, gets reordered automatically. No one complains. Choosing detergent isn’t an experience. It’s a chore.

DIAL CEILINGS BY DOMAIN

DIAL CEILINGS BY DOMAIN

─────────────────────────────────────────

Routine replenishment: Ceiling = Auto

Choosing doesn’t matter.

Why Amazon’s Smart Reorder works.


Entertainment: Ceiling = Better Suggest

Choosing IS the experience.

Why “Surprise Me” failed.

AI’s job: surface the right options first.


Finance (routine): Ceiling = Auto

Auto-investing, auto-budgeting,

auto-categorizing expenses.


Finance (high-stakes): Ceiling = Confirm

New investment, large transfer, loan.

Notice: finance doesn’t have one ceiling. Monthly auto-investments run on Auto. But putting $10,000 into a new fund? You decide.

Same category. Different tasks. Different dial settings.

This connects to the four dimensions from earlier essays: reversibility, familiarity, stakes, context. The dial ceiling is their combination.

Implicit Dial and Explicit Dial Are Not the Same

Netflix, Spotify, Amazon recommendations get better automatically. You set nothing. Just use them. This is Implicit Dial — it rises through observation.

Amazon Auto Buy is different. You set it. “Auto-purchase this if the price drops below $15.” Conscious. Deliberate. This is Explicit Dial — you dial it yourself.

IMPLICIT DIAL (rises through behavior):

IMPLICIT DIAL (rises through behavior):
─────────────────────────────────────────
Netflix:        Recommendation accuracy improves as you watch
Spotify:        Discover Weekly gets better every week
Robo-advisors:  Portfolio rebalancing optimizes through learning

EXPLICIT DIAL (you set it deliberately):

EXPLICIT DIAL (you set it deliberately):

─────────────────────────────────────────

Amazon Auto Buy: “Auto-purchase below $15”

Tesla FSD: You choose Sloth or Mad Max mode

Google Personal Allow/block Gmail access per app

Intelligence:

Which is right? You need both. The rule is simple:

Low-risk, easily reversible  → Implicit Dial is fine
  Recommendations, playlists, search quality.
  Wrong? Just skip or click back.

High-risk, hard to undo      → Explicit Dial required
  Purchases, sends, bookings.
  Wrong? Too late.

Cross-Service Learning Doesn’t Exist Yet

Spotify knows your music taste. Amazon knows your shopping patterns. Netflix knows your entertainment preferences.

No single system knows you.

Monday morning you listen to jazz on Spotify. Order premium coffee beans on Amazon. Watch a cooking show on Netflix. One thread — a relaxed morning ritual. But no system sees that thread. Each service optimizes only within its own silo.

This is where the housekeeper example becomes instructive.

A real housekeeper sees your entire life. The refrigerator. The pantry. The family’s preferences. Next week’s schedule. She doesn’t optimize one category in isolation. She learns across your whole home.

That’s not Spotify. That’s not Amazon. That’s something else entirely.

Imagine You Hire a Housekeeper

Day one.

“Where’s the sugar? Which salt brand? Does your daughter drink milk?”

Everything, you have to tell her. You hired her to do the shopping — that’s delegated. But what to buy — still all your call.

Month 1: The Learning Starts

Month 1: The Learning Starts

MAP SHIFTING:

Delegate → onion brand, yogurt type, restock timing

Own → this week’s meals, special ingredients


DIAL:

Onions → Suggest (”Sweet onion again?”)

Yogurt → Suggest (”The usual three kinds?”)

Month 3: She’s Learning the Household

She’s noticed things you never said out loud.

YOUR WIFE:   Trader Joe's honey yogurt. This one only.
YOU:         Non-fat Greek yogurt. Brand flexible.
YOUR KID:    Dairy-free yogurt. Any brand, any flavor.

THE RIBEYES: This supermarket has 2-3 ribeyes,
             but only one specific package is right for you.
             Others won't work.

ONIONS:      Sweet is your base. If they're out,
             yellow or white is fine.
             Purple onions? Never.

The dial is rising:

Yogurt (3 kinds) → Confirm (”The usual three, yes?”)

Ribeyes → Confirm (”Found them. Buy?”)

Month 6: Substitution Modes Emerge

This is where it gets interesting. As the dial rises, something new appears: rules for how to substitute.

Not levels. Modes. Not better-or-worse. Different. For different items, the AI needs different instructions.

Mode: Flexible

Mode: Flexible

FLEXIBLE MODE
─────────────────────────────────────────
Onions → Sweet is standard.
         If out, yellow or white works.
         Purple? No.

Your yogurt → Non-fat Greek.
              Brand doesn't matter much.
              Any Greek yogurt of that type works.

→ AI substitutes and notifies.
→ "Sweet onions were out, so I got yellow."

Mode: Exact

EXACT MODE
─────────────────────────────────────────
Your wife's yogurt → Trader Joe's honey yogurt.
                     This product only.
                     Not other flavors. Not other brands.
                     Unless: large size is out,
                     then 6 small ones is fine.

Ribeyes → This specific package.
          No other ribeyes. None.
          If they're not there, don't buy.

Vitamins → This brand only.

→ AI doesn't substitute.
→ If unavailable, she doesn't buy it.
→ Only pre-approved substitutions (like size) execute.

Same mode, different levels of flexibility. Your wife’s yogurt: “brand and flavor absolute, size flexible.” Ribeyes: “zero compromise.” AI learns these micro-differences over time.

Mode: Exploring

XPLORING MODE
─────────────────────────────────────────
Protein powder → Whey is standard.
                 But you're actively testing right now.
                 Last week: Double Chocolate.
                 This week: Vanilla.
                 Next week: trying something else.

Good:      Vanilla (doesn't interfere with smoothie taste)
Bad:       Strawberry, Caramel (too sweet)
Curious:   Other brands of the same type

→ AI logs feedback chronologically.
→ "Vanilla was popular last time.
    Want to try the same brand's Unflavored?"
→ Not locked to one. Can rotate through options.

Exploring mode is a process in motion. You’re actively testing, giving feedback, AI is learning. Eventually, it might become Flexible (”rotate these three”) or Exact (”this one wins”).

Modes aren’t static. They transition.

Mode: Surprise

SURPRISE MODE
─────────────────────────────────────────
Japanese snacks → You like this category,
                  so bring me things I don't know yet.
                  Crunchy. Not too sweet.
                  Within that range, anything works.

→ AI picks unknown options within the criteria.
→ Logs your reaction: "this one hit," "this one missed."

But not everything gets Surprise:

Japanese snacks    → Surprise me  ✓
Vitamins           → Surprise me  ✗
Protein powders    → Exploring (new flavors), not pure surprise

Surprise is opt-in per category. When something surprising bombs, you might want less surprise. Or more. That’s another dial — the autonomy of the surprise itself.

Modes are fluid. They evolve with you:

MODE TRANSITIONS

MODE TRANSITIONS
─────────────────────────────────────────
Exploring → found a winner      → Exact ("this one finally")
Exploring → found several       → Flexible ("these three")
Exact     → bored               → Exploring ("let's try new things")
Surprise  → found a favorite    → Exact ("more of this")
Flexible  → tastes changed      → Exploring ("what am I in the mood for now?")

Taste isn’t fixed. It shifts with seasons, with mood, with energy, with growth. AI learns not just your current preference. It learns how your preferences evolve.

Year 1: The Complete System

Your refrigerator is always stocked. You’re doing nothing.

When something runs out, AI follows the mode. New items or price shifts trigger temporary confirmation. Surprises appear a few times a month. New things on the shelf.

One month you’re craving acid. Sour things. AI detects this shift. Without you saying anything, the Surprise category tilts toward sourness. You might not even notice. The shelf is changing anyway.

This is what “nurturing” means.

Does the Dial Rise on Its Own, or Do You Raise It?

Both. Always both.

Implicit Dial rises by itself. Netflix, Spotify, Amazon recommendations improve with use. You set nothing. Your behavior turns the dial.

Explicit Dial — you set it. Amazon Auto Buy: “$15 price cap on this item.” Tesla FSD modes. Google Personal Intelligence permissions. You choose the setting.

Risk determines which:

WHICH DIAL TYPE TO USE

WHICH DIAL TYPE TO USE

─────────────────────────────────────────

Low-risk, reversible → Implicit Dial

Recommendations, music, thumbnails.

Mistake? Skip and move on.

High-risk, irreversible → Explicit Dial

Purchases, sends, confirmations.

Mistake? It stays.

With a housekeeper, both happen at once:

Implicit:
  She sees you pick sweet onions every week.
  Next week, she brings sweet onions without being asked.

Explicit:
  You say: "Ribeyes. Only this specific package.
  Nothing else. Got it?"
  That's a clear instruction.

Observation builds one kind of trust. Direct instruction builds another. Together, they deepen the relationship.

The Full Architecture

THE AUTONOMY SYSTEM — FOUR LAYERS

THE AUTONOMY SYSTEM — FOUR LAYERS
═════════════════════════════════════════

① AUTONOMY MAP (where to draw the line)
   "What gets delegated, what stays yours"
   → Baseline exists the moment you use the tool
   → Shifts over time as Own → Delegate

② AUTONOMY DIAL (how far within delegated)
   Range: Suggest → Confirm → Notify → Auto
   → Implicit (rises through use)
   → Explicit (you set it)
   → Drops temporarily in exceptions

③ SUBSTITUTION MODES (how to handle exceptions)
   For items in Delegate, what patterns govern?
   → Flexible / Exact / Exploring / Surprise
   → Modes shift over time

④ TRUST (what moves all three over time)
   → Successful experiences → wider Map + higher Dial
   → Failed experiences → narrower Map / lower Dial
   → Unexpected situations → temporary Dial freeze

─────────────────────────────────────────
Map  = what
Dial = how far (auto or explicit)
Mode = how to handle each item
Trust = when and how fast

How the Biggest Tech Companies Are Thinking About This Right Now

Google — Building Both Map and Dial

Google Maps:

After 500 commutes, the map app you see today is different from day one. Open it and it predicts: “Twenty minutes to work” before you ask. That’s Implicit Dial. It reroutes around traffic automatically. But 500 commutes in, it still doesn’t auto-start toward your office. It suggests. You confirm. The dial has room to rise.

Gemini Personal Intelligence (2026):

Google is connecting Gemini to Gmail, Photos, YouTube, search history. The design principle is clear: default everything off. Users opt in per app. That’s Explicit Dial. Gmail allowed, Photos blocked — your choice.

Gemini’s Memory function learns your preferences from conversations and applies them next time. That’s Implicit Dial. February 2026, it rolled out free for everyone.

Apple — Using Privacy to Expand the Map

Apple Intelligence runs roughly 3 billion parameters directly on your phone. Most processing stays on-device. January 2026, Apple announced its Gemini partnership — Google’s model runs on Apple’s Private Cloud Compute servers. “Intelligence from Google, data inside Apple’s boundary.”

Privacy design is the engine that expands the map. If data never leaves your device, the psychological resistance to delegation drops. Late 2026, Agentic Siri launches — reads your emails for flight info, auto-books Uber. That’s when the dial moves.

Samsung — Context-Aware Home Appliances

CES 2026: Bespoke AI Jet Bot Steam Ultra. The robot vacuum uses AI Object Recognition. Sees people, cats, dogs, cables. AI Liquid Recognition detects spills. Then it decides: clean or avoid? Based on your rules. That’s Explicit Dial. Autonomous execution, but you wrote the rules.

Kitchen AI Vision, powered by Gemini, looks inside the fridge and suggests recipes — a real implementation of “what’s actually executable right now.”

Microsoft — The Organization Draws the Map, Not the User

Copilot Control System. Here’s the twist: the organization’s IT admin draws the Autonomy Map, not the individual user. What data can Copilot access? What actions can it execute? Set at tenant and user-group level. The individual calibrates the dial within those bounds.

Two Maps layered: organizational, then personal.

Amazon Alexa+ — Auto Buy and Context Memory

Auto Buy: the clearest implementation of Explicit Dial. “Alexa, buy this when the price drops below 100.” Deliberate. One request per item. Max 200 active. Cancel within 24 hours.

Context Memory: conversations layer up. You say “vegetarian this week” on Monday. Thursday dinner suggestions shift. Map expands. That’s Implicit.

Tesla Full Self-Driving (FSD)— Dial by Scenario and Individual

FSD adjusts per-scenario. Low-stakes parking lot: dial higher. High-stakes pedestrian crossing: dial lower. You pick driving style — Sloth vs. Mad Max. That’s Explicit Dial.

The novel part: Safety Score. Individual scoring on hard braking frequency, distance maintenance, 30-day rolling average. It doesn’t yet alter FSD autonomy directly. But the infrastructure is there. This could be the foundation for a dial that rises with demonstrated trust.

The Companies, Mapped

COMPANY AUTONOMY PATTERNS

COMPANY AUTONOMY PATTERNS
═════════════════════════════════════════

Google:     User sets the Map (Explicit)
            Memory learns from conversations (Implicit)

Apple:      Privacy expands the Map safely
            Agentic Siri expands Dial in late 2026

Samsung:    Users set the rules (Explicit)
            Gemini strengthens kitchen AI Vision

Microsoft:  Organization sets the Map
            Users tune the Dial within those bounds

Amazon:     Auto Buy sets Dial explicitly (Explicit)
            Context memory widens Map (Implicit)

Tesla:      Dial adjusts by risk (scenario-based)
            Safety Score tracks individual trust
            (foundation only)

Common design opportunity across all:

1. Incremental Map expansion — as you use the tool more, Own shifts to Delegate

2. Trust-linked Dial movement — successful interactions raise the dial; failures lower it

3. Substitution Modes — exceptions aren’t all handled the same; each item has its own rules

Three Things AI Product Teams Miss

1. Setting Dial Without a Map

Most teams talk about “AI autonomy” but never ask “autonomy to do what?“ You can optimize the dial brilliantly and still have AI deciding things the user wanted to own. No map means you build into the wrong moments.

2. Confusing Implicit and Explicit Dial

Low-risk and reversible — recommendations — work with Implicit. High-risk and irreversible — purchases, sends — need Explicit. No distinction means either “it did that without asking” or “it keeps asking about things I don’t care about.”

3. The Dial Doesn’t Reset on Exception

Stockouts. Price changes. Unexpected situations. The AI should drop to confirmation mode temporarily. Without Substitution Modes designed in, exceptions get handled with the same autonomy as normal moments. Trust breaks.

If You’re Designing an AI Product

Three questions for your team.

Question 1: “What does the user want to own?”

That’s the Own column. Don’t put AI there.

Question 2: “Should this Dial rise implicitly or does the user set it explicitly?”

Judge by risk and reversibility.

Question 3: “When trust accumulates, how does the Dial respond?”

Design the success-to-dial-rise mechanism. Also design the failure-to-dial-drop mechanism.

The Through-Line

THE SYSTEM AT A GLANCE

THE SYSTEM AT A GLANCE
═════════════════════════════════════════

Autonomy Map       = where to draw the line
Autonomy Dial      = how far into Delegate
  → Implicit (observed behavior)
  → Explicit (user-set)
Substitution Modes = exception handling per item
Trust              = the engine that moves all three

─────────────────────────────────────────
Don't run Dial without Map.
Don't confuse Implicit and Explicit.
Don't let exceptions execute with full autonomy.
Don't move anything without earned trust.
And remember: preferences change.

One year later, your refrigerator is always stocked. You’re doing nothing.

But if you see an unfamiliar brand on the shelf — that’s the AI. If you don’t like it, say so. The rule gets smarter.

That’s the relationship between humans and AI. Not command. Not obedience. Nurturing.

P.S. When I started building this framework, I thought trust was binary. You either trust the system or you don’t. Writing the housekeeper example changed my mind. Trust is granular. You trust one person with your onions but not your ribeyes. With your playlists but not your investments. That granularity is the entire design space most teams are ignoring. I keep finding more layers the longer I look.

Sources

Netflix:

• How Netflix Uses Machine Learning to Create Perfect Recommendations

• Netflix Personalization, Recommendations & Search Workshop 2025

• Netflix Foundation Model for Personalized Recommendation

Amazon:

• Amazon Hyper Personalization: E-Commerce Revolution

• AI Product Recommendations: From Amazon’s 35% Revenue Model

• About Auto Buy — Amazon Customer Service

• Amazon’s Alexa+ Revolution (Feb 2026)

Spotify:

• Spotify Lets You Steer the Algorithm (Dec 2025)

• How the Spotify Algorithm Works in 2025

• How Does Spotify’s Algorithm Work? Complete 2026 Breakdown

Google:

• Google Personal Intelligence — connecting Gemini to Google apps

• Gemini Personal Intelligence now free for all US users (March 2026)

• Gemini Memory — past chats personalization (Feb 2026)

• Google Maps 101: How AI helps predict traffic and determine routes

Apple:

• Apple Intelligence

• Apple confirms Gemini-powered Siri will use Private Cloud Compute (Jan 2026)

Samsung:

• CES 2026: Samsung to Unveil the Next Stage of AI Appliances

• Samsung AI Vision built with Google Gemini

Microsoft:

• Copilot Control System Management Controls

Tesla:

• Tesla FSD Safety Report

• Tesla Safety Score Guide: 2025 Update

• Tesla FSD v14: What’s New

Related Articles

• Autonomy Map details in #013: AI Can Do the Job. But Should It? — Introduces the Autonomy Map: a diagnostic for separating jobs worth delegating from decisions worth owning. The ski slope example. Why the Map must come before the Dial.

• Autonomy Dial’s four positions in #009: Every AI Product Makes a Hidden Decision About Autonomy. — Defines the four positions of the Autonomy Dial (Suggest, Confirm, Notify, Auto) and the four dimensions for calibrating it (reversibility, familiarity, stakes, context).

This piece connects those two and adds the new dimensions: Implicit vs. Explicit Dial and Substitution Modes.

This article connects the two and adds three new dimensions: Implicit vs. Explicit Dial, Dial ceilings by domain, and Substitution Modes.

#AIDesign #UXDesign #AutonomyMap #AutonomyDial #AgenticUX #IntentFirst #HumanAI

Eighth floor. A warm, dry conference room in winter. Three designers and I.

We were discussing a project that had surfaced several problems in the interviews — the HiPPO effect (the Highest Paid Person’s Opinion overrides data-driven insights, objective evidence, and the collective expertise of the team), misaligned assumptions, and strategic thinking getting squeezed out by delivery pressure—the usual.

By then, I had already built the pipeline agents. Sally for UX validation. Justin for edge case detection. WDS for end-to-end strategic design work. Designers could upload strategy documents and business requirements, and the system would generate user flows, accessibility audits, edge case matrices — fast and structured.

Too fast.

For solo work, it was excellent. A designer working alone could race from brief to prototype-ready spec in a fraction of the time. But design organizations do not work solo. Teams need to discuss. Debate. Align with PMs. Challenge each other’s assumptions. Decide together which direction to take.

The AI outpaced the human process. It produced deliverables before the team had agreed on what to build. Stakeholders felt bypassed. Assumptions stayed untested. Alignment debt piled up.

Sitting in that room, I realized: the pipeline agents were blind to the moment that matters most.

The Best Design Happens in Arguments, Not Pipelines

Here is what none of my pipeline agents could handle:

A team sitting in a room trying to figure out if they are solving the right problem.

The messy part. The part where someone says “wait, are we sure about this direction?” The part where the quietest person has the insight that changes everything. The part where two strong opinions need resolution — without someone just giving up.

Design does not happen in a pipeline. The best design happens in conversations. In friction between perspectives. In the pressure of pushback. In the synthesis that emerges when a room of people work through something together.

No AI tool I had built could participate in that.

Meanwhile, Verizon had already rolled out Gemini and NotebookLM for months. People used them here and there. Trial and error. Useful moments happened. Day-to-day work did not change.

Most other AI tools were blocked for security. So I went deep on what we had. Pushed Gemini hard. Tested workflows constantly. Learned by doing. Shared practical patterns with the team.

Then I built something different.

I built Ren.

Ren Is a Thinking Partner, Not a Production Tool

Ren is an AI design thinking partner built as a Google Gemini Gem.

Not a “one prompt and done” machine. A system designed to fit real team process.

It works across multiple collaboration patterns — and switches between them as the project moves:

COLLABORATION MODES

COLLABORATION MODES

───────────────────────────────────────────

Human ↔ AI Solo thinking partner

Human ↔ Human AI silent unless asked

Human + AI + Humans AI in the room with the team

Human+AI + Human+AI Multiple AI-supported perspectives

Mixed teams Some use AI, some don’t

───────────────────────────────────────────

This flexibility is what separates Ren from every agent I built before.

Human ↔ AI: Your senior peer who won’t let you off easy

Working alone with Ren is not like giving orders. It is like thinking with a colleague who has no patience for weak reasoning.

It challenges your assumptions before letting you run with them. Reframes your problem before you jump to solutions. At Level 3 — “Spar” mode — it pushes back the way a senior peer would. Directly. Specifically. Without softening the challenge to protect your feelings.

Ten specialist facets surface contextually — Researcher, Behavioral Scientist, Strategist, Interaction Designer, UX Writer, and more. Each contributes 2-4 lines of specific, actionable thinking. Not a lecture. Not a framework dump. A perspective.

Twenty-seven frameworks work invisibly in the background — Cialdini, Kahneman, Fogg, Nielsen, JTBD, SIT. You get the insight. Never the theory name. Unless you are at Level 3 and want the citation.

Human ↔ Human: The facilitation engine that does not exist anywhere else

This is where Ren breaks new ground.

Three collaboration modes. Each one changes how the AI behaves in the room.

Facilitate — Ren runs the session. Controls pacing. Ensures everyone participates. Captures ideas. Manages convergence. Detects and intervenes on groupthink. Catches HiPPO bias — when the highest-paid person’s opinion quietly overrides everyone else. Flags dominant voices. Eight structured exercises built in: Crazy 8s, Design Studio, 6-3-5 Brainwriting, Challenge Auction, Rose/Thorn/Bud, and more.

Participate — Ren joins as a team member. Contributes ideas alongside humans. Builds on others’ thinking. Targets roughly 25% contribution. Present enough to add value. Restrained enough not to dominate.

Stepback — Ren goes silent. Completely silent. Not helpful silence with occasional interjections. Not “I noticed something interesting.” Silence. It observes. Takes notes. Provides synthesis only when asked. For sensitive discussions where AI influence would be counterproductive.

In practice, Stepback means the team meets in Google Meet without Ren present. Afterward, someone pastes the transcript into the Gem. Ren returns a synthesis from the outside — free from the social dynamics that shaped the room.

Across all three modes, Ren has pace control. It can stay process-aligned and incremental. Or switch to high-speed sprint behavior when the team explicitly wants velocity.

Speed Was Never the Real Bottleneck

Every AI tool in the design space right now optimizes for the same thing. Faster output.

Faster research synthesis. Faster wireframing. Faster documentation. The value proposition is always speed. The architecture is always the same pipeline. Input in. Artifact out.

That speed is genuinely useful. But speed was not our main bottleneck.

Think of it like a factory floor. You can make the assembly line twice as fast. But if the blueprint is wrong, you just produce the wrong thing faster.

Today’s strongest AI systems can generate a full package from a short brief: plan, strategy, design direction, sometimes even code. Great for solo exploration. Inside organizations, it creates a different problem. The work races ahead of alignment.

One person runs end-to-end in a single burst. Stakeholders feel bypassed. Assumptions stay untested. Collaboration debt shows up later — when it is expensive to fix.

In most design processes, the real bottleneck is decision quality. The quality of thinking before anyone opens Figma. Whether the team is solving the right problem. Whether trade-offs are clear. Whether the assumptions that can quietly break the work have been surfaced.

PRODUCTION TOOLS vs. THINKING TOOLS

PRODUCTION TOOLS vs. THINKING TOOLS

────────────────────────────────────────────

Production tools: Make fast work happen faster

Thinking tools: Make better decisions happen

more reliably

────────────────────────────────────────────

Ren is a thinking tool.

Building a Team Facilitator Is a Different Category of Hard

Building a good 1:1 thinking partner is hard but doable. Getting an AI to ask strong questions, challenge assumptions, bring in relevant frameworks — that is a prompt design problem with known patterns.

Building a team facilitation system is a different beast entirely.

Four problems nearly broke the project:

Participation balance. How do you get an AI to contribute meaningfully without crowding out human thinking? Ren targets ~25% contribution in Participate mode. But that percentage means nothing without a mechanism for tracking and adjusting. The solution: turn-counting, explicit contribution budgets, and a prompt architecture that actively holds the AI back when it hits its ceiling. Like a thermostat for conversation — measuring the temperature of participation and adjusting in real time.

Dynamic detection. Groupthink, HiPPO bias, and premature convergence are subtle. They do not announce themselves. Ren detects them from participation patterns — who is speaking, how ideas are clustering, whether disagreement is getting expressed or suppressed — and intervenes in a way that opens the conversation rather than shutting it down.

Mode discipline. The hardest design constraint. Stepback mode has to mean complete silence. The credibility of the entire system depends on Ren doing exactly what it says it will do. One unwanted interjection destroys trust. Not just in the feature. In the whole system.

Session persistence. Design conversations rarely happen in one sitting. A facilitation agent that loses context at the end of each call is close to useless. Ren’s session log captures project context, key decisions, open questions, and assumptions — so they carry into the next session intact.

What Ren Looks Like When You Open It

The architecture: 10 files, ~4,000 lines, loaded hierarchically. Three anchor files load at startup — Workflow Compendium, Systems/Templates, Toolbox. Seven files load on-demand as phases activate. A system deep enough to run a full design process from problem framing to prototype-ready specification, without requiring the user to manage its state.

DESIGN PHASES

DESIGN PHASES

─────────────────────────────────────────

UNDERSTAND → IDEATE → DESIGN → EVALUATE → PREPARE

↕ ↕ ↕ ↕ ↕

[Collaboration overlay activates at any phase]

─────────────────────────────────────────

In team settings, the workflow looks like this: Designer A, B, and C each explore with their own AI support. They upload outputs to a shared Google Doc. Ren ingests that shared source, compares where ideas converge or conflict, and returns focused feedback. What to combine. What to challenge. What to test next.

It generates a light “next-session menu” for the team: discussion prompts, validation checks, small training tasks to sharpen the next round of thinking.

Seventeen visual output templates — progress bars, session logs, comparison tables, wireframes, flow diagrams, test reports. Every response is structured. No text walls.

EXPERTISE LEVELS

EXPERTISE LEVELS

─────────────────────────────────────────

Level 1 — Guide: Scaffolded. Concepts

explained. Beginners

welcome.


Level 2 — Stretch: Professional default.

Assumptions challenged.

Alternatives surfaced.


Level 3 — Spar: Academic rigor. Active

pushback. Weak arguments

get named.

─────────────────────────────────────────

Artifacts React. Thinking Directs.

Sally, Justin, and WDS work on artifacts. They take something that already exists and improve it. Even when they catch issues early, they are reacting to work in progress.

Ren operates on thinking. It is present at the moment when the project direction is still genuinely undecided. It influences the quality of the decisions being made — not just the quality of the artifacts those decisions produce.

That distinction matters more than it seems.

Most AI in design works as a speed booster for production. You design something. AI helps you move faster — audit it, generate options, write handoff docs. Human thinking happens first. AI speeds up what comes after.

Ren inverts that sequence. AI participates in the thinking itself.

The improvement is not to the production pipeline. It is to the decisions that determine whether the production pipeline is building the right thing at all.

The Sequence That Taught Me What AI Cannot Do

Gemini and NotebookLM were already available inside Verizon. People tried them in isolated ways, without a shared method. The result was familiar. Small wins. Limited day-to-day impact.

I kept exploring what was possible inside those constraints. Then I reset. Went back to the work itself. More than a month of interviews. 16 designers. One hour each. Some sessions felt closer to mediation than research — people had so much built-up friction to unpack.

Those interviews made one thing clear: in a large enterprise, old habits look like process. Process hides real problems. I mapped 40+ friction points. Built Sally to strengthen validation. Justin to catch edge cases early. WDS to support strategic design work.

Then I realized there was a friction point nobody had named directly. Because it is invisible.

The quality of thinking that happens before any formal process begins.

That is what Ren addresses.

The progression from Sally → Justin → WDS → Ren is not accidental. It is the sequence of learning what AI can and cannot do in a design workflow when you take it seriously.

Pipelines are necessary. Thinking partners change the work.

Ren is built as a Google Gemini Gem. If you are exploring what AI collaboration looks like beyond the pipeline model — DM me. Happy to share how I structured it.

Next: #012: The designer’s job didn’t disappear. It moved upstream.→

P.S. — When I started building agents, I believed the right architecture could eliminate the need for messy human debate. Give the AI enough context, enough frameworks, enough structure — and it would converge on the right answer. Nine months of building taught me the opposite. The debate is not the problem. The debate is the product. Ren did not make my team argue less. It made their arguments sharper, more inclusive, and harder to ignore. The best design decision I made this year was building an AI that protects the space for disagreement — instead of optimizing it away.

#UXDesign #AI #DesignThinking #AICollaboration #ProductDesign #Gemini #FutureOfDesign #ArtificialIntelligence

Last week, a comment on one of my posts stopped me.

wrote:

“Teams almost always design for the functional job and assume they know where that line is. They don’t, not usually. And it’s exactly what AI system design needs right now.”

He was talking about the autonomy map framing — jobs worth delegating vs. decisions worth owning. And he was right.

But here’s the part I keep thinking about: the teams aren’t incompetent. They’re not lazy. They’re solving for the wrong question.

The Right Product, The Wrong Design

Last winter, I was at a ski resort, mid-slope, trying to pull up a YouTube video to check my technique. Gloves on. Snow falling. Goggles slightly fogged.

The app worked. The video loaded. Everything was functionally correct.

I still couldn’t use it.

The buttons were too small for gloved fingers. The scrubber was impossible to control. The interface had no idea I was standing on a mountain, freezing, in a five-minute window before getting back on the lift. It gave me the same experience it gives someone watching from a couch at home.

The product team designed for the functional job: watch a video. They got it right.

But they never asked the question underneath: what does this user want to remain in control of, and what do they just need the system to handle?

Those are different questions. And the gap between them is where the user experience breaks.

A Framework That’s Been Around for 30 Years

Jobs-to-be-Done — the framework originally developed by at Strategyn in the late 1980s — tells us that people don’t use products. They hire them to do a job in their lives.

Every job has three layers:

Functional: what the user is literally trying to accomplish. Emotional: how they want to feel while doing it. Social: how they want to be perceived as a result.

Most teams design for the functional layer. Some teams make it to emotional. Almost none get to the question that matters most in AI product design:

What does the user want to remain in control of?

This is the question that decides whether your AI product feels like a collaborator or an intruder. And it can’t be answered from a feature list. It requires understanding the specific texture of a person’s situation — their physical context, their cognitive load, their stakes, their moment.

Two Kinds of Jobs

When you apply JTBD to AI system design, you discover that the user’s job has a hidden internal structure.

Some parts of the job are worth delegating. The user genuinely doesn’t care who or what handles them — they just want them done, reliably and correctly, without interruption.

Other parts are decisions worth owning. These are the moments where the user wants — even needs — to be the one making the call. Taking these away doesn’t help them. It unnerves them.

Jobs worth delegating tend to share certain characteristics:

• Low stakes if wrong

• Easily reversible

• Routine and predictable

• The user doesn’t derive meaning from doing them

Decisions worth owning tend to look different:

• High stakes or irreversible

• Tied to identity or values

• Involve unpredictable, improvised judgment

• The user would feel violated if the decision was made without them

The map between these two categories — for a specific user, in a specific context, doing a specific job — is what I call the Autonomy Map.

And almost no product team builds one.

The Ski Slope, Mapped

# AI Can Do the Job. But Should It? The Line Your Product Is Drawing Without Asking.

Last week, a comment on one of my posts stopped me.

Skipper Chong Warson wrote:

“Teams almost always design for the functional job and assume they know where that line is. They don’t, not usually. And it’s exactly what AI system design needs right now.”

He was talking about the autonomy map framing — jobs worth delegating vs. decisions worth owning. He was right.

But here is the part I keep thinking about: the teams are not incompetent. They are not lazy. They are solving for the wrong question.

The Right Product, The Wrong Design

A few winters ago. Mid-slope at a ski resort. Gloves on. Snow falling. Goggles fogged at the edges.

I was trying to pull up a YouTube video to check my technique. Five minutes before the next lift. Freezing fingers. A screen that did not care.

The app worked. The video loaded. Everything was functionally correct.

I still could not use it.

Buttons too small for gloved hands. Scrubber impossible to control. The interface gave me the same experience it gives someone on a couch at home. It had no idea I was standing on a mountain in a five-minute window.

The product team designed for the functional job: watch a video. They nailed it.

They never asked the question underneath.

What does this user want to remain in control of — and what do they just need the system to handle?

Those are different questions. The gap between them is where the experience breaks.

The Framework Is 30 Years Old. Teams Still Miss the Third Layer.

Jobs-to-be-Done — developed by Tony Ulwick at Strategyn in the late 1980s — tells us something simple. People don’t use products. They hire them to do a job in their lives.

Every job has three layers:

JTBD LAYER STRUCTURE

JTBD LAYER STRUCTURE

─────────────────────────────────────────

Layer 1: FUNCTIONAL

What the user is literally trying to accomplish.

Layer 2: EMOTIONAL

How they want to feel while doing it.

Layer 3: SOCIAL

How they want to be perceived as a result.

Most teams design for Layer 1. Some reach Layer 2. Almost none reach the question that matters most in AI product design:

What does the user want to remain in control of?

This question decides everything. Whether your AI feels like a collaborator or an intruder. Whether the user leans in or pulls back. And it cannot be answered from a feature list.

It requires understanding the specific texture of a person’s situation. Their physical context. Their cognitive load. Their stakes. Their moment.

Every Job Has a Hidden Split

Apply JTBD to AI system design and a fault line appears inside the user’s job.

Some parts are worth delegating. The user genuinely doesn’t care who or what handles them. They just want them done. Reliably. Correctly. Without interruption.

Other parts are decisions worth owning. The user wants — even needs — to be the one making the call. Take these away and you don’t help them. You unnerve them.

AUTONOMY MAP: TWO CATEGORIES

AUTONOMY MAP: TWO CATEGORIES

─────────────────────────────────────────

JOBS WORTH DELEGATING:

- Low stakes if wrong

- Easily reversible

- Routine and predictable

- User doesn’t derive meaning from doing them

DECISIONS WORTH OWNING:

- High stakes or irreversible

- Tied to identity or values

- Involve unpredictable, improvised judgment

- User would feel violated if decided without them

The map between these two categories — for a specific user, in a specific context, doing a specific job — is the Autonomy Map.

Almost no product team builds one.

The Ski Slope, Mapped

Back on the mountain.

I was there to improve my technique. Functional job: find and watch instructional video content. But underneath that were layers the app never saw.

Jobs I was happy to delegate:

• Finding the right video based on my skill level

• Resuming where I left off from the previous session

• Filtering out content irrelevant to my current terrain

Decisions I needed to own:

• When to stop skiing and watch — that depended on how my body felt, how snow conditions were shifting, how much time remained before my kids’ lesson ended

• How long to watch before trying again — I needed to feel that rhythm, not have it managed for me

• Which moment on the slope to stop — safety, visibility, other skiers

The app made none of these distinctions. It treated everything as a neutral delivery problem. Here is content. Here is an interface. Interact with it.

The result: a product that was 100% functionally correct and genuinely unusable in the moment that mattered.

When the Real World Interrupts, Ownership Gets Visceral

Decisions worth owning are often spontaneous.

Last week I was driving a familiar route. Kids in the back seat. Calendar clear. Smooth afternoon.

Then: child urgently needs a bathroom. Phone rings — my wife asking me to pick up a cake. Suddenly I’m hungry too. The route I had in mind is no longer the route I’m driving.

I overrode the navigation. Twice. Made three unplanned stops. Arrived twenty minutes later than estimated.

The navigation system had no idea any of this was happening. It kept recalculating for the original destination. Patiently. Uselessly. Until I told it something different.

Now imagine a more capable AI system. One that could see my calendar, my location history, my kids’ schedules, my previous purchase patterns. It might have predicted some of this. It might have suggested a bathroom stop proactively.

I might have been grateful for the suggestion.

But I would have resented the decision. The moment of “we’re stopping here” belongs to me. Not because it’s complex. Because it’s mine.

This is the texture of real user autonomy. It’s not about risk or stakes in the traditional sense. It’s about the improvised, unpredictable, deeply human quality of being in charge of your own day.

Three Ways Teams Draw the Line Wrong

I see the same failure modes everywhere.

Failure 1: Automating by capability, not by user preference.

The question becomes: can we do this automatically? Not should we?

If the system can generate a response, it generates one. If it can book the appointment, it books it. Engineering capability becomes the design decision. User preferences get assumed, not asked.

Failure 2: Uniform autonomy across all users.

Different people draw their autonomy maps differently. A person who has used an AI scheduling assistant for a year has a completely different comfort level than someone encountering it for the first time.

But most products apply the same setting to everyone. The experienced user gets confirmation requests they no longer need. The new user gets automation they haven’t built trust in yet. Neither experience is right. The same product creates both.

Failure 3: Ignoring context.

Same user. Same task. Different context.

Checking your calendar on a quiet Tuesday afternoon is not the same as checking it while navigating an unfamiliar mountain slope with a child’s lesson ending in forty minutes.

The job is nominally identical. The Autonomy Map is completely different.

Context-blind products apply the same logic to both. They ignore the mountain. They ignore the gloves. They ignore the forty minutes. They deliver a technically correct experience that is behaviorally wrong.

How to Build an Autonomy Map

The Autonomy Map isn’t a deliverable you create once and file away. It’s a set of questions you ask about every meaningful moment in your user’s job.

AUTONOMY MAP DIAGNOSTIC

AUTONOMY MAP DIAGNOSTIC

─────────────────────────────────────────

For each key moment, ask:

1\. What is the user actually trying to do here?

→ Functional job

2\. How do they want to feel while doing it?

→ Emotional job

3\. What context are they in — physical, cognitive, social?

4\. What does success FEEL like, not just look like?

5\. What does the user want to remain in control of?

→ This is the map question.

6\. What would feel like a violation, even if technically correct?

Questions 5 and 6 give you the map. Everything in the “remain in control of” column stays at lower autonomy — confirm before acting, or surface for decision rather than decide. Everything outside it can be delegated.

Then layer in variability:

• Does this change based on how experienced the user is?

• Does this change based on context — location, time pressure, physical state?

• Does this change based on who else is affected by the decision?

The Autonomy Map isn’t static. It shifts with the user’s situation. The product has to be designed to shift with it.

The Map Makes the Dial Usable

Once you have the map, you have what you need to set the dial.

The Autonomy Dial — a framework I’ve written about separately — gives you four positions: observe and suggest, act with confirmation, act with notification, act autonomously.

Most teams try to set the dial without a map. They pick a default — usually cautious, because caution is defensible — and apply it uniformly.

The result: constant confirmation requests for things the user was happy to delegate. Silent automation of things the user wanted to own. Both feel wrong. Both erode trust. Just in opposite directions.

The map tells you which dial setting belongs to which moment. It’s the diagnostic that makes the dial usable.

Without the map, you’re not making autonomy design decisions. You’re guessing. And hoping your guess matches your user’s actual experience.

What Changes When You Build One

When teams actually ask “what does this user want to remain in control of?” — a few things happen.

The product gets more specific. Not in a complex way. In a respectful way. It starts behaving as if it understands the difference between a task the user wants handled and a decision the user wants to make.

The user’s cognitive load drops. Not because the AI is doing more. Because the AI is doing the right things — handling what should be handled, stepping aside when the human needs to be present.

And trust compounds. Not through big gestures or feature announcements. Through the small, consistent experience of a system that seems to understand where its job ends and the user’s begins.

That’s not a UX goal. It’s a relationship.

And like all relationships, it starts with the right question.

The framework for setting autonomy levels — the Autonomy Dial — is in #009: Every AI Product Makes a Hidden Decision About Autonomy. Almost None Make It Deliberately. This is the diagnostic that comes before it.

If your team is making AI product decisions without an Autonomy Map, you’re drawing the line. You’re just not drawing it deliberately.

————————

P.S. I used to think the hard part of AI design was getting the AI to do more. Faster. Smarter. More autonomous. I was wrong. The hard part is restraint. Knowing when to stop. Knowing when the user’s control isn’t a friction point to optimize away — it’s the entire point. That shift changed how I design everything.

#AIDesign #UXDesign #JTBD #AgenticUX #ProductDesign #IntentFirst #HumanAI #FutureOfDesign

Tuesday morning. A product manager opens her email. Her AI assistant has already responded to three messages.

One was a routine scheduling confirmation. Fine.

One was a reply to her VP, committing her team to a Thursday deadline she hasn’t discussed with engineering. Not fine.

One was a message to a client she’s never emailed before, using a casual tone pulled from her other correspondence. Career-damaging.

Same AI. Same capability. Same autonomy setting for all three.

That’s the problem.

The question nobody asks out loud

Every AI product is built around a question that almost nobody states explicitly.

Not: what should the AI do? Not: how accurate should it be? Not: what should the interface look like?

The question is: how much should the AI do on its own?

This decision determines whether users trust the product or abandon it. And it’s almost always made badly. Implicitly. By engineers rather than designers. Without a framework. Applied uniformly when it should be applied contextually.

The result is predictable. Products either interrupt constantly — training users to stop paying attention to confirmations — or act too freely on things users wanted to control.

Neither is the right answer. The right answer is a framework.

I call it the Autonomy Dial.

The four positions of the Autonomy Dial

Think of a volume knob on a stereo. Four clicks. Each one changes the relationship between human and machine.

THE AUTONOMY DIAL

THE AUTONOMY DIAL

==================

Position 1: OBSERVE AND SUGGEST

├── AI watches. AI advises. AI never acts.

├── User controls every action.

└── Example: Email client notices “I’ll send that by Friday”

→ suggests a calendar reminder. You decide.



Position 2: ACT WITH CONFIRMATION

├── AI proposes a specific action. Waits for approval.

├── One tap to proceed. One tap to cancel.

└── Example: Assistant drafts a meeting response.

Shows it to you. “Send this?” You review. You confirm.



Position 3: ACT WITH NOTIFICATION

├── AI takes the action. Tells you what it did.

├── You can undo. But you have to choose to.

└── Example: AI schedules meeting based on your calendar

and preferences. “Done. Here’s what I booked.”



Position 4: ACT AUTONOMOUSLY

├── AI handles it completely. You see outcomes, not process.

├── Intervention requires you to actively look for it.

└── Example: AI manages your inbox — archiving, categorizing,

drafting routine responses. You see a clean inbox.

Details available if you want them.

Four positions. One dial. The entire trust relationship lives here.

Why this matters more than any other AI design decision

The Autonomy Dial isn’t a UX pattern. It’s the mechanism by which users calibrate trust.

Trust in AI doesn’t work like trust in other products. You don’t decide you trust an AI and then use it freely. You build trust incrementally. Each successful autonomous action nudges your willingness forward. Each mistake — especially one that’s hard to undo — slams it backward.

The dial is the interface where this calibration happens.

Set it too conservatively — Position 1 or 2 for everything — and users drown in interruptions. The AI feels like a nervous intern who can’t send an email without asking permission. Users stop reading the confirmations. They tap through on autopilot. This is dangerous. Or they abandon the system entirely because it creates more friction than value.

Set it too aggressively — Position 4 for things users aren’t ready to delegate — and users feel ambushed. They can’t predict what the AI will do. When something goes wrong, they don’t know how to recover. Trust collapses. Rebuilding it takes ten times longer than building it the first time.

The right setting is neither conservative nor aggressive. It’s contextual. Different for different tasks. Different for different users. Different for different moments.

Four dimensions that determine the right dial position

Getting this right means thinking across four dimensions simultaneously.

AUTONOMY CALIBRATION MATRIX

AUTONOMY CALIBRATION MATRIX

=============================

DIMENSION 1: TASK REVERSIBILITY

─────────────────────────────────

High reversibility → Higher autonomy OK

(archive email = one click to restore)

Medium reversibility → Moderate autonomy

(schedule meeting = cancellable, but social cost)

Low reversibility → Lower autonomy required

(send message = cannot unsend)

(process payment = cannot uncharge)



DIMENSION 2: USER FAMILIARITY

─────────────────────────────────

Experienced user (6+ months with task type)

→ Has mental model of AI behavior

→ Position 3 appropriate

New user (first encounter with capability)

→ No mental model yet

→ Position 2 appropriate

→ Dial should EVOLVE as familiarity grows



DIMENSION 3: DOMAIN STAKES

─────────────────────────────────

Low stakes → Higher autonomy tolerable

(content organization, reminders, drafts)

High stakes → Lower autonomy regardless of familiarity

(communication sent on your behalf)

(financial transactions)

(medical information)



DIMENSION 4: CONTEXTUAL SIGNALS

─────────────────────

Same user. Same task type. Different context.

Message to close colleague → Position 3

Message to new client → Position 2

Message with sensitive topic → Position 1


Detection signals:

- New recipient

- Unusual phrasing

- Time sensitivity

- Emotional language

These four dimensions interact. A high-stakes task with a new user and low reversibility? Position 1. A low-stakes task with an experienced user and high reversibility? Position 4.

The math isn’t complicated. The discipline of actually doing it is rare.

The design failure destroying most AI products right now

The most common failure has a name. Uniform autonomy. Same dial setting for every interaction. Every task type. Every stakes level. Every context.

It happens because nobody explicitly made autonomy a design decision. An engineer picked a default — usually cautious, because caution is defensible — and that default became the setting for everything.

Here’s what happens next.

Confirmation requests appear constantly. Before archiving an email. Before saving a draft. Before every low-stakes action. Users stop reading them. They tap through. The confirmation UI is still there. The user’s attention is gone.

Then the AI sends the message to the new client. The one the user hadn’t actually read.

Uniform caution doesn’t prevent errors. It trains users to ignore the safeguard. Then it removes the safeguard when it matters most.

The safety design becomes the mechanism of the failure it was trying to prevent.

Read that again.

What good autonomy design actually looks like

The products that get this right share four characteristics.

They surface the dial. Users can see — in plain language, not buried in settings — what autonomy level is active for different task types. “For calendar scheduling, I’ll act and notify you. For external emails, I’ll always ask first.” Transparency turns the autonomy setting into a choice rather than something done to the user.

They make adjustment instant. When a user wants to change the autonomy level for a specific task, it happens in one action, in the moment. Not a trip through settings. “Always ask before doing this” — available immediately when the AI does something unexpected. Friction in adjustment means users won’t adjust. They’ll just leave.

They adapt over time. The system tracks which confirmations the user approves without changes. It gradually suggests moving to higher autonomy for those patterns. “You’ve approved my last 12 meeting scheduling suggestions without changes. Want me to handle these automatically going forward?” This is trust built into the system architecture. Not just the interface.

They escalate gracefully. When the AI encounters uncertainty — unusual context, ambiguous intent, higher-than-normal stakes — it drops to a lower autonomy position and says why. “I want to check this one with you because it involves a new contact.” This behavior, done consistently, is what makes users comfortable letting the system run freely the rest of the time.

GOOD AUTONOMY DESIGN — SYSTEM SPEC

=====================================

SURFACE THE DIAL

→ Plain-language autonomy status per task type

→ Visible in main interface, not settings


INSTANT ADJUSTMENT

→ One-action change, in context

→ “Always ask before doing this” = one tap


ADAPTIVE EVOLUTION

→ Track approval-without-change patterns

→ Suggest autonomy upgrades at thresholds

→ User confirms the upgrade explicitly


GRACEFUL ESCALATION

→ Uncertainty detected → drop autonomy level

→ Explain why: “New contact” / “Unusual amount” / “Sensitive topic”

→ Return to normal autonomy after resolution

Autonomy is not a feature. It’s a relationship.

This is the deeper principle underneath the dial.

Autonomy develops over time. Through accumulated experience. In a specific domain. With a specific user. It can’t be granted by default. It can’t be assumed from technical capability. It has to be earned. Interaction by interaction. Through consistent, trustworthy behavior.

Think of it like driving with someone new. The first time they’re behind the wheel, you watch the road. You grip the armrest. You notice every lane change. After a hundred trips without incident, you fall asleep in the passenger seat.

Nobody told you to trust them. You just did. Because they earned it. One uneventful drive at a time.

The designer’s job is to create the conditions for that relationship to develop. Build the scaffolding that lets users extend trust gradually. Recover quickly when something goes wrong. Always feel meaningful control over what the system does on their behalf.

Get that right, and autonomy becomes something users actively want. Get it wrong, and the most capable AI in the world becomes the one nobody uses.

Next in this series [#010: Users Don't Stop Trusting AI Suddenly. They Stop the Same Six Ways, Every Time.] — the interface patterns that make autonomous action feel safe rather than alarming.

P.S. — I used to think the Autonomy Dial was a UX pattern. A design artifact. Something you ship. I’ve come to see it differently. The dial is a mirror of how humans extend trust to anything — people, institutions, tools. We start cautious. We test. We watch for consistency. We extend gradually. We retract sharply when surprised. Every relationship in your life follows this pattern. The fact that AI trust works the same way isn’t a design insight. It’s a human insight. We’re not designing for machines. We’re designing for the oldest trust architecture in existence — the human one.

#AIDesign #AgenticUX #UXDesign #ProductDesign #IntentFirst #FutureOfDesign #HumanAI

# Your Company Knows More Than It Thinks. It Just Cannot Access Any of It.

Most AI deployments fail not because of the model. Because of what came before it.

3:47 PM. A product designer stares at her screen.

She needs to know why the team chose a modal over a slide-out panel six months ago. There was a reason. Someone explained it in a meeting. The meeting had a recording. The recording is somewhere in Google Drive. Or maybe Confluence. Or maybe it was a Slack thread.

She spends twenty minutes searching. Finds nothing. Opens Slack. Messages a colleague who was in that meeting. The colleague is on PTO until Thursday.

She picks the modal. Moves on. Two weeks later, stakeholder feedback: “We already decided against this approach.” Back to square one.

This scene plays out hundreds of times a day across every enterprise I have worked in. It is not a technology problem. It is not a people problem.

It is a knowledge architecture problem. And it is the single most common reason AI transformations stall.

The AI Is Not Broken. The Context Is Empty.

There is a moment that happens in almost every enterprise AI rollout.

Tools arrive. People start using them. A few weeks in, someone asks the AI something important — a business decision, a design rationale, a historical context — and the AI returns a confident, well-structured, completely useless answer.

Not wrong, exactly. Hollow. Generic. Untethered from the actual reality of the organization.

The team concludes: “AI cannot do this kind of work.”

The real conclusion: “We have not given it anything real to work with.”

Imagine hiring a world-class surgeon and handing her a butter knife. Then concluding that surgery does not work. The surgeon is not the problem. The instruments are.

AI without organizational context is a surgeon with a butter knife. Technically capable. Practically useless.

What Knowledge Architecture Actually Means

Most organizations have enormous amounts of institutional knowledge. They also have almost none of it in usable form.

The knowledge exists. In email threads. In Slack conversations. In meeting recordings nobody watches. In the heads of the one person who has been on the project since the beginning. In the slide deck explaining the strategic rationale everyone has forgotten.

None of it is structured. None of it is queryable. None of it is connected.

THE KNOWLEDGE PARADOX

THE KNOWLEDGE PARADOX

━━━━━━━━━━━━━━━━━━━

What the organization knows: ENORMOUS

What it can actually access: ALMOST NOTHING

Knowledge exists in:

→ Email threads

→ Slack messages

→ Meeting recordings

→ Individual memories

→ Forgotten slide decks

→ Departed employees’ heads

Knowledge is queryable in: ZERO of these

When AI arrives into this environment, it runs on impoverished context and produces impoverished output. This is not the model’s failure. It is an architecture failure. It happened long before the AI was ever turned on.

Knowledge architecture is the discipline of solving this. What does our organization actually know? Where does it live? How do we make it accessible? How do we keep it current?

This is different from documentation. Documentation is a photograph. Knowledge architecture is a living camera.

The Three-Layer Model

After running this process at Verizon — across sixteen designer interviews, 40+ friction points, and multiple AI system deployments — I arrived at a three-layer model. I now use it as the starting template for any knowledge architecture build.

Three layers. Three questions. Three different heartbeats.

KNOWLEDGE ARCHITECTURE: THREE-LAYER MODEL

KNOWLEDGE ARCHITECTURE: THREE-LAYER MODEL

━━━━━━━━━━━━━━━━━

Layer 1: BRAND MASTER BRAIN

Question: “Who are we, and how do we decide?”

Heartbeat: Quarterly


Layer 2: RESEARCH MASTER BRAIN

Question: “What do we know about our users?”

Heartbeat: Continuous + monthly synthesis


Layer 3: PROJECT MASTER BRAIN

Question: “What is happening on this project right now?”

Heartbeat: Daily

Each layer answers a different question. Each has different source material, different update cadences, different use cases. Conflating them is one of the most common mistakes I see.

Layer 1: Brand Master Brain — The Organization’s Identity

The question it answers: Who are we, and how do we make decisions?

This layer holds identity infrastructure. The things that should not change from project to project. The things new team members spend months absorbing by osmosis instead of reading directly.

BRAND MASTER BRAIN — SOURCE MATERIAL

BRAND MASTER BRAIN — SOURCE MATERIAL

━━━━━━━━━━━━━━

→ Brand guidelines and design principles

→ Voice and tone documentation

→ Competitor positioning and market context

→ Strategic direction and organizational priorities

→ Historical decisions AND the rationale behind them


KEY DISTINCTION:

Most orgs document WHAT they decided.

Very few document WHY.

The Brand Brain must hold both.

Without the “why,” consistency is impossible.


UPDATE CADENCE: Quarterly reviews + triggered updates

on major strategic decisions

The key word is rationale. When an AI — or a new designer — needs to make a decision consistent with the brand, they need the reasoning. Not just the rule. Rules without reasoning create compliance. Reasoning creates judgment.

How to build it: Start with what exists. Brand guidelines. Principle documents. Strategic decks. Then do the harder work: identify the tribal knowledge that is not written down anywhere. Interview the people who have been around longest. Ask them: What would a new person get wrong about how we make decisions here?

The answers to that question are your most important source material. They are also the knowledge most at risk of disappearing when people leave.

Layer 2: Research Master Brain — The User Intelligence System

The question it answers: What do we know about the people we design for?

This layer holds accumulated understanding of users. Synthesized and queryable. Not buried in individual research repositories that nobody revisits.

RESEARCH MASTER BRAIN — SOURCE MATERIAL

RESEARCH MASTER BRAIN — SOURCE MATERIAL

━━━━━━━━━━━━━━━━

→ User research reports and synthesis documents

→ Usability testing findings

→ Customer feedback and support themes

→ Behavioral analytics and usage patterns

→ Journey maps and persona frameworks

→ Competitive UX analysis


THE PROBLEM THIS SOLVES: RESEARCH DEBT

Research gets done.

Report gets written.

Report gets shared in a meeting.

Report disappears into a folder.

Six months later, a team guesses

about something the research already answered.


UPDATE CADENCE: Continuous as research completes

+ monthly synthesis reviews

Research debt is one of the most expensive invisible costs in any design organization. The research exists. The insights exist. Nobody can find them fast enough to use them when it matters.

The Research Master Brain changes the retrieval model. Instead of searching through folders, a designer asks: “What do we know about how our users think about account management?” and gets a synthesized answer drawing from three studies, two usability tests, and six months of support data.

How to build it: Audit existing research first. You almost certainly have more than you think. It is just scattered. Collect, tag, and load everything. Then establish a protocol: every piece of research goes into the Brain before the project closes. No exceptions. The protocol matters more than the initial load.

Layer 3: Project Master Brain — The Living Memory

The question it answers: What is happening on this specific project, right now?

This is the most dynamic layer. It is also the one that solves the friction point I heard most consistently in interviews: designers spending hours trying to reconstruct context that should have been easy to find.

PROJECT MASTER BRAIN — SOURCE MATERIAL

PROJECT MASTER BRAIN — SOURCE MATERIAL

━━━━━━━━━━━━━━━━━━━━━━

→ Project briefs and initiative documents

→ Meeting transcripts and decision logs

→ Stakeholder feedback and alignment notes

→ Design iterations and reasoning behind changes

→ Open questions and known unknowns

→ Dependencies and blockers


CRITICAL CAPTURE: DECISION ARCHAEOLOGY

Not just WHAT was decided —

but what options were considered,

what was rejected, and WHY.

This is the information that gets lost fastest.

It matters most when circumstances change.


UPDATE CADENCE: Continuous throughout project lifecycle

The Project Master Brain is a living memory for the project. When someone joins mid-project, they do not need a two-hour onboarding call. They query the Brain. When a decision gets revisited three months later, the context for why it was made is retrievable. When a designer needs to remember what was said in last Tuesday’s alignment meeting, they do not dig through notes. They ask.

How to build it: Establish a protocol at project kickoff. Every meeting transcript gets uploaded. Every significant decision gets a one-paragraph rationale logged. Every version change gets a note. The Brain gets fed continuously. Not in a cleanup sprint at the end.

The cleanup sprint never happens. Everyone knows this. Build the habit from day one or it will not exist at day ninety.

A Filing Cabinet Is Not Infrastructure. A Thinking Partner Is.

There is a version of this that organizations do and feel good about. It does not work.

It looks like this: a team creates a shared folder. They put documents in it. They call it their “knowledge base.” Six months later, nobody uses it. Finding anything requires knowing what you are looking for. The folder structure made sense to whoever built it. It makes sense to nobody else.

This is a filing cabinet. Not infrastructure.

FILING CABINET vs. THINKING PARTNER

FILING CABINET vs. THINKING PARTNER

━━━━━━━━━━━━━━━━━━━━

Filing Cabinet (activity):

→ Holds information

→ Requires you to know what to look for

→ Structure reflects the builder’s mental model

→ Goes stale silently

→ Stores documents


Thinking Partner (infrastructure):

→ Surfaces insight

→ Queryable in plain language

→ Relevant context without knowing where to look

→ Stays current via built-in update protocol

→ Synthesizes knowledge

Infrastructure is queryable in plain language. Infrastructure surfaces relevant context without requiring you to know where to look. Infrastructure stays current because the process of updating it is built into the work itself.

NotebookLM — which I used to build the Master Brain system at Verizon — is the closest thing to infrastructure that is currently accessible inside most enterprise environments. The key is loading it correctly, maintaining it consistently, and training the team to query it rather than search it.

The Query Protocol: Teaching People to Think Out Loud

The most underrated part of knowledge architecture is teaching people how to use it.

Most people, when they first interact with an AI knowledge system, ask closed questions:

“Is there research on checkout flows?”

This gets a yes-or-no answer. Useful. But barely scratching the surface.

The system becomes genuinely powerful when people learn to ask open questions:

“What do we know about user behavior during checkout, and what are the gaps in our current research?”

This gets synthesis. Context. Actionable next steps.

QUERY PROTOCOL

QUERY PROTOCOL

━━━━━━━━━━━━━━━━━━━━━

WEAK QUERY (search engine mode):

“Is there research on X?”

→ Gets: yes/no + document link

→ Value: minimal

STRONG QUERY (thinking partner mode):

“What do we know about X, what patterns emerge

across our research, and where are the gaps?”

→ Gets: synthesis + connections + recommendations

→ Value: transformative

The difference between these two query styles is the difference between using a vending machine and having a conversation with someone who has read everything in the system. Both retrieve information. Only one generates insight.

I spend time explicitly training this with every team. It is not obvious. It is not natural. Especially for people who have spent years treating knowledge systems like search engines. But it is learnable. And once a team gets it, the quality of output from the system changes dramatically.

The Three Ways Knowledge Architecture Breaks

Knowledge architecture fails in three predictable ways. All three are preventable.

1. The Cold Start Problem

The system is only as useful as what is in it. An empty Brain is useless. The temptation is to wait until you have “enough” to make it worthwhile.

“Enough” never arrives.

Start with what exists. Accept imperfection. Let it grow. A Brain with three months of meeting transcripts and a project brief is already more useful than no Brain at all. Perfection is the enemy of adoption.

2. The Maintenance Gap

Most teams are disciplined about loading material at the beginning and terrible about maintaining it. The Brain that was current in month one is stale by month four.

The fix is protocol, not motivation. Build the update process into existing workflows so it happens automatically. Upload the transcript as part of closing the meeting. Log the decision as part of making it. When maintenance is a separate task, it dies. When it is embedded in the workflow, it lives.

3. The Over-Centralization Trap

Not everything should live in one place. A Project Master Brain that contains brand guidelines, five years of research, and every meeting transcript for six months is unusable. Too much noise to surface signal.

The three-layer model exists precisely to prevent this. Separation is a feature, not a compromise. Each Brain stays focused. Each query returns signal, not noise.

Start Smaller Than You Think Is Possible

The most common objection: this sounds like a big project.

It can be. It does not have to start that way.

MINIMUM VIABLE KNOWLEDGE ARCHITECTURE

MINIMUM VIABLE KNOWLEDGE ARCHITECTURE

━━━━━━━━━━━━━━━━━━━━━━━

Start:

One Project Master Brain.

One project.

Last three months of meeting transcripts.

Current project brief.

That is it.

Build it. Use it for one month. Observe.

What usually happens:

Week 1 → Team queries context they used to

spend hours reconstructing

Week 2 → New team members onboard faster

Week 3 → Decisions reference actual history

Week 4 → The team refuses to work without it

Then:

Add a Research Master Brain.

Then Brand.

Architecture grows with the need.

The system becomes indispensable faster than anyone expects. Not because it is magical. Because the alternative — digging through folders, messaging colleagues, guessing — is so painfully slow that even an imperfect Brain feels like a superpower.

The Deeper Point

Knowledge architecture is not really about AI.

It is about organizational intelligence. The degree to which an organization can access and apply what it collectively knows. AI makes this more urgent and more achievable. But the underlying problem predates AI by decades.

Most organizations operate well below their own intelligence ceiling. The knowledge exists. The experience exists. The hard-won judgment exists. It is just inaccessible. Locked in formats that cannot be queried. In locations that cannot be found. In the heads of people who will eventually leave.

Building knowledge architecture is the work of changing that.

When AI arrives — and it will keep arriving, in better and better forms — you want it running on the richest possible context. The organizations that have done this work will use AI to think at a level that was not previously possible. The ones that have not will use it to generate slightly faster versions of the same hollow output they have always produced.

The preparation happens now. The payoff compounds forever.

P.S. — The hardest lesson I learned building the Master Brain at Verizon was not technical. It was emotional. I built what I thought was a beautiful knowledge architecture — clean layers, good protocols, solid source material. Nobody used it for the first two weeks. I was crushed. Then I realized I had built the system for how I thought people should retrieve information, not for how they actually do. They did not want to write structured queries. They wanted to ask messy, half-formed questions the way they would ask a colleague. Once I stopped training people to query “correctly” and started training the system to handle how people actually think, adoption changed overnight. The architecture was not the hard part. Letting go of my assumptions about how it should be used — that was the hard part.

Next: #008: I Built a Team-Level AI Operating System. Then I Saw the Blueprint for Everything Coming Next. →

#KnowledgeManagement #EnterpriseAI #AIDesign #DesignOperations #AIWorkflow #UXDesign #ProductDesign

A designer on my team uploads a set of screens and a user persona into a Gemini Gem. The Gem runs an accessibility audit, flags three usability friction points, and returns a structured report with severity ratings and recommended fixes.

Another designer feeds business requirements into a different Gem. It scans for edge cases across four layers — data states, system conditions, user states, temporal factors — and returns a logic gap matrix before a single line of code is written.

A third designer asks the team’s shared knowledge system a plain-language question about a decision made two months ago. The answer comes back in seconds, with context and rationale.

None of this existed a year earlier. I built these systems at Verizon — not as a single product, but as a set of Gemini Gems designed to fill specific structural gaps in the design workflow. Each Gem had a defined role, defined inputs, defined outputs.

Looking back, the architecture follows the same pattern that Samsung, Google, and Apple are now racing to ship at consumer scale. I did not set out to build an operating system. But that is what emerged.

An operating system manages chaos so users don’t have to

Strip away the marketing language. An operating system does five things.

It manages resources. It routes tasks to the right processes. It maintains state across sessions. It handles errors and exceptions. It provides a stable foundation for applications to run.

What I built at Verizon did all five. Not for a computer. For a design organization.

Here’s the architecture.

TEAM-LEVEL AI OPERATING SYSTEM

TEAM-LEVEL AI OPERATING SYSTEM

================================

MEMORY LAYER — “Master Brain”

├── Every project document

├── Every meeting transcript

├── Every strategic decision

├── Every research artifact

└── Queryable in plain language

Persistent across sessions

Available to every designer


VALIDATION LAYER — “Sally”

├── Input: Design + user context

├── Process: Audit against behavioral science + UX standards

├── Output: Structured findings

└── Behavior: Predictable. Repeatable. Reliable.


EXCEPTION HANDLER — “Justin”

├── Scans before development starts

├── Layer 1: Data states

├── Layer 2: System conditions

├── Layer 3: User states

├── Layer 4: Temporal factors

└── Surfaces failures before they reach production


ORCHESTRATION LAYER — “WDS”

├── Strategy agent

├── Analysis agent

├── Design agent

├── Architecture agent

├── Visual agent

└── Directed at a problem → returns structured outputs

across multiple dimensions simultaneously

Master Brain was the memory layer. Think of a library where every book opens to the right page the moment you think of a question. No searching. No filing. Just ask and receive. That’s what an OS does with storage — makes information accessible to any process without that process needing to know where the information lives.

Sally was the validation process. Hand her a design and a user context. She returns a structured audit. Same input format every time. Same output format every time. Predictable behavior. That’s what an OS does with applications — provides stable interfaces that behave the same way Tuesday as they do Friday.

Justin was the exception handler. Before a single line of code gets written, he scans four layers deep for the failures that would otherwise surface in production. Data states. System conditions. User states. Temporal factors. Operating systems catch exceptions before they propagate into expensive territory. Justin did the same.

WDS was the orchestration layer. Five specialist agents — strategy, analysis, design, architecture, visual — aimed at a problem simultaneously. Orchestration is the beating heart of any operating system.

The full loop looked like this:

OPERATING SYSTEM LOOP

OPERATING SYSTEM LOOP

======================

Intent (designer states a goal)

↓

Orchestration (WDS routes to the right agent)

↓

Execution (Sally audits / Justin scans / Brain retrieves)

↓

Human review and judgment

↓

Next intent

User states intent. System routes it. Processes execute. Human judgment closes the loop. That’s an operating system.

The consumer version is the same blueprint at planetary scale

Samsung, Google, Apple, Microsoft — they’re all building the same architecture. Different scale. Same bones.

CONSUMER AGENTIC OS LOOP

==========================

Intent (user states a goal)

↓

Orchestration (OS routes to the right agent)

↓

Execution (agents act across apps / devices / services)

↓

Human review and control

↓

Next intent

Building the team version first taught me four things 
that aren’t obvious until you’ve shipped this and watched people use it.

The AI isn’t the hard part. The handoff is.

The critical moments in my system were never when Sally was running an audit or Justin was scanning for edge cases. The agents worked fine. The critical moments were the seams between human and machine.

When does the system act on its own? When does it pause and surface a decision for a human?

Get it wrong in one direction — constant interruptions. The system asks permission for things the user wanted automated. Designers start ignoring it. The confirmations become wallpaper.

Get it wrong in the other direction — the system acts on something the user wanted to control. Trust doesn’t erode. It shatters.

This is the Autonomy Dial problem. The design question is never “how powerful should the AI be?” The question is always: for this task, for this user, in this moment — what level of autonomy is right?

A designer who wants full automation for file organization might want full manual control for client-facing deliverables. The system has to hold both configurations simultaneously. Surface the right one in context. Let the user adjust without navigating settings.

One answer for everything is no answer at all.

Context is the operating resource of the agentic era

A traditional OS manages CPU, memory, storage. An Agentic OS manages context.

Context is the accumulated understanding of who the user is. What they’re trying to accomplish. What happened before. What constraints apply.

Master Brain was my context layer. Everything the design team had ever done, decided, or discussed — queryable in plain language. This made every agent more useful. No agent operated in a vacuum. Sally’s audits were sharper because she could reference past decisions. Justin’s scans were smarter because he knew the project history.

Think of context like soil. An agent without context is a seed dropped on concrete. An agent with rich context is a seed in deep earth. Same seed. Radically different outcomes.

Consumer Agentic OS needs the same thing at massive scale. The system needs to know: What has this user done before? What are their preferences? What did they decide last time they faced a similar choice? What constraints apply — privacy limits, budget caps, time availability?

This context transforms generic AI into something that feels like it understands you.

But the design challenge is enormous. Users must see what context the system holds. They must be able to correct it. They must selectively share it across applications without feeling surveilled. Context architecture is a UX problem as much as a technical one.

Maybe more.

Failure modes must be designed, not just handled

The most important design work I did at Verizon wasn’t the happy path. It was the failure architecture.

What happens when Justin flags an edge case that blocks a deadline? What happens when Sally’s audit conflicts with stakeholder direction? What happens when Master Brain has no context on a new project type?

Each scenario required a designed response. Not an error message. A path back to productive work that preserved trust and didn’t require starting over.

FAILURE ARCHITECTURE — DESIGN SPEC

FAILURE ARCHITECTURE — DESIGN SPEC

=====================================

Principle: Every failure mode gets a designed recovery path.

SCENARIO → DESIGNED RESPONSE

Edge case blocks deadline → Prioritized list + workaround options

Audit conflicts with stakeholder → Side-by-side comparison + risk framing

No context for new project type → Graceful degradation + learning prompt


NEVER acceptable:

- Generic error messages

- “Try again later”

- Dead ends that require restart

- Silent failures

Consumer Agentic OS has failure modes that are harder and higher stakes. The agent books the wrong flight. The AI drafts an email with wrong information — and the user sends it before catching the mistake. The system’s understanding of intent is subtly wrong in a way that compounds over weeks.

The undo architecture. The audit trail. The escalation pathways. These aren’t features bolted on at the end. They’re the foundation that makes trust possible. Design them with the same rigor as the happy path. These are the moments that determine whether users keep using the system or walk away.

Trust is built through specificity, not capability

Sally was trusted because she did one thing. CX audits. Justin was trusted because he did one thing. Edge case detection. The specificity made them reliable. Designers knew exactly what to expect. They got it consistently.

A Swiss army knife is versatile. A scalpel is trusted. In surgery, you reach for the scalpel.

Consumer Agentic OS faces a harder version of this problem. The system is general-purpose. It can do many things. But users still need a mental model of what it will and won’t do. Where it can be trusted. Where it should be checked.

That mental model has to be cultivated through design. Consistent behavior. Transparent communication about what the system is doing and why. Graceful handling of uncertainty.

The most sophisticated AI is useless if users don’t know when to trust it. Designing that understanding is a UX problem. Perhaps the UX problem of this decade.

The outcome I didn’t design for became the most important one

I started building AI infrastructure for efficiency. Faster work. More output.

That happened. But it wasn’t the thing that mattered.

The thing that mattered was this: the work changed. Not the speed. The nature. With scaffolding handled by AI, human work moved upstream. More time on problem framing. More time on strategic decisions. More time on the judgment calls machines can’t make.

The designers didn’t become faster versions of themselves. They became elevated versions of themselves.

The same thing will happen at the consumer level. When Agentic OS handles the scaffolding of daily life — scheduling, research, routine correspondence, information retrieval — human work moves upstream too. More bandwidth for decisions that require judgment. More cognitive space for the things that actually matter.

That’s the real promise of Agentic OS. Not efficiency. Cognitive liberation.

Designing it well — so the system is trustworthy enough that users actually let it handle the scaffolding — is the hardest and most important design problem in the industry right now.

I’ve been working on a small version of it. The consumer version is the same problem, larger.

The next piece [009: Every AI Product Makes a Hidden Decision About Autonomy. Almost None Deliberately.] in this series goes deeper on the autonomy question: how do you design a system that knows when to act and when to ask?

P.S. — When I first built Master Brain, I thought I was solving a knowledge management problem. Six months in, I realized I’d been solving a trust problem the entire time. Every design decision I thought was about efficiency was actually about whether people would believe the system enough to change how they worked. That realization changed how I think about every AI product. The technical capability is table stakes. The trust architecture is the product.

#AgenticOS #AIDesign #UXDesign #FutureOfDesign #IntentFirst #ProductDesign #AIStrategy

I spent three months building an AI agent for usability testing. It analyzes user behavior, identifies friction points, generates research questions — work that used to take a researcher days.

In pilot projects, it surfaced insights product teams had missed entirely. In real engagements, it contributed to measurable improvements. The outputs were good. Sometimes better than good.

Then I put it in front of designers who had spent their careers running usability sessions with real people.

They didn’t try it. Not because they tested it and found it lacking. They didn’t get that far. The response was immediate and visceral: How can an AI understand what a real user feels? You have to be in the room. You have to watch their face.

The AI wasn’t wrong. It wasn’t broken. It had proven itself. But none of that mattered — because trust doesn’t transfer through proof. It transfers through experience. And these designers had no experience with the system. No mental model for what it does, how it reasons, or when it might fail.

That gap — between what an AI system can do and what users believe it can do — is the central design problem of the agentic era. Not capability. Credibility. Not accuracy.

Trust.

What follows are six patterns for closing that gap. Not theoretical. From building AI systems that real people use, watching where trust forms, and watching where it fractures.

Pattern 1: Intent Preview

— Show the plan before executing it

Before the AI acts, it shows the user what it’s about to do. Plain language. Enough specificity to meaningfully evaluate.

The most common failure in agentic systems isn’t the AI doing something wrong. It’s the user not knowing what the AI is about to do — and being ambushed by the result. Surprise destroys trust. Even when the action was correct.

Intent Preview shifts the AI from actor to collaborator. “Here’s my plan” before “here’s what I did” changes the psychological dynamic entirely. The user feels like a co-pilot. Not a passenger.

INTENT PREVIEW — DESIGN SPEC

INTENT PREVIEW — DESIGN SPEC

===============================

WELL-DESIGNED:

├── Numbered list of specific actions the AI will take

├── Three response options: Proceed / Edit / Handle-it-myself

├── Ability to adjust the plan without starting over

└── Specificity sufficient for informed evaluation



POORLY-DESIGNED:

├── “Are you sure?” with no specifics

├── “I’ll take care of this for you” (vague, unevaluable)

└── Binary accept/reject with no edit option



UNDERLYING PRINCIPLE:

Users don’t need to understand HOW the AI works.

They need to understand WHAT it’s about to do

well enough to decide whether to let it proceed.

Think of it like a surgeon briefing a patient before an operation. You don’t need to understand the technique. You need to understand what’s going to happen, what the risks are, and what the alternatives look like. Informed consent. Not blind faith.

Pattern 2: The Autonomy Dial

— One size fits nothing

A configurable spectrum of how much the AI does on its own. Adjustable per task type, per context, and over time as trust develops.

There is no universally correct autonomy level. The right setting depends on the task’s reversibility, the user’s familiarity with AI behavior in that domain, and the stakes involved. A system that applies the same autonomy to everything will either interrupt too much or act too freely. Both failures erode trust.

THE AUTONOMY DIAL — FOUR POSITIONS

THE AUTONOMY DIAL — FOUR POSITIONS

=====================================

Position 1: OBSERVE AND SUGGEST

AI advises. Never acts. User controls everything.


Position 2: ACT WITH CONFIRMATION

AI proposes. Waits for approval. User reviews.


Position 3: ACT WITH NOTIFICATION

AI acts. Tells you what it did. Undo available.


Position 4: ACT AUTONOMOUSLY

AI handles it. Details available if you want them.



CALIBRATION SPEC:

─────────────────────────────────────

Low reversibility tasks

(sending messages, making purchases)

→ Default to Position 2

High reversibility tasks

(drafting, organizing, categorizing)

→ Default to Position 3 or 4


Adaptation rule:

Consistent approvals without changes

→ System suggests moving to higher autonomy


Adjustment mechanism:

“Always ask before doing this” = one tap, in context

Never requires navigating to settings



ANTI-PATTERN:

Same confirmation for archiving email

and sending message to new client.

That’s not safety. That’s training users

to ignore safety.

Pattern 3: Explainable Rationale

— Show your reasoning, not your math

When the AI makes a decision, it explains why. Not the technical mechanism. The reasoning a thoughtful person would recognize as valid.

Users who understand why can evaluate whether the logic applies to their situation. Users who don’t understand why can only accept or reject blindly. Blind acceptance isn’t trust. It’s resignation. Resigned users are one bad experience from walking away.

EXPLAINABLE RATIONALE — DESIGN SPEC

EXPLAINABLE RATIONALE — DESIGN SPEC

======================================

WELL-DESIGNED:

“I suggested this meeting time because you have

a 2-hour focus block before it and your calendar

shows you prefer morning calls with this contact.”

→ Specific factors

→ Right level of detail for evaluation

→ No more, no less


POORLY-DESIGNED:

“AI-powered recommendation”

→ No explanation at all

“Selected based on transformer attention weights

across your behavioral embedding space”

→ Technical. Useless to the user.

“This matches your history”

→ Accurate but unhelpful. Which history? How?


CALIBRATION:

Stakes determine depth.

Financial recommendation → more explanation.

Content organization → less explanation.

Expert user → wants the reasoning.

New user → wants confidence that reasoning exists.


BEST PRACTICE:

Make explanation available on demand.

Small “why?” affordance that expands rationale.

Present for those who want it.

Invisible for those who don’t.

The difference between “Based on your preferences” and “Because you rescheduled your last three Thursday afternoon meetings” is the difference between a vague acquaintance and a trusted advisor. Specificity is credibility.

Pattern 4: Confidence Signals

— Honest AI admits what it doesn’t know

Visual or linguistic indicators of how certain the AI is about a recommendation, prediction, or action. Communicated in a way users can interpret and act on.

AI systems are not uniformly reliable. They’re more accurate in some domains. More certain about some outputs. A system that presents all outputs with equal confidence teaches users to either trust everything — dangerous — or trust nothing — useless.

Calibrated confidence signals help users build an accurate mental model of when to rely on AI judgment and when to apply their own.

CONFIDENCE SIGNALS — DESIGN SPEC

CONFIDENCE SIGNALS — DESIGN SPEC

===================================

WELL-DESIGNED:

“I’m confident about X, but less sure about Y —

you may want to verify.”

→ Language reflects actual uncertainty

→ Specific about what the uncertainty IS:

“I don’t have recent data on this”

“This is outside my expertise”

“There are multiple valid approaches here”

→ Visual differentiation between high/low confidence

(without being alarmist about uncertainty)



POORLY-DESIGNED:

“73% confident”

→ What does that mean? Compared to what?

Uniform language implying equal certainty everywhere

→ Teaches users the wrong mental model

Uncertainty markers so prominent they

undermine confidence in everything

→ The system that’s always uncertain is

the system that’s never used



PATTERN WORTH STEALING:

The Counterfactual.

Instead of: “I’m not confident about this”

Say: “If you had X additional information,

I could give a more definitive answer.”

→ Transforms uncertainty from dead end

into productive next step

Think of confidence signals like a weather forecast. “60% chance of rain” is useless. “Rain likely after 3pm — bring an umbrella for the commute home” is actionable. The difference isn’t precision. It’s usability.

Pattern 5: Action Audit and Undo

— The safety net that makes freedom possible

A complete, accessible record of what the AI has done on the user’s behalf. With the ability to reverse actions, understand effects, and learn from history.

Autonomous systems make mistakes. This isn’t a failure condition. It’s a design condition. The question is never whether the AI will act incorrectly. The question is whether users can recover when it does. Systems that make recovery difficult are systems users stop trusting with anything important.

The audit trail serves a second function. It’s how users learn what the AI is actually doing. Users who can see the history build better mental models. Better mental models mean better direction.

ACTION AUDIT AND UNDO — DESIGN SPEC

ACTION AUDIT AND UNDO — DESIGN SPEC

======================================

WELL-DESIGNED:

├── Chronological log of AI actions

│ → Plain language, not technical

│ → Accessible from main interface

├── One-click undo for reversible actions

│ → Clear indication: reversible vs. not

├── Related actions grouped by session

│ → Review a “batch,” not a list of atoms

└── Context for each action:

→ What triggered it

→ What it changed

→ What the alternatives were



POORLY-DESIGNED:

├── Undo buried in settings

├── Log shows “API call to calendar service”

│ instead of “Moved your 3pm to Thursday”

├── No indication of what’s reversible

└── History disappears after session



THE IRREVERSIBILITY PROTOCOL:

Some actions cannot be undone.

Message sent. Payment processed. File deleted.



These require special treatment:

1. Explicit warning before action

2. Confirmation step regardless of autonomy level

3. Clear acknowledgment: “This cannot be reversed”


No exceptions. No matter the dial position.

Think of the audit trail like a flight recorder. Pilots don’t check it every flight. But knowing it exists — knowing every action is documented and recoverable — is what makes it possible to fly at all.

Pattern 6: Escalation Pathway

— Knowing when to hand off is the highest form of intelligence

A designed mechanism for the AI to transfer control to a human when it encounters ambiguity, uncertainty, or situations beyond its competence. In a way that preserves context and enables the human to pick up without starting over.

The failure mode that destroys trust fastest is an AI that confidently handles situations it shouldn’t. A system that knows its limits and escalates gracefully is far more trustworthy than one that pushes through uncertainty.

Escalation is not failure. It’s evidence the system is honest about what it can and can’t do.

ESCALATION PATHWAY — DESIGN SPEC

ESCALATION PATHWAY — DESIGN SPEC

===================================

TRIGGER CONDITIONS:

├── Uncertainty exceeds threshold

├── Stakes exceed normal range

├── Explicit user request

└── Novel situation with no precedent


WELL-DESIGNED HANDOFF:

├── Context-preserving: human receives everything

│ needed to understand the situation

├── Reason explained: “This involves a financial

│ decision over your usual threshold —

│ I want to make sure you’re in the loop”

└── Easy return path to AI handling

after human resolves the escalation


POORLY-DESIGNED HANDOFF:

├── “Something went wrong. Please try again.”

│ → Context dropped. User starts over.

├── Escalation indistinguishable from failure

│ → User thinks system is broken

├── No return path to AI after intervention

│ → User stuck in manual mode

└── Over-escalation / Under-escalation

→ Both destroy calibration


THE PRINCIPLE:

A great assistant doesn’t try to handle

everything. A great assistant knows exactly

when to say: “This one needs you.”

These six patterns form one system

These patterns aren’t independent features. They’re a circulatory system. Remove one and the others weaken.

THE EARNED AUTONOMY SYSTEM

THE EARNED AUTONOMY SYSTEM

=============================

Intent Preview

→ Sets up the interaction

↓

Autonomy Dial

→ Determines how often Preview appears

↓

Explainable Rationale + Confidence Signals

→ Build understanding that makes users

comfortable with higher autonomy over time

↓

Action Audit + Undo

→ Provide the safety net that makes

higher autonomy feel safe to try

↓

Escalation Pathway

→ Handles situations where the system

reaches its limits

↓

RESULT: EARNED AUTONOMY

Users have enough understanding of system behavior

to let it act with minimal intervention.


They trust it will:

- Behave predictably

- Explain itself honestly

- Recover gracefully when wrong

Earned autonomy. That’s the goal. These six patterns are how you get there.

The mistake most teams make with these patterns

Most teams add these patterns as features. Discrete UI elements. Designed. Implemented. Shipped. Checked off.

The teams that get this right treat them as principles that shape every design decision from the beginning.

The question “does this interaction need an Intent Preview?” only makes sense if you’ve already asked “what’s the right autonomy level for this task?” Which only makes sense if you’ve already asked “how reversible is this action and how well does the user understand the AI’s behavior here?”

These patterns answer those questions. They need to be in the room at the earliest design conversations. Not added at the end when the core experience is locked.

If you’re building a product where AI acts on behalf of users, the time to think about these patterns is now. Before the happy path is designed. While there’s still room to make the architecture of trust part of the foundation.

Not on top of it. Inside it.

Next: #011:The AI That Made My Team Argue More — and Decide Better.→

P.S. — I originally designed these six patterns as a checklist. A quality bar. Ship a product, check the boxes, move on. But watching real users interact with systems I built changed my thinking. These patterns aren’t a checklist. They’re a language. The language humans use to negotiate trust with machines. And like any language, fluency matters more than vocabulary. A product that implements all six patterns mechanically will still feel wrong. A product that deeply understands why each pattern exists — that trust is incremental, that surprise is the enemy, that honesty about limitations builds more confidence than flawless performance — will feel right even if its implementation is imperfect. I stopped optimizing for coverage and started optimizing for fluency. That shift changed everything.

#AgenticUX #AIDesign #UXDesign #ProductDesign #IntentFirst #HumanAI #FutureOfDesign

A new CEO arrives. The mandate comes down fast. Use AI. Every team. Every leader. No exceptions.

Licenses get signed. Tools get deployed. Training sessions run across the organization. Adoption dashboards show green.

Six months later, nothing has changed. The same meetings. The same bottlenecks. The same rework cycles. The AI leaders themselves — the peop…

Read more

Tuesday afternoon. A designer at Verizon leans back in her chair, pinches the bridge of her nose, and sighs.

She has spent forty minutes hunting through Slack threads for a stakeholder decision made three weeks ago. She will not find it. She will guess instead. She will guess wrong. The rework will cost two sprints.

She will never file a complaint about t…

Read more

Picture this. Forty-two designers. Enterprise AI stack fully deployed. Gemini. NotebookLM. Every approved tool is available.

Nine months in, I pulled the metrics.

Designers were still spending half their day in clarification meetings. Edge cases were still exploding in development. Strategic thinking was still getting crushed by “just push the pixels” pre…

Read more

Imagine this. A team ships a smart assistant. It books flights. It drafts emails. It schedules meetings. Every function works.

Users abandon it within three weeks.

The system did exactly what it was told. It never understood what anyone actually needed.

This happens constantly. The gap between the request and the real need has a name. And a framework built to close it. It has existed for over thirty years. Most AI teams are building without it.

Jobs-to-be-Done.

The Origin Story Most People Get Wrong

The creator is not who you think.

— founder of Strategyn — developed the core concepts in the late 1980s at Cordis Corporation. He built it into a rigorous, repeatable methodology called Outcome-Driven Innovation. He holds patents on the process. His work is among the most precise and operationally useful frameworks for understanding what people actually need — not what they say, not what they do, but the underlying progress they are trying to make.

Most people credit Clayton Christensen. That is a misattribution.

Christensen engaged with Ulwick’s thinking. He incorporated it into his own innovation theory. He popularized it enormously — the famous Milkshake Marketing story, his book Competing Against Luck (2016). His contribution to spreading the ideas was real and significant.

But the origin is Ulwick’s.

The core insight they both point to: people do not buy products. They hire them to do a job in their lives. This has been part of the product design vocabulary for decades. Most experienced designers have encountered it. Many have used it.

So why write about it now, as if it is urgent?

Because the role of the framework just changed completely.

For most of its history, JTBD was a research input. A way to understand users that then got translated into interface design. Useful. Sometimes transformative. But always one step removed from the product itself.

In the age of AI, that step disappears.

JTBD stops being research input. It becomes system design language. The gap between understanding the job and defining what the system does closes almost completely.

The framework did not change. What you do with it changed. That is why the stakes are different now.

People Don’t Want Your Product. They Want Progress.

For anyone coming to this fresh.

The Jobs-to-be-Done framework says users do not want your product. They want to make progress in a specific situation in their lives. They “hire” your product to help them make that progress.

Think of it like hiring a contractor for your house. You do not care about the contractor’s tools. You care about the kitchen you want to cook in.

The job has three components:

The functional job. What the user is literally trying to accomplish. Book a flight. Write a report. Organize a project.

The emotional job. How the user wants to feel while doing it — or as a result. Confident. In control. Relieved. Impressive to others.

The social job. How the user wants to be perceived. Competent. Thoughtful. A good parent. A reliable colleague.

All three are real. All three drive behavior. Designing for only the functional job is the most common way to build something technically correct that nobody loves.

The famous Milkshake example proves this.

McDonald’s discovered their morning milkshake customers were not hiring the milkshake because they were hungry. They were hiring it to make a long, boring commute more interesting. To keep them full until lunch. The milkshake was easy to hold. It took a long time to finish. It felt like a small treat.

The job was never “consume a milkshake.”

The job was “survive a boring commute and arrive at work having done something slightly nice for myself.”

That insight changed everything about how they thought about the product. Not the recipe. The purpose.

In the 2.0 Era, JTBD Made Better Interfaces

In the UX 2.0 era, JTBD research produced better screens.

If you understood that users were not hiring your app to complete tasks — they were hiring it to feel in control of a chaotic situation — you designed differently. Less about speed. More about confidence. Less about features. More about clarity. Less about what the system could do. More about what the user could understand and trust.

This was valuable. It elevated design from “make the flow work” to “serve the human goal behind the flow.”

But a translation step always existed.

Understand the job. Decide what that means for the interface. Design the interface. Hope users accomplish their jobs through it.

The job informed the design. The user still did the work.

Four steps between insight and impact. Every step leaked fidelity.

In the 3.0 Era, The Job Becomes the System’s Operating Instructions

When AI acts on behalf of users, the translation step compresses dramatically.

The AI needs to know the job — not as inspiration for design decisions, but as operational instructions. The job structure becomes the system’s decision-making framework. No translation layer. No fidelity loss.

A concrete example makes this clear.

Scenario: A user asks an AI assistant to help them prepare for a difficult conversation with their manager about workload.

Surface request: “Help me prepare for a meeting.”

Five words. A dozen possible interpretations. Here is what the job actually looks like, broken down:

Functional: Have the conversation without it going badly. Communicate clearly. Reach a resolution.

Emotional: Feel prepared rather than anxious. Feel heard. Not feel like a complainer — feel like a problem-solver.

Social: Be seen as a capable professional who manages up well. Not as someone who cannot handle their workload.

Success criteria: Leave the meeting with either a concrete plan to address the overload, or a clear understanding of why the current situation is necessary and for how long.

What they want to control: The specific things they say. The framing of the problem. Their own words.

What they are happy to delegate: Finding frameworks for this kind of conversation. Anticipating how the manager might respond. Structuring the talking points.

Now watch the difference.

Without the job structure: “Here are some tips for difficult workplace conversations. 1. Be specific about the issue. 2. Focus on solutions...”

Generic. Possibly useful. Not designed for this person’s actual situation. A pamphlet, not a partner.

With the job structure: The AI knows this person wants to feel prepared and professional, not like they are complaining. It knows success means leaving with a plan or an explanation. It knows they want to own the specific language but want help with structure and anticipation.

Now the AI frames the conversation as problem-solving rather than grievance. It anticipates the manager’s likely responses. It prepares them for the moment when they need to push back without sounding defensive.

The JTBD understanding did not inform an interface.

It became the system’s operating instructions.

Four Questions That Separate Useful AI From Generic AI

When doing JTBD research to inform AI system design, four questions go deeper than the standard framework.

1. What Does Success Feel Like — Not Just Look Like?

Functional success criteria are easy. The flight is booked. The report is written. The meeting is scheduled.

But AI systems optimizing purely for functional success often feel hollow. Like a gift wrapped in newspaper.

The question that matters: when this job is done well, what does the user feel? What are they no longer worried about? What can they now do that they could not before?

This shapes how the AI communicates, not just what it does.

An AI that books a flight and says “done” versus one that says “I found an option that gets you there before your meeting with two hours to spare and gets you home by 10pm — want me to book it?” serves the same functional job in completely different ways.

Same task completed. Entirely different experience.

2. What Does the User Want to Remain in Control Of?

This question directly shapes autonomy design — how much the AI does versus how much it surfaces for human decision.

There is a part of almost every job that the user wants to own. The specific words in an important email. The final call on a significant purchase. The decision about what to tell their child.

Understanding this is not about UX preferences. It is about respecting the boundary between “jobs worth delegating” and “decisions worth owning.”

Getting this wrong — having the AI do things the user wanted to control — is one of the fastest ways to break trust. It is the digital equivalent of someone finishing your sentences. Helpful in theory. Infuriating in practice.

3. What Would Make This Feel Wrong Even If It Is Technically Correct?

This question surfaces the emotional and social dimensions that functional analysis misses entirely.

A travel AI that books the cheapest available option may be technically correct. But if the user was hiring the AI partly to feel like they made a smart, considered choice — not just the cheapest one — the technically correct outcome produces the wrong feeling.

The answer to this question often becomes a hard constraint on AI behavior: “Never optimize purely for price without surfacing the tradeoff.”

Correct and wrong at the same time. That is what happens when you ignore the emotional job.

4. What Context Would Change the Job Entirely?

Same user. Same request. Completely different jobs.

“Help me draft a message to my team” on a normal Monday is a productivity job. The same request the day after a major organizational change is an emotional leadership job — the user needs to communicate clearly while managing their own feelings and their team’s uncertainty.

AI systems that detect contextual signals and adjust their understanding of the job are dramatically more useful than systems that treat every instance of the same request as identical.

Context is not metadata. Context is the job itself.

Research Looks the Same. The Output Looks Completely Different.

The interviews are similar. The analysis diverges sharply.

In a standard JTBD research session, you listen for moments of struggle and the progress the user is trying to make. You ask: what were you doing when you first realized you needed this? What did you try before? What almost stopped you?

When designing for AI, you listen for the same things. But you also build a model of the job specific enough to be operationalized. Specific enough for a machine to act on.

After the research, instead of producing persona documents and journey maps, you produce:

JTBD SYSTEM SPECIFICATION

Job Statements

─────────────────────────────────

Format: “When [situation], I want to [motivation],

so I can [outcome].”

Clear. Structured. Testable.

Success Criteria

─────────────────────────────────

Functional: [specific, measurable outcomes]

Emotional: [how the user should feel when done]

Social: [how the user should be perceived]

Autonomy Map

─────────────────────────────────

DELEGATE → [parts the user wants the AI to handle]

OWN → [parts the user must control]

BOUNDARY → [the line between the two]

Context Triggers

─────────────────────────────────

Signal: [what changes in the environment]

Job Shift: [how the underlying need transforms]

Response: [how the system should adapt]

These artifacts feed directly into AI system design. They are not inspiration. They are specifications.

Not a mood board. A blueprint.

The Framework Did Not Change. The Stakes Did.

Jobs-to-be-Done has always been about a deceptively simple insight: people are not doing what you think they are doing. They are not using your product. They are trying to make progress in their lives. Your product is one thing they hire to help.

What Ulwick built at Strategyn — and what I have applied in practice — is a way to make that insight operational. Not a mindset shift. A rigorous process for surfacing unmet needs with enough specificity to drive real product decisions.

Acting on this insight has always required more than surface-level task analysis. It demands genuine curiosity about human motivation. Willingness to sit with ambiguity. Skill at building models of behavior that go below what users can articulate directly.

None of that changes.

What changes is that the model you build does not stay in your head or a research document. It goes into the system. It shapes what the AI does. It determines whether an autonomous system serves the human behind the request — or just the request itself.

The framework is the same. The stakes of applying it well are higher than they have ever been.

If you want to go deep on the original methodology, Tony Ulwick’s work at Strategyn is where to start. It is the most rigorous version of this thinking that exists.

P.S. — I spent years treating JTBD as a research exercise. Interesting but academic. Something you did in discovery workshops and then filed away. It took building AI systems that failed — systems that completed every task and satisfied no one — to understand that the job IS the design. Not an input to it. The design itself. That was a humbling realization. The framework had been telling me this for years. I was not listening closely enough.

This piece is a companion to [#002 The Interface Used to Protect Us From Bad Design Decisions. AI Removed the Buffer.→]. If you found the framing of intent-as-system-parameter useful there, this goes deeper on the research method behind it.

If you are working on AI products and want to think through how to structure intent research for your context — reach out. This is one of the conversations I find most valuable.

#JTBD #UXResearch #AIDesign #ProductDesign #intentFirst #DesignThinking #FutureOfDesign

Picture this.

A mother sits on her couch at 9pm. Kids finally asleep. She opens a travel app. She is looking for a family vacation — somewhere the kids will talk about for years. Not a beach resort. An adventure. She has $3,000 and a week in July.

In the old world, she scrolls. She filters. She reads reviews. She opens six tabs. The interface is clunky, but it gives her control. She finds what she wants — eventually. The app did not understand her. But it gave her enough room to understand herself.

Now picture the new world.

She tells the AI agent: “Plan a family trip for late July, under three thousand dollars.”

The AI books a beachfront all-inclusive in Cancun. Four-star reviews. Under budget. Technically perfect.

Her kids wanted to see bears in Yellowstone.

The system executed flawlessly. And it got the job completely wrong. Because nobody defined what “family vacation” meant for this family.

The Real Shift Is Not AI Itself. It Is Where Your Understanding Goes.

Something has changed in design. Not the tools — tools change constantly and designers adapt. Not AI being added to products — that has been happening since recommendation engines and autocomplete.

The change is more specific. And understanding exactly what shifted matters more than the broad-strokes version of this story.

A quick history, with a correction built in.

UX 1.0: Can the user figure it out? The web was new. Software was confusing. The designer’s job: make things learnable and functional. Nielsen’s heuristics. Information architecture. User testing. Success meant the user could complete the task.

UX 2.0: Does the user feel good doing it? Digital products matured. Competition intensified. Usability became table stakes. The job expanded: delight, emotion, brand coherence. Journey mapping. Design systems. Jobs-to-be-Done research. Success meant the experience felt right.

UX 3.0: What is “it” — at the level of human intent? AI handles the mechanics. The designer’s job shifts to defining what the system should actually accomplish for the human it serves.

Here is the correction. The idea of designing from user intent is not new. Good designers have always done this. Jobs-to-be-Done theory was formalized in the 1990s. Don Norman wrote about designing for human goals in 1988. The best UX practitioners in the 2.0 era were not just designing flows — they were understanding the deeper motivations behind them.

So what actually changed?

Same Research. Different Destination.

The method has not changed. The destination has.

In the 2.0 era, a designer who deeply understood user intent used that understanding to design a better interface. The intent informed the layout. The navigation. The labels. The flow. But the user still operated the interface. The designer’s understanding was translated into screens. Users interacted with those screens to reach their goal.

The interface was the medium through which intent became action.

In the 3.0 era, AI receives intent more directly. The user says “find me a flight to Tokyo for next month, under $800, with no more than one stop.” The system acts. The interface does not disappear — but for many interactions it becomes thinner. Optional. A confirmation layer rather than an operational one.

This changes where the designer’s understanding of intent needs to go.

Instead of translating intent into screen layouts, designers now translate intent into the parameters that govern AI behavior.

SYSTEM SPEC: Intent-to-Parameter Translation

2.0 Output:

- Wireframes, prototypes, screen flows

- Navigation architecture

- Visual hierarchy and interaction patterns


3.0 Output:

- Structured job statements (functional/emotional/social)

- Success criteria specific enough for AI optimization

- Autonomy boundaries (delegate vs. control)

- Context triggers (when the same request means something different)

- Constraint hierarchies (what matters most, second-most, least)


Input (unchanged):

- Deep user research

- Contextual inquiry

- JTBD interviews

- Behavioral observation


Key Difference:

- 2.0: Understanding → screens → user operates → goal achieved

- 3.0: Understanding → parameters → AI operates → goal achieved

The research is identical. The same interviews. The same frameworks. The same deep listening.

What changed is what the designer does with the output. Not a better filter UI. A set of decision parameters for an autonomous system.

The Shock Absorber Theory of Interface Design

This is the part that is genuinely new. And it changes everything.

In the 2.0 era, if a designer’s understanding of user intent was slightly off, the interface absorbed it. A well-designed navigation gave users enough control to find their own way — even when the designer had not perfectly anticipated their path. A clear layout let users scan and self-correct.

The interface was a shock absorber. It sat between imperfect design decisions and user goals. It absorbed the bumps.

Think of it physically. A car with good suspension handles rough roads. The driver barely notices the potholes. The ride is smooth enough. The shock absorber does not fix the road. It makes the road survivable.

The interface did the same thing for design decisions. Imperfect understanding? The user could still navigate. Wrong assumptions about priority? The user could reorder their own workflow. Missed context? The user could fill in the gaps manually.

When AI handles execution, that shock absorber is gone.

The driver is no longer driving. The AI is. And it is driving at full speed over every pothole the designer left in the road — because it does not know they are there.

If the intent has been modeled incorrectly. If the success criteria are defined imprecisely. If the constraints are specified incompletely. The AI acts on that wrong model. Confidently. At speed. Sometimes irreversibly.

The imprecision that a good interface could absorb becomes a system failure when AI executes on behalf of the user.

The quality of intent understanding is no longer just good practice.

It is structural. It determines whether the system works or does not.

One Family. Two Eras. The Difference Is the Buffer.

Let me make this concrete.

A user wants to book a family vacation. In the 2.0 world, a designer researching this user learns: they find too many options overwhelming. They want to feel confident in their choice. They care more about their kids’ experience than price.

The 2.0 designer uses this to build a better booking interface. Fewer options surfaced at once. Clear social proof. Filters that highlight family-friendliness.

The user still makes every decision. The designer made the decision-making environment better.

In the 3.0 world, an AI agent books this vacation. For the AI to do its job well, the designer needs to have defined something structured enough to act on:

SYSTEM SPEC: Family Vacation Agent — Intent Model

Job Statement:

“Create a family vacation the kids will remember”

Success Criteria:

- Kids report enjoying the experience (functional)

- Parents feel it was worth the investment (emotional)

- Family creates shared memories (social)

Constraints:

- Budget: $3,000 max

- Dates: July 20–27

- Travel: Max 4-hour flight

- Type: Adventure/exploration, NOT resort/beach

Priority Hierarchy:

1. Experience quality (highest weight)

2. Price

3. Convenience (lowest weight)

Autonomy Boundaries:

- DELEGATE: Flight search, hotel search, itinerary drafting

- CONTROL: Final confirmation before any booking

- ESCALATE: If budget conflict with experience quality

Context Triggers:

- If kids are under 6 → prioritize logistics ease

- If anniversary falls during trip → add one adults-only evening

- If user has booked adventure trips before → increase autonomy

This is the intent translated into system parameters. The AI uses this structure to decide which options to surface. What to prioritize. When to ask versus when to act.

The research that produced this understanding looks identical to 2.0 research. The same interviews. The same JTBD framework. The same deep listening.

The difference: the output is not a better filter UI. It is a set of decision parameters for an autonomous system. And if those parameters are wrong, there is no interface to catch the mistake.

Three Shifts That Define the New Era

What the designer builds is changing.

Alongside wireframes and prototypes, the artifacts that matter now include: intent models, agent role definitions, autonomy parameters, success criteria frameworks. These are not peripheral. They are often what determines whether the system works.

Where the highest-leverage design decisions live is changing.

The most important decisions now happen before Figma opens. What does this system need to understand about the user to act well on their behalf? What should it do autonomously? What should it surface for human decision? What does success look like — in terms specific enough that an AI can optimize for it?

The cost of imprecision is changing.

A slightly wrong mental model produced a slightly confusing interface. Users worked around it.

A slightly wrong intent model produces an AI that confidently does the wrong thing. At speed. At scale.

The stakes of getting the understanding right have increased by an order of magnitude.

The Core Has Not Changed. The Consequences Have.

The fundamental discipline is the same: understanding people deeply enough to know what they are actually trying to accomplish in their lives. Not just what they are doing in your product.

This has always been the core of good design. JTBD. Contextual inquiry. Ethnographic research. The five whys. All tools for getting past surface behavior to underlying intent.

That work is unchanged.

What changed is that this understanding is now the direct input to system behavior — not a step removed through interface design. The quality of the understanding is more exposed. More consequential. More directly testable.

The AI either acts correctly on the intent. Or it does not.

There is no interface to soften the gap.

Good designers have always known that understanding intent was the job. UX 3.0 makes that true for the whole system — not just the human doing the design.

The One Question That Reorients Everything

If you are trying to orient yourself to this shift, the most useful question is not “what tools should I learn?”

It is this:

If an AI were going to act on behalf of my user, what would it need to know?

Not just what the user wants to do. What they are trying to accomplish. What success looks like. What they want to control. What constraints matter and which do not. What context would change everything.

SYSTEM SPEC: The Reorientation Exercise

Step 1: Pick one user task your product handles today

Step 2: Imagine an AI agent will handle it autonomously tomorrow

Step 3: Write down everything the AI would need to know to do it WELL

(not just correctly — well)

Step 4: Notice the gap between what you wrote and what your

current design artifacts capture

That gap is the translation layer.

That gap is where UX 3.0 lives.

That gap is your new job.

Answer that question rigorously, and you have done the most important design work for the AI era. Work that looks almost identical to the best design work of the previous era — applied to a context where it matters more than ever.

That is what UX 3.0 feels like from the inside. Not a revolution. A raising of the stakes on work that was always worth doing well.

P.S. — I resisted this framing for a long time. “The shock absorber is gone” felt too dramatic. Too neat. I kept thinking: interfaces will not disappear. Screens still matter. People still click things. All true. But then I watched a user test where an AI assistant rebooked someone’s hotel to save $40 — and moved them from a quiet boutique hotel near the conference venue to a highway-adjacent chain twenty minutes away. The user had not specified “location matters.” The system had no way to know. In the old world, the user would have seen both options on a screen and chosen the boutique in two seconds. The buffer would have caught it. In this test, the buffer was gone. The AI acted on what it knew. And what it knew was incomplete. That is when I stopped resisting the metaphor. The shock absorber is real. And we are the ones who have to rebuild it — not as an interface, but as an architecture of understanding.

Want to go deeper on the framework behind this? Jobs-to-be-Done is the most useful lens I have found for structuring intent in a way AI systems can actually use. I wrote a companion piece on exactly how to apply it: [#003: A 30-Year-Old Research Framework Is Now Writing AI Instructions. Most Teams Don’t Know It Exists. →]

#UXDesign #AIDesign #FutureOfDesign #ProductDesign #IntentFirst #DesignThinking #JTBD

Picture this.

A product team demos their new AI travel agent. It works. The model responds in 400 milliseconds. The booking goes through without a single error.

Then someone checks the result. The system just booked a red-eye through Atlanta for a user who explicitly hates layovers. It optimized for price. The user was optimizing for sanity.

The room goes quiet. Not because the technology failed. It didn’t. The silence is because everyone realizes the same thing: nobody told the system what mattered to the human on the other side.

The Gap Is Not Technical. It Is Human.

There is a gap at the center of almost every AI product shipping right now.

Not a compute gap. Not an infrastructure gap. Not a talent gap.

A translation gap.

Nobody has defined — with precision, with depth, with structural rigor — what the AI is supposed to accomplish for the person using it.

Not at the surface level. At the level that matters:

What is this person actually trying to achieve in their life? What does success feel like for them — not just look like on a dashboard? What do they want to keep in their own hands? What context would flip the entire equation?

This is the work that separates AI products people integrate into their lives from AI products people try once and delete.

This work has a name. It is design.

What AI Actually Needs to Serve Humans

An AI system that acts on behalf of users — booking travel, managing communication, executing tasks — needs more than instructions.

It needs a model of the human it serves.

Not a demographic profile. Not a marketing persona pinned to a whiteboard. A working model of:

• The goal beneath the request. “Book a flight” is a surface instruction. “Arrive at my daughter’s recital feeling like the logistics didn’t consume my week” is the actual job.

• What success really means. Functionally. Emotionally. Socially. How this person wants to feel and be perceived when the task is done.

• The autonomy boundary. What they want to control themselves. Where they genuinely welcome delegation. These two zones are different for every person, every context, every level of trust.

• The context triggers. When the same request means something completely different. A “quick dinner reservation” on a Tuesday night versus the night before an anniversary — same words, different universe.

Without this model, AI operates on the surface of requests. It does what was asked. Not what was needed.

The result is technically correct. Humanly insufficient.

Users feel that gap immediately. Even when they cannot name it.

Engineers Build Engines. Designers Build the Destination.

Here is why this is a design problem. Not an engineering problem. Not a product problem.

Engineers build systems that execute any instruction perfectly. What no engineering process produces is the translation of messy, contextual, emotionally charged human goals into instructions precise enough for a machine to act on well.

Product managers define features and prioritize roadmaps. What they do not do is sit with a user long enough to understand that the job is not “book a flight” but “protect my energy for the things that actually matter this week.”

This translation — from human intent to system behavior — is a design skill.

It requires methods designers have spent decades developing: deep user research, contextual inquiry, Jobs-to-be-Done analysis, the ability to construct accurate models of human motivation from incomplete and contradictory evidence.

It also requires something no method can teach: genuine curiosity about why people do what they do. And the patience to stay with that question until the real answer surfaces.

Designers carry this. It is what the profession has always cultivated — even when the output was “just” an interface.

Now the output is an AI system that acts in the world on behalf of real people.

The translation has never mattered more.

The Interface Was a Shock Absorber. AI Ripped It Out.

In the era of interface design, imprecision was expensive but recoverable.

A designer misread user intent. Built the wrong screen. Users hit friction. Some gave up. The product underperformed. The team iterated.

Bad, yes. But bounded.

A confused user clicked the wrong button. Saw an error message. Navigated back. Tried again. The interface — however flawed — gave them control over every step. It absorbed the designer’s mistakes like a shock absorber on a rough road.

When AI acts autonomously, that shock absorber is gone.

A misunderstood intent does not produce a confusing screen. It produces an AI that confidently does the wrong thing. Books the wrong flight. Sends the message the user was not ready to send. Makes the purchase the user was still considering. Optimizes for price when the user was optimizing for peace of mind.

And it does this at the speed of automation. Sometimes irreversibly. With the confidence of a system that has no idea it is wrong.

The buffer is gone. Imprecision is no longer absorbed by the interface. It becomes system behavior.

This is why the translation layer matters now more than at any point in design history. Not because understanding intent is a new idea. It has always been central to good design. But because the cost of getting it wrong has increased by an order of magnitude — and the cost of getting it right flows directly into whether the product works at all.

What I Found When I Went Looking

I have spent the past several years building AI systems inside large organizations — at Verizon, at Dyson, across multiple enterprise environments. I did not start with AI. I started with people.

At Verizon, I ran hour-long interviews with 16 designers. Not about AI. About their actual work. What surfaced: 40+ distinct friction points, ranked by severity and business impact. The AI architecture came from that diagnosis — not from whatever tools were available.

Here is what I have consistently observed:

The conversation about what the AI should do for users is almost always the shortest conversation in the room.

Engineers spend weeks on model selection and infrastructure. Product managers spend months on feature prioritization. Designers, when they are in the room at all, get brought in to make the interface look right — after the fundamental decisions about what the AI does and why have already been made.

The translation layer is being skipped. Or worse: filled in by assumption.

But the diagnosis revealed something I had not anticipated.

The translation layer does not just need to be filled. It needs infrastructure underneath it.

Teams were not failing because they lacked understanding of their users. Many had strong instincts about user intent. They were failing because the organizational knowledge that should have fed the translation — past decisions, research findings, contextual rationale — was scattered. Tribal. Inaccessible.

The translation layer was empty not from lack of skill. From lack of architecture.

So I built both. Knowledge infrastructure first — a three-layer system that made everything the organization knew queryable. Then the agents that operated on top of it: validation systems, edge case detection, strategic design scaffolding, and a thinking partner built for human-AI-human collaboration.

The result was not faster design. It was different design. More strategic. More considered. Operating at the level the role always should have required.

That work taught me what the abstract argument never could:

The translation layer is not a single act of understanding. It is an architecture.

It has components. It requires infrastructure. And those components can be named.

The Translation Architecture: Five Interlocking Systems

Through this work — and the thinking it forced — I arrived at a set of interconnected frameworks that give the translation layer structure.

System 1: Jobs-to-be-Done as Operating Instructions

JTBD has been a research framework for 30 years. In the AI era, it becomes something more direct: the operating instructions for how an AI system behaves.

The functional, emotional, and social dimensions of the job do not inform an interface. They become the parameters that govern system behavior.

SYSTEM SPEC: Intent Model

Inputs:

- User research (contextual inquiry, JTBD interviews)

- Behavioral data (usage patterns, abandonment signals)

- Contextual variables (time, environment, emotional state)

Output:

- Structured job statement with functional/emotional/social layers

- Success criteria (measurable, specific, testable by AI)

- Context triggers (conditions that change the job entirely)

Success Criteria:

- AI can act on the model without human clarification 80%+ of the time

- Users confirm the system “understood what I actually needed”

Constraints:

- Must update as user behavior evolves

- Must handle ambiguity gracefully (ask, don’t guess)

System 2: The Autonomy Map

Every job has parts worth delegating and decisions worth owning. The map between these two — for a specific user, in a specific context — determines where the AI acts and where it steps aside.

Most product teams never build one. They draw the line by default. Users feel the mismatch immediately.

System 3: The Autonomy Dial

Once something is delegated, how autonomous should the AI be? Four positions:

SYSTEM SPEC: Autonomy Dial

Positions:

1. SUGGEST — AI recommends, human decides and acts

2. CONFIRM — AI prepares action, human approves

3. NOTIFY — AI acts, human is informed after

4. AUTONOMOUS — AI acts, no notification needed

Calibration Inputs:

- Reversibility (can this be undone?)

- Familiarity (has user done this before?)

- Stakes (what’s the cost of getting it wrong?)

- Context (routine Tuesday vs. high-stakes Thursday)

Constraints:

- Not a single setting. A contextual, evolving calibration.

- Trust accumulates through consistent correct behavior.

- Dial moves toward autonomy as trust is earned, never assumed.

System 4: Knowledge Architecture

AI is only as good as the context it can access. The knowledge layer — structured, queryable, maintained — transforms a general-purpose model into something that can serve specific humans in specific situations.

Without it, the translation layer has nothing to work with.

System 5: Agentic UX Patterns

Six interaction patterns that create the conditions for earned autonomy:

SYSTEM SPEC: Earned Autonomy Patterns

1. Intent Preview — Show the user what you understood before acting

2. Autonomy Dial — Let the user adjust delegation levels

3. Explainable Rationale — Show why the AI chose this action

4. Confidence Signals — Communicate certainty levels honestly

5. Action Audit — Provide full history of autonomous decisions

6. Escalation Pathway — Clear route back to human control

Success Criteria:

- Users report feeling “in control” even when AI acts autonomously

- Trust metrics increase over time, not just at launch

- Recovery from errors is graceful, not catastrophic

None of these are theoretical. Each emerged from building systems that real people use. From watching where they succeeded. From understanding why they broke when they broke.

What This Means for Design: The New Deliverables

The translation layer is not an abstraction. It is a set of specific, buildable, testable artifacts that determine whether AI systems serve humans or merely respond to them.

Intent models that feed system behavior, not just interface decisions.

Job statements. Success criteria. Context triggers. Structured precisely enough that an AI system can act on them. These are not research documents. They are system specifications.

Autonomy architectures that earn trust over time.

Not a single setting. A designed relationship between what the AI does and what the human controls — calibrated by domain, by context, by the trust the user has actually developed through experience.

Knowledge infrastructure that gives AI real context.

Not a folder of documents. A living, queryable system that makes organizational intelligence accessible to every agent and every team member.

Agent designs scoped to specific structural roles.

Not “AI that helps.” Agents with defined inputs, defined processes, defined outputs — each filling a role that was previously unfilled.

This work happens before Figma opens. It determines the quality of everything built afterward. And it requires designers who operate at the level of systems architecture — not because interface craft is dead, but because the craft now serves a system that extends far beyond the screen.

The Claim, Stated Plainly

AI is the most consequential technology shift in design history.

Not because it threatens to replace designers. Because it creates a category of work that designers are uniquely equipped to do — and that no one else is doing well.

The work is translation. Taking the complex, contextual, human reality of what people are trying to accomplish and converting it into the precise, structured, operationalizable form that AI systems need to act well on behalf of people.

That translation has an architecture. Intent models. Autonomy frameworks. Knowledge infrastructure. Interaction patterns designed for earned trust. These are not peripheral additions. They are what determines whether an AI product works.

This translation is the difference between AI that serves humans and AI that merely responds to them. Between AI that earns trust and AI that produces impressive demos. Between AI that people integrate into their lives and AI that people try once and abandon.

The field is wide open. The frameworks exist. The work is available.

This newsletter is the map.

P.S. — I want to be honest about something. When I first started building AI systems, I did not think of myself as a “translation architect.” I thought of myself as a designer who happened to work on AI. The shift was not intellectual — it was visceral. I watched a system I helped build send a notification to a user at 11pm about a task they had deliberately postponed to reduce their stress. The system was “working correctly.” The user felt surveilled. That moment broke something in how I thought about my role. The technology was not the problem. The missing layer — the one that should have known what this person was actually trying to protect — was. I have been building that layer ever since. Some days I am not sure I have it right. But I am certain it is the work that matters most.

This is the thesis behind everything I write in Intent First. Each article goes deeper into one component of the translation architecture — from JTBD as system design language to Autonomy Maps, from Knowledge Architecture to the six patterns of Agentic UX.

If you are building AI products and the translation layer in your process feels thin — that is the conversation I find most valuable. Reach out.

#AIDesign #UXDesign #DesignLeadership #FutureOfDesign #IntentFirst #ProductDesign #AgenticAI