Explore interface changes in a working prototype
Let product and design staff use an AI coding assistant to try interface changes in the product workspace, then review and keep or revert them.
How this works
Let product and design staff use an AI coding assistant to try interface changes in the product workspace, then review and keep or revert them. Use this when product or design staff need to explore an interface change in realistic product context. The experiment should preserve the working product and make it easy to keep, revise or discard the proposed change.
Create an isolated working version, describe a narrow interaction or visual change, and let a coding assistant implement it using existing components. Review the running result rather than only a screenshot. Engineering evaluates accepted changes before they become production work.
Before you start
Working product checkout
Confirm the relevant branch, local changes and runnable environment.
Design brief
Specify the target flow, intended change and unchanged behavior.
Review criteria
Agree the viewports, interaction states and accessibility checks relevant to the experiment.
Prepare the inputs
- target_surface
- Required
route, component or user journey
Keep the change boundary explicit.
- design_request
- Required
desired behavior and visual references
Treat references as inspiration or requirements according to the user's brief.
- existing_components
- Required
design tokens and reusable patterns
Prefer current product conventions where suitable.
- test_states
- Required
sample data and relevant UI states
Use synthetic or permitted data.
Implementation, step by step
Isolate the experiment
- Create a separate working context and record the starting revision.
- Preserve existing uncommitted work and identify the files likely to change.
Checkpoint: The experiment can be reverted safely.
Translate the design request
- Describe layout, interaction and content changes in observable terms.
- Clarify consequential ambiguity while proceeding with reversible visual choices.
Checkpoint: The assistant has a bounded implementation brief.
Implement in context
- Modify the relevant components using existing styles and behavior patterns.
- Avoid backend or permission changes unless they are part of the authorized experiment.
Checkpoint: A runnable prototype exists.
Review the experience
- Inspect the interface at intended sizes and exercise relevant states.
- Check keyboard access, focus, long text and failure behavior where affected.
Checkpoint: Feedback references the running result.
Prepare keep-or-revert handoff
- Summarize the diff, accepted behavior and unresolved production concerns.
- Keep the accepted patch for engineering review or revert only the experiment's changes.
Checkpoint: The outcome is explicit and reviewable.
Decisions along the way
Design requires a backend change
Separate the prototype simulation from the proposed production requirement.
Existing component cannot support the idea
Document the constraint and make a bounded local variant.
Stakeholders reject the direction
Revert the experiment without disturbing unrelated work.
What you will produce
interface-prototype-patch
Code diffA bounded implementation of the design experiment.
Include: components · styles · states · limitations
design-review.md
MarkdownA handoff explaining what was actually reviewed.
Include: observations · accepted_behavior · open_issues · validation
Check the result
- Inspect the running interface rather than only source code.
- Verify relevant controls still work at intended viewports.
- Check the diff for unrelated changes.
- Confirm prototype limitations are visible in the handoff.
When something goes wrong
Product fails to start
Record the error and distinguish baseline setup issues from the experiment.
Shared styles cause regressions
Scope the change and retest affected neighboring surfaces.
Revert conflicts with other work
Stop and preserve both changes for manual reconciliation.
A worked example
SYNTHETIC EXAMPLE · NOT A REPORTED BUSINESS RESULT
Request
Synthetic: explore a denser task list.
Inputs
Brief asks to move status badges beside titles while preserving sorting and row actions. Existing long titles wrap onto three lines.
Expected result
Synthetic result: implement the badge layout in an isolated checkout, test long titles and keyboard row actions, and provide the diff for review. Do not change task status logic.
Run a small pilot
Start small
Explore one surface and one design question.
Record the baseline
Record iteration time and production concerns discovered during review.
Agree success criteria
Agree visual and behavioral acceptance criteria before expanding the experiment.
Stop or revise
Stop when the prototype requires unapproved system changes or damages unrelated work.
Keep the scope clear
- A convincing prototype does not establish production readiness.
- Keep deployment and permanent integration under the responsible engineering process.
Check before using
Prototype success does not establish production readiness. Verify accessibility, behavior, security, and platform support before release.
Business activities
- Plan products and business changes
- Build and change software
FROM A RECIPE TO YOUR WORKFLOW
Bring the company context together.
This workflow needs reliable inputs before it needs a better prompt. Moat8 Vault brings working information into a readable archive for the AI tools you use.
For this recipe: Existing product code · Design intent · Review and release requirements
Start with one recurring task, agree which sources to use, and review the first result with your team.
Discuss this workflow