Dan Stevens — Information Experience Design

Product Work

Enterprise product design at scale — from Bitbucket's 3M-user growth arc to ServiceNow's ITSM implementation hub and AI adoption tooling. The common thread: making complex systems navigable for people who have real work to do.

ServiceNow

Manage

Applications

Implementation

ITSM Product Hub ⭐

ITSM Applications

All available applications and their current status

Overall adoption status

Not installed 51

Implementing 0

In use 0

Adoption score

↑ 0 since Oct 09

ITSM

Incident Management

Minimize incident impact by quickly restoring service

Installed

ITSM

Service Operations Workspace

Manage IT Services and Operations from a single interface

Not installed

Core Platform

Config. Management (CMDB)

Visibility of critical configuration items and relationships

Not installed

Core Platform

Platform Analytics

Visualized business outcomes with KPI reporting

Not installed

ServiceNow · ITSM Product Hub

Implementation adoption metrics and application discovery

The ITSM Product Hub surfaces adoption status, application inventory, and implementation roadmaps for enterprise IT organizations. The content system — descriptions, status labels, onboarding copy — needed to serve both technical admins evaluating new capabilities and platform owners tracking portfolio health.

Enterprise UX writing Information architecture Adoption metrics Status copy

"These are all the available applications and their current status. Select an application to open it in its app console where you can monitor and manage that application."

Get started with an outcome you want to drive

This will help you define the requirements and applications to reach this outcome.

ITSM Adoption Roadmaps

Optimize Service Desk to manage incidents

View details

Implement

Understand and implement the applications to manage incidents

Applications 8 By ServiceNow

ITSMPlatform

Optimize Service Desk Operations

Move agent operations to SOW and take advantage of new functions

Applications 8 By ServiceNow

ServiceNow · Adoption Roadmaps

Outcome-driven implementation guidance

Roadmaps frame implementation as a set of business outcomes rather than a list of products. Each roadmap card anchors on what the organization wants to achieve — reducing the cognitive gap between "what do I install" and "what does this solve."

Goal-first UX writing Card content architecture

alectri

Now Assist in Virtual Agent ⭐

Now Assist in Virtual Agent - 1

Overview

Now Assist skills

Display experience

Information Sources

Choose information sources

Select what information should be available to this assistant.

Search configuration

Control how your assistant handles searches.

Search sources 2

Name Indexed source Conditions

Now Assist Q&A Genius Results Knowledge Table Knowledge base Active = true .and. Workflow = Published

Now Assist Multi-Turn Catalog Ordering Catalog Item Table Active = true .and. No search != true

ServiceNow · AI Agent Setup

Now Assist Virtual Agent configuration flow

The agent setup experience walks admins through configuring a generative AI assistant — selecting skills, information sources, branding, and behavior. Dan designed the information architecture and copy for the stepwise setup flow, balancing technical specificity with approachability.

Setup UX writing Progressive disclosure AI configuration

Tara.ai

AI-Powered Engineering

Active Sprint

12 of 18 tasks complete

🎉 Success state

+ Add task

Tara.AI · Product Redesign

Complete product reconception — from first style guide to launch

Working alongside the CEO and product designer, Dan established the entire information architecture, first style guide, and UX writing system for Tara.AI. Designed landing pages, empty states, success states, sprint UI, and marketing — most of which remains in the live product. Tara.ai did not survive, but the work does.

UX writing end-to-end Style guide creation IA guidance Marketing copy Empty state design

"My design work and contributions to the product are still present in much or most of the product."

Conversation & AI Design

Multi-persona conversational flows, AI reasoning layer architecture, and enterprise virtual agent design. This is the work Dan does at the edge of what LLM-native product design looks like in practice.

Otto · Now Assist Active · 3 participants

The Support Specialist agent is ready to set up — but there's a step that needs Marcus, your ITSM process owner. The escalation path and L1 scope need to match how your support center actually runs. That's not an admin decision.

AI reasoning layer (not shown to users)

This decision scope belongs to the Process Owner persona. Surface the dependency before proceeding; offer to bridge the gap rather than block.

Want me to bring Marcus in directly? He'll be able to review the three configuration points and approve — without needing admin access.

Invite Marcus

Review scope first

Explain more

Marcus (Process Owner) joined the conversation

Marcus — Sarah's activating the Support Specialist agent. Three things need your input: (1) L1 resolution scope, (2) escalation group, (3) escalation trigger. Sarah owns the configuration — you're confirming the workflow decisions match how the team actually operates.

