---
type: plan
title: "Step 1 execution checklist — two home-page directions"
status: active
updated: 2026-09-03 (Brand Kit received; Phase 0.1 reopened)
step: "Design mockup round, Step 1 of 2"
owner: "Adi (builds) · Rian (reviews, chooses the direction)"
retires: "when Rian records the chosen direction and date in .logs/handoff.md"
---

# Step 1 execution checklist

> **STOP — read `.logs/handoff.md` first.** Rian's direction of 2026-09-03: **stay on task, do
> not go outside the mockup.** Three tasks, in order: (1) incorporate the Brand Kit into
> Direction A — the palette swap off `#004963` to NIGHT `#003B53`, Montserrat, the real logo;
> (2) finish Direction A; (3) build Direction B, which does not exist. Then hand back. Anything
> else is not permitted, including anything already begun. An idea that is worth doing gets
> written down and raised — it does not get built first. Asking twice is not approval.


The **contract** for this step is `.logs/planning/homepage-mockup-brief.md`; it governs wherever
this file and it differ, and its section 8 fence and section 10 pre-flight are not restated here.
This file is only the **working order of operations** — what gets done, in what sequence, and what
is decided once and shared by both directions. It is deleted or archived when Step 1 closes.

No commercial figure of any kind appears here or in any mockup.

## Sequencing principle

Everything shared by both directions is settled in Phase 0, **before either direction is drawn**.
The client compares design, not content (brief §2), so copy, section order, nav and footer labels,
placeholder wording and the licence position must be identical in A and B. Anything decided twice
is a defect.

## Phase 0 — shared groundwork (no direction drawn yet)

- [x] **0.1 Palette and type — SUPERSEDED and redone 2026-09-03.** The provisional live-site
      extraction was replaced the same day when the **Brand Kit arrived**
      (`notes/source/brand-kit/`, digest in its `README.md`). Confirmed values are now in
      `notes/mockups/shared-v1/design-system.md`. **Two consequences for work already drawn:**
      the primary dark `#004963` used throughout the Direction A artboard is *not* a brand
      colour and must be swapped to **NIGHT `#003B53`**; and the logo placeholder is cleared —
      use `Equinox__Logo_SLCTag_B_RGB.png` on white, the reverse lockup on dark. Gold `#FFD457`
      was already correct. Heading weight coming down from 900 is now a brand rule, not taste:
      the brand maximum is ExtraBold 800 and H1 is Bold 700.
- [x] **0.2 The shared copy deck.** DONE 2026-09-03 → `notes/mockups/shared-v1/copy-deck.md`; generated mechanically, 1386/1400 source words verified carried. Assemble all 13 sections verbatim from
      `notes/source/aisv-brand-story.md`, plus the six nav labels, the footer tree
      (`.logs/planning/site-architecture.md`) and the UI labels (Menu, Close). Exactly two
      sanctioned substitutions: the revenue criterion set as "Your company generates more than
      approximately [revenue threshold: AISV to confirm] in annual revenue", and the
      "(name to be confirmed)" note once. Objection section heading = "[Section heading: AISV to
      confirm]". One "DRAFT copy: to be finalized by Equinox with AISV" note per export, no
      per-section stamps. **Both directions render from this one deck.**
