# Design process (draft) A reusable playbook for building web mockups with AI and getting them reviewed in Easel. Project agnostic. Written from one homepage build; the project-specific record is in `mockup-process-draft-by-claude.md`. **This belongs in the standards library, not in a project.** It sits here until someone moves it. --- ## Roles | | Owns | | --- | --- | | **Client lead** | The client relationship. Onboarding, collecting what they say and send, the record of their decisions, standing up Easel, scope | | **Lead designer** | The design system, the rounds, the choices. Triages feedback | | **Designer** | Runs the loop. Builds sheets, works the checkpoints, merges, measures, records. Proposes choices | | **AI** | The mechanical half of every step | **A person chooses, and a person is accountable to the client.** Everything else is fair game for automation, and this line is expected to move. --- ## Phase 0. Set up, day one - [ ] `wp-content/mockups/` with `img/`, `_drafting/`, `_easel_ready/` - [ ] `notes/` with a **decisions register**: one screen, every client instruction, each with a source - [ ] Easel project created, client invited, so review is not a scramble later The register is the thing that makes the rest transferable. Written down and sourced, anyone can design against the client's instructions. In one person's head, only they can. ## Phase 1. Learn the context Ask the AI to read and summarise in one pass: brief and scope, the client's stated decisions and where each came from, brand assets, the copy, the existing site, any partner's plan. **Output:** an orientation, plus the register. Then ask the one question that matters: > What has the client explicitly asked for or ruled out, in their own words? **Read the register before the first sheet, not on day three.** The most expensive rounds are the ones constrained by a rule that was already written down. ## Phase 2. Base mockup A rough full page from the AI: every section in order, real copy, placeholders where images go. **Not a design. A skeleton to react to.** It immediately makes three things visible: the real section list, how much copy each section holds, and where the page is too long. ## Phase 3. Build order Build in the order that unblocks the most work, not top to bottom. | | Element | Why here | | --- | --- | --- | | 1 | **Header** | On every page | | 2 | **Footer** | On every page, low risk, settle it early | | 3 | **Hero** | Nearly every site has one, and it sets the tone | | 4 | **Under hero** | Second thing seen, most client-specific choice on the page | | 5 | The rest, in page order | The system exists now, so this is assembly | **Header:** nav depth (links, dropdowns, mega menu) · CTA in the bar · phone visibility · sticky and shrink · solid or transparent over the hero · what survives into the mobile drawer. **Footer:** columns · newsletter placement · which social platforms (**client decision**) · contact block · legal bar · reversed logo for a dark ground. **Hero:** height · layout · background · one CTA or two at different weights · supporting line · where trust sits. **The CTA count matters most:** one suits a single audience, two suit a site where most visitors are not ready yet. **Under hero:** no default. Pick one or two, driven by the buyer's first question. | Block | Use when | | --- | --- | | Trust and proof | The first question is "are you real" | | The problem | They do not yet know they have one | | Services or products | They know what they want and need to find it | | Who it is for | The offer is easy to mistake, or you need to disqualify | | About or the team | Trust is personal here. **Ask: some clients want faces, some do not** | | How it works | The offer is unfamiliar and process is the reassurance | | Testimonial | One quote beats a paragraph of claims | | Tool or assessment | There is a low-commitment first step worth pushing | **Settle once, at the start:** page width and section rhythm · grounds · type scale · heading treatment · imagery type · people in images (**client decision**) · image treatment · icon family · primary and secondary CTA · CTA repetition · proof placement · forms · motion. --- ## The round Every element is settled the same way. ```text 1. NAME one element. Never "design the page" 2. CHECK the orientation questions 3. BUILD an options sheet: N variations, standalone page, deployed to a URL 4. LOOK in a browser at the real width, with the real treatment 5. CHOOSE one by name. Rejecting all of them is normal and cheap 6. MERGE into the canonical page, regenerate the other versions 7. RECORD the decision and why, the same day ``` **Never try something on the real page.** The sheet is the test harness, the page is the deliverable. Isolation is what makes blunt rejection free, and blunt rejection is the biggest speed advantage in the method. **A good sheet:** three to six variations differing on **one named axis**, written at the top. One deliberately conservative. One deliberately too far. Each with a note saying what it is good and bad at, because the weakness is the useful half. Five things differing on five axes is a mood board. **Instructions that work.** Name the element, never the outcome. Ask for a number. Reject without softening it. Supply your own material rather than waiting to be offered it. Correct the process, not only the output. --- ## Checkpoints Not judgement, which takes years. **The questions that surface what judgement would have caught.** **Before a round.** One element? What did the client say about it in their own words, and where is that written? Is there already a rule? What is this section's job: persuade, reassure, qualify, convert? **Before the sheet.** What is the one axis? Which option is conservative? What treatment will the result get: greyscale, grain, dark ground, crop? What size and shape will it really occupy? **Before choosing.** Seen at real width? Seen with the treatment applied? Still reads at its real size? What is the named weakness of the one you are picking? If you cannot name one, you have not looked. **Before merging.** Contradicts anything the client stated? Every version regenerated? Has the thing that changed been **measured**, at two or three widths? Decision recorded today? **Before the client sees it.** Placeholders filled or named? Any number derived from a date, which will go stale? Anything departing from a client instruction, named out loud? Compliance check run? --- ## A and B **A is the preferred design.** What you would recommend, given the brief plus your judgement. **B follows the instruction.** The client's direction, built as well as you can build it. **Both get your best work.** B is not a control and never an argument that the client is wrong. It is their idea taken seriously. You are not trying to win; you are giving two genuine proposals so they can choose with something real in front of them. **Why B is worth building.** The brief comes from people who know the business, with insider knowledge of the market, customers and objections that a designer will never have. **B is that knowledge rendered as they expressed it, unfiltered by your interpretation.** What they lack is a real page in front of them, so an instruction can read perfectly in a document and behave differently once built. **Neither direction is senior.** B holds their expertise, A is your interpretation of the same thinking with page craft applied. **The risk in A is yours to watch: an interpretation can quietly drop something they knew mattered and you did not.** **Ask who wrote the brief.** It may be a partner agency who has known the client far longer than you have. The principle is proximity to the source of truth, not "the client is always right". Whether AI helped write it changes nothing; responsibility sits with whoever put their name to it. When a partner wrote it, findings go to the partner first. **Silence is not an instruction.** A brief states only what its author thought to state. Nobody buying a car specifies that it has wheels. Following a brief means doing what it says **plus everything a competent designer would obviously do**: responsive, contrast, focus states, alt text, heading order, working links and states, sized images, one type scale, forms that validate and confirm. > **The test:** is this a decision the brief *made*, or a topic it never *addressed*? A decision gets > followed. A silence gets best practice. When genuinely ambiguous, ask in one line. **If B has limits, they come from the instruction, never from your effort.** A carelessly built B is a straw man and clients can tell. Where the instruction strains, say so plainly and offer the fix. Do not silently turn B into A; that takes the choice away from them. --- ## Files ```text /srv/apps/{projectname}/wp-content/mockups/ ├── index.html navigation, working pages only ├── img/ every image, served locally ├── {page}_{direction}_v{n}.html the deliverable pages ├── _easel_ready/ │ └── {page}_{direction}/ │ ├── index.html merged, both looks │ ├── img/ │ └── assets/ └── _drafting/ ├── index.html contact sheet: element, date, tested, won ├── {page}_{element}.html option sheets └── {page}_{direction}_v{n}.html retired versions kept as evidence ``` **Naming:** `{pagename}_{type}_{version}.html`, e.g. `home_A_v1.html`, `about_A_v1.html`. - **Same letter, different number: nearly identical.** One small nameable change. If you cannot name it in one short phrase, it is not a version. - **Different letter: a different direction.** Substantially unalike. **`index.html` is reserved:** the navigational page linking to working pages only. Test sheets, variation sheets and proofs are excluded deliberately, so no page file is ever named `index.html`. **`img/` is not optional.** Never hot-link a foreign URL: it can vanish or change, and Easel needs assets local when the mockup is packaged. **`_drafting/` is organisation, not security.** A dot-directory would be served over HTTP exactly like any other, so the underscore is honest about what it does. What keeps drafts from the client is that `index.html` does not link them and the client is only ever sent specific URLs or an Easel board. **Source and served are different.** The truth is the project's source folder, edited by hand. The served copy is build output and is **never edited directly**: editing it works, looks fine, and is silently lost on the next build. --- ## Easel bundle Easel presents a mockup as a **folder** and switches variations by toggling a class on ``. | You have | Do | | --- | --- | | One version | No merge. Package only | | Two, small difference | Merge into one `index.html` with a variation class | | Two, large difference | **Stop, these are directions.** Two separate Easel options | | Three or more | One class each, plus an Easel variation **group** so only one is active | **Steps.** Diff the files · take the variant's markup wholesale · scope only its CSS to `html.v-{name}` (or scope an existing hide rule to `html:not(.v-{name})`) · add a `display:none` guard so nothing renders unstyled · copy only referenced assets · name the entry `index.html` · verify by rendering. **The rule that causes the most trouble: the base is the absence of the class.** There is no `v-base`. With no class, the file must render exactly as v1. **One bundle, not two folders:** two folders means uploading the same photographs twice, re-downloading on every switch, and losing the client's scroll position. One bundle means a class is added and the browser repaints. ### Pre-upload checklist - [ ] Entry named `index.html` - [ ] **Base renders identical to the original v1**, same height, same pixels - [ ] Class renders identical to the original v2 - [ ] Every `src=` and `url(` resolves inside the bundle. No absolute paths, no external URLs except the font stylesheet - [ ] Only referenced assets copied - [ ] Class named `v-{something-readable}` - [ ] Opens correctly from `file://` ### The prompt > Build an Easel bundle at `wp-content/mockups/_easel_ready/{PAGE}_{DIRECTION}/`, merging > `{PAGE}_{DIRECTION}_v1.html` as the base with `{PAGE}_{DIRECTION}_v2.html` as a variation named > `v-{NAME}`. > > 1. **The base is the absence of the class.** No `v-base`. With no class on `` the merged file > must render byte-identical to v1. > 2. Keep all of the variant's markup. Scope only its CSS to `html.v-{NAME}`, or scope an existing hide > rule to `html:not(.v-{NAME})`, whichever is fewer edits. > 3. Add a default `display:none` guard for any variant element that would render unstyled. > 4. Name the entry file `index.html`. > 5. Copy only the assets the merged file references, preserving relative paths. > 6. **Verify by rendering, not by reading the CSS.** Screenshot the original v1 and the merged file > with no class at 1440 wide; confirm page heights and pixels match. Then confirm the class turns the > variant on. > 7. Report file count, bundle size, and both page heights. --- ## Presenting and feedback **Walkthrough captions** guide the client through the mockup, one beat per idea, and the last one asks for acknowledgement. Format: `(title, body, target_selector, requires_approval)`. Write them in second person, plain, saying **why** rather than what, and **name the client's own instruction back to them wherever the design follows it**. "You asked us to remove X, so there is none anywhere on this page" gets a very different response from a description of a layout. Use two or three beats to **ask a question** rather than present a decision; a walkthrough is a better way to get an answer than an email. Verify every selector is single-use before shipping. **Feedback comes back pinned to the element**, which is the reason to use Easel rather than email. Everything sorts into four buckets: | Bucket | What happens | | --- | --- | | A change we make | Becomes the next round | | A question for the client | Answer in the thread, or hold for the call | | A question for us | Usually a rule nobody wrote down. Add it to the register | | Out of scope | Say so in the thread, kindly, with what it would take | **Reply in the thread, not by email.** Six weeks later nobody can reconstruct which paragraph an email was about. --- ## What goes wrong 1. **Invalid CSS fails silently.** A declared behaviour is not a working behaviour. Sticky headers that never stick, animations that never run, grids at half the intended width: all render as a normal-looking page. **Measure the specific thing that changed, at two or three widths, after every merge.** 2. **Bare `fr` in a grid.** A grid item's automatic minimum size is its min-content width, and for an `` that is the file's intrinsic width. Use `minmax(0, 1fr)` plus `min-width:0` wherever an item is a replaced element or can hold long unbreakable content. 3. **Substring matches in find-and-replace.** A short class name that is a suffix of a longer one in the same block will silently eat half a section. Match on a full token. 4. **Hand-synced versions drift.** One canonical page, generate the rest. 5. **Derived numbers go stale.** Anything computed from today's date is wrong within a year and contradicts its other copies. Store the source fact and compute at render time. 6. **AI is confidently wrong at the same speed it is confidently right.** Checking a source is not the same as checking that the source answers your question. 7. **"Make more variations of X" means X is not working.** It is not approval of X.