Meet the TheyDo Agent

Read more in our blog

Intro to journey frameworks

A journey framework is how you build the graph: the connected structure of journeys that lets one piece of evidence be found by everyone who needs it, at whatever altitude they work. This article explains what that structure is made of, why it is a graph rather than a filing tree, and which article to read next.

A framework is a structure you build, not an object you create

There is no Create framework button, and that is not an omission. A framework is made entirely out of journeys and the connections between them. The word describes the arrangement.

Which means a framework is a set of decisions rather than a setup task: what deserves to be a journey, what altitude it belongs at, and what connects to what. TheyDo will hold any structure you give it, including a poor one, so the thinking is the work.

Note: if you have used TheyDo for a long time you may remember Frameworks and Boards as objects you could create and open. That older hierarchy model has been retired and its interface removed. Old framework links now open the matching journey instead.

Journeys are nodes, connections are the structure

Two pieces build everything.

Journeys are the nodes. Each one is a real journey with its own phases, steps, lanes, owner and permissions. Nothing about being part of a framework makes a journey special or subordinate.

Nesting journeys into phases of the above journey is the connection. When you nest a journey inside another, you attach it to the step it belongs to. That connection is what makes the higher journey a way in to the lower one, and what lets progress and evidence travel between them.

Put enough of those connections together and you have a graph: a structure you can enter at any point and move through in any direction.

Read the picture

image.png

Three things in that picture matter more than the boxes.

The rows are altitudes. Each row describes the same customer experience from a different height. The top row is the whole lifecycle. The bottom row is a single task.

The boxes do not line up, and that is deliberate. "In-store vehicle sales" sits beneath Try and reaches into Buy, because that is true: the experience of buying a car in a showroom spans both. A journey is not filed inside one parent. It is referenced by every journey that contains it.

The vertical lines are the mechanism. They are the through-line from the top of the structure to the bottom. Because Finance Application is connected upward, an insight attached to a step inside it is reachable from "Buying a car without a trade-in", from "Digital Vehicle Sales", and from Buy. Nobody copies it up. It is one record, visible from every altitude that contains it.

Why a graph and not a tree?

In a tree, every journey has exactly one parent, so a journey that is genuinely shared has to be duplicated. Two copies of "Finance Application" means two owners, two sets of insights, and two versions of the truth within a month.

In a graph, Finance Application exists once and is referenced by everything that needs it. Build once, reference many times. That is the whole reason for the structure, and it is the difference between a framework and a folder tree.

You can see this in the product. If your workspace has the Observatory page, it draws your journeys as a graph rather than an outline, and when you select a journey its lineage card shows a path count such as "2 paths" whenever that journey sits under more than one ancestor chain. It can also show you orphan journeys: real journeys that nobody connected to anything.

Altitudes are about decisions, not detail

The levels are usually described as lifecycle, macro and micro, and it is tempting to read them as "how much detail". That framing leads teams to build a fourth level nobody asked for.

The more useful question is which decision each altitude supports:

  • The lifecycle altitude is where you decide where to invest across the whole relationship. Its audience is leadership, and its content is headline metrics and structure.
  • The macro altitude is where you decide what to fix or build in one major experience. Its audience is the people accountable for that experience.
  • The micro altitude is where you decide how something should actually work. Its audience is the people designing and researching it.

image.png

The same graph, read at a different height, answers a different question. A journey belongs at the altitude where the decisions about it get made. See Journey framework zoom levels for how the levels are usually laid out.

What the graph gives you

One address per piece of evidence. An insight and a metric attached to the same step of the same journey stop being two unrelated records and start describing the same moment. The graph extends that from one journey to the whole portfolio, so there is exactly one right place for a new finding.

Reach without duplication. Because a journey can be referenced from several places, the shared parts of your experience get built once.

Progress that adds up on its own. Opportunities and solutions on a nested journey contribute to the progress shown above them, so a leadership view stays current without anyone maintaining it.

A portfolio people can navigate. Journeys in a graph are found by moving through the structure. Journeys in a flat list are only found by already knowing their name.

  1. Journey framework zoom levels for the altitudes most frameworks start with.
  2. What are nested journeys? for the connection that holds the graph together.
  3. Every journey counts: how to recognize and organize journeys at scale in TheyDo for deciding what deserves to be a node.
  4. How to create a framework for building one.
  5. How to use frameworks in practice for living with it.

Tip: with only a handful of journeys you do not need to design a framework today. Name journeys as if the graph already existed, and connect them as they arrive.

Further reading