1.3.3 - Describe One Main Path - Then Ignore the Rest

Main path

Is the main path clear enough to ignore the rest?

The call

Describe one path first. Otherwise AI generates alternatives that split attention before the core flow is proven.

Why it matters

One main path keeps every design choice pointed at a single user result before edge cases enter the picture. AI can generate many alternatives quickly, but human judgement decides which options protect the main path and which can wait. The difference is between focused progress and scattered output that confuses users.

Explainer

A main path is not the average journey. It is the single route that matters most for the user and the decision in front of you. Until you can point to one user, one trigger and one path to the outcome, attention will keep splitting. AI can help map flows, but it cannot decide which one deserves focus first.

Make the main path concrete

Compare the broad version with a version you can actually test.

• Too vague: Users can explore the search tool in a few different ways.
• Concrete enough to test: A content creator opens the app, enters a question about what to write next, sees results shaped by their saved context and acts on one result in the same session.

The second version lets two people design the same flow from it.

Check the main path

• Pass: You can describe the user, what starts the flow and the exact steps that lead to the outcome.
• Fail: If the path still reads like a menu of possibilities instead of one route, it is not focused enough yet.

Do not move into feature, navigation or prototype work until this passes.

How to use AI for the main path

• AI chat: Rewrite the main path until you can state all three parts clearly.
• vibeCoding: Build the thinnest flow that tests this main path in practice before broader build work.
• AI-assisted coding: Carry the same main path into implementation and review so the live system keeps the same decision.

Sharpen the main path

Copy this prompt into AI chat, replace the bracketed lines with your real main path and keep the instruction exactly as visible here.

You are checking whether this main path is clear enough before you move forward.

Constraint:
The main path must be specific enough that two people would design the same flow from it.

Working draft:
User: [who the path is for]
Trigger: [what starts the flow]
Path to outcome: [the exact steps that lead to the outcome]

Task:
Decide whether this main path is specific enough to guide the next decision. If it is vague, rewrite it so two people would make the same decision from this main path.

Check:
- Would two people interpret this the same way?
- Does it stay concrete enough to guide the next step?
- Does it meet this bar: You can describe the user, what starts the flow and the exact steps that lead to the outcome.

Return:
- A corrected main path
- A short explanation of what was vague

Evaluation

Before accepting the result, check whether two people would design the same flow from it.

Example

To help you work through this, here is a real example. StartWithYourContext is an AI search tool built as part of the vibe2value project. Here is how its main path was written using the three parts:

• User: A content creator who manages a website and publishes regularly.
• Trigger: They open the app and enter a question about what to write next.
• Path to outcome: They see results shaped by their saved context, review the suggestions and act on one result in the same session.

That path is specific enough that two people would design the same flow from it.

When there is more than one side

Not every product has a single main path. When a system serves more than one side, each side follows a different route through the same product and designing for one path may leave the other unfinished.

Multi-sided worked example

For example, StartWithYourContext has two different main paths:

• Content creator: Opens the app, enters a question, sees results shaped by their context and acts on one.
• Developer: Clones the repo, follows the README, runs the project locally and understands how the layers connect.

Both paths are real, but they touch different parts of the system. If only one is designed, the other side’s experience happens by accident.

Risk and mitigation

• Risk: Adding side paths too early, which dilutes focus and makes feedback contradictory.
• Mitigation: Define one path-level success signal and decline extra routes until that signal is stable.

Key takeaway

Do not move forward until you can describe the user, what starts the flow and the exact steps that lead to the outcome.

Work through this in a workshop

If your main path is still unclear, bring it to a free weekly workshop. Bring the messy part of your AI-assisted build and leave with a clearer next step. In some sessions, we walk through practical examples on the Cloudflare Workers stack to show how a rough idea turns into something that actually runs.

What do you think?

How are you keeping one main path clear in your work and how is AI helping you hold that focus when new requests appear?