Diffuse.
Designing the review loop.

My prototypes were already in the browser. Reviewing them still meant moving screenshots and explanations elsewhere.

Lost context

The page, viewport and state disappeared from the conversation.

Repeated work

The same observation was rewritten for every handoff.

Unclear evidence

Changed builds and AI conclusions were difficult to check.

I used a small fictional Atlas scenario: what does “New item” create? A cropped screenshot could not carry the whole question.

On the page

The surrounding interface helps explain the ambiguity.

After sharing

Someone has to recover the page, viewport and intended change.

The opportunity

Capture that context while it is still available.

I followed one observation from the first question to the next review. Each handoff needed a different piece of context.

Capture

The subject, page and state.

Act

The expected behavior and supporting evidence.

Recheck

The updated preview and the build being checked.

I took Diffuse from problem framing and solution ideation to a working Chrome extension, vibe coding with Codex and Claude.

Design

Define the review flow, interactions and handoff requirements.

Build

Create capture, comparison, portable reviews, integrations and AI workflows.

Refine

Try the implementation, review generated code and adjust the interaction.

Browser capture was only the beginning. I built the Jira and GitHub apps around what the next person needed to do.

Jira

An editable issue preview, project fields, evidence uploads and delivery receipts.

GitHub

OAuth sign-in and the Diffuse Review App connect findings, commits and rechecks.

Portable review

A file-based handoff when neither service is needed.

I authored custom OpenAI and Anthropic agents, including their instructions, review criteria, tools and output structures.

Three responsibilities

Review screens, attempt a journey, and evaluate its saved evidence.

Deployment in Settings

Choose a provider and key; set up the reviewer or journey agents. Diffuse creates, checks and enables them.

Clear boundaries

The extension controls browser actions. The evaluator cannot operate the page.

I made the selected element the starting point. A reviewer can explain the problem beside its subject, with the interface still visible.

Pin

Identify one element or select an area.

Context

Save the page and viewport with the observation.

Example

Atlas says “New item”; the reference says “Create release.”

I built a live-tab comparison so the reviewer could inspect the implementation against an interactive reference.

Align

Compare both views at the same viewport.

Inspect

Move the divider or adjust opacity to reveal differences.

Repeat

Check desktop and phone layouts before capturing the finding.

The same action can wrap, move or become harder to find on a phone. I treated viewport size as part of the observation.

Capture

Keep the reviewed viewport with the feedback.

Reproduce

Reopen the layout at the size that prompted the issue.

Recheck

For Atlas: check the label, release form and keyboard access across sizes.

The first design asked for title, component and state too soon. I moved the composer beside the selected element and made the comment the starting point.

Start small

A comment first; expected behavior is optional.

Keep choices compact

Category and severity become dropdowns.

Expand when useful

Reproduction steps and evidence stay within reach.

Simplifying the composer should not make a detailed issue harder to explain. Supporting material stayed with its comment.

Explain

Add reproduction steps when the behavior needs context.

Show

Attach or inspect a screenshot or recording.

Extend

Turn a short observation into a reproducible issue without starting again.

In the Atlas example, Save reveals a three-character minimum only after submission. The screenshot shows the error, but misses the sequence.

Observed

An empty Release name reaches validation after Save.

Proposed

Explain the requirement beside the field beforehand.

Evidence

Keep the screenshot, reproduction steps and recording together.

I designed AI review as another pass over the work, with an explicit question and a bounded view of the evidence.

Choose

One entry opens Screen review or Journey test.

Focus

Use the current page, a live prototype or a frame reference.

Ask

For Atlas: inspect the action label, hierarchy and copy at this viewport.

I made Anthropic and OpenAI separate connections, so provider choice would not erase the context of work already recorded.

New work

Uses the selected provider and its saved configuration.

Saved journeys

Keep their original provider for discussion, continuation and alternative routes.

Responsibilities

Screen review, journey actions and evaluation stay distinct.

I structured the reviewer around a versioned set of NN/g and W3C-informed checks, with three explicit assessment types.

Visible observation

Something the captured screen supports.

UX recommendation

A proposed improvement, with its rationale.

Needs verification

Behavior or accessibility that requires additional evidence.

