# User flows

Source: https://docs.tai.ga/learn/user-flows/

A user flow is one thing a person does with your product, from the first screen to the outcome, drawn as a diagram and written out as steps.
The User Flows document is the set of them, with an overview of the whole set at the top.

Taiga drafts it from the specification, and everything downstream reads it once it is published:
the architecture and the service blueprint are written against these journeys, and the work that gets planned and built follows them.
So the flows are worth arguing with, and arguing with them is a conversation rather than a form.

## Where it starts

In the project's document list, **User Flows** is the row after the specification.
It needs a published specification and nothing else.

Choose **Generate** on the row.
Taiga reads the specification and drafts a first set: one flow for each journey it finds, and an overview that summarizes them.
Each flow says who is doing it and what they are trying to achieve, shows the journey as a diagram with its decision points, and lists the steps.
The row reports progress while it works, and the document appears when it is done.

## The document

The document page shows the overview first, then one section per flow with its diagram and steps.
Open a diagram to see it at full size; you can fit it to the window, show it at actual size, zoom, and move around it with the mouse or the arrow keys.

The document is versioned and reviewed like every other project document:
publishing writes the next version rather than rewriting history, and you can mark a version reviewed once you have read it.
[Project documents](https://docs.tai.ga/learn/project-documents/) covers what that means for the set as a whole.

## Changing it

Choose **Edit** on the document.
Editing a flow document is a conversation: the document stays on one side and you talk on the other.

Say what you want in your own words.
Ask for a flow that is missing, tell it a step is wrong, question whether two flows overlap, or ask what it thinks of the set.
The agent writes the change into the document as you watch, section by section, and keeps the overview true to the flows it now describes.
It has the specification in front of it, and it can consult the reference material in Knowledge when a question needs it.
Suggested starting points sit under the message box if you would rather begin from one.

Every change you agree on lands in a working draft at once, so the next thing you say is about the document you are looking at.
The published version is untouched until you publish.

## Removing a flow

There are two ways, and they end in the same place.
Ask for it in the conversation, or remove it from the flow itself.

Either way the flow stays on the page, marked as removed, with **Undo** beside it.
Undo puts it back where it was.
The overview is rewritten to match, whichever way you removed the flow.

## Draft, publish, discard

While a draft exists, the document page says you have unpublished changes, and **Edit** takes you back to the conversation to continue.
Nothing downstream reads the draft.

**Publish** writes the next version of the document and returns you to it.
That is the version the architecture, the service blueprint and the plans are grounded in from then on.

**Discard draft** throws the draft away and brings the published flows back:
what the conversation wrote, what you removed and what you brought back all go.

## During setup and after

The user flows are generated and worked out while the project is being set up, in the documents step.

Once setup has finished, the document is locked, together with the rest of the set the project was defined by.
The plans and the work in flight trace back to that set, so changing one of them quietly would move the ground under them.
To change the flows after that, reopen setup from the document's page; the conversation is then available again in the same way.

If you can read the project but not change it, you see the document and not the conversation.