Creating a Conversation Design
Discipline at ServiceNow

Conversation is the most intuitive interface ever built

Often, teams still treat conversation quality as a writing problem. Better copy, clearer tone, more natural language. These things help, but they don't address the real issue: conversation design wasn't treated as a discipline at all.

At ServiceNow, it was treated as decoration on top of a system. A way to make technical output feel friendlier. But that's not what conversation is.

When you get this right, conversation is easier to interact with than any UI. Faster. More natural. Less cognitive load.

When you get it wrong, the damage is worse than a bad UI. Because bad UI is frustrating. Bad conversation feels like betrayal. You trusted the system to understand you, and it didn't.

ServiceNow's design org needed this discipline, so I built it.

Defining what good looked like

As I began to explore the landscape of skills my colleagues had, I quickly realized that one of the major issues was there was no clear definition of what good meant, both in conversation in general and especially for the ServiceNow users and use cases. This was something I could fix.

I started with principles.

Conversation design at ServiceNow is different from consumer AI because the stakes are different. When someone asks the system to fulfill an access request or route a ticket, it isn't assisting, it's acting. And the user is responsible for what happens next.

Three realities shape every design choice:

First: users are doing high stakes tasks in a time-constrained environment. A service desk agent has 90 seconds to triage. They don't need personality. They need a system that already understands their role, has inferred the context they don't have time to explain, and surfaces the next move without confusion.

Second: automation demands transparency. As the system automates more, users need to understand why it made a decision, not just trust that it can. It's not about showing your work, it's about building confidence in the system's reasoning.

Third: enterprise users know what they want, even if they don't say it clearly. They already have intent, but they may not have time to articulate it perfectly. The system's job is to infer that intent from context and respond intelligently. And because edge cases are what actually ships, design for those first.

These constraints produced the principles below. They're not universal conversation design. They're grounded in the specific work the system is automating.

Building the training

With principles defined, I needed to teach them to the organization. I brought in two content design colleagues to help me design and run a set of trainings. We spent roughly a month planning and creating the sessions. It ended up being a great collaboration and mind-meld. The three of us together created something stronger than any one of us could have alone. The training ran across three sections, giving designers the fundamentals and showing them how to use that to build the best products.

The third part (how and when to use conversation) was the one I led. The core idea was that conversation is a unique mode of interaction. It can't just replace a UI. It needs careful consideration to be its own good and unique experience. Understanding that distinction changed how people approached the work.

The response was immediate

We ran three live sessions and directly trained 600+ designers. The enablement materials and recordings have since reached close to 2,000 people across design, PM, and engineering. Reach isn't the same as impact, so I'll be precise: what these numbers prove is distribution and demand, the material spread well beyond the rooms it was delivered in, and people kept pulling it in. The proof of behavior change comes later, in the standards teams adopted and the work they went on to produce.

One leading indicator worth naming honestly: a month after the training, 84% of attendees reported feeling more equipped to approach conversation design. That’s confidence, not competence, but it’s the precondition for an org actually adopting a new way of working, and adoption is what followed.

How to deliver a modern conversation design

With training complete, I began to ideate on how conversation design functions in the modern age of AI. When I started my career in conversation design, I created flow diagrams and scripts for every conversation that would be supported. That was no longer needed. The AI could write the words itself. So what does a conversation designer actually need to do?

I started by looking at what was happening inside the company, and across the tech industry as a whole.

At the company

I brought in a junior colleague to help figure out exactly what was going on. They sat in on sessions designers were quietly running for their own teams, because the official guidance wasn't working. They interviewed engineers across the organization. They dove deep to get a thorough understanding of the landscape.

What they found: nobody knew how to deliver a conversation, and most were under-delivering. Designers were handing off a single happy-path flow and getting back a product that looked nothing like it.

Engineering had the mirror-image problem: a single script that defined responses but no behaviors, forcing them to either hard-code the flow (defeating the point of AI) or fill the gaps with assumptions design never validated.

The reality was that designers weren't handing off the right deliverables, and were under-defining the things that needed to be clarified. The model is non-deterministic. You can't script every response. You have to design the constraints and let the model reason within them. That wasn't a gap in anyone's experience. It was a shift in what the problem required.

How the industry is handling it

The gap I identified at ServiceNow, designers handing off scripts and engineers making assumptions, isn't unique. Across tech, conversational AI teams are struggling with the same problem of defining and handing off specific AI behaviors. As researchers at Carnegie Mellon University put it:

I can't know how things function inside the major frontier labs. All I have access to is the products they ship, the articles they publish, and, in some cases, their published system prompts. But from those signals, one thing is clear: they've baked intentional behavioral decisions directly into their prompts. How a system reasons, when it signals uncertainty, how it carries itself, those aren't technical defaults. Someone designed them.