We handle Tier 1 through P3. Anything above that goes to the Network Ops group.

ServiceNow · Now Assist Center

Multi-participant AI conversation design — the handoff as a design problem

Research identified the Admin-to-Process Owner handoff as the primary AI adoption failure point. Rather than treating it as an organizational problem, Dan designed it as a conversation design problem — and solved it with a three-way thread where Otto (the AI) facilitates decisions across roles in real time.

Multi-persona conversation flow AI reasoning layer architecture Enterprise LLM design Turn-by-turn scripting Interactive prototype

"The AI reasoning layer is shown in the design document but explicitly never visible to users — it makes the AI's intent legible to collaborators without leaking it into the UX."

alectri support

Answers generated by AI. Review for accuracy.

Hi System. How can I help you today?
I can answer questions, fulfill requests, and generally point you in the right direction.

How do I ask for time off?

OK, here's what I found for that
(Catalog) Kronos - Create Time Off Request

"How do I ask for time off?"

Search Results

Analyze test phrases · Variables · Context · Logs

ServiceNow · Virtual Agent Designer

Conversational AI testing and intent analysis

Working in the Virtual Agent Designer to test and refine conversational flows — analyzing how the AI interprets user intent and whether responses reflect good information design decisions. The content designer's role here extends into the model's behavior, not just its surface copy.

LLM behavior testing Intent analysis Conversational UX

🤖✨

Meet the AI Crew

🤖

AI Agent

⚡

Sally Skill

🔧

Tiffiny Tool

💡

Carl Capability

"In fact, sometimes we directly refer to each other as the other. It's a bit embarrassing, really."
— The Narrator

ServiceNow · AI Terminology Education

Narrative design as information architecture — the AI story

Dan wrote a character-based script to teach the ServiceNow AI taxonomy to admins and implementors: Alie the AI, Sally Skill, Carl Capability, Tiffiny Tool. He then directed an AI to produce it as an interactive website with SVG characters. The Narrator even acknowledges the taxonomy inconsistencies — designed honesty built into the educational content.

Narrative design AI education Taxonomy management Interactive content

Tone evolution model

Stage 1

Sessions 1–4

Helpful, warm, reassuring. Confirms intent. Offers chips at every branch.

Stage 2

Sessions 5–20

Direct, efficient. Reduces friction. Notes preferred interaction style.

Stage 3

Sessions 21+

Personal, predictive, precise. By name. Anticipates role-typical tasks.

Stage 3 example

"Good morning, Sarah. The Ziegler model connection flagged a compliance issue overnight — Incident Triage can't activate until it's resolved. Want me to open model config?"

NAC · Tone Design

A three-stage tone model that treats the AI-user relationship as something that develops

Rather than a single voice and tone spec, Dan designed a behavioral progression tied to session count — with explicit signals the system watches for at each transition. The model defines what the AI learns and how it adapts, not just how it sounds.

Behavioral design Voice and tone systems AI personalization

Design Systems

Content models, taxonomy architecture, information hierarchies, and the structural thinking that makes everything else hold together. The invisible work that makes products scalable.

The Ontology Pipeline

Controlled Vocabulary

Foundation of semantic knowledge systems; reconciles synonyms

Metadata Standards

Schema-based control; structural, descriptive, administrative

Taxonomy

Structures vocabulary into hierarchy; parent-child relations

Thesaurus

Reconciles synonyms; extends taxonomy beyond parent-child

Ontology

Introduces logical reasoning; defines classes, relations, properties

Knowledge Graph

Includes all stages; visual representation of semantic relations

ServiceNow · Taxonomy Research

Taxonomy needs evaluation across 7 business verticals

Co-led a major research project evaluating taxonomy needs across 7 ServiceNow business verticals — the full spectrum from controlled vocabulary to knowledge graph. Presented findings to top-tier customers (10,000+ users). The ontology pipeline above represents the conceptual framework that anchored the research.

Taxonomy architecture Research leadership Ontology design Customer presentation DITA background

"That's where I got my start in tech — defining XML schemas in DITA (Darwin Information Typing Architecture)."

Simplified Content Model

UI LAYER

Labels
Actions
Status

GUIDANCE

Empty states
Tooltips
Modals

NARRATIVE

Onboarding
Education
Recovery

↓ Every layer feeds into the user's mental model ↓

User journey (ongoing)

Marketing → Onboarding → Usage → Mastery

Lightstep · Content System

Content model spanning the full product experience

