Map the surfaces that matter
Start with the parts of your product where people make decisions or get work done: pricing, signup, onboarding, checkout, settings, and help. Pick the surfaces your customers depend on. You do not need to review the entire product at once.
For example, a trial signup has several questions: does pricing explain the offer, does signup communicate what is required, and can a new user reach the first useful screen? Review each page first, then explore how the pages connect. This guide walks through that progression and shows how to keep useful checks running as the product changes.
1. Choose the workspace and target
Sign in to the Flock dashboard and select the workspace where the review belongs. Use a public, preview, or staging URL that Flock’s hosted browser can reach. A development server available only on your laptop needs an appropriate deployed target; connecting MCP does not expose it to Flock.
If the journey requires login, prepare a saved sign-in in Settings → Integrations and complete the browser login yourself. You will select that profile in the review’s Auth step. For a signup task, use the intended test environment and test data.
2. Start with a single page or design review
On a desktop-sized browser, choose New Review and keep Guided selected. Review creation currently requires a viewport at least 768 pixels wide; existing results can be read on mobile.
Choose Single Page Run for a focused review of one captured page, without navigation. Enter its URL in Target, choose relevant profiles in Personas, and select a saved sign-in in Auth if needed. In Review, inspect the setup and estimated usage, then choose Launch Review.
For pricing, an unfamiliar user and a skeptical evaluator can raise different questions about the same offer. Inspect their evidence before adding more personas or more pages. The persona guide explains how to choose and customize those perspectives.
For a design-focused question, select Design Reviewer when it is offered in the persona selector. It is a reviewer option, not a separate goal type. An approved design baseline can provide a reference for comparison when that option is available. Use the review setup reference for the controls and their limits.
3. Explore the connections with Roam
Once the individual pages make sense, create a Roam review. Roam lets the reviewer navigate across steps rather than analyze only the starting page. Start at the same pricing page, for example, and examine the path toward signup and help.
Choose personas that reflect the people you want to learn about. Check the navigation and time budgets before launch. A bounded exploratory run gives you evidence about the path it took; it does not establish coverage of every route in the product.
Read the visited steps and findings. An unclear link or unexpected detour can explain why a journey needs a more specific goal review next.
4. Give important journeys a clear goal
Choose Goal when you want to state a task, with This page only or Follow the flow determining its scope. For “Create an account and reach the welcome screen,” use Form Completion and Follow the flow.
For a goal review, describe what the persona should accomplish, how you will recognize completion, and where it should stop.
For example:
- Starting page: your staging signup page.
- Task: create a trial account and reach the welcome screen.
- Completion: the expected welcome text or page is visible.
- Boundary: stop before inviting anyone or entering payment details.
The exact completion condition should match your application. Keep the step and time limits appropriate to the task. A bounded, specific journey is easier to interpret and repeat.
Provide the test inputs the journey requires. For signup, generated email and password inputs can help make the setup repeatable. For checkout, define the choices that matter to the question. The goal and input reference explains supplied values, reviewer choices, generators, and one-time values.
In Target, enter the starting URL and resolve any detected setup values. Select personas and sign-in, then inspect the completed setup in Review. A sign-in to Flock and a sign-in to your application serve different purposes.
In Review, inspect the target, scope, personas, sign-in choice, limits, and estimated usage. Resolve any readiness requirement shown by the dashboard, then choose Launch Review when the setup is the one you intend.
The estimate lets you understand expected usage before launching. Your workspace permissions and account terms determine which reviews are available. Completion criteria should describe a finish line you actually want: a matching URL, visible content or element, or a successful request. Any one supplied criterion can mark the goal achieved, so choose each carefully.
5. Triage the findings and verify the change
Open the review summary, then inspect an individual persona’s findings and evidence. Start with three questions: did it reach the goal, what difficulty did it observe, and what supports that observation?
Use review scores to understand impressions and findings and evidence to understand priority and proof. A completed run describes execution; its task outcome and evidence tell you what happened during the journey.
Use Address, Defer, or Dismiss to record what should happen next. Address selects work for a repair; it does not prove the issue is fixed. Defer keeps future work visible and can carry forward when Flock can match the same finding and target. Dismiss records why no fix is needed. The review triage guide explains the distinction and how to reopen a deferred finding.
After a change, review the same target with comparable personas, goal, sign-in, and limits. Compare the evidence as well as the scores. When Run again is available, use the saved setup; repair a one-time or unavailable setup before trying to repeat it.
6. Keep useful checks running
Once a review answers a useful question, make it part of how you maintain the product.
- Scheduled reviews revisit a stable target over time. Open the review’s Schedule control, choose the cadence, timezone, and time preference, and create the schedule. Read scheduled reviews before relying on saved inputs or sign-in across repeats.
- The GitHub App reviews configured pull-request previews as code changes. Its Preview Gate, summary, and evidence help you investigate regressions before merging. Follow the GitHub setup guide to connect the repository, target, and reviewers.
A schedule is useful for “is this experience still working?” A PR review is useful for “what did this change affect?” Both provide evidence to inspect; a successful check cannot guarantee that every possible regression was covered.
Bring the review into your normal workflow
Connect MCP so your coding agent can help plan a review, read its evidence, and work on the repair. Review the proposed setup and usage before authorizing a launch.
For example, ask the agent: “Help me review the signup changes on this preview. Recommend personas available to this workspace, show the goal, limits, and estimate, and wait for approval before launch.”