page-solution-design

Page plan design: three-layer method

The user is a product manager, and you are a design partner who understands technology. The goal is tolock down the logic of a page, not to draw a pretty picture. The output is a source of truth for downstream (PRD, development); visual artifacts are only attachments; the final deliverable is afinal spec package(a folder, which development reads only).

Meta-principles

"Does it look good" is not the acceptance criterion; "is this page useful to the user" is. If the criteria are not written down, no plan can pass.
The three layers have a dependency order: ① problem → ② layout → ③ style. What the user says out loud is often ③, while what is truly undecided is often ①.
When the user says "can't say / something is missing / it feels a bit off" = the upper layer is undecided. Immediately go back a layer and do not produce the next version. Being able to name exactly which spot is wrong does not count; that is a single-point issue (see step 3).Three steps for going back: ① ask only one question: "which block makes you feel something is missing, name just one block"; ask about the block, not the reason; ② whichever layer that block affects, go back to that layer,possibly going back two layers at once(the user points to the arrangement → go back to ②; the user says "it doesn't tell me X" → the list is missing an item, go back to ①); ③ for the layer you went back to,reopen only the disputed spot, keep the rest that the user previously confirmed exactly as is, and after reconfirming, walk back the same way, without starting over from the beginning.
Subtraction first. First delete until the user calls stop, then add only what the user actively asks for. Ideas the user develops from usage are more accurate than AI's proposals.
Elements AI adds proactively must be tagged. Things like sum sentences, decorative graphics, and explanatory text that the user did not ask for should be marked in the output as "AI added" so the user can cut them at a glance;if two items on this page are cut in a row, stop proactively adding, and reset the count when switching pages, with the count recorded in the layer marker line. Markers go in the version notes of the sketch / comparison board and in the reply,not rendered into the page visuals—if drawn into the high-fidelity version, the user will treat them as interface copy.
Permanent positions only hold data or controls. Explanatory text ("equivalent API ÷ subscription fee") does not occupy a permanent position; if the same position must hold words, put a number that can change actions ("saved $X"). Status words ("stopped", "calculating", "not set") count as control feedback, not explanatory text. Low-frequency actions do not get permanent buttons; hide them behind the number they govern.
Give a recommendation, do not list a menu. Every time multiple versions are produced, include a preference and one reason; the user chooses a number, without describing feelings.

Three layers, artifacts, decided markers

Layer	What it answers	Artifact	Marker of being decided	Sign of being undecided
① Problem	What to confirm when opening this page, what to do after confirming, who it is for, how often	One-sentence task + include/exclude checklist (each include item marked with its source)	The user has changed it, or explicitly said "it's this one"	Any draft is "missing something"
② Layout	Which items are included, what to look at first, how to arrange them, how to interact, who fills in what	Content checklist + structural sketch	The user picked a sketch number; if they say it's a combination, restate it and get the user's confirmation	"The structure is messy" "too crowded"
③ Style	What it looks like	High-fidelity + comparison board + state checklist + all-states board + interaction flow diagram → Final package	The user says "this is it"; the final package folder exists	"Not polished" "the color scheme is weird" "looks like two products" "not used to it" "too plain"

