I made AI behavior
a design decision

I used the tools I had: competitive analysis, research, architecture diagrams, prompt work, evaluation criteria, and a lot of repeated advocacy. I turned that argument into the places the organization already used to make decisions: prompts, PRDs, design reviews, rubrics, design-system guidance, and OKRs.

The search team pivoted to LLM-generated summaries of knowledge articles, HR policies, and IT requests. The responses were long, wordy, often only semi-related, and assumed a lot about the user. But they were “accurate.”

Accuracy was the only bar, and it was the wrong bar. A response can be factually correct and still fail. Too long to read. Too generic to use. Technically sound while eroding trust through confident guessing.

Research confirmed this was not just an anecdote. Across AI-readiness studies, usability research, customer interviews, and internal quality reviews, the same pattern kept showing up:

The research made the gap visible in numbers, not just anecdotes.

In one comparison, QE scores were much higher than user-perceived quality scores across key dimensions:

QE vs. user-perceived quality gap

Scores on a 0–100 axis. Third value per row is the gap in points, user-perceived minus QE.

A related comparison showed a 94% mean under QE versus a 74% mean under AI-Readiness testing, with unhappy-task conversations averaging 60%.

Here, the important point is simpler:

The gap made behavior quality impossible to ignore.

That comparison bothered me in exactly the right way.

Otto had more raw material than any tool in the matrix: a live context engine, conversation memory, employee history, customer workflows, and enterprise data.

Claude had none of that.

So why did Claude behave as if it understood the person better?

The gap was not data.

It was whether anyone had designed how the system should use what it already knew.

Across the org, the LLM was often treated as a black box, something engineering tackled and design did not need to understand.

I never accepted that.

ServiceNow does not run its own model. Customers pick one of several frontier models, and the same query across different models got wildly different answers.

If the model alone were the arbiter of quality, shouldn’t those answers have been nearly identical?

And if ServiceNow had direct access to customer data and context those models could only reach through integrations, shouldn’t ours have been better across the board?

That sent me into investigator mode. I read engineering docs, consulted outside research, interviewed people across my team, and pressure-tested the patterns against the AI tools I used every day.

The six levers gave design fixed points to attach to.

Intent routing
Should the assistant answer, ask, decline, route, or act?

Context usage
What should the assistant infer from user role, history, permissions, conversation memory, uploaded files, or customer data?

Source retrieval
What source should the assistant trust, and how should it make that source visible?

Prompt guidance
What behavior should the system follow when the request is ambiguous, sensitive, broad, or action-oriented?

LLM inference
What does the model generate after the surrounding decisions shape the input?

Response structure
Should the answer be prose, bullets, a table, a card, a workflow, or a next-step prompt?

This is where the case changed from “AI quality feels bad” to “here are the decisions shaping it.”

The reframe was the easy part.

Getting the organization to operate as if it were true took longer.

What I care most about here is not one artifact. It is that I was one of the people inside a large enterprise defining what design’s job is in this new era of AI.

I had a direct hand in framing how our design organization understood AI behavior: not as model output, but as a set of product decisions.

Once I was in the right rooms, the shift was almost anticlimactic.

I did not need to rebuild the whole system to make change. I could point to a decision before it became a product problem. I could say where behavior would default. I could show what it would cost us if nobody owned it.

At first, the argument sounded like this:

“Design thinks this matters.”

That was easy to deprioritize.

Then it became:

“Competitors already do this.”

That helped, but it was still abstract.

The version that finally stuck was:

“Here is what it costs us when we do not have it.”

That changed the conversation. I was no longer asking people to care about an ideal. I was showing them what happened when the standard was missing: lower perceived quality, confused users, missed context, unhelpful answers, and customer paths that could not deflect work they should have resolved.

That framing is how tone work usually gets scoped, and it is why tone work usually changes nothing.

Five adjectives, no order of precedence, and two of them in tension: concise and sympathetic pull against each other on exactly the turns that matter.

Nothing here says what to lead with, what to do when the request is ambiguous, what context to use, when to ask, or how to end.

An engineer building from this has to invent the behavior.

Which means the behavior is whatever the model happens to do.

A persona can describe a vibe.

It does not reliably define behavior.

“Professional” does not tell the assistant whether to lead with the answer or context.

“Concise” does not tell it when to use a table instead of prose.

“Sympathetic” does not tell it whether to comfort the user, solve the task, or do both.

“Polite” does not tell it when to ask a clarifying question.

The rewrite made those decisions explicit enough to evaluate.

That was the point: not better tone, better behavior.

The first answer is not unfriendly.

It just does not know who is asking, buries the answer, and hands off to HR for something it should have handled itself.

The second reads cooler. It is also the one that actually helps.

It leads with the answer and names the one real uncertainty instead of guessing.

This was an independent platform evaluation of the product before and after the prompt rewrite.

It supports the claim that specifying behavior in the prompt changed measurable response quality.

It does not prove the full organizational standard by itself.

That is why I treat the prompt rewrite as one important proof point inside a broader advocacy story: it showed that design-written behavior could move product output, which made the larger standard harder to dismiss.

A framework nobody is obliged to use is a point of view.

To stop having the same argument every quarter, the six decision points had to get into the places where the organization actually commits to things.

That took four mechanisms: the PRD, the quality rubric, a design-org OKR, and design-system standards.

The rubric mattered here because it gave the behavior standards a measurement surface.

Behavioral quality stopped being something designers argued for in reviews and became something the org reports on.

That is the difference between a point of view people can ignore and a standard the organization has to account for.

The standard became real when it showed up in multiple decision systems.

PRD
Product had to name the standard as part of the work, not treat it as a design preference after scope was set.

Design review
Designers had shared language to critique behavior, not just screens.

Rubric
Behavioral quality became measurable enough to sit next to latency and accuracy.

OKR
Adoption had a named owner and review cadence.

Design system
The guidance lived where designers already work, so using it did not require a separate persuasion campaign.

That was the goal: stop making behavior depend on whether I happened to be in the meeting.

Early on, I treated the rubric mostly as a scoring instrument: did the response pass or fail?

What I care about more now is what a score actually licenses you to claim.

A 4× deflection number and an 83-out-of-100 rubric score can both be real, and both be early.

So I distinguish:

• what is measured from what is directional
• what I authored from what the platform delivers at scale
• what the standard influenced from what I directly built
• what the evaluation proves from what it suggests

That distinction is the thing I now push hardest on when anyone, including me, wants to round a number up.

These are early, directional figures from a mid-year launch. But they show the kind of impact advocacy is supposed to have: not one better screen, but a standard other teams can use to make better product decisions.

The case-creation journey had three paths:

That abandoned group mattered. Nearly a fifth of people left before picking either path. That was a design problem nobody had assigned to anyone.

For the people who did choose a path, the designed AI conversation performed much better.

Deflection by path

Bars scaled to a 15% axis, not 0–100%, so the difference between paths stays legible.

After the original reporting window, the AI path’s deflection rate was later reported at 19%, roughly seven times the legacy path.

That figure is directional: it sits outside the original Jan to Jun reporting window.

The opportunity sizing made the business case clearer.

Opportunity sizing cascade

Each bar is a share of total case volume, on a 0–100% axis.

That final band represented the cases where better self-service and better AI behavior could realistically matter.

An earlier estimate put that final band at roughly 120,000 cases a year.

AI-Readiness tracking also showed perceived quality moving over the same broader period.

Quality tracking

User experience jumped hard, then settled back slightly in Q4 as new capabilities shipped and reset expectations.

Quality is not a finish line. As the product gets more capable, the user’s expectations move too.