On Lightstep Incident Response, Dan built a simplified content model to enable every designer, PM, and developer to understand how content impacts different aspects of the product — then extended it into a user journey model and end-to-end layered architecture including marketing, developer relations, and community.

Content modeling Cross-functional enablement Systems thinking

Content Canvas

User need

What does the person need to do, understand, or decide?

Business goal

What outcome does the product need here?

Content strategy

What information, in what form, at what moment?

Success signal

How do we know it worked?

Atlassian · Craft Foundation

First content canvas — the discipline's founding artifact

Dan built Atlassian's first content canvas — a structured framework for aligning user need, business goal, content strategy, and success signal. Similar in form to the content canvas later developed by Elle Geherity. It became the foundation for how the IX team approached every project.

Content strategy Craft development Team enablement

Leadership & Craft

From building Information Experience at Atlassian from a small team of technical writers into one of the most respected Content Design groups in the world, to shaping how ServiceNow measures and advocates for the discipline.

#756

Employee at Atlassian

4,000+

When Dan left

Built the IX team

From a small group of technical writers into one of the most respected Content Design groups in the world

Bitbucket growth arc

Grew product by 3M+ users as lead writer through innovative growth design and end-to-end information experience

Design Week runner-up

Idea to full prototype in 24 hours. Many design patterns from that project are used across Atlassian's products today.

Atlassian · 2013–2019

Building the discipline — from technical writing to world-class Content Design

Dan joined Atlassian as employee #756 when the company had a small group of technical writers called Information Experience. Over six years he helped transform that group — building the craft, the methodology, the first content canvas, and the team identity — into one of the most respected Content Design organizations in the world.

Team building Craft leadership Growth design Bitbucket +3M users Write Measure Repeat

"I created the process to land on a content design team vision. Using all the skills of writing, analysis, and psychology, I helped the organization come to one idea of who we were — and our teams were already behind it."

Match each piece of feedback to the most relevant evaluation focus area: Process, Approach, or Judgment.

"The candidate asked clarifying questions and adapted based on input."

Evaluation Focus: Judgment

✗ Incorrect. Correct: "The candidate explored multiple ways to frame the problem before deciding."

"The candidate clearly outlined the steps they would take before beginning."

Evaluation Focus: Process

✓ Correct

ServiceNow · Internal Learning

EX Hiring Excellence — interactive assessment design

An interactive learning module teaching hiring managers how to assess EX talent using ServiceNow's 2:1 whiteboard challenge interview format. The matching exercise shown here distinguishes Process, Approach, and Judgment — a content design challenge requiring both pedagogical thinking and precise language.

Instructional design Assessment writing Internal enablement

Making the case for content design

Craft

Content-specific tenets and traps cards. Integrated into 5 usability studies with UXR.

Process

"How CDx adds value from strategy to launch" — presentation for EX and Product leadership.

Business

Clear value metrics — working alongside research to represent actual CDx impact in data.

Measurement · Advocacy · Investment

ServiceNow · CDx OKRs

Building the evidence base for content design investment

Dan's leadership OKRs reveal a methodical approach to elevating the discipline: content-specific usability studies, cross-functional presentations, and value metrics built alongside research. He frames measurement as both a business requirement and a craft integrity issue — not just "prove ROI" but "agree on what we're measuring."

Strategic advocacy Measurement systems Cross-functional leadership

01 Conversation Design · AI Adoption 2024–2025

Designing AI Adoption at Scale

One assistant. Three radically different users. A handoff that was breaking everything.

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 turn

The handoff was an organizational problem. I made it a design problem — which is what made it ownable.

The usual answer

The admin configures what they can, sends an email, and waits. The process owner responds eventually, or doesn't. The configuration stalls, adoption stalls, and the gap between the two roles belongs to nobody.

→

What I designed instead

Otto surfaces the dependency the moment it appears, offers to bring the process owner into the same thread, briefs them on arrival, holds the three-way alignment on scope and escalation, and shows all three parties the agreed configuration before anything activates.

What makes this work distinctive

—

The reasoning layer Showing AI reasoning in the design doc but hiding it from users is an architectural decision: it makes intent legible to engineers without polluting the UX with system-speak.

—

The handoff as a design problem Rather than treating the admin-to-process-owner failure as an org chart problem, I treated it as a conversation design problem — and solved it with a multi-participant thread.

—

Tone that earns its way The three-stage tone model treats the AI-user relationship as something that develops — with explicit behavioral signals the system watches for, not vibes.