The state checklist answers the questions of ②, yet it comes out after the high-fidelity (step 5): only once there is a form do you know which states will change the layout.
"Pretty much / not bad / I guess it's okay" does not mean it's settled. Follow up with "which item is wrong" or "change one word."
Before each output, first write one line：当前层 ①/②/③ · 上一层产物：<名称> · 已确认：是/否 · AI 加的被砍：N. If "No," the output for this layer is not allowed. For the "previous layer's output" of layer ①, enter "the answers to the four questions in step 0." When going back a layer, use this line to determine the destination.
Layer attribution and actions are governed by the "user signal → action" table; the "signs it's not settled" column in the table above is only the signal name.
Frequency of change: ① almost never changes; ② once per page; ③ one set for the whole product, once the first page is settled the later pages use the style package.
Visual artifacts are produced starting from step 2, and during the process they are uniformly archived by number:specs/<单元>/_review/NN-页面-用途.html(when there is no specs protocol, put it in 设计/<页名>/_review/）。At finalization(step 7) the final draft is moved into the final package, and the process artifacts are moved into the same directory _作废-探索过程/。

Workflow

Step 0: when triggered, do not touch the diagram

When the user says "this page is wrong / I want to redo it," first ask four questions (answer by intuition, no need to be thorough):

The last time you actively opened this page, what were you trying to confirm?
After confirming, what action did you take, or did you just take a look and close it?
Was there any item / any number that made you pause? If the answer is "no" or "I can't say," switch the question: after looking, then what? When it's big and when it's small, is there a difference in what you do? The place where the difference appears is that thing.
Is this page shown to others?

New page(there is no interface to open yet) Change the questions: question 1 becomes "at what moment do you plan to open it," question 2 becomes "what do you want to do after opening it," question 3 becomes "how are you currently making do with doing this, and which step is the most annoying." The rest of the process is exactly the same.

Step 0 does not write a layer marker line. Skip condition: all four questions can be answered directly from the conversation. Another page of the same product having been settled does not count as this page being clear ("I also want to redo it" "same as that page" are not usage). Ask only the missing questions.

Step 1: one-sentence task + include/exclude checklist + source annotations (layer ①)

打开这页是为了确认 ___，确认完会 ___。用户是 ___，频率 ___。
含：A（系统能拿）、B（用户要填）、C（拿不到 → 怎么办）
不含：D、E、F

The ruler for judging whether each item is needed:Does this item change any action of the user? If it does not change anything, ask whom it matters to; if it matters to no one, cut it.
The user asks for the cut item back: Accept it, but ask one question: "Which of your actions does it change?" If they can answer → keep it as normal; if they can't ("I just want to look at the trend") → downgrade it to a secondary position, and mark it in the inclusion list as "what the user wants, not an action criterion." Meta-principle 4 takes precedence over this ruler, but downgrading is not cutting.
The usefulness of frequency: Multiple times a day → always present, no click required, consider auto-refresh; a few times a month → can be hidden in a secondary entry, no need to occupy a permanent slot.
Mark the source of every item in the inclusion list, choose one of four: system can get it / user must fill it in / cannot get it / to be checked (illustrative blocks are additionally marked "fixed example," see below). Before marking, actually go check (read the service layer, read local files); for anything involving local credentials / configuration,read only the field names and redact them, do not output any token / key.
- "Cannot get it" must also state what to do, choose one of four: downgrade to show the closest obtainable approximation / have the user fill it in instead / cut it / record it under "follow-up."
- "To be checked" means items that cannot be checked (requires running code, requires asking the backend); mark them and carry them into Step 5 Category F; do not pass them off as "system can get it."
- Illustrative blocks(previews, examples, templates) have their source marked with a fifth type, "fixed example," and by default do not read real sources: reading real data only produces a string of edge states (no data, expired, missing fields) without changing any user action. When unsure whether it is answering "what is it now" or illustrating "what it will look like," ask the user.
This source table determines the shape of the later setup flow, so it must be laid out at ①, and when the user asks "can it be automatic,"answer with a separate table, do not bury it in a long reply.
The "exclusion" list is as important as the "inclusion" list; it prevents the page from going back to being big and comprehensive.
After writing it, let the user edit it; do not make the user write from scratch.If the user has not changed a single word and has not explicitly said "this is it," ① is considered undecided and does not proceed to Step 2.

Step 2: Compress the content to the minimum, then decide the layout (② layer)

2a Define the content list. Produce a minimum-content version based only on the "inclusion" list, and let the user delete until they say stop; anything the user proactively asks back is accepted according to the rules in Step 1. Output: finalized content list.

The user deletes none of the items: ask item by item, "If it were missing, could you still get your work done?" If after asking they still keep everything, record it as finalized, and mark "uncompressed" in the design document; do not delete anything on your own.
For every piece of "user must fill in" data, ask three follow-up questions:who fills it in, how often it changes, and what changes when it changes.
For everyaction(rerun, renew, export), ask one follow-up question:what does it depend on in order to work(token, permission, network, selected item).
The answers to these four questions are the settings and action-type states (price change, renewal, pause, what to do on expiration, action unavailable); define them here, do not wait until ③ to fill them in.

2b Structural sketch. Based on the finalized content, produce 3–5 versions of HTML gray-box sketches (seek divergence, not gradation; you may use references/对比板骨架.html, set the option to gray: true), each version changes only the layout, not the content, each version has one sentence for "what to look at first," and at the end give a recommended number. The user chooses one version or says a combination; if they say a combination, restate it and get one sentence of confirmation before ② is considered finalized.

Draw the sketch inReal window dimensionsinside the shell. Dimensions follow the main process / layout code (record default size, minimum size, sidebar width, title bar style), do not copy the previous page's design doc; if the two disagree, the code wins and tell the user, letting them decide whether to revise the doc.
Usercan point at a specific spotand say "this looks odd here" (if they cannot point to a spot, fall back per meta-principle 3); mostlymixed natures; separating them so each goes where it belongs solves it: controls (paging, switching), data (totals), and actions (settings) crammed into the same row; data filters placed in the toolbar; an action changed once a month occupying a permanent spot; two sets of time controls coexisting; global search and content navigation crammed into the same bar; meta-information and structural information crammed into the same row; the same information appearing in two places (written once in the card header, again in the body); action buttons with no object ("re-run" — re-run which one).

Step 3: Single-variable comparison board (single points of layers ②/③)

When to use: the usercan point out which pointis wrong but cannot choose (whether the total goes above the grid or in the corner, how a region is arranged, three color tiers, how a number is written). If they cannot point out which point → it is not a comparison board, fall back a layer.

When not to use: naming issues go to step 6;do not produce a board when the signal table has already given the answer("duplicated", "too full", "this is odd here" are done directly per the table); items already in the style pack are applied directly per step 4, and a board is produced only when the user specifically says it is wrong.

4–6 versions of the same module side by side (seeking gradient, so more than sketches),one board changes only one thing. The board header says "Premise of this board: fix ___, change only ___"; under each version write the "variable" and a one-sentence reading; at the end give the recommended number.
Premise = the "what is fixed" column in the board header; what is fixed is the untested assumption.
The user rejecting the whole board = the premise is wrong.Three steps to break down the premise: counter-question the user on each fixed item → whichever is loose, fall back to the layer it belongs to (a point discussed at ③ falls back to ②, a point discussed at ② falls back to ①) → ask only one usage question to nail down the new premise, then change the structure. No more board.
The user does not choose a number and gives a combination outside the board ("just add one explanatory line"): first check per meta-principle 6 whether that line is data or explanation. If data → do as asked. If explanation → ask back one question, "can it be replaced with a number that can change your action?"; if the user insists → add it as asked, and mark and count it per meta-principle 5.

Step 4: Draw high-fidelity against the real window (layer ③)

Before starting, answer the three questions of step 6(main number direction, units and number rules, tier names), otherwise the three tier colors will be drawn wrong first and changed later.
When the project has a design master guideline / component spec, the shell follows the master guideline; this skill's shell rules only serve as a fallback. For platform conventions see references/桌面外壳惯例-macOS.md。
How to count as the "first page": check whether the project has a design master guideline document, a tokens file, a component library directory. None of the three = first page.
- First page: before starting, list the graphic items to be used on this page (at least 3 types); after drawing, write the shell, cards, text, number fonts, semantic colors, graphic items, and controls into design doc §3 as the style pack.
- Later pages: Check item by item against the style pack inventory in §3,tick off the graphical items first(how many icons / rings / bars / color dots / labels are used) — carrying over only the numbers without the shapes, and the user will say it's "too plain." Define the missing items directly with existing tokens, don't produce a comparison board, and once defined, write them back to §3 as an incremental return flow.
The final HTML needs anchors embedded: add portable ones before and after paragraphs /* @export:<名> */ … /* @end */（CSS）、// @export:<名> … // @end(JS); in step 7, slice and extract them into the final document by anchor, don't copy by hand. At minimum embed: component CSS, rendering logic, popover markup.
For clickable controls, the focus box should only be written as :focus-visible，:focus set to outline: none. Otherwise, the moment the mouse clicks, the browser's default blue box pops up and the user will treat it as a styling problem.
Component styles should not rely on global inheritance：box-sizing, font stacks,font-variant-numeric — properties like these written at the top of <style> ; whatever a component depends on should be written directly into the component rules, or listed separately in step 7 as a "basic prerequisites" code block. Extracting only the component section and missing the global section is the number one cause of ported output growing crooked.
Fake data first,then run a version rendered with real data(except for illustrative-type blocks, which use fixed examples). Data sources: prefer calling the project's existing data-fetching service / script to write the results as JSON into the HTML; if you can't find one, ask the user for an export; if you can't get that, use the closest real sample and mark "real data unverified" in the design document under "Follow-up".
- History / list-type pages: real data will definitely cause problems (unit weight, zero-value display, unnormalized names, row count exceeding one screen, overly long entries).
- Snapshot-type pages (a single current state, such as quota / connection): real data only covers the current state; for the other states, use constructed data in the all-states board and mark "constructed" window by window.
- When real data contains the user's private content (conversation body, paths, keys), desensitize it before archiving or capture only the structure.
Run before every version is delivered scripts/check-layout.js(see the script header for what it checks and how to run it). It can catch problems invisible in screenshots, such as missing component sections when applying the style pack, or controls falling back to the browser's default appearance. The final HTML only checks the state directory below (win: '#catalog .win'）。

Step 5: State inventory → all-states board

List all six categories completely, each entry one sentence of state and one sentence of suggestion:Data、Computation、Settings and actions、Layout、Interaction、Integration / source(for pages that depend on external tools). See the template at references/状态清单模板.md; before filling it in, first declare the page type (metric / list / list + detail / form / snapshot / mixed); cross out what doesn't apply, don't delete it.

AI gives suggestions, the user only vetoes. If the user says "you design it directly," decide everything according to the suggestions; for partial vetoes, only restate the ones that were vetoed.
All-states board: anychanges layoutstate (zero / missing / entire section has no data / first load / overall failure / not set / extreme volume / expired / disabled / history / minimum window) must be rendered as a window, using the real shell; states that only change copy just need to be clearly written in the inventory. When producing a separate board during the process, reuse references/对比板骨架.html（premise rewrite as "page type + real/constructed data description";recommend if left blank, no recommendation is rendered); at finalization it becomes the "state directory" below the final HTML, switching to using references/交互流程骨架.html in #catalog, sharing one rendering function with the process above.
One slot, multiple messages: write a replacement priority table(e.g.: secondary line = status message > saved $X > empty), ensuring only one line appears in that position in any state.
Run long copy for constructed states (popup hints, error explanations, action explanations) at real width; read-only cells stay one line, hints no more than two lines.
For status copy on existing pages, prefer the original text from existing code; for copy that needs to be newly written, mark it as "new copy" in the list and wait for user confirmation; do not make up explanations or loading hints on your own.
Write interaction items (C / E types) as "trigger → display → where to go afterward", and connect them directly when drawing the flow in step 5b.
Source items marked "to be checked" in step 1 must have a conclusion by this point or fall into category F.
Archive:specs/<单元>/状态清单-<页名>-草案.md; when finalizing, remove "draft" and move it into the final package.

