Definition Phase

The Definition phase is where research becomes structure. You take everything you learned in Discovery — goals, interview insights, competitive findings — and shape it into the artifacts that describe what you are going to build and for whom. By the end of Definition, your team will have a shared, detailed picture of the product before a single line of code is written or a single screen is designed.

Audra Flow provides five artifact types in Definition: Personas, Use Cases, User Journeys, Service Maps, and Storyboards. Each one connects to the others and traces back to your Discovery goals, so nothing gets lost in translation.

Overview

Discovery answers “why.” Definition answers “what” and “who.” The artifacts you create here serve as the bridge between research and execution:

• Personas give your team a shared understanding of the people you are building for.
• Use Cases describe the specific things those people need to accomplish.
• User Journeys map how people move through an experience, step by step, including how they feel along the way.
• Service Maps look behind the curtain to show every system, team, and process that supports each journey.
• Storyboards tell the story visually, frame by frame, so stakeholders can see the experience before it exists.

Together, these artifacts form a complete specification that both business and technical team members can understand and sign off on.

Personas

A persona is a detailed profile of a representative user. It is not a real person — it is a composite based on actual research. Good personas keep your team focused on real needs instead of building for an imaginary “average user.”

Creating a Persona

1. Open your project and navigate to the Definition phase in the sidebar.
2. Click Personas.
3. Click Add Persona and give them a name and role (for example, “Maria — Operations Manager”).
4. Fill in the profile sections described below.

What to Include

AI-Generated Personas

If you conducted stakeholder interviews in Discovery, you can ask the Product Owner agent to draft personas based on that research. The AI will scan your interview findings, identify distinct user groups, and generate a starting persona for each one. You can then review, edit, and refine the output.

Try this: “Generate personas based on my Discovery interviews. Focus on the different user roles that were mentioned.”

Use Cases

A use case describes a specific task or goal that a user wants to accomplish with your product. It is more structured than a user story and more detailed than a feature request. Use cases spell out the normal flow, what happens when things go wrong, and what the user expects to achieve.

Creating a Use Case

1. In the Definition phase, click Use Cases.
2. Click Add Use Case.
3. Give it a clear title that starts with an action verb — for example, “Submit an expense report for approval.”
4. Select the persona (or personas) who will perform this use case.

Structuring the Flow

Every use case in Audra Flow has these key components:

• Preconditions — What must be true before the user begins (e.g., “User is logged in and has at least one expense to submit”).
• Main Flow — The step-by-step sequence of actions in the normal, successful scenario.
• Alternative Flows — Variations that lead to the same outcome via a different path (e.g., uploading a receipt photo instead of typing the amount).
• Exception Paths — What happens when something goes wrong — validation errors, timeouts, permission issues. Documenting these early prevents surprises during development.
• Postconditions — What is true after the use case completes successfully (e.g., “Expense report is saved with status Pending Approval”).

Connecting to Personas

Each use case is linked to one or more personas. This connection ensures that you are always designing for a specific type of user, not for an abstract “someone.” When you view a persona, you can see all the use cases associated with them, and vice versa.

User Journeys

While use cases focus on individual tasks, user journeys zoom out to show the full experience over time. A journey captures every touchpoint — from the moment someone first hears about your product to the moment they achieve their goal (and beyond).

Mapping Journey Phases

Each journey is divided into phases. For example, an onboarding journey might have phases like:

1. Awareness — The user discovers your product through a colleague's recommendation.
2. Sign-Up — They create an account and enter basic information.
3. First Use — They complete a guided setup and try the core feature.
4. Habit Formation — They return regularly and integrate the product into their daily routine.
5. Advocacy — They recommend the product to others on their team.

Emotional States

One of the most valuable parts of a user journey is tracking how the person feels at each phase. Audra Flow lets you assign emotional states — such as excited, confused, frustrated, or satisfied — to each step. This makes pain points impossible to ignore and highlights the moments where your product can truly delight people.

Linking to Personas and Use Cases

Each journey is tied to a persona, and individual steps within the journey can reference specific use cases. This creates a layered model: the journey shows the big picture, the use cases show the details, and the persona reminds everyone who you are designing for.

Service Maps

A service map (also called a service blueprint) shows what happens behind the scenes to deliver each step of a user journey. While journeys focus on the customer's experience, service maps reveal the systems, teams, and processes that make that experience possible.

Creating a Service Map

1. In the Definition phase, click Service Maps.
2. Click Add Service Map.
3. Link the service map to an existing user journey so the two are always viewed together.
4. For each journey step, document what happens at each layer (see below).

Service Map Layers

Connecting to Architecture Decisions

Service maps are especially valuable when you reach the Design & Delivery phase. They give your architects and engineers a clear picture of what systems are needed, where integration points exist, and which processes are candidates for automation. The connections you build here directly inform your product architecture and technical specifications later.

Storyboards

Storyboards tell the story of a user experience as a sequence of visual frames — like a comic strip for your product. They are powerful communication tools because they make abstract journeys feel concrete and human.

Creating a Storyboard

