best-practices-bespoke-design

# Best Practices: Bespoke Digital Design ## Position A bespoke interface is not a fashionable component library with unusual colors. For day-to-day project work, this skill is a practical design advisor first: it should identify the smallest visible change that makes a site more specific, useful, and coherent for its real audience. For new design directions, the deeper model is a traceable transformation: **brand and audience truth → personality → narrative premise → visual grammar → responsive component system → rendered proof.** This skill was informed by Meagan Fisher Couldwell's Owltastic portfolio. The lesson to retain is her method of making each project feel authored for its subject. Do not reproduce her owls, celestial engravings, exact typography, page compositions, palettes, illustrations, or other signature surfaces. ## Immutable Outcome The finished work must be: 1. **Specific** — it could not be swapped onto a close competitor without visible conceptual tension. 2. **Useful** — the expressive system strengthens the user job and content hierarchy rather than competing with them. 3. **Coherent** — typography, palette, imagery, motifs, composition, motion, and voice express the same premise. 4. **Systemic** — the premise survives across page types, components, states, and breakpoints; it is not confined to a hero illustration. 5. **Inclusive and performant** — personality does not excuse inaccessible type, contrast, focus, motion, controls, or poor field performance. 6. **Grounded** — conclusions are tied to source context, rendered screens, or user-provided artifacts at the tier being used. Formal proof packets are required only for formal certification claims. When evidence needed for the selected tier is missing, report `NOT_TESTED`, `NOT_ESTABLISHED`, or `BLOCKED`. Missing formal receipts, blind raters, crop manifests, or G0-G20 gates are not design failures in advisory or ordinary release-risk work; they are simply outside the selected tier unless the human asked for formal certification. ## Modes Use one of three explicit modes: - **ANALYZE** — reverse-engineer the durable method behind a body of work while separating method from copyable surface style. - **DIRECT** — create a new, brand-specific visual world and implementation brief. - **AUDIT** — test an existing design for specificity, coherence, usability, accessibility, system depth, and template residue. ## Default Operating Posture Default to **targeted advisory repair**, not formal certification. This skill is commonly used to improve a live project page such as `grahama.co`, `grahama.co/resume`, a README, or a project microsite. In that context, the correct output is usually a short, source-grounded diagnosis and one implementable next slice: copy tone, visual hierarchy, interaction friction, card treatment, metadata, responsive behavior, or a section-level composition repair. Do not run or demand proof packets, blind raters, G0-G20 gates, formal crop manifests, reviewer swarms, or durable receipt validation unless one of these is true: - the human explicitly asks for `READY`, formal certification, a final gate, or adversarial distinctiveness proof; - a deployment/release policy requires that formal gate; - the disputed claim is itself a proof claim, such as accessibility, performance, originality, deployed behavior, or "verified". For ordinary advisory work, use available screenshots, live renders, source files, user-provided critique, and local browser checks when relevant. If those are enough to answer the design question, stop at the recommendation or targeted patch. Do not convert advisory design work into a reporting campaign. ## Current Evidence Gate Before making a recommendation about an existing live design, classify the evidence as `current_evidence`, `historical_context`, or `not_established`. Use `current_evidence` only when the recommendation is grounded in one of these: - a live browser/render check from the target URL or local dev server in the current turn; - a source-file read from the repository that serves the target surface, plus a build/render check when the claim is visual; - a user-provided screenshot that the human explicitly identifies as the current target state; - a current project monitor receipt, such as `monitor-website audit`, `design-render-check`, `test-interactions`, or `verify-ui-cdp`, when it directly covers the surface being discussed. Use `historical_context` for prior commits, old screenshots, old UI markers, previous reviewer notes, memory recall, or past recommendations. Historical context may explain why a decision was made, but it must not be presented as a current defect or current recommendation. If a prior recommendation appears in memory, chat, or old receipts, first check whether it has already been implemented before listing it as a next action. For example, do not recommend removing a Calendly auto-launch unless a current render or source read shows that the auto-launch still exists. Every targeted advisory output about a live surface must include enough freshness metadata for the human to see what was reviewed: ```markdown ## Evidence Used - evidence_status: current_evidence | historical_context | not_established - surface: <URL, route, screenshot, file, or component> - checked_at: <absolute timestamp or "user-provided current screenshot"> - artifact: <command, marker, screenshot, source path, or receipt> ``` If current evidence is missing or conflicts with historical evidence, say the recommendation is `not_established` and name the next command that would make it current. Do not produce a ranked design-change list from stale evidence. ## Evidence Tiers Do not run the formal certification path when the human only needs a design decision, release-risk read, or next repair slice. Choose the lightest tier that answers the current decision and state the tier in every report. | Tier | Use when | Evidence required | Allowed conclusion | | --- | --- | --- | --- | | `directional` | Choosing or improving a concept, copy, section, or component | source context, user-provided artifact or screenshot when available, concrete critique | `promising`, `needs repair`, or `not established` | | `release-risk` | Deciding whether to keep, patch, commit, or deploy a public candidate | current render or screenshot, focused local checks for changed behavior, known gaps | `credible with gaps`, `hold release`, or `ready for bounded deployment` | | `formal-certification` | The human asks for `READY`, a final gate, or adversarial proof | every required G0-G20 gate with current receipts | `READY` only when every gate is `PASS` | Default to `directional` for critique, copy, visual hierarchy, and micro-polish. Use `release-risk` before committing, pushing, deploying, or claiming a live public surface is ready. Escalate to `formal-certification` only when the human explicitly asks for formal READY, when a deployment policy requires it, or when the disputed claim is itself a formal gate. A `release-risk` pass is not a `formal-certification` pass. ## Call Budget External reviewers are optional advisory inputs unless the tier is `formal-certification`. No reviewer call may run until local inspection has identified the actual surface and question, unless the human is explicitly asking for early ideation. Exceeding the budget is a process failure, not an evidence upgrade. Reviewer calls must not diagnose local CSS/source defects, missing sections, stale receipts, missing crops, or harness failures; those stay in deterministic repair lanes. Web review before local artifacts are current is instability. | Tier | Local checks | Reviewer providers | Submissions | Controlled tabs | | --- | --- | --- | --- | --- | | `directional` | inspect available artifact | 0-1 | one compact packet only if useful | shared reviewer window or none | | `release-risk` | required for changed surface | 0-2 | one compact packet per provider only if local evidence is inconclusive | shared reviewer window or one per provider | | `formal-certification` | required | pre-registered G11 set | one per rater seat | one per provider + site | ## Required Inputs For targeted advisory changes, collect only what is needed for the current slice: - target surface, route, screenshot, file, or section; - primary audience and job for that surface; - the visible problem or critique to answer; - source or live render when the recommendation depends on current behavior; - implementation boundary: advise only, patch local code, or verify live. Do not block a small repair because a full brand brief, competitor set, or formal proof packet is absent. Before full art direction, collect or mark missing: - authoritative brand/product claims and source locations; - primary audiences, jobs, anxieties, desired feelings, and decisions; - real content inventory, including awkward and dense content; - current identity assets and constraints; - three to five close competitors or plausible substitutes; - implementation environment and editable primitives; - required page types, states, and breakpoints; - accessibility, browser, and performance targets; - human approver and approval boundary. Do not invent brand values, audience needs, product capabilities, awards, metrics, or cultural references to make a visual concept easier. ## Core Model ### 1. Truth Create an evidence ledger before a mood board. Each row contains: - `claim_id`; - exact claim or observation; - source and source type; - confidence; - audience relevance; - possible visual implication; - prohibited inference. A visual decision may be inspired by a claim, but it must not become evidence for that claim. ### 2. Personality Describe the brand as behavior, not a pile of adjectives. Use paired tensions, for example: - learned ↔ plainspoken; - precise ↔ improvisational; - archival ↔ future-facing; - quiet ↔ theatrical; - institutional ↔ intimate; - rigorous ↔ mischievous; - protective ↔ provocative. For each selected position, name the source evidence and the audience consequence. Avoid generic combinations such as “modern, clean, friendly, innovative.” ### 3. Narrative Premise Write one sentence that joins subject, action, and emotional promise: > This experience behaves like **[specific world or instrument]** so that > **[audience]** can **[job or decision]** while feeling **[earned emotion]**. The premise must be semantically related to the brand and useful to page composition. A mood such as “retro-futurist” is not yet a premise. ### 4. Visual Grammar Define rules, not a collage of preferences: - **typographic roles** — display, reading, utility, data, annotation; - **palette roles** — anchor, field, signal, atmosphere, semantic state; - **motif family** — one primary device and a small supporting vocabulary; - **image system** — subject, crop, treatment, sequencing, and provenance; - **spatial grammar** — grid, reading lane, focal scale, rhythm, and permitted ruptures; - **material language** — line, border, texture, depth, radius, and shadow; - **motion grammar** — what moves, why, amplitude, duration, and reduced-motion equivalent; - **voice** — headline behavior, labels, calls to action, wit boundary, and prohibited tones; - **component invariants** — at least three identity-bearing rules that remain recognizable without the logo or palette; - **responsive choreography** — what reorders, collapses, crops, simplifies, or changes modality at each breakpoint. Every recurring expressive device must map to a claim, audience need, or narrative function. “It looks interesting” is insufficient provenance. For font choice, pairing, hierarchy, delivery, and type-specific proof, compose with `best-practices-font`. Bespoke design owns the world model and distinctness gates; `best-practices-font` owns the font-world contract and receipt. ### 5. System Translate the grammar into reusable primitives without sanding off its identity. The component inventory must include: - navigation and wayfinding; - hero and editorial lead; - dense prose and long-form reading; - card/list/index patterns; - proof, quote, metric, and source treatment; - forms and transactional states; - empty, loading, error, disabled, and success states; - footer/contact/end-state; - at least one high-density and one low-density page; - small, medium, and large viewport behavior. A bespoke design that works only on the homepage is a campaign image, not a system. ### 6. Proof Use screenshots and runnable behavior. A design is not accepted because a model, designer, or stakeholder says it feels special. ## Protocol ### Reliability Guard — Candidate Binding and Two Verdicts Do not collapse practical site judgment and formal proof status into one word. Use two verdicts only when both are relevant. Advisory work usually needs only the practical design verdict and next slice. - `release_design_verdict` — whether the rendered site is coherent, useful, and appropriate for the stated audience based on the current review bundle. - `formal_bespoke_ready` — whether every required G0-G20 gate has current, hash-bound evidence and therefore may legally report `READY`. A site may be acceptable for public use while `formal_bespoke_ready` is `NOT_READY`. That is not a design contradiction; it means the formal packet is incomplete. Conversely, a historical `READY` receipt is not current proof. Every receipt, crop corpus, contact sheet, rater output, accessibility result, performance result, and finish-review packet must be bound to the active candidate by source revision or candidate fingerprint. If the active candidate changes, older receipts become historical evidence only. They may inform the next slice, but they must not count toward current `formal_bespoke_ready`. Candidate freshness is fail-closed: - matching candidate + passing evidence → gate may `PASS`; - matching candidate + absent evidence → gate is `NOT_TESTED`; - matching candidate + disproving evidence → gate is `FAIL`; - stale or mismatched candidate evidence → gate is `FAIL` for the current run unless explicitly archived outside the active proof packet. This guard exists to prevent brittle false-green behavior: a checker must not say the current implementation passes because an older commit produced valid screenshots or reviewer outputs. ### Live Collaboration Ledger For multi-step live site work, audits, amend loops, and disputed reviews, keep a compact phase ledger visible to the human. If the human cannot tell where the agent is, what is known, what is unknown, and what command comes next, the process is anti-collaborative. For simple advisory answers, do not emit a heavy ledger. For multi-step work, status updates and handoffs should name: `tier=<tier> lane=<lane> gate=<gate>:<status> artifact=<path> next=<command>` Expand with facts, unknowns, blocker, and stop condition on handoff, blocker, tier change, or human status request. Do not make every normal update a nine-field report if the compact stamp answers where the work is. Only one lane may be primary at a time. If implementation, screenshot capture, reviewer submission, and skill-contract repair all appear relevant, declare the primary lane and freeze the others until that lane has an artifact or an explicit blocker. Do not let a final proof packet, a design critique, a site patch, and a tool-debug session run as one blended task. ### Lean Default Loop The normal loop is small and visible: 1. Name the current tier, lane, and stop condition. 2. Inspect the current source, screenshot, browser render, or section crop for the surface under discussion. 3. Ask one direct design question: what should change next, and why? 4. Apply the smallest repair that improves the brand-derived world without broad redesign. 5. Re-render the same crop set and report what changed, what remains untested, and whether escalation is needed. Do not create dashboards, broad orchestration, multi-tab browser campaigns, web review loops, or full G0-G20 proof packets before this loop has answered the immediate decision. If the loop fails twice on the same blocker, preserve the two receipts and ask for a reviewer or human decision instead of expanding the machinery. Bind one deterministic local render command and one certification command per project. Missing blind-rater output means certification is `NOT_TESTED`, not a broken crop. Project lane examples live in `references/workflow-phases.md`. ### Phase Summary Use the full phase detail only when it helps the current tier: `references/workflow-phases.md`. | Phase | Output | Stop condition | | --- | --- | --- | | 0 Goal/provenance | user job, primary object, source of truth | content or authority missing | | 1 Brand material | evidence ledger | visual idea lacks source evidence | | 2 Territories | three genuinely different directions | territories differ only by style | | 3 Selection | chosen direction and rejected alternatives | no human selection for implementation | | 4 Grammar | `visual-world-brief.yaml` | rules are vague or decorative | | 5 Page story | beat sheet per page | page falls back to template sequence | | 6 Browser build | rendered prototype | browser disproves the composition | | 7 System | component rules and states | identity exists only on homepage | ### Phase 8 — Render the Stress Corpus Use this phase for formal certification, significant redesigns, or release-risk work where responsive behavior is the risk. Do not require the stress corpus for ordinary copy, hierarchy, micro-interaction, metadata, or card-polish advice. Render at minimum: - 390 × 844; - 768 × 1024; - 1440 × 900; - one extra-wide viewport; - 200% text zoom; - long headline and long-label fixtures; - no-image or failed-image state; - keyboard focus traversal; - reduced-motion mode; - low- and high-density pages. Use real or claim-valid content, not lorem ipsum, for acceptance. The stress corpus must be reviewable without panning through a tall page strip. Do not use one full-page or whole-site screenshot as the evaluation unit. Full-page captures are navigation/debug artifacts only. Acceptance evidence must be split into section, component, or page-state screenshots, each cropped to the evaluated surface and recorded in a manifest with route, selector or section id, viewport, scroll state, fixture/state, dimensions, screenshot path, capture tool, and what the crop is meant to prove. If a section exceeds a practical review height, split it into ordered sub-crops. Raters receive those crops, or compact contact sheets assembled from those crops, never a single unreadable full-site image as primary evidence. ### Phase 9 — Run Adversarial Distinctiveness Tests G11 is a composite gate, not a single vague reviewer verdict. Status reports and receipts must expose these child states separately: - `corpus_current` — the section/component/page-state crop manifest exists, hashes match, counts are nonzero, failures are zero, and rater inputs use reviewable crops/contact sheets instead of one whole-site image; - `raters_recorded` — the pre-registered number of fresh usable rater records exists and every counted rater has preserved raw/parsed output; - `thresholds_met` — logo-off, competitor-swap, cross-screen-family, generic-template, and leakage thresholds pass. If the crop corpus is current but fresh raters are absent, G11 is `NOT_TESTED` with next lane `rater_submission`. If the fresh rater set is complete and a threshold fails, G11 is `FAIL`, not `NOT_TESTED`. Transport acknowledgements, old browser tabs, previous-corpus rater results, and advisory reviewer responses must never be counted as G11 rater evidence. #### Default Reviewer Workflow Default review is URL-first, crop-backed, and transport-neutral. Use `references/review-url-transport.md`, `schemas/bespoke-review-bundle.schema.json`, and `schemas/bespoke-review-transport.schema.json`. Reviewer seats should be submitted through `$ask`/Tau handler runs, not through hand-managed browser tabs. Browser-backed handlers, API/model handlers, and live agent handlers are peer transports when they receive the same candidate-bound review bundle and return Ask/Tau receipts. Prefer non-web model or agent seats when they can inspect the actual section crops/contact sheets through supported image or attachment input; text-only seats may review copy, hierarchy, prompts, and receipt logic, but they do not count as visual G11 raters unless the visual evidence they judged is preserved in their run artifact. Web handlers remain useful independent seats, but they are not special and should not force a multi-tab manual campaign. The order is: local deterministic checks; current section/page-state crops; hash-bound review bundle; verified immutable review URL; direct canonical artifact/attachment fallback only when URL inspection is unsupported. A URL preflight never counts as a rater. A counted rater must echo the expected candidate fingerprint and unit IDs, preserve raw output, and answer the registered G11 questions directly. For `directional` and `release-risk`, zero external reviewers is the default when local evidence answers the decision. For `formal-certification`, use one compact review index URL per rater seat and apply registered sequential stopping. Provider rate limits, stale tabs, upload failures, and login pages are `reviewer_transport`, not design findings. Run the registered G11 questions: logo-off recognition, competitor swap, motif semantics, cross-screen family, reference leakage, and template residue. The full formal threshold table lives in `references/formal-certification.md`. ### Phase 10 — Accessibility and Performance Gates Run these only for `release-risk` or `formal-certification` tiers unless the human asks specifically about accessibility or performance. The detailed checklist lives in `references/workflow-phases.md`. ### Phase 11 — Emit the Proof Packet Emit a proof packet only for `formal-certification` or when the human requests a durable receipt. Receipt evidence must be current to the implementation it claims; stale receipts make the affected gate `NOT_TESTED` or `FAIL`. Required artifact detail lives in `references/workflow-phases.md`. Run: ```bash python scripts/validate_receipt.py path/to/bespoke-design-receipt.json ``` ## Owltastic-Derived Principles, Not Owltastic Motifs The source lesson is method, not motif: make the subject's own premise govern words, type, imagery, composition, components, and responsive behavior. Detailed evidence and transferable principles live in `references/owltastic-design-dna.md`. ## Misuse Guard Reject these shortcuts: - copying Owltastic's owl, night-sky, astronomy, vintage-engraving, warm-cream, dark-brown, chunky-serif, or framed-portfolio combination without independent brand evidence; - asking for “the Owltastic style” as a substitute for a brief; - treating a palette or font pairing as a complete visual world; - producing three nearly identical territories; - adding random squiggles, stars, gradients, grain, arches, stickers, or collages merely to signal “bespoke”; - **imitation material** — CSS bevel/emboss, faux letterpress, faux foil, faux stamped-metal, or a gradient standing in for a produced texture/asset; - using image generation to fabricate evidence or cultural specificity; - hiding weak information architecture under decorative density; - reviewing an old screenshot, stale CDP marker, previous commit, or memory recall as if it were the current live design; - listing a historical recommendation as a current action without first checking whether it has already been implemented; - approving desktop beauty while mobile becomes a stacked residue; - sending a whole website screenshot to a web LLM as the primary design-review artifact; use section/page-state crops with a manifest instead; - claiming accessibility, performance, usability, originality, or shipped impact from screenshots alone; - replacing all standard controls with novel interactions that reduce clarity. ## Acceptance Gate