- [x] **0.3 Asset and licence decisions, recorded now.** DONE 2026-09-03 → `design-system.md`, Assets and licences. At most two web-font families,
      self-hostable, licence noted (brief §9). Direction B's icon set: one open-licence SVG set
      (Kadence Blocks' bundled set or a permissively licensed one), named with its licence,
      monochrome or duotone within the palette, at most 11 icons. Any imagery: non-people only,
      source and licence recorded. Nothing that would have to be bought after approval.
- [x] **0.4 Pre-declare the structural difference.** DONE 2026-09-03 → `notes/mockups/shared-v1/directions-and-placeholders.md`; A and B differ on all five axes. Name which of the five axes A and B differ on
      — hero composition; sectioning device; construction of the four patterns; role of imagery;
      header composition — minimum three (brief §7). Written down before drawing, so pre-flight
      item 3 is checkable rather than argued after the fact.
- [x] **0.5 Start the placeholder register.** DONE 2026-09-03 → `directions-and-placeholders.md`, 9 rows. One running list, appended to as work proceeds:
      logo, revenue threshold, objection heading, canonical firm name, street address, palette,
      type, every imagery slot. Feeds pre-flight item 17 and the handoff entry.

## Phase 1 — Direction A (editorial and typographic)

Calm, whitespace-led, long-form authority. Type carries hierarchy; minimal imagery; sections
separated by rhythm and scale, not bands. The four patterns as typographic structures.

- [ ] **1.1 Desktop, full length.** Header (logo, six nav labels, both CTAs, nothing else) →
      sections 1–12 in order → footer line → footer (brand column, Explore, five Community
      Involvement text links, contact block, LinkedIn + YouTube, bottom bar). Exactly one CTA
      band between the assessment section and the footer columns.
- [ ] **1.2 Mobile.** Header closed; header drawer open once (both CTAs + nav labels); sections
      1–6 in full; sections 8 and 10. No full-length mobile page, no tablet, no footer.
- [ ] **1.3 Direction statement.** One sentence naming the idea, plus two sentences (words only)
      on how the system carries a long migrated post and the General Counsel tier cards.
- [ ] **1.4 Callouts.** Label how the four patterns and the paired CTAs are expressed here.

## Phase 2 — Direction B (modular and structured)

Bands and cards, library iconography doing the sectioning, more signposting for a scanner. The
four patterns as bounded modules. Must not become busy: one idea per module, generous gutters,
value groups at most 2 x 2 or stacked.

- [ ] **2.1 Desktop, full length** — same section list and same copy as 1.1.
- [ ] **2.2 Mobile** — same coverage as 1.2.
- [ ] **2.3 Direction statement** (+ the two extension sentences).
- [ ] **2.4 Callouts.**

## Phase 3 — check, file, hand back

- [ ] **3.1 Pre-flight.** Run all 29 items of brief §10 against both directions. A single no stops
      the set. Fix, then re-run.
- [ ] **3.2 Export and file.** PNG or PDF at desktop and mobile widths into
      `notes/mockups/home-A-v1/` and `notes/mockups/home-B-v1/`. A design-tool link may accompany
      the exports; it never replaces them.
- [ ] **3.3 Index** the two folders in `notes/README.md`.
- [ ] **3.4 Handoff entry** in `.logs/handoff.md`: what was delivered, both direction statements,
      the placeholder register, open questions for Rian, the date.
- [ ] **3.5 Rian reviews first.** Nobody else sees it before he does. He chooses a direction, or
      takes both to the client as a direction check only (not the feedback round). The choice and
      its date go in `.logs/handoff.md`; that entry is the evidence for checklist item 16 in
      `.logs/planning/design-direction.md` and the gate on Step 2.

## Standing rules for this step

- **One channel to the client.** Every question for the client or AISV goes to Rian. The designer
  contacts nobody and shows nothing before Rian's review.
- **A pivot is a two-line check-in with Rian before hours go in, and you wait for the answer** —
  a replacement axis, a photography-led hero, a different nav model, dropping or merging a
  section, a third direction. Raising a request and proceeding without a reply is not a
  check-in; it is the crossing the check-in exists to prevent (Rian, 2026-09-03).
- **An inner page is not a pivot, it is a fence crossing** with no approval path inside Step 1.
- **The Brand Kit is in hand (2026-09-03) and its values are not optional.** Read
  `notes/source/brand-kit/README.md` and `notes/mockups/shared-v1/design-system.md` before
  drawing anything further, and swap the wrong dark out of what is already drawn. The "sites they
  like" answers are still outstanding: record them in the handoff, apply in Step 2, do not re-cut
  mid-step.

## Requests raised during Step 1, pending Rian (brief §8: record it either way)

Raised by Adi 2026-09-03. None is absorbed into Step 1; each is a scope or client question. The
mockup is built without them, and any that are accepted land in Step 2 or the build.

| Request | Disposition | Who decides |
|---|---|---|
| **Google reviews section on the home page** (4.5 from 14 reviews, unverified) | **Fence crossing** — §8 bars testimonial bands, trust strips and stat counters; not one of the 13 sections. Two risks to check first: self-serving `AggregateRating` markup is against Google's structured-data guidelines for `LocalBusiness`/`Organization` (displaying reviews is fine, marking them up is not — verify against current guidance), and Washington attorney advertising rules (RPC 7.1) constrain how a firm presents testimonials. The rating also needs a dated, verified source. Testimonials already has its own page | Rian with the client; the schema question with Michelle Bomberger |
| **A dedicated FAQ section** | **Already sold and planned** — section 10 (objection handling) *is* the FAQ section, four Q&A pairs on the `bw-ai-schema-pro` FAQ block with `FAQPage` markup on launch day. A second FAQ block beyond it would be adding a section, which is AISV's lane | No action — already in scope |
| **Lawyer faces / a team grid on the home page** | **Contradicts a binding client decision** (Alicia Wimmer, 2026-08-27: remove team photos from the homepage; the stated reason was that keeping them current is cumbersome). §8 bars a team strip, grid or "meet the team" band on Home. The lawyer grid already exists in the plan as the **team index of 9 headshots** — a headshot is the bio, not a team photo (`.logs/planning/design-direction.md`). The counter-argument is legitimate and worth putting to the client, because headshots on bios answer the maintenance objection directly; if they reverse it, the Guide section (§4) is where a face belongs, in Step 2 | Rian at the review call. Never added to Step 1 unilaterally |
| **Make the phone easy to reach; not several scrolls down** | **Fence crossing for Step 1** — §6 fixes the header at logo, six nav labels and the two CTAs, explicitly no phone number, and §7 bars a phone button as a third ask, because a third ask competes with the paired CTAs. The point is real for a law firm on mobile, where a `tel:` link costs no visual weight and is trackable as its own event. A genuine question for the review round | Rian with the client; if accepted, `.logs/planning/tracking-conversion.md` gains a `tel:` click event |
| **State the firm's longevity ("21 years", founded 2005)** | **Out of Step 1, and the year is not yet knowable.** §8 bars stats and number counters and any copy outside the brand story, so no longevity badge appears in either direction. More importantly the crawl found **three founding years on the client's own site** — `/about-us/` says "We began in 2004 as Small Business Legal Services", Michelle's bio says "In 2005 … Michelle decided it was time to launch her firm", and the 20-years blog says the Equinox brand began with a 2009 rebrand. The client's own anniversary campaign counts from 2005 (April 2025 → April 2026). Recorded as `.memory/naming-conflicts.md` §5; `foundingDate` stays empty in the schema until Michelle Bomberger confirms which entity the date describes. **And never a year count**: the client just retired the 20th-anniversary logo because the number expired, so "21 years" would need editing every April while "since <year>" would not. Any longevity wording is AISV's to write | Michelle Bomberger confirms the year; AISV writes any copy; Rian carries both |
| **Mega menu in the header, drawn open, with a CTA inside it** | **Fence crossing, built anyway on Adi's instruction (2026-09-03), and now an interactive prototype rather than a drawn state** — §8 bars "interaction or animation prototypes" as well as mega-menu states, so this is the deepest crossing in Step 1. §6 says "the nav is drawn closed, once; no dropdown, mega-menu or hover state" and §8 lists "dropdown or mega-menu states" twice as out of scope, on the grounds that menu behaviour is a Kadence build decision. Adi asked for it twice and it is now in the Direction A artboard: a high-fidelity Services panel built from **real live-site content only** (Adi, 2026-09-03) — the 6 real practice areas with descriptors condensed from the client's own page copy, the 5 real function groups with their real counts and real sub-items, the 5 real industries recovered from the crawl (which retires the `[TBC: names]` placeholder), General Counsel plans and A La Carte Solutions, a teal assessment CTA card, and a bottom strip with "View all Practice Areas & Industries" and the phone number. The case for keeping it: the sold requirement is "a navigation structure that surfaces your services and the general counsel offer", and the crawl proved the General Counsel page is **orphaned** — zero inbound internal links across 98 pages, absent from the 5-item nav, and the legacy `/general-counsel/` shortcut 301s to the parent. A closed six-label nav cannot show that offer's shape; the panel can. The child items drawn are exactly those already defined in `.logs/planning/site-architecture.md`, so nothing new was invented. **Rian's call is whether the open state stays in the client-facing export or is trimmed back to the closed nav before review** | Rian, before the export is filed |
| **Wordmark reads "Equinox", not "Equinox Business Law Group"** | **Built (Adi, 2026-09-03), and it is a placeholder either way.** The header and footer marks now read "Equinox" at 30px/26px. The Brand Kit logo has not arrived, so every mark on the artboard is provisional and will be replaced wholesale; this only changes what the placeholder says. Worth flagging to the client because the firm's own email signature points at `equinox.law` and the short form is already in use, but a shortened wordmark is a brand decision, not a design one. The full legal name stays in the footer copyright line and in the schema `name` | Rian with the client; the Brand Kit settles it |
| **One header CTA, "Contact Us", replacing the paired buttons** | **Built (Adi, 2026-09-03), with one consequence to accept.** The header now carries a single gold "Contact Us"; the assessment moved into the mega-menu CTA card, and the hero still carries both paired CTAs. `.logs/planning/site-architecture.md` specifies both CTAs in the header on every page, each firing its own GTM event, so that file needs amending if this stands. The tracking requirement itself survives — `.logs/planning/tracking-conversion.md` needs CTA-click events for the direct and transitional paths, not specifically from the header — but the transitional CTA loses its persistent placement, which is the one thing AISV's funnel leans on. The gain is a header that asks for one thing instead of three | Rian; if it stands, amend `site-architecture.md` and `tracking-conversion.md` |
| **Braver header colour — dark blue, brand blue, green, keeping the gold CTA** (Adi, 2026-09-03) | **Re-answered 2026-09-03 after the Brand Kit arrived; the earlier verdict was wrong on one point.** The kit's palette is six named colours, so there *is* a real brand blue: **BUSINESS `#027CA1`**, with **FREEDOM `#93BCCD`** as its light partner. The earlier note said brand blue was not brand — that was true of the live site's `#0098f4`, and untrue of the actual system nobody had seen yet. So: *dark blue is fine* (**NIGHT `#003B53`**, the brand's own dark — and note the navy `#112337` and teal `#004963` in the live CSS are both drift, not brand). *Brand blue is now available* (`#027CA1`). *Green is still not in the system.* Two constraints still bind: the one-accent rule means gold stays the only accent and a blue header ground is structural, not a second accent; and the guide's own logo rule is that the logo "should be on white or bright brand gradient backgrounds", so a dark or saturated header is a **declared departure** using the reverse lockup, and the export notes must say so. The genuinely new option the kit unlocks is a **brand gradient header or hero ground** — on-brand, weightless in CSS, and the guide's stated preference | Adi picks the treatment within `design-system.md`; Rian carries any question to the client |
| **Lead with pain — people do not call a lawyer unless stuck** | **Accepted and acted on, as hierarchy not copy.** The brand story already carries 13 concrete pain lines in sections 2 and 3, directly under the hero. The risk was design burying them, so both directions now give sections 2 and 3 real visual weight — recorded in `notes/mockups/shared-v1/directions-and-placeholders.md`. No copy changed | Done |
| **A prototype for an inner page, starting with an inner service page** (2026-09-18) | **Blocked twice over, and the second reason is the load-bearing one.** (1) Step 1’s gate is not cleared: `agents.md` bars inner pages until a direction is chosen AND recorded in `.logs/handoff.md`, and the newest handoff entry is a 2026-09-08 stub with no choice in it. This checklist puts it plainly at line 116: an inner page is not a pivot, it is a fence crossing with no approval path inside Step 1. (2) **There is no inner service page in what was sold.** Services live on ONE page, `/practice-areas-industry/`, rebuilt as a single structured page with an anchor per group (`site-architecture.md` rows 62 and 232). Per-service child pages were the Practice Area and Topic Hub Architecture add-on, **not accepted 2026-08-13**, and the taxonomy they would need is still owed by AISV with the client. Building one would be an unsold deliverable drawn against an unsettled taxonomy. | Rian: name the direction and it is recorded, then the first inner page is the practice-areas hub, not a per-service page |

## What Rian owes, tracked here so it is not lost

| Owed | Effect if it does not arrive |
|---|---|
| ~~Brand Kit pulled to `notes/source/brand-kit/`~~ **DONE 2026-09-03** — filed, with the 2026 Brand Photo Shoot at `notes/source/photos/` | Nothing outstanding. Follow-on ask: **vector logo files (SVG/EPS/AI)** from the client, since the kit is raster only. Not a Step 1 blocker |
| The two Step 1 dates (directions to him; mockup to the client) | The step runs without a stated date; the client is not told anything |
| Re-ask: examples of sites the client likes | Nothing — do not block; anything that arrives is applied in Step 2 |
| Decisions to close at the review call, not now | Assessment name; Fractional GC landing page go/no-go; the direct-CTA destination (on-site form vs Outlook, `.logs/handoff.md` 2026-09-03); whether the header carries a state list |