Personas and journeys

A list of capabilities tells you what a product does. It does not tell you what a person is trying to achieve. You need that before you can split the work into pieces that are worth building. This skill turns the audience from the brief into named personas, and the goal of each persona into a journey through the product.

Skill name: discovery-personas-journeys-atlassian. It reads the brief.

How to start it

Right after the brief you do not need the name of the skill. Say what comes next:

Let's continue with personas and customer journeys.
Which personas would you propose?

In a new session, name the skill and say where the brief is:

/discovery-personas-journeys-atlassian You'll find the product brief at
<Confluence URL>. Let's continue with personas and customer journeys.

What it works out with you

One persona per audience group in the brief, then one journey per flow.

Per persona	What it wants from you
Name, age, characterization	Enough to describe a person and not a group. This becomes the page title.
Description	One paragraph: where this person works, what their situation is, and why the problem affects them.
Expectations	Three or four, each with a short title and one or two sentences. Every title becomes its own heading, so you can comment on a single expectation or link to it.

Per journey	What it wants from you
Title	The action, with a number, J-001: <action>. No poetic titles, because nobody finds them again.
Short summary	One sentence.
Persona	Which persona walks through it.
Core capabilities addressed	Which capabilities from the brief this journey covers, each one as a direct link into the brief. The later epic uses the same link.
Trigger	The moment that starts it: the day, the time, the situation.
Journey	The path when everything goes well, told in four parts, each at least one paragraph.
Pain points today	Three or four, each with a short title and a reason.
What the app changes	Three or four, one per pain point and in the same order.

Then it checks the coverage, and this is the most useful part of the step. Every core capability from the brief has to show up in at least one journey. If one does not, then either a journey is missing or nobody really needs that capability. The skill says which of the two it thinks it is.

The work often shows that the brief itself is wrong or incomplete. The skill names that when it happens and offers to fix the brief first. It does not carry the contradiction into the next page.

Where it lands

A small tree of Confluence pages under the brief. A Personas page and a Journeys page collect the rest, and under them sits one page per persona and one page per journey.

A journey page has two placeholders, one for the epic and one for the related work items. They stay empty until the backlog exists, and the backlog skill fills them in then.

Mark a journey as agreed

Every journey page starts with a status at the top of its table: Draft, in blue. When the journey is ready to be discussed, set it to In review, in yellow. When the team agrees on it, set it to Agreed, in green. Change it in the table on the page, or tell the skill that a journey is agreed and it sets the status for you.

The status decides what the backlog creates. A draft gets nothing yet. A journey in review gets its epic, so it already shows up on a timeline. An agreed journey gets its stories too.

Note

The first skill that creates a page under the brief asks once whether the page titles should start with the product name. In a space of its own you do not need that prefix. In a space you share with other products it makes a page easier to find. Later skills look at the existing titles instead of asking again.

Next

The domain model, then the design brief. Both build on the journeys, and the design brief also uses the domain model when it already exists.