Prompt Storming: A Collaborative Way to Design AI Chat Features

Hi! I'm Corey, a Staff Developer at Jane.

As Jane — and my team — move further into building AI-powered features, we've realized something important: it's not just the technology that needs to evolve. Our processes do too.

When we started planning chat experiences embedded directly into our product, we found ourselves asking new kinds of questions. How might a real user navigate this conversation? Where does the system need to step in? What happens when things don't go as expected? We quickly realized our usual planning tools weren't enough — designing conversational experiences required a more collaborative, more visual way of thinking.

That's where a process we now call Prompt Storming began to take shape, born out of a recent Hackathon week that my team participated in.

We're no longer designing static screens or tidy, linear workflows. We're designing conversations — and conversational branches. Prompt Storming is a collaborative process for mapping those branches before anything gets built. It helps teams explore how a real end user might chat with a system inside your product, and decide together what to support, what to guard, and what to intentionally leave out.

As part of the same Hackathon, I built a custom tool for my team, and others, to support the process — giving teams a dedicated space to map conversation branches collaboratively, rather than adapting general-purpose diagramming tools to fit a problem they weren't designed for.

The Core Idea

Prompt Storming is a structured brainstorming session where a team role-plays a conversation between a user and a chat system embedded in the product. It's inspired by Event Storming (collaborative system mapping) and dialogue trees in video games (branching choices and outcomes) — but instead of mapping backend events, you map conversation paths.

The purpose is simple: make the invisible structure of a chat experience visible.

Why This Matters

When chat becomes part of your product, it becomes part of the core user journey. A user might open the assistant and say "I want to create a new user," "Why was my account locked?", or "Can you update this setting?" — and each of those isn't a single flow. It's the beginning of a branching tree.

If teams don't explicitly map those branches, they often miss important paths, discover capability gaps mid-build, bolt on guardrails late, and struggle to define scope. Prompt Storming moves those discoveries earlier, into a shared conversation.

What a Session Looks Like

A typical session includes product, engineering, design, and someone thinking about policy or safety. You start with one clear user intent — for example:

Create a new user.

Then the team role-plays the interaction:

I want to create a new user. — User

Sure, what's their name? — System

John Doe. — User

Pause. What could happen next? The user already exists. The user doesn't exist. The requester lacks permission. Required information is missing. Each becomes a visible branch, and within a few turns, what looked simple starts to fan out.

That moment of visual expansion is often the breakthrough.

What the Board Reveals

A Prompt Storming board typically includes a central conversation thread, separate panels for major branches, notes capturing open questions, and clear markings for what's in scope. Some branches are supported; others are labelled "Not currently working on these." That clarity reduces ambiguity — scope becomes explicit instead of implied.

But the board also does a few deeper and very practical things for teams. It highlights where skills or subagents may be useful, since certain branches naturally behave like "mini-flows" that are good candidates for a specialized capability rather than a single giant chat prompt. It exposes gaps in what you can support today — when you map branches honestly, you quickly see where you're missing a tool, an integration, or a policy decision, and that becomes a clear input into what needs to be developed next. And it makes the branching moments concrete, helping the team agree on when the conversation should split, what signals cause that split (a missing detail, a permission issue, a duplicate, a risk trigger), and what the system should do to guide the user toward a helpful outcome.

In other words, the board isn't just a diagram of what users might say. It's a shared view of what exists, what's missing, and how the experience should steer the conversation.

The Three Decisions at Every Branch

Every time the conversation splits, the team answers three questions: Do we support this path in this release? Does this path require a system capability or integration? Does this path require guardrails?

For example, if someone tries to create a user who already exists — should the system detect duplicates automatically? Should it ask a clarifying question? Should it escalate to a human? By mapping this visually, the team makes product decisions, not just conversational ones.

Guardrails as Product Design

One of the biggest shifts Prompt Storming encourages is treating guardrails as first-class design elements. As teams explore "What if the user says this instead?", edge cases surface naturally: attempts to access restricted data, suspicious or repeated actions, abusive language, requests outside the assistant's purpose. Instead of reacting to these later, they're mapped alongside happy paths. Guardrails stop being an afterthought and become intentional design choices.

Conversations Are Graphs, Not Flows

A key insight from Prompt Storming is this: conversations are not linear flows. They are graphs. A single intent can split into multiple sub-paths within a few turns — some paths converge, others diverge completely. Seeing this structure helps teams simplify overly complex branches, identify unnecessary edge cases, spot missing capabilities early, and prioritize what truly matters for users.

The visual map becomes a shared mental model.

From Workshop to Roadmap

Prompt Storming doesn't replace detailed design or specifications — it prepares the ground for them. After a session, teams typically walk away with a clear set of supported conversation paths, a list of deferred paths, identified system capabilities required for certain branches, and defined areas where guardrails are needed. Instead of asking "What are we building?", the team can ask "Which branches are we committing to?" That's a more focused conversation.

When to Use Prompt Storming

Prompt Storming is especially useful when introducing AI chat into an existing product, designing multi-step conversational workflows, exploring identity- or permission-sensitive experiences, or clarifying the boundaries of an AI assistant. It works best early — before implementation details lock you in.

Closing Thoughts

Designing AI chat inside a product isn't just about writing better prompts. It's about understanding how users might navigate a conversation and making deliberate decisions at each turn. Prompt Storming creates a shared space for that exploration — by mapping branches together, teams can clarify scope, expose hidden complexity, and design more thoughtful experiences before committing to build.

If your team is embedding AI into your product, consider running a Prompt Storming session before your next feature cycle. You may discover that the real complexity isn't in the first reply — it's in the third branch that follows.

Thanks for reading. If you try this approach, I'd love to hear what your team uncovers.