—

Prototypes instead of specs Interactive HTML prototypes let engineers and PMs walk the conversation step by step. Teams aligned when they moved through the flow, not when they read the document.

What came of it

The framework was adopted as the design foundation for conversation patterns across Now Assist Center — the document a designer joining the team is handed.

The three-way handoff flow cleared engineering feasibility and was approved as design.

Prototype review replaced document review as how the team aligned on conversation behavior.

Worked with

Data readiness team Agent builder team Engineering Product management UX research Product leadership

Artifacts

Available on request

Conversation design framework Multi-participant flow prototype Admin conversational flow prototype Conversation architecture diagram Stakeholder lifecycle map Conversation spec (DOCX)

Lineage

Getting the right people into one conversation at the moment the decision is actually made is a problem I first solved with no AI in it at all — global, multi-craft design review at Atlassian, written up as Spar from afar. Same problem, different medium.

02 Taxonomy · Information Architecture · Narrative Design 2024–2025

Making Complex Systems Legible

Naming things at enterprise scale — and teaching the vocabulary through story, including the part of it that was broken.

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. With lead researchers I co-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 turn

Most terminology work hides the inconsistency. I built it into the lesson.

The usual answer

Pick one term, declare it correct, and publish documentation that quietly contradicts the product. The reader hits the contradiction alone, decides the material is unreliable, and stops trusting the rest of it.

→

What I designed instead

The Narrator names the seam out loud, explains it in context, and moves on. The reader learns the taxonomy and its known limitation at the same time — and the honesty is what makes the rest of it credible.

What makes this work distinctive

—

Narrative as information architectureEach character is a taxonomy node. The hierarchy flows through the story — it doesn't sit alongside it as a caption.

—

Designed honestyBuilding the known limitation of a taxonomy into the educational content — transparently — is a rare move. Most documentation papers over these gaps.

—

A taxonomy you can testAbstract vocabulary systems usually get argued about rather than measured. The research methods made the taxonomy something a team could evaluate and iterate on.

—

AI as a production toolI wrote the narrative architecture and prompted an AI to build the interactive site. The content designer's role is the structure; execution is delegated.

What came of it

A taxonomy evaluated across seven business verticals and presented to enterprise customers with 10,000 users and above.

New methods for testing and iterating complex taxonomy systems — flexible enough for the general platform, specific enough for individual enterprises.

A term derivation framework and a character-driven interactive story used to teach the AI vocabulary to implementors and technical partners.

Worked with

UX research leads Seven business verticals Implementors & technical partners Enterprise customers

Artifacts

Available on request

Interactive story (HTML / SVG characters) ↗ AI term derivation framework AI taxonomy diagrams (Venn-style) Seven-vertical taxonomy research AI Agent Reference Index Terminology alignment template

Lineage

Deciding what a term means and where it sits is where this career started — XML schemas in DITA at IBM, then taxonomy systems built alongside information architecture at Atlassian and Tara. The vocabulary being organized changed. The work didn't.

My role

Content Designer — AI Adoption · Research co-lead

ServiceNow · 2024–2025

Core challenge

Taxonomy that was genuinely fuzzy — overlapping terms even internally

Had to satisfy multiple enterprise customers and stay flexible on the platform

Non-specialist audience making real configuration decisions

Design decisions

Overlapping circle diagram shows real fuzziness rather than false clarity

Characters embody concepts — learning the story is learning the taxonomy

Narrator's fourth-wall break addresses the inconsistency honestly

Generative AI used for production execution, not for the design

03 Implementation UX · Progressive Disclosure 2024–2025

Implementation as an Information Experience

When setup is too complex for any one person, the design problem is actually about delegation.

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 turn

The setup wasn't too long. It was assigned to the wrong number of people.

The usual answer

One linear setup guide with one owner. Everything the platform admin doesn't personally know becomes a blocker, and the decisions that belong to someone else get guessed at — then corrected in production.

→

What I designed instead

Discrete worksheets, each gated to the role that actually holds the answer and each independently assignable. The estimate comes out before configuration begins, so the organization can see the scope it is committing to.

What makes this work distinctive

—

Delegation as a design principleThe worksheet structure makes handoff explicit and safe — the platform admin doesn't have to own everything, and the design communicates that without requiring a manual.

—

Journey mapping as information architectureThe swim lane map isn't just a UX artifact — it's a content architecture decision made visible, including the emotional arc and the "whoa" moment of relief when the worksheets click.

—

