When a user has a vague idea to create a new feature or module but hasn't clarified the specifics yet, this structured exploration process helps the user converge from the vague idea to a clear design solution and produce a complete design reference document.
Core Principles
- No Guessing, Ask More Questions — Do not create drafts without confirming the scope; ask about design specifications if unclear; let users make choices when uncertain
- ASCII First — Align information structure and layout logic first, then invest in HTML only when the logic is correct
- Multiple Solutions at Once — Produce 5-8 schemes in batches for users to choose a direction, instead of testing one by one
- Full State Coverage is Mandatory — Normal state is just the starting point; exception states, boundary cases, and interactive feedback must be fully enumerated
- Document All Decisions — Every decision confirmed in conversations must be written into the requirements summary, not just kept in conversation context
Deliverables
Each exploration produces
3 files, archived in the
设计/v{version}-{module-name}/
directory:
| File | Content | Purpose |
|---|
| Background, objectives, feature scope, key decisions, technical constraints | Input for the PRD phase, clarifying "why build it and what to build" |
{module-name}-design-draft.html
| Main interface HTML mockup | Visual reference for PRD and front-end development |
{module-name}-full-state-design-reference.html
| All page states, Toast, boundary cases, interactive rule table | Directly referenced by front-end developers for implementation |
The version number and module name are determined by the user and must be confirmed with them.
Workflow
Step 1: Requirements Divergence and Convergence
After the user shares a vague idea, proactively ask:
- What are the pain points? — What problems are encountered now? Why do you want to build this?
- Core Scenarios — What is the most typical usage scenario?
- What are the boundaries? — What will be included in this version? What will be excluded?
Organize into a structured requirements consensus:
What to build:
- xxx
- xxx
What not to build:
- xxx
Carrier: Standalone App / New Tab in Existing App / Plugin / ...
Prohibition: Start creating drafts right after the user says one sentence. Must align on requirements boundaries first.
Step 2: Technical Research (As Needed)
Determine if research is required: If the function involves external data (configuration files, APIs, third-party systems, file formats), technical constraints must be researched first. Skip if it's a pure UI function without external dependencies.
Research content:
- Data storage location and format
- Interfaces and limitations of existing systems
- Technical feasibility verification
Research results will directly affect the design solution (e.g., discovering different configuration formats between two tools may require adding a "Type" column to the interface).
Prohibition: Skip research and start drafting directly, only to find it's technically unimplementable.
Step 3: ASCII Batch Exploration
Produce 5-8 ASCII layout schemes with different ideas at once, each including:
- ASCII layout diagram
- One-sentence explanation of the core idea
Scheme A: Card List + Tool Checkboxes
┌──────────────────────────────────┐
│ ┌────────────────────────────┐ │
│ │ pencil [✓] CC [✓] CX│ │
│ └────────────────────────────┘ │
└──────────────────────────────────┘
Scheme B: Table View, One per Row
┌──────────────────────────────────┐
│ Name Type CC CX │
│ pencil stdio [✓] [✓] │
│ github http [✓] [✓] │
└──────────────────────────────────┘
Users can:
- Directly select one scheme
- Combine elements from multiple schemes ("Structure of B + Switch style of E")
- Reject all schemes and provide new directions
Prohibitions:
- Produce only 1-2 schemes (no choice space for users)
- Produce more than 10 schemes (choice overload)
- Schemes with minimal differences (cosmetic changes only)
Step 4: Confirm Design Style
Ask the user the following questions:
-
Is there an existing design system? (e.g., design-system.html)
- Yes → Read and strictly follow design tokens (colors, font sizes, rounded corners, spacing)
- No → Ask about style preferences, or directly produce drafts for users to choose a style
-
Are there existing pages to reference? (Outer frame, navigation structure)
- Yes → Read the reference page and align the outer frame style (e.g., mac-window, sidebar layout)
- No → Treat as an independent page
-
Carrier form?
- New page/Tab in existing app → Must align with the outer frame and navigation of the existing page
- Standalone app → Custom outer frame
- Other → Clarify details
Prohibition: Default to a certain design system without asking.
Step 5: HTML Design Draft
Based on the selected scheme + confirmed design style, output an HTML mockup:
- Fill with real data (do not use lorem ipsum)
- Strictly use CSS variables / design tokens if a design system is available
- Keep the outer frame structure consistent if a reference page is available
After output, ask the user to open it in a browser for review and make minor adjustments based on feedback. Minor adjustments refer to specific small changes (spacing, color matching, copy), which can be executed directly without re-selecting schemes.
Step 6: Full State Coverage
Produce a complete full-state design reference HTML, which must include the following content:
Mandatory Page States to Cover
| State | Description |
|---|
| Normal State | Standard display with data |
| Loading State | Data loading in progress (spinner + disabled interactions) |
| Empty State | No data, with guidance copy |
| No Results from Search/Filter | Data exists but no matches for current conditions |
| Error State | Data loading failure, file not found, format error, etc. (split into multiple by scenario) |
| Partially Available | Some data sources available, some failed |
Mandatory Interactive Feedback to Cover
- Toast Summary: All success/failure/warning Toasts for operations, including specific copy
- Toast Rules: Position, duration (short for success, long for error), maximum number displayed at the same time
Mandatory Boundary Cases to Cover
- Long text truncation (names, paths, URLs)
- Scrolling with large amounts of data
- Others added based on specific scenarios
Mandatory Interactive Behavior Rule Table
Table format with column definitions:
| Trigger | User Action | System Behavior | Feedback |
|---|
| User/System/Exception | Specific action | Detailed system processing steps | Toast/state change/interface update |
Covers the complete mapping of all user operations and system behaviors, directly referenced by front-end developers for implementation.
Document Structure
- Top: Title, version, date
- Directory: Anchor jump
- Each state as a section: Tag + Title + Description + Preview Section + Annotations
- Bottom: Interactive Behavior Rule Table
Prohibition: Stop after only completing the normal state. Full state coverage is the core deliverable of this process.
Step 7: Requirements Summary + Archiving
Generate a requirements summary document using the template (
).
Extract all decisions confirmed in conversations and write them into the "Key Decisions" section. These decisions are often scattered in conversations and must be actively collected and organized without omission.
Archive the three files in the
设计/v{version}-{module-name}/
directory. Confirm the version number and module name with the user.
设计/v0.11-MCP管理/
├── 需求总结.md
├── mcp-manager-设计稿.html
└── mcp-manager-全状态设计参考.html
Communication Specifications During the Process
Must Ask the User
| Timing | Questions |
|---|
| Step 1 | Pain points, scenarios, boundaries (what to build/what not to build) |
| Step 3 | Which scheme to select |
| Step 4 | Whether there is a design system, reference pages, carrier form |
| Step 5 | Whether the mockup effect is satisfactory, any minor adjustments needed |
| Step 6 | Whether any scenarios are missing in full state coverage |
| Step 7 | Version number and module name |
No Need to Ask the User
| Item | Directly Execute |
|---|
| Whether to cover full states | Mandatory, no need to ask |
| Whether to write interactive rule table | Mandatory, no need to ask |
| Whether to output requirements summary | Mandatory, no need to ask |
| Toast copy | Provide suggestions first, adjust if user is unsatisfied |
What AI Should Never Do
- Start creating HTML right after the user shares a vague idea
- Produce only one ASCII scheme
- Only handle normal state and ignore exception states
- Skip technical research and start drafting directly (if external data is involved)
- Keep decisions only in conversations instead of writing them into the requirements summary
- Make up version numbers and module names on its own
- Default to a certain design system without asking