This is the same conclusion, reached from the other direction.

The shift from writing to designing

The most important realization came when I accepted what the real problem was. The first goal was to get designers to write better conversations. We tried a number of techniques. But I kept running into the same wall: you can't expect an entire design organization, including people who aren't writers, people for whom English is a second language, people who'd never written conversational copy, to suddenly become conversation writers. That was an unrealistic ask.

The question became: what if designers didn't write conversations at all? What if instead, they designed the system that produces conversations?

The distinction: output vs. behavioral intent

Building a tool to create a better design and a better handoff

The team was handing off conversation flows that didn't work. They were misaligned with platform patterns. They didn't translate into something an engineer could reliably recreate in a nondeterministic system.

So I am building the Conversation Design Brief. A tool that doesn't ask designers to write response copy, it asks them to do systems thinking. It asks them to define constraints and guardrails. What data flows at what moment. What the system is never permitted to do. What requires explicit user confirmation. How recovery works when things go wrong.

The playbook walks designers through six steps:

At the end, the tool uses those responses plus a detailed system prompt I wrote to generate three sample conversations: the happy path and two edge cases. This serves two purposes: it helps non-writers produce a strong script and proves the system will generate what they want. If not, they adjust and regenerate.

Once the designers approve the scripts, the tool produces an engineering handoff: system prompt, data model, decision logic, golden datasets, and guardrails. Everything an engineer needs to implement it.

The tool is still in development, but early feedback from designers is clear:

Next is internal usability testing with designers at different levels, engineering validation that they can use the handoff, then release and training. This is a fundamental shift in how design and engineering collaborate on conversational AI. It deserves to be done right.

What the work actually moved

Here is what is already true: the standards I created are a required baseline in more than eight business units, and the discipline changed how the whole org frames its problems. That is adoption, not just reach, and the two aren't the same thing. (The design brief is still in active development, so I won't claim outcomes it hasn't earned yet, that story is still being written.)

Adoption: the standards became the baseline

The clearest signal isn't reach, it's that the frameworks stopped being my documents and became the org's. (How the behavioral standards became the Otto PRD's source of truth is its own story, told in the advocacy case study.) The aggregate picture belongs here: 8+ business units now use the standards as a required baseline, not guidance a team could route around. The three shipped specs, processing state, disambiguation, and response taxonomy, are referenced across PRDs and cross-functional working groups rather than living in a design folder. The conversation design brief is still earning that track record; it's a fourth framework in progress, not counted among these yet.

Systemic footprint: the thinking outlived the documents

The point of building shared foundations is that other people build on them. Across the conversational AI ecosystem, 25+ identified downstream artifacts, PRDs, framework libraries, training materials, disambiguation standards, and quality programs, trace back to these frameworks and the thinking behind them.

How I measure this

The metric that matters isn't how many things I shipped. It's how many other people's work got better because they had stronger thinking to build on. The shift from individual-team fixes to a shared architectural foundation is visible in how the organization now frames conversation failures: not as model limitations, but as design and architecture problems that can be addressed systematically.

Conversation design is systems design

When I say I built a discipline, I mean the infrastructure that forces an organization to treat conversation as a behavioral system rather than a writing task: principles that define behavior at the system level, training that teaches people to reason about it, and a handoff that turns design intent into something engineers can build from and validate against. Underneath all of it is one idea, designers don't need to write the conversation, they need to design the system that produces it.

Why this matters beyond one company

Most organizations still treat conversation design as a writing problem:

Make the responses shorter Make the tone warmer Sound more natural

That approach breaks down immediately with LLMs. You can't deterministically specify what a model will say. You can specify how it should reason, define confidence thresholds, describe which signals matter to the user, and set behavioral boundaries. The hard problems in conversational AI aren't at the output layer, they're at the reasoning layer. How does the system decide what to do? How does it know when it's uncertain, and signal that? How does it recover from error? When does it ask instead of act?

Those are design problems, and most organizations don't yet have the vocabulary to talk about them. The evidence that the field is converging here is visible from the outside: the major AI labs have baked deliberate behavioral intent directly into their system prompts, not technical defaults, but designed behavior. Someone decided how those systems should reason and carry themselves. That's the same work, at a different scale.

References

1. Chenyang Yang, Yike Shi, Qianou Ma, Michael Xieyang Liu, Christian Kästner, and Tongshuang Wu. “What Prompts Don't Say: Understanding and Managing Underspecification in LLM Prompts.” Carnegie Mellon University, 2025. arXiv:2505.13360