Progressive disclosure at the system levelEach worksheet surfaces only what the current role needs to know — not all at once, not in a single monolithic flow.

What came of it

A worksheet-based implementation system designed to reduce setup time and admin cognitive load.

A clear role-based delegation model for complex multi-admin implementations.

In-app guidance connected to the documentation hub as one layered path rather than two separate destinations.

Worked with

Product design Product management Implementation consultants Documentation hub team

Artifacts

Available on request

Now Assist Studio IA audit Implementation journey map (swim lane) People & Permissions worksheet Platform implementation worksheet SOW implementation worksheet In-app guidance strategy

Lineage

The three-layer guidance model — in-context, in-panel, in-hub — is a direct descendant of the layered path built for Bitbucket a decade earlier: microsite, tutorials, onboarding, UI. Same structure, different product. See case study 04.

My role

Content Designer — Implementation, AI Adoption

ServiceNow · 2024–2025

Core challenge

No two organizations arrive with the same configuration profile

Implementation requires multiple roles — but the product assumed one owner

Users needed to know the scope before they committed to starting

Design decisions

Modular worksheets assignable to the right role at the right time

Permission gating built into the worksheet structure itself

Implementation estimate surfaces complexity before configuration begins

Three-layer guidance model: in-context, in-panel, in-hub

04 Growth Design · Information Experience · Craft Building 2013–2019

Growth as an Information Problem

The people who needed Bitbucket hadn't learned Git yet. So the path into the product had to teach them on the way in.

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.

The turn

Tutorials weren't support material. They were the top of the funnel.

The usual answer

Teaching material sits downstream of acquisition — written for people who already signed up, measured as ticket deflection, and owned by a team that never sees the marketing narrative.

→

What I designed instead

The teaching material is the acquisition path. Someone learning Git on the microsite is already inside the product's information experience, and onboarding picks up precisely where the tutorial left them.

What makes this work distinctive

—

Teaching as the acquisition pathThe tutorial layer wasn't a support asset repurposed for marketing. It was designed as the front door, for people who needed to learn a technology before a product could mean anything to them.

—

One journey, four ownersDesigning continuously across marketing, product, engineering, and design — before "end-to-end content design" was a named practice anyone was hiring for.

—

Measurement built in, not bolted onWrite Measure Repeat gave content the same instrumentation as any other growth surface — which is how the work stopped being the first thing cut.

—

A framework, not just a funnelThe content canvas let non-content people make good content decisions without a content designer present. That's what made it scale past me.

What came of it

Three million user growth over two years as lead writer for Bitbucket.

The combined marketing-narrative-and-onboarding system brought hundreds of thousands of people in to try Bitbucket. It was replicated by other Atlassian products and became the model for product-led growth there.

The Information Experience team grew from a small group of technical writers into a full content design organization.

Write Measure Repeat and the content canvas became standing team practice — and the multi-craft design review process became Spar from afar.

Worked with

Marketing Product Engineering Design SourceTree team Opsgenie (post-acquisition)

Artifacts

Designing experiences with information ↗ Spar from afar ↗ Git microsite & tutorial system Atlassian content canvas Write Measure Repeat Bitbucket two-step verification content

Lineage

Almost everything above this on the page is a variation on what was built here. The layered guidance model in case study 03 is this funnel's direct descendant, and the habit of shipping a framework alongside the deliverable — in 01 and 02 — starts with the content canvas.

My role

Lead IX Designer, Bitbucket → Content Design & Information Experience Manager

Atlassian · 2013–2019 · Employee #756

Core challenge

The audience had to learn a technology before the product could make sense

Four functions owned four pieces of one journey

Content effectiveness had no accepted measurement at the time

Design decisions

Microsite → tutorials → onboarding → UI designed as one continuous path

Each layer assumes only what the previous layer taught

Content canvas so non-content people could make content decisions

Success signals defined before the writing, not after

Dan Stevens Information Experience Designer

Career Arc

Product Work

Conversation & AI Design

Design Systems

Leadership & Craft

Creating clear human experiences in an AI-driven world

Designing AI Adoption at Scale

Making Complex Systems Legible

Implementation as an Information Experience

Growth as an Information Problem

Designing AI Adoption at Scale

The problem

The approach

The turn

What came of it

Making Complex Systems Legible

The problem

The approach

The turn

What came of it

Implementation as an Information Experience

The problem

The approach

The turn

What came of it

Growth as an Information Problem

The problem

The approach

The turn

What came of it