Map missing interface states before implementation
Expand a proposed product flow into an explicit matrix of normal, empty, error, permission and recovery states so designers can close gaps before development.
How this works
Use this when a design proposal shows the main screens but leaves behavior between screens uncertain. The assistant enumerates reachable states, events and recovery paths using the supplied product rules. The deliverable is a review matrix, not code or a claim that the interface has been tested.
Focus on states that matter for this flow: missing records, loading, partial completion, expired sessions, unavailable services, permissions, duplicate submissions and return navigation. Do not add all imaginable edge cases to every screen. Keep questions separate from established requirements and preserve the owner’s intended user experience.
Before you start
Bounded flow
Choose a start event, user goal and end condition so the review does not become a whole-product audit.
Behavior owners
Identify the designer, product owner and technical contact who can resolve uncertain system behavior.
Current design evidence
Obtain screen exports, flow notes and applicable permission or validation rules.
Prepare the inputs
- design_artifacts
- Required
Screens, prototype link or local image exports
Record version and identify every screen reviewed; inaccessible screens remain unreviewed.
- product_rules
- Required
Validation, permissions and completion behavior
Distinguish documented requirements from proposed assumptions.
- flow_scope
- Required
Start, end and supported user roles
Exclude unrelated features explicitly.
- known_dependencies
- Required
Services, asynchronous operations and saved state
If unavailable, mark technical questions rather than assuming instantaneous success.
Implementation, step by step
Describe the intended journey
- Write the observed start state, user actions and successful end state from the proposal.
- Assign stable screen and action IDs so findings are not tied only to visual position.
Checkpoint: The happy path is explicit and traceable to the design.
Identify state dimensions
- List data availability, authorization, operation progress and relevant validation outcomes for each action.
- Use actual dependencies to choose meaningful combinations; do not multiply impossible states.
Checkpoint: The matrix distinguishes reachable conditions from hypothetical ones.
Map transitions and ownership
- Record which event causes each transition and whether the user, client or service supplies it.
- Mark uncertainty about persistence, retries and navigation as questions for the technical contact.
Checkpoint: Every transition has a trigger and an expected destination or open issue.
Inspect missing and contradictory behavior
- Compare screen copy, available actions and recovery routes across the reachable states.
- Check whether success messages can appear before completion or whether a user can repeat an irreversible action.
Checkpoint: Findings describe the concrete user consequence and evidence.
Propose bounded design decisions
- Offer a specific missing state or recovery option for each confirmed gap.
- Preserve approved product rules and present alternatives only where the owner must choose.
Checkpoint: The designer receives actionable changes and a separate decision queue.
Reconcile the revised design
- Review changed screens against affected transitions and close only evidence-backed items.
- Keep implementation-dependent checks for engineering rather than marking them passed from mockups.
Checkpoint: The final handoff separates specified behavior from later runtime verification.
Decisions along the way
A proposed state contradicts a documented product rule
Flag the conflict for the product owner; do not silently alter the rule.
A dependency’s completion semantics are unknown
Leave success and retry behavior unresolved until the technical owner explains it.
What you will produce
interface-state-matrix.csv
CSVReachable-state coverage for the bounded design flow.
Include: screen_id · condition · event · expected_state · recovery · evidence · status
design-decisions.md
MarkdownSpecific design changes and unresolved behavior choices.
Include: finding · user_consequence · proposal · owner · verification_stage
Check the result
- Ensure every visible action has a defined success, failure or pending outcome where relevant.
- Check recovery paths do not discard acknowledged work without explanation.
- Keep inaccessible designs and undocumented backend behavior labeled unknown.
- Confirm state names and messages use consistent product vocabulary.
When something goes wrong
Screens belong to different revisions
Reconcile versions before reporting cross-screen contradictions.
The state matrix grows with impossible combinations
Use the documented transition rules to remove unreachable cases and retain the reasoning.
A worked example
SYNTHETIC EXAMPLE · NOT A REPORTED BUSINESS RESULT
Request
Synthetic: review an invoice-upload flow before implementation.
Inputs
The design includes file selection and a success screen. Upload and extraction are separate asynchronous operations; validation may reject an unreadable file.
Expected result
Add separate uploading, extracting and unreadable-file states, plus a recoverable retry path. Ask when the interface may truthfully show completion.
Run a small pilot
Start small
Review a few upcoming flows and compare findings with later implementation issues.
Record the baseline
Record edge cases first discovered during development or support.
Agree success criteria
Agree a useful confirmed-gap rate and reduced unresolved behavior at handoff.
Stop or revise
Pause broad conclusions if product rules or the actual design version cannot be identified.
Keep the scope clear
- Mockup review does not prove accessibility, browser behavior or working software.
- The workflow does not change production code, user permissions or product commitments.
Check before using
The designer and product owner approve behavior, permissions and recovery choices; implementation tests remain a later check.
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: design artifacts · product rules · flow scope · known dependencies
Start with one recurring task, agree which sources to use, and review the first result with your team.
Discuss this workflow