Step 5b: Interaction flow diagram (string the states together)

A full-state board has only static screens, so users cannot tell where a screen comes from, what was clicked to get here, or where they can go afterward, and they say "I can't see the details, I don't know how to judge". The interaction flow diagram strings state windows together by task, letting users judge segment by segment.Must be produced before the user says "this is it", and have the user review each segment's "judgment" sentence; for pure display pages with only one or two states and no actions, it can be omitted, with the reason stated in the design document. For the code skeleton and parameters, see references/交互流程骨架.html。

Where to put it: put it in the same HTML as the full-state board, with the flow on top and the state catalog (id="catalog") below; nodes and catalog windows usethe same render function, not drawn separately.
How to split segments: one segment = one user task (changing a setting, first-time onboarding, a dangerous action). The first segment is fixed as "entering the page": loading → various starting states (which state the system lands in based on the read result). At the start of each segment, one sentence: "Judgment:", writing what the user should use to judge whether this segment is correct.
How far to draw: actions that write, call external services, or may fail (save, connect, delete, test connection, retry) must be drawn to at least two branches, success and failure; if there is a confirmation step, add cancel as well. Pure local view switches (paging, expanding, switching months) only draw the success branch.
Main line and branches: the main line uses arrows to follow the most common outcome. Other outcomes of the same step start on a new row,placed side by side, with the trigger condition written above each; do not connect them with arrows to each other—connecting them would be read as happening in sequence. Another user action on the same node (such as "cancel") also starts on a new row and is connected with an arrow. At the start of the row, uniformly write "branches from X-Y"; one row carries only one node.
Nodes: real window thumbnails, with the sidebar and toolbar cropped by default; if the position to click is in the toolbar or sidebar, do not crop that node. Scale is max(0.5, 7 ÷ the page's smallest font size), ensuring the smallest text is no less than 7px after thumbnail scaling; clicking a thumbnail opens it at original size. Draw the position to click in the next step with apurple dashed circle(do not use red, to avoid confusion with the red border for errors). Add a frame to the endpoint of a path, with the color following the result: success green, failure red, cancel or return to original state gray; the starting states in the "entering the page" segment are not action results, so do not add a frame. Below the node, write the number, a one-sentence state explanation, and the state catalog number.
Arrows: Write the action or event ("click 'Confirm takeover'", "read complete"), with small text supplementing key rules ("click to save", "no confirmation"). Four colors: user action, system event, success, failure.
Intermediate screens must be drawn: confirmation dialogs and Toasts are drawn on the upper layer of the page; processing, writing, and button disabled are made into a state of the page. Actions like click-to-save and save-on-blur also need a "saving" node. The full state board may not draw them as windows, but they must be drawn in the flow. If something in the checklist has no number, first add it to the state checklist (generally falls under category C) and then mark it on the node. If they are existing components in the project, the final document must state the component name, path, and the parameters used, and mark it "demo layer, not ported".
AI-added behavior: behavior added on your own when drawing the flow that is not in the checklist (Esc to cancel, keep input after failure), mark it with small text on the arrow as "AI added", and backfill the checklist for user confirmation.
If the user looks at the flow diagram and asks "under what circumstances does this happen" or "what happens when clicked", it means the state checklist is missing trigger conditions or results: answer first, then backfill the checklist and node descriptions.

Step 6: Three semantic questions

When to execute:answer once before starting step 4, and review once after steps 5 / 5b (including action names on flow arrows).

Is the name correct. The tier / label / button copy matches its scope ("only 200% counts as excess" is misleading; "earned" when money was not actually received should be written as "saved"; "rerun" has no object, write "rerun this time").
Is the color meaning correct. First write down the direction of the main number:
- Goal type (bigger is better): exceeding is good, no orange / red needed.
- Upper-limit type (bigger is worse): being close to full is bad, green / yellow / red hold.
- Countdown type (due date, days remaining): the closer, the tighter, use orange only at the threshold.
- Discrete state type(success / failure / in progress; connected / disconnected): there is no size direction, set the color by "is this state bad", only bad things use red / orange, the rest use neutral hues.
- Use three hues for three tiers, not shades of the same color.
Are unit and number rules defined. Unit scale, decimal places, zero values, percentage rounding, merging of too-small values, and the boundary between relative time and absolute time should be written as rules rather than adjusted case by case.

Step 7: Consolidate → final package

The design document goes in the project protocol location. From the second page of the same unit, use 2-design-<页名>.md, and §3 only writes the delta relative to the first page and writes back to the style package. Five sections:

What problem this page solves (one-sentence task + not included + source table)
Page content and layout (blocks, order, finalized states, number and semantic rules)
Visual language / style package (enumerable checklist for checking subsequent pages)
Implementation contract (reused components, new components and reasons, state mapping, new tokens, conflicts with current specifications and backflow)
Explicitly not doing / follow-up

Then package it, for how to package see references/定稿包模板.md. For projects without a specs protocol, the final package goes in 设计/<页名>-定稿/, at the same level as 设计/<页名>/_review/ . The prerequisite isthe user explicitly says "this is the one"; when the user only says "it's a bit messy / which one is final," first archive the process artifacts and point out the current version awaiting confirmation, then package it after confirmation.

After packaging, tell the user: this folder is the input for writing the PRD / test cases and development; downstream reads only from it.

Before delivering visual artifacts, self-check with a playwright screenshot.

User signal → Action

First look at the layer marker line to locate the current layer, then follow the action.

User says	Meaning	Action
Doesn't look good / not refined	Mostly ① not decided, a few ③	First ask about usage; if ① is decided, check platform conventions (font size, line width, corner radius, shadow layers)
Can't say / something's missing	Upper layer not decided	Use meta-principle 3's three-step fallback: ask which part → decide which layer to fall back to (may be two layers) → reopen only that one place
Pretty much / okay / it's fine	Neither confirmed nor denied	Don't go to the next layer; follow up with "which one is wrong" or "change one word"
Not used to it	Changed a structure the user is used to	At ③ say: go back to ② and change only that one place, first ask "which part are you not used to" (ask only one place), keep the rest; at ② say: treat it as ① not decided, return to step 0
Structure is messy	② not decided (within this page)	Go back to the content list and ask "what to look at first," rearrange the sketch. When the user is talking about cross-page navigation / sidebar grouping, it's not part of this skill
Too locked in	Keeps reskinning in the same module	At layer ②, produce multiple layouts
Too full	Gray cards edge-to-edge, two sets of controls coexisting	Merge cards, layer them, remove duplicate controls
Too plain	High fidelity only carried over the numbers without the shapes	Check how many graphic items are used (icons / rings / bars / color dots / labels); add shapes, not colors
Doesn't feel like one product / separated	Missing a shell layer spanning both sides	Add a shell according to the general outline or platform conventions
This looks weird here / it's duplicated	Mixed natures or the same information appearing in two places	Separate controls / data / actions into their proper places; for duplicates, delete one place and keep the one that can be operated. Don't produce a comparison board
None are good	The premise is wrong	Take apart the premise in three steps, don't produce more variants
Can't see the details / don't know how to judge / under what circumstances does this happen / what happens when clicked	Only static screens, missing the causality between states	If they can point out which step or which screen is unclear: if the state list is already out, do it or supplement the step 5b flowchart; if not yet out, first list it according to step 5 and then do it; if they can't point it out → fall back a layer according to meta-principle 3. Backfill the asked conditions and results into the state list
A bit messy / which one is final	Deliverables scattered	Archive process artifacts to `_作废-探索过程/`, point out the current version awaiting confirmation; only package the final version after the user confirms

Self-check before delivery

① No high fidelity was produced before confirmation.
Every output wrote a layer marker line; every board was given a recommended number and a one-sentence reason.
Every checklist item has a source annotation; what to do when something is "unavailable" is written down; "to be checked" items reached a conclusion in step 5; for local credentials only field names were read.
Each comparison board changed only one thing, and the precondition is stated.
All elements AI proactively added are marked, and the count is in the layer marker line.
Color direction is correct: target type does not use warning colors, "almost full" for cap type does not use green, countdown type uses orange only at the critical point, and for discrete state type only bad things use red.
Low-frequency actions are not made into persistent buttons; persistent positions have no explanatory text; action buttons have objects.
It has been run with real data (on the snapshot page at least the current state is real, constructed states are annotated); visual artifacts containing private content have been desensitized.
scripts/check-layout.js It has been run only against the state directory and problems is empty (including class name and native control checks); long text for constructed states has been run at real width.
The interaction flow diagram has been produced (except for purely display pages exempted under 5b, with the reason written in the design document), and before the user said "this is the one" they had seen: the first segment is "enter the page"; actions that write / may fail go to success and failure, and those with confirmation have cancel added; branches are side by side, not chained; dialogs, in-progress states, and Toast are all drawn in; the end box color follows the result; each segment has a "judgment" sentence; nodes and the directory use the same rendering function; each node is labeled with the state checklist number; behaviors asked about in the flow and supplemented by AI have been backfilled into the checklist.
Illustrative blocks use fixed sample data, and no boundary state with a real source was introduced for them.
State copy for existing pages takes the existing original text; new copy has been marked out and confirmed by the user.
For one slot with multiple phrasings, there is a replacement priority table.
The design document has all five sections complete, and the style pack can be enumerated; the final pack is complete according to references/定稿包模板.md and the upper-level README has been registered, with no old paths.