Dan StevensInformation Experience Designer

The problem

Now Assist Center is ServiceNow's AI assistant hub for enterprise IT workflows. The surface is a single chat interface — but the people using it couldn't be more different. System admins are configuring AI skills and need to know exactly what's irreversible before they act. Platform owners are thinking about ROI and portfolio decisions and don't want step-by-step instructions. Process owners define what the AI should do, but have no idea how to make it happen technically.

The research was clear: the handoff between admins and process owners was where AI adoption was failing. Not because of the technology — because nobody had designed for the conversation that had to happen between the two humans before the technology could work.

Three constraints shaped everything that followed. Activating an AI skill in a 50,000-seat enterprise is not easily undone, so confirmation and rollback had to be structural rather than optional. The three audiences share almost no vocabulary — admins speak in tables, platform owners in outcomes, process owners in workflows — so the system had to route each person into the right language before confusion set in, without their noticing they'd been routed. And some configurations genuinely require a decision from two different people who are never in the same tool at the same time.

"The escalation path and L1 scope need to match how your support center actually runs. That's usually a decision for your ITSM process owner — not just the admin."

The approach

I built a full conversation design framework anchored in three distinct user profiles, each with their own language, trust signals, and blockers. The framework includes turn-by-turn conversation scripts with an explicit AI reasoning layer — visible in the design document, never surfaced to users. Engineers and PMs could understand what the AI was doing without it leaking into the experience.

The centerpiece of the work is a three-way conversation flow — a single chat thread where the AI assistant (named Otto) facilitates a structured handoff between an admin, the AI, and a process owner who is invited into the thread mid-conversation. Otto re-orients the process owner on join, makes the three decision points explicit, and clarifies role boundaries. Neither user hits a dead end.

I also designed a tone model that evolves with the relationship — different conversational behavior in sessions 1–4, 5–20, and 21+. The AI watches for signals at each stage and adjusts: reducing confirmation friction as trust builds, becoming proactive once patterns are established.

The problem

ServiceNow's AI landscape is genuinely complex: Agents, Virtual Assistants, Skills, Tools, Capabilities, and traditional ML functions are distinct concepts that interact in intricate ways — and the terminology was still evolving. "Skill" and "tool" were used interchangeably even inside the product. The people who needed to understand this — admins, implementors, platform owners, technical partners — were enterprise IT professionals making real decisions, not AI researchers.

The vocabulary problem sat inside a larger one. A taxonomy at this scale has to satisfy multiple enterprise customers with genuinely different internal languages while staying flexible enough to work on the general platform — and there was no accepted method for testing whether a taxonomy that abstract was actually working for anyone.

"Narrative design as part of human design is essential. People will almost always understand things if they can place them in the context of a story."

The approach

The structural work came first. Working with lead researchers, I led a research program evaluating taxonomy needs across seven business verticals, and built new methods for testing and iterating taxonomy systems that had to hold up against multiple enterprise customers at once. The findings were presented directly to top-tier customers — organizations with 10,000 users and above.

For the AI vocabulary specifically, I mapped the taxonomy visually — overlapping circles showing Agents, Virtual Assistants, Skills, Tools, and traditional ML functions. The overlaps aren't bugs. They're the honest truth about how these components blur at the edges, and the diagram earns the complexity rather than papering over it.

Then I wrote a character-based interactive story — each character is a concept. Alie the AI hosts. Agent explains itself. Sally Skill introduces Carl Capability. Tiffiny Tool is Sally's sibling. And when the script reaches the point where "skill" and "tool" are sometimes used interchangeably in the product, a Narrator breaks the fourth wall and says so directly: "Sometimes we directly refer to each other as the other. It's a bit embarrassing, really." I wrote the narrative architecture and prompted an AI to build the interactive site — SVG characters, branding, frame-by-frame navigation.

The problem

Service Operations Workspace is ServiceNow's product for IT operations teams — managing on-call rotations, services, integrations, and incident response. Implementation is genuinely complex: organizations arrive with different team sizes, service counts, integration profiles, and geographic footprints. A single linear setup flow would either overwhelm one person or fail to account for the fact that no single person usually owns all of it.

The standard approach — put everything in a long setup guide — would have transferred the complexity from the product to the user. I wanted to design the implementation as an information experience that met people where they were and handed off gracefully to the right person at the right moment.

"Product Content writes docs. Content Design designs information experiences as part of the overall design of the product."

The approach

I designed a system of modular worksheets — discrete, assignable information chunks with explicit role gating. The People & Permissions worksheet is platform-admin only by design. The Platform worksheet handles team, user, and geographic configuration. The SOW worksheet handles on-call teams, services, and integrations — the technical setup that often belongs to a different person than the one who started the process.

The worksheets function as structured data-collection tools that guide admins through complex decisions before they touch the product. The output isn't just configuration data — it's an implementation estimate: hours required, tasks flagged as custom, integrations categorized by complexity. The user knows what they're walking into before they begin.

The in-app guidance follows a layered model: immediate in-context → expandable in-panel → comprehensive in hub docs. Content meets users at their point of need without burying them in documentation they didn't ask for.

The problem

Bitbucket was competing for teams in the middle of adopting Git. For most of them, the obstacle in front of the product wasn't the product — it was the technology the product assumed they already understood. Someone evaluating Bitbucket often couldn't yet evaluate it, because the vocabulary of the thing hadn't landed.

The second problem was structural. The journey a person actually took, from first search to first repository, was owned in pieces by four different functions — marketing, product, engineering, and design. Every piece was competent. The path between them was nobody's job. And at the time, content had no accepted way to prove it had worked, which meant it was always the easiest thing to cut.

"I read the entire git scm manual twice to prepare for the interview."

The approach

I treated the whole path as a single information experience rather than four handoffs: a Git microsite and tutorial set that taught the technology itself, connected directly into product onboarding, connected into the UI copy — each layer assuming exactly what the previous layer had taught, and no more. It ran across design, engineering, marketing, and product as one system.

Alongside it I built the things that let other people do this without me. Atlassian's first content canvas — user need → business goal → content strategy → success signal — gave designers, PMs, and engineers a way to make content decisions in the room. And Write Measure Repeat, co-created with the team, applied growth-marketing instrumentation to content, so a piece of writing carried a success signal like any other product change.

The detail work mattered too: I did all the UX writing and documentation for Bitbucket's two-step verification — one of Atlassian's first 2FA implementations, where every sentence sits on a security boundary and a confused user is a locked-out user.