Bezel Team hitl-screen-design design-001
The current design process produces useful intent, architecture, and plans, but it does not reliably break the product into human-reviewable screens, wireframes, and states before implementation. That creates a gap where agents can build technically plausible software that the product owner never truly visualized or approved.
The current design process produces useful intent, architecture, and plans, but it does not reliably break the product into human-reviewable screens, wireframes, and states before implementation. That creates a gap where agents can build technically plausible software that the product owner never truly visualized or approved.
Before any production build starts, Bezel must guide the customer through a concrete screen and workflow review: what screens exist, what each screen does, what states it has, what data it needs, what actions are possible, and what the customer is approving.
The current design process produces useful intent, architecture, and plans, but it does not reliably break the product into human-reviewable screens, wireframes, and states before implementation. That creates a gap where agents can build technically plausible software that the product owner never truly visualized or approved.
- Customer can explain what will be built by pointing to screens, not prose.
- Zero build tasks are dispatched for screens lacking approved records.
- Implementation defects caused by misunderstood screen behavior decrease over successive projects.
- First customer approves screen map and top wireframes before build starts.
The current design process produces useful intent, architecture, and plans, but it does not reliably break the product into human-reviewable screens, wireframes, and states before implementation. That creates a gap where agents can build technically plausible software that the product owner never truly visualized or approved.
Before any production build starts, Bezel must guide the customer through a concrete screen and workflow review: what screens exist, what each screen does, what states it has, what data it needs, what actions are possible, and what the customer is approving.
- Customer can explain what will be built by pointing to screens, not prose.
- Zero build tasks are dispatched for screens lacking approved records.
- Implementation defects caused by misunderstood screen behavior decrease over successive projects.
- First customer approves screen map and top wireframes before build starts.
Machine-readable source fields
Before any production build starts, Bezel must guide the customer through a concrete screen and workflow review: what screens exist, what each screen does, what states it has, what data it needs, what actions are possible, and what the customer is approving.
bezel.hitl-screen-design
HITL Screen Design Layer
The current design process produces useful intent, architecture, and plans, but it does not reliably break the product into human-reviewable screens, wireframes, and states before implementation. That creates a gap where agents can build technically plausible software that the product owner never truly visualized or approved.
1
2026-05-04T12:11:14.124Z
- Build cannot start from prose-only requirements.
- Every must-have screen must have an approved screen record.
- Every must-have flow must have at least one approved flow path.
- Every production-critical screen must define non-happy-path states before implementation.
- Open questions on screen purpose, role access, primary action, or data source block build.
- Customer comments should attach to screen IDs, not free-floating prose.
- Agents may propose screens and wireframes, but the customer approves or rejects them.
- Agent recommendations are part of product strategy; building/operating those agents is separate expansion scope unless explicitly included.
- Every screen review must explain where the customer is in the design/build process and what approval unlocks next.
- Playgrounds are generated from artifacts for review; they are not source of truth and cannot bypass artifact approval.
bezel-team
2026-05-04T14:57:54.482Z
Decide whether wireframes should be rendered as structured HTML inside Bezel first, or generated as image/board artifacts later. Recommendation: start with structured HTML wireframes because they are easier to diff, comment on, and translate into implementation tasks.
- Customer can explain what will be built by pointing to screens, not prose.
- Zero build tasks are dispatched for screens lacking approved records.
- Implementation defects caused by misunderstood screen behavior decrease over successive projects.
- First customer approves screen map and top wireframes before build starts.
Low-to-mid fidelity, intentionally fast: structure, hierarchy, copy blocks, controls, data areas, and states. Not final visual polish.
The goal is shared understanding and build correctness, not dribbble-level mockups before validation.
High-fidelity visual design can become an optional paid design pass or happen for screens selected as brand-critical.
For nontechnical product owners, a screen is the unit of understanding. Requirements become real only when the customer can see and approve the screens and flows.
The customer should always know where they are in the product-build process and what they are doing next.
Every review screen must have one primary next action and one clear escape: request changes, ask question, or save for later.
Orientation data should come from phase/gate status and artifact approval state, not static copy.
Persistent project progress rail plus current-step header plus next-action panel.
- Where am I?
- What phase is this?
- What did Bezel just produce or learn?
- What decision/action is needed from me?
- What happens next after I approve or request changes?
- What is blocked?
| purpose | status gate | artifact type |
|---|---|---|
| Canonical inventory of screens, routes, roles, data needs, actions, dependencies, and priority. | Must be approved before wireframes are considered complete. | screen-map |
| Human-reviewable layout and interaction spec for each critical screen. | Must be approved before architecture/build tasks are locked. | wireframe-spec |
| User journey map across screens, including alternate and recovery paths. | Must be approved before build plan generation. | flow-spec |
| Screen-by-screen state matrix: default, empty, loading, error, success, permission/locked, mobile/responsive where relevant. | Must be approved for all screens marked production-critical. | screen-state-spec |
| Identifies where the customer should move from SaaS-shaped screens/manual workflows to AI-first agent workflows, including recommended agents, triggers, human gates, data needs, and whether each agent is included or expansion scope. | Must be reviewed before final build plan so customer understands product scope vs optional agent infrastructure scope. | ai-first-opportunity-map |
| Defines where multi-model research runs, which models critique which decisions, and how outputs become accepted artifacts. | Must be defined before automating model review gates. | model-collaboration-protocol |
| Defines how artifacts become sandboxed visual playgrounds for HITL review and how feedback flows back into canonical artifacts. | Must be reviewed before implementing playground generation. | playground-generation-protocol |
stable screen id, e.g. dashboard.home
Human-readable screen name
must | should | later
- Who can see/use this screen
M-XX or TBD
- Data needed to render the screen
- Data created or changed by this screen
- External/internal services this screen touches
What the user is trying to accomplish here
- Questions that block approval
URL route, modal, tab, or embedded surface
- Actions the user can take
| step | output | customer experience |
|---|---|---|
| Product Intake | Intent summary and open questions. | Customer explains the product, users, workflows, business rules, and desired outcome. |
| Screen Inventory | Screen map with purpose, owner/user, route, data, actions, and priority. | Bezel proposes every screen needed for the product, grouped by user journey and role. |
| AI-First Opportunity Review | Opportunity map with recommended agents, workflow shifts, expected value, and expansion-scope flags. | Bezel shows where the proposed product should stop copying SaaS screens and instead use agents, approvals, and automated workflows. |
| Flow Review | Primary flows, alternate flows, and blocked/error paths. | Customer reviews how users move through the product from entry to completion. |
| Wireframe Review | Approved wireframe set. | Customer sees low/mid-fidelity wireframes for each critical screen and can request changes before build. |
| Playground Review | Playground feedback attached to screen/component ids and promoted into artifact revisions. | Customer opens an interactive sandbox generated from approved/draft wireframe artifacts to see the product before build. |
| State Review | State-complete screen spec. | Customer reviews default, empty, loading, error, success, permission, and edge states for screens that need them. |
| Build Plan Approval | Build-ready plan and acceptance criteria. | Customer approves what will be built, in what order, and what counts as done. |
- Claude critiques whether the flow is understandable and product-focused.
- Gemini suggests missing screens, alternate states, and AI-first workflow opportunities.
- Codex/OpenAI checks whether the screen spec is implementable and testable.
Screens, flows, and wireframes should be critiqued by multiple models before customer approval when the decision materially affects product direction.
Store model review evidence and synthesis before build plan approval.
- Screen map board grouped by journey/role
- Review queue for screens needing approval
- Wireframe viewer with comments and approve/request changes controls
- State checklist per screen
- Change summary between revisions
- Build readiness indicator based on approved screens/states
- AI-first opportunity map with Included vs Expansion labels for recommended agents
- Screen IDs become build task anchors
- Wireframe/spec links are injected into task briefs
- Review feedback creates revision tasks instead of ad hoc chat
- Completion verification checks implemented UI against approved screen-state spec
Screen Map + Wireframe Approval MVP
- Create screen-map artifact from intake
- Render screen cards in Bezel Studio project view
- Generate simple wireframe specs for top 3 must-have screens
- Support approve/request-changes per screen
- Block build plan until required screens are approved
- Create AI-first opportunity map from intake and screen review
- Full Figma integration
- Pixel-perfect visual design
- Realtime collaborative editing
- Automatic implementation from wireframes without build artifacts