---
type: process
project: leaguelaw
title: Internal design process — how we get from client input to an approved direction
audience: Adi (designer) · Rian (senior/owner) · Adi's junior · Rob (PlusROI, client relationship)
status: DRAFT — mixes Rian's binding rulings with Adi's proposals (marked); review together before treating the proposals as agreed
created: 2026-08-24
---

# Internal design process (v1 draft)

**Internal only — never sent to a client.** One page on how we work, so
anyone on the team (designer, senior, junior, client-relationship owner) can
see the whole machine and their part in it. Written on the League Law
project; meant to be reusable.

## The idea in one paragraph

We get the client to confirm a **direction** before anyone builds a mockup —
"sedan, sports car, SUV or truck," never "comment on the rims." The direction
work is deliberately unhurried and internally reviewed; the client's part is
tiny, easy, and early, so they feel involved and never see anything rawer
than we intend or more finished than the phase allows. High fidelity comes
back later, in the mockup phase. Humans distill; automated parts (Claude,
Scout) do the leg work.

## Roles

| Who | Role in this process |
|---|---|
| **Rian** (senior/owner) | Collects the client's stated position into a written direction doc (the anchor). Reviews every client-facing artifact — the internal gate. Sets timeboxes. Rules on process changes. |
| **Adi** (designer) | Comprehends the collected input, crafts the direction options, makes the design-judgment calls. Owns what to show and how many options. |
| **Junior** | Runs the direction-independent prep in the background (see "obvious work" below). |
| **Rob** (client relationship) | Owns the client channel. Client-facing artifacts reach the client through/with him; he calibrates tone and timing with the client. |
| **Claude** | The system half: loads context, drafts artifacts to spec, checks them against the anchor doc, records decisions. Flags drift from the agreed approach. |

## The pipeline

1. **Intake — senior collects.** Client's words, constraints, scope sold,
   do's and don'ts → written into an anchor doc (League:
   `.logs/planning/design-direction.md`). FIRST action of any session:
   read the planning folder + the anchor. Nothing anchors on the current
   site — it's measured (internally) but never the baseline.
2. **Direction craft — designer, unhurried.** *(Adi proposal)* The designer
   comprehends, then crafts ~3 direction options for the **homepage only** —
   roughly 2 full days + a night to sleep on it for a League-sized project,
   scaled to project size. Low-fi on purpose: the client chooses structure,
   not design. Meanwhile the junior runs the **obvious work** in parallel —
   the test: *"needed no matter which option wins?"* → yes = start now
   (brand assets, broken tel: links, analytics/perf baseline, content
   inventory, checklist items, photographer's shot brief); no = it waits.
3. **Internal gate — Rian reviews.** Good → client. Not good → back to the
   designer for internal revision. The client only ever sees work that
   passed both the designer's considered judgment and the senior review.
4. **The client ask — tiny, easy, involving.** ≤3 options · few words ·
   under ~5 minutes · click-through walkthrough format (sample:
   `wp-content/prototype/direction.html`) · delivered via Rob's channel.
   The client picks / reacts; open questions ride along as one or two small
   questions. Internal completeness checklist available as an appendix,
   never required reading.
5. **Confirm & record.** The choice + its assumptions go into a decision
   record ("picked X, assuming Y") so a wrong bet is later traceable to an
   assumption, not a person. Direction is a cheap, recorded, shared bet —
   not a proven truth.
6. **Then, and only then: mockup phase.** High fidelity returns — option
   funnels per component, the craft work. (League's parked mega menu /
   CTA / section work lives here.)
7. **Measure (proposed, after launch).** *(Adi + Claude proposal)* The
   direction's assumptions get tested with real numbers — tap-to-call rate,
   zone click-through, contact submissions, Core Web Vitals before/after.
   Success metric per the anchor: matched-and-contacted, not time-on-site.

## Standing rules (binding — Rian's rulings)

- **A pivot IS the check-in.** When an agreed approach isn't working: two
  lines to Rian (what's failing / what to try) BEFORE hours go into a
  replacement. Async preferred. Design details stay the designer's call.
- **Direction before mockup; fidelity by phase.** Client-facing direction
  work is low-fi and deliberately unfinished-looking; hi-fi belongs to the
  mockup phase. The current-site replica is an internal measurement artifact.
- **Client-facing artifacts anchor on the client's written input** — never
  on the current site, never on our assumptions about taste.
- **Client effort:** no significant burden — small, easy, early, and theirs.
  Fewer options (≈3), short wording, minutes not homework, real involvement.
- **File discipline (League):** served prototypes only in
  `wp-content/prototype/` · working versions in `prototyping/` · temp in the
  session scratchpad. `adi-note.md` + `prototype.md` are binding reading
  before prototype work.

## Proposals awaiting Rian's OK (from Adi — discuss, don't assume)

1. The **cadence** in step 2 (≈2 days + sleep, scaled) and **homepage-only**
   scope for direction craft.
2. The **background/obvious-work lane** for the junior, with the
   "needed-regardless?" test.
3. The **Measure step** (7) + decision records with assumptions (5).
4. The **art/system split**: automate the system half (intake, checklists,
   search, scoring, drafting, records) so designer time and client attention
   go to the judgment half; make the hand-off points explicit.
5. **Website-type completeness checklists** (start: "law firm website") as
   our own standard — examples inform taste; the checklist guarantees
   completeness; neither depends on what other sites happen to do.

## Where things live (League instance)

Anchor: `.logs/planning/design-direction.md` · Research:
`.logs/planning/examples-shortlist.md` (+ `prototyping/examples-shots/`) ·
Conceptualizer spec: `.logs/planning/design-conceptualizer.md` · Client-ask
sample: `wp-content/prototype/direction.html` · Designer's notes:
`adi-note.md` · Process distillation: `prototype.md` · Session state:
`.logs/handoff.md`.