Accepted AI findings join the same comment system as human feedback. Acceptance is a reviewer decision.

Locate

A numbered pin keeps the page and viewport.

Inspect

The finding retains its evidence, assessment and guidance links.

Act

The Atlas suggestion becomes “New item” → “Create release.”

I shaped the AI handoff .md around a small verification brief, giving a coding assistant a scoped change and a way to check it.

Current

The action says “New item.”

Change to

Use “Create release” to explain the action.

Verify

Check desktop and phone, the release form, and keyboard access.

I brought screen review and journey testing into one entry. Journey setup makes the intended task and simulated perspective explicit.

Task

Set a goal, optional success criteria and test data.

Perspective

Choose confidence, familiarity, persistence, review focus and exploration style.

Benchmark

An action target measures the attempt; passing it does not stop execution.

I gave acting and evaluating different responsibilities, with the reviewer deciding which findings become comments.

Journey User

Attempts the goal. Diffuse validates each proposed action against a fresh page observation.

Journey Evaluator

Inspects saved evidence and answers questions; it cannot operate the website.

Continuity

A saved journey keeps its original Anthropic or OpenAI provider.

I made the attempted path inspectable: step notes, screenshots and a silent recording support the assessment.

Inspect

“Watch this step” opens its recorded moment.

Control

Pause, resume or stop; the ending retains a specific reason.

Accept

Useful findings become comments with page context and reproduction steps.

A blocker should leave room for judgment: an experience issue, an AI miss, or something still uncertain.

Discuss

Ask about the journey or one step, with links to saved evidence.

Continue

Use guidance in a linked attempt from the current page.

Try another route

Start a separate attempt from the original URL; preserve earlier evidence.

I added Journeys to Review Reports so an unfinished attempt remains inspectable, even with no accepted comments or executed actions.

Context

Keep the goal, persona, action target and known stop reason.

Step ledger

Retain the action, reasoning, execution status, result and page context.

Evidence

Include screenshots and recordings while stored; notes remain after older media clears.

I separated capture from the second pass before sharing: refine the wording, choose what needs action and retain the evidence.

Design peer

Reopen a portable review.

Coding assistant

Work from the Markdown verification brief.

Delivery team

Send selected findings to Jira or the relevant GitHub PR.

I designed .diffuse-review.json as a portable handoff that could return to the interface without a shared ticketing system.

Export

Package saved comments and evidence.

Share

Pass the review to someone with access to the site.

Continue

Load it in Diffuse and inspect the original context.

The file carries the review context. The recipient still needs their own access to the reviewed site.

Included

Comments, evidence, page, viewport and recorded location.

AI findings

Accepted assessments retain their labels and guidance links.

Separate

Site login and unsaved application state stay on the original device.

I paired export with Load review so the next person could interpret the feedback against the interface itself.

Load

Bring the saved comments into the sidebar and page.

Select

Restore the recorded page, viewport and location.

Inspect

Read the original explanation before deciding what to change.

I delayed Jira’s task structure until delivery, keeping quick capture separate from preparing an actionable issue.

Prepare

Edit the title and project fields in the preview.

Attach

Carry the selected finding’s screenshots or recording.

Recover

Delivery receipts and upload recovery help finish interrupted handoffs.

I extended GitHub review around the original finding, the proposed change and the later check.

Preview

Make the PR, working preview and reviewed commit explicit.

Publish

Keep selected findings in one summary with native evidence attachments.

Respond

Read in GitHub or load the review onto the working preview.

A reviewee needs a way to show progress without declaring their own change verified.

Recover

Load the PR feedback and inspect the original capture.

Adapt

Remap the preview origin or moved pin while preserving the evidence.

Return

Capture the update and choose “Share update & mark ready.”

I tied verification to the preview and build that someone actually checked.

Compare

Inspect original and current evidence; capture the fresh check.

Decide

Choose “Verify on preview” or “Still present.”

Revisit

A new commit or changed preview makes the earlier check historical.

Building the plugin, apps, services and agents let me carry design intent through the whole review loop.

Capture taught me

Reduce initial decisions and keep evidence close.

AI taught me

Separate action from evaluation; retain unsuccessful attempts.

Next validation

Test whether another person can reproduce a finding and confidently recheck the change.