1. In the Definition phase, click Storyboards.
2. Click Add Storyboard.
3. Link it to a user journey so the narrative follows a documented experience.
4. Add frames one by one. Each frame has a title, description, and optional image or sketch.

Tips for Effective Storyboards

• Keep each frame focused on a single moment or action. If a frame tries to show too much, split it into two.
• Include the user's emotional state in the description — this carries the empathy from your journey maps into a visual format.
• You do not need polished artwork. Rough sketches or even text-only descriptions are effective for early-stage communication.
• Share storyboards with stakeholders who are not involved in the day-to-day. They are one of the easiest artifacts for non-technical team members to understand.

Approval Workflow

Definition artifacts go through a review and approval process before the project moves to Design & Delivery. This ensures that everyone — product managers, business stakeholders, and technical leads — agrees on what is being built before significant effort is invested.

How Approval Works

1. Create your artifacts and set their status to In Progress while you are still refining them.
2. When an artifact is ready for review, change its status to Complete.
3. A project manager or product owner reviews the artifact. They can leave comments, request changes, or approve it.
4. Approved artifacts are locked for editing (though they can be unlocked if changes are needed later).

The approval status is tracked per artifact. You can see at a glance which personas, use cases, journeys, service maps, and storyboards have been approved and which still need review.

Version History

Every change to a Definition artifact is recorded in its version history. You can view previous versions, compare changes, and understand how the artifact evolved over time. This is especially helpful during approval — reviewers can see exactly what changed since the last review.

Traceability

One of the most powerful features of Audra Flow is end-to-end traceability. Every Definition artifact links back to the Discovery goals that inspired it and forward to the Design artifacts that implement it.

Backward Links (to Discovery)

When you create a persona, use case, or journey, you can tag it with the Discovery goals it supports. This means you can always answer:

• “Which personas are we building for, and which goal does each one address?”
• “Which use cases directly support our highest-priority goal?”
• “Are there any goals that are not covered by any use case?” (A gap worth investigating.)

Forward Links (to Design & Delivery)

When you move into Design & Delivery, user stories reference the use cases they implement. Architecture decisions reference the service maps that identified the need. This chain of connections means every piece of work can be traced back to a real user need and a business objective.

Why traceability matters: When a stakeholder asks “Why are we building this feature?” you can follow the trail from a user story, through a use case, through a persona, all the way back to a Discovery goal with a measurable KPI. That level of clarity reduces scope debates and keeps the team aligned.

Using AI in Definition

Two AI agents are particularly useful during the Definition phase: the Product Owner and the Architect.

Product Owner Agent

The Product Owner agent specialises in product specifications, requirements, and acceptance criteria. Use it to:

• Draft personas from your Discovery interview data.
• Generate use case flows, including exception paths you might not have thought of.
• Write acceptance criteria for each use case so the development team knows exactly what “done” looks like.
• Suggest journey phases based on your personas and use cases.

Try this: “Write a detailed use case for submitting an expense report, including preconditions, main flow, alternative flows, and exception paths.”

Architect Agent

The Architect agent focuses on the technical side of your definitions. Use it to:

• Review service maps and suggest which systems or APIs are needed at each layer.
• Identify technical risks in your use case flows (e.g., a step that requires real-time data synchronisation across services).
• Recommend integration patterns based on your service map.
• Flag non-functional requirements — performance, security, scalability — that your use cases imply but do not explicitly state.

Try this: “Review my service map and suggest what APIs and backend services we will need to support the front stage interactions.”

Product Guru for Quick Answers

If you have uploaded domain documents — industry regulations, internal policies, competitor research — you can use the Product Guru agent to get quick, citation-backed answers. For example: “What are the data retention requirements in our compliance document?” This saves you from switching to another tool to look things up while writing your definitions.

When to Move to Design

The Definition phase is complete when your team has a clear, agreed- upon picture of what you are building. Use this checklist to assess your readiness:

• You have created personas for all major user groups identified in Discovery.
• Each persona has at least one use case describing a core task they need to accomplish.
• Use cases include main flows, alternative flows, and exception paths.
• At least one user journey maps the end-to-end experience for your primary persona.
• Service maps document what happens behind the scenes for your most important journeys.
• Storyboards have been created for key scenarios (especially ones that need stakeholder buy-in).
• All critical artifacts have been reviewed and approved by the product owner or project manager.
• Every artifact links back to at least one Discovery goal, and there are no orphan goals — goals with no Definition artifacts supporting them.
• The team has no major unresolved questions about the scope or direction of the product.

Tip: Like Discovery, the Definition phase is not permanently closed. You can return to update personas or add use cases as you learn more during Design & Delivery. But having solid definitions before you begin architecture and story mapping dramatically reduces the cost of changes later.

Next Steps

With your definitions in place, you are ready to move into Design & Delivery. There, your team will translate personas, use cases, and journeys into a product architecture, story map, MVP scope, and detailed user stories that development can pick up.

• Design & Delivery — Build your product architecture, create story maps, define MVP scope, and write user stories.
• Discovery Phase — Go back to review or update your goals, interviews, and competitor analysis.
• Collaboration & Approvals — Learn more about team review workflows and approval gates.
• Working with AI Agents — Explore all four AI agents and how they support each phase.