# adi-note.md — Adi's working notes

Manual notes from **Adi** (web designer + web developer on this build). This is
Adi's clean thinking space — design intent, dev observations, questions, ideas.

**For Claude:** read this file at the start of a session for context on Adi's
current thinking, and treat it as *input*. Do not edit, reorganize, or "clean up"
this file unless Adi explicitly asks. If a note here conflicts with `brief.md` or
`.logs/planning/build-plan.md`, flag the conflict to Adi rather than silently
picking one.

Convention: newest entries at the top, dated `## YYYY-MM-DD — topic`.

---

## Notes

## 2026-08-24 — Process proposal: balance the direction gate with our traditional craft — don't rush the direction

Balancing the new direction-gate process with the traditional design process:
**direction is indeed important — which is exactly why the proposal to the
client should not be hurried.** What I think the process should include:

1. **A senior collects first.** Someone senior (Rian, on League) spends the
   time gathering facts from the client — the do's and don'ts, the written
   input, the constraints. This is what `design-direction.md` is: that step
   already exists and worked.
2. **The designer comprehends, then crafts — with time to sleep on it.** A
   designer (me, here) takes the collected facts and *tests/crafts* the
   direction — not a rushed 1-day turnaround. For a big enough project:
   around **2 full days of work with a night to sleep on it**; scaled down
   for simpler projects. Comprehension first, craft second. The sleep matters
   — direction judged only on day one is direction judged on first
   impressions.
3. **Internal review gate before the client sees anything.** The direction
   draft goes to Rian: if good → it goes to the client; if not → back to the
   designer for internal revision. The client only ever sees something that
   has passed both the designer's considered judgment AND the senior review.

Why I think this fits what Rian wants: it's literally his "the default should
be to slow down" applied to the direction phase, and the internal review gate
is the check-in culture made structural — no client-facing artifact ships on
one person's same-day judgment. It also gives the timebox a natural shape:
Rian sets the box; ~2 days is my proposed default for a project League's
size.

**And the scope rule: before anything else, draft the HOMEPAGE only.** The
direction is crafted and confirmed on the homepage first — one page, the page
whose job is triage and contact. Inner pages, templates, everything else
follows *after* the homepage direction is agreed; they inherit from it. One
page keeps the ask small for the client, the craft focused for the designer,
and the revision loop cheap for everyone.

**With flexibility for the obvious.** The deliberate pace applies to the
direction work, not to everything — things that are needed with high
certainty *whatever* direction wins can run in the background in parallel,
e.g. by a junior: the goes-without-saying items. On a project like League
that's things like collecting brand assets (logo files, colours, fonts),
fixing the broken `tel:` links, the performance/analytics baseline, the
content inventory, the standards-checklist items (privacy policy, disclaimers,
FAQ material), the photographer's shot brief. The test for what qualifies:
"would we need this no matter which option the client picks?" If yes, it can
start now; if it depends on the direction, it waits.

For the process doc (to discuss with Rian before writing it in): this is the
**human cadence layer** over steps 1–2 — Intake = senior collects · Direction
= designer crafts with deliberate time (homepage only), while
direction-independent prep runs in the background · then the internal
gate → client.

## 2026-08-21 (evening, Indonesia) — Met Rian (his morning): directions on the client ask — fewer, shorter, easier, involved

Ending my day; continuing tomorrow morning (Indonesia). This evening (Rian's
morning) we talked and he gave directions / explanations that aren't fully
written anywhere yet — capturing them here so they're not lost:

- **Too many options confuse the client.** Five is way too much; **maybe
  three.** (So the 5 + 2 deck proposal is too big as-is — rethink the count.)
- **Wording that's too long is not good.** What we ask the client needs a
  balance — enough to be clear, short enough to be easy. Not a wall of text.
- **It should not cost the client even ~5 minutes.** The ask has to be
  genuinely easy — something they can react to almost immediately.
- **The feeling of involvement matters.** The client needs to feel part of the
  process at this stage — that's what keeps them with us. The risk Rian named:
  if we jump too far ahead (e.g. a finished-looking mockup when we're not in
  that phase yet), the client can "fly away" — it's no longer their decision,
  it's ours, and they disengage. Small, easy, early involvement is the point of
  the direction gate.

Mental update from this: the direction-phase ask is a **tiny, warm
invitation** — a few options, few words, a minute of their time, and a clear
sense that their answer shapes what comes next. Tomorrow: re-cut the examples
deck with this in mind (3? which 3? bookends still?) before anything else.

**How the ask could actually work (thinking ahead):** maybe an HTML page (or
another simple format) where the client just **selects** — click option 1, 2
or 3. The options are **layout wireframes** (low-fi, deliberately rough) that
are built from two sources at once: the client's own unique requests (Darren's
four criteria, the league idea) and our **own internal standard checklist**
for this website type. The client should **not** have to read our standard —
it stays behind the scenes, available as an appendix just in case they want
it — but it means the options are complete and ours, not dependent on what
other websites happen to do.

Other websites are still good for us — to **steal ideas from, if they're
good** — but adapted to match our project, never copied. That's why we're
here with expertise: the examples inform us; the options we present are made
for *this* client. So the deck for the client is probably fewer reference
sites and more "pick your layout" — and the reference sites become our
research, with the best of them folded into the three options.

## 2026-08-21 — Portrait expressions: suggest "welcoming, wants to talk" for the November shoot

Just a thought, and I don't know the etiquette of it — is it even appropriate
to ask a lawyer to smile? — but looking at the current lawyer portraits, some
are not smiling much — some neutral, a few reading as cold or even mournful.
That's partly personal preference (what reads warm to one person reads
unserious to another), so I'm not stating it as a rule. But we could **suggest
a consistent expression across the team for the November photography:
welcoming, open, "I want to talk to you" — a smile is better than a neutral
face, and neutral is better than stern or sombre.**

Why it fits the direction: it's the human version of everything above — the
emotional title area, the local familiarity, the tap-to-call bar. If the whole
site is built to get a stressed person to *contact a human*, the first human
they see should look like someone they'd want to call. Consistency matters as
much as the expression itself: a mixed set (some warm, some cold) reads as
less of a team — and "teams, not lone lawyers" is Darren's own idea.

One practical extension, in case we want to design for **empathy** as well
as welcome: ask the photographer for **two expressions per person — a smile
and a calm neutral** — so the site can choose the right one for the context:
the warm, welcoming smile on general and team pages; the calm neutral where a
big smile would feel wrong next to someone's situation (estate disputes,
serious injury, a loss). Same person, same light, same crop — just the
expression matched to the moment.

Where it belongs: the **photographer's shot brief** (which the placeholders
already double as) — phrase it as a gentle art-direction note for the shoot,
not a request to individuals. Darren is the one to carry it to his team if he
agrees; our job is to suggest it once, clearly, and leave it to them.

## 2026-08-21 — The local feeling: familiarity lowers the barrier to calling

A note about feeling: when you look at a website and you know *exactly* where
they are — a place in your hometown, a building you've walked past — there's a
small "oh, I know that place" moment. **Familiarity.** It makes the firm feel
not foreign, not strange — and for something like a legal problem, that's the
difference between hesitating and just calling or emailing.

So add it to the list of elements we should consider bringing to the website
(parking here for now): **a recognisable local presence** — the new office
across from the courthouse (everyone in Victoria knows the courthouse), the
six locations named plainly, real photos of the real place and the real
people (the November shoot again), maybe the neighbourhood in view. Not
scenery-as-decoration (Darren's rule) — place-as-recognition. Closely related
to the emotional title-area note above: trust from recognition, not from
reading.

Process note: this probably belongs in the brand-inputs intake (office
exterior/interior, local landmarks, how locals refer to the place) and then
in the designer's judgment about where recognition does the most work (the
contact/locations area, the inner-page title areas, the footer). For a
six-office firm, "which place" is itself a question — the same one as "which
phone number."

## 2026-08-21 — Armstrong Legal, inner pages: the "title area" that works on emotion, not reading

Looking at <https://www.armstronglegal.com.au/family-law/>: their practice
page has what most sites would call a "title page" area — but it's doing more
than a title. In that area they put the **phone number and a CTA**, a
**thumbnail**, and an **emotionally chosen image**: for Family Law it's a
child — likely the person most impacted by divorce, separation, custody — put
in front of the visitor's face.

My assumption (just mine, not proven): imagine someone in a stressful
situation — they don't want to divorce; they're not in a state to focus on
writing or read many paragraphs. They're on **emotion**. What that title area
gives them instead of reading is: a phone number to call, an image that
reminds them what actually matters, and an instant sense of trust that comes
from branding and speed rather than text. **I'm predicting many people on the
internet are not readers** — they're on emotion, they click click click, and
then they want to talk or email — to see the human behind it.

Why it matters for League Law: this is Darren's "match their issue and contact
us, not impress them" — but pushed one level deeper than the homepage. The
practice/inner pages may need the same discipline as the top: contact + CTA
in the title area, one image chosen for the person's *emotional* situation
(injury, loss, a boat, a home), trust signals, and the reading *available
below* for the minority who read. It also argues for real photography of
people (the November shoot) over scenery — which is inside Darren's rules.

Note to self: this is an assumption about behaviour, not a measured fact —
worth checking against League Law's analytics (time on page, scroll depth,
tap-to-call rate) when we can. But as a design lens it feels right: design
for the person in the moment, not for the reader.

## 2026-08-21 — Armstrong Legal again: it's also FAST — performance belongs in the process somewhere

Digging further into <https://www.armstronglegal.com.au/>: it isn't just a
layout that fits Darren's brief — it's also genuinely well built. GTmetrix
(checked 2026-08-21):

| GTmetrix | Result |
|---|---|
| Grade | **A** |
| Performance | 98% |
| Structure | 96% |
| Largest Contentful Paint | 642 ms |
| Total Blocking Time | 108 ms |
| Cumulative Layout Shift | 0 |

So the closest existing match to the brief also happens to be wonderful work
under the hood — the "no hero imagery" structure and the speed are probably
related (less to load), which is itself an argument for the direction.

**Process note — I'm not sure which phase this belongs to, but fast loading
should be part of the standard.** Candidates:
- It's a **checklist item** (the website-type standards idea): a law-firm site
  should meet a performance bar — Core Web Vitals green, a GTmetrix/Lighthouse
  target — as a "must have", not a "nice to have".
- It's a **build/QA gate**, not a direction question — but the *direction*
  can make it easy or hard (a video hero makes an A grade much harder), so it's
  worth naming during direction so we don't choose a direction that can't be
  fast.
- For League Law specifically, `brief.md` already promises a **performance
  pass with before/after Core Web Vitals**, and the current site loads ~50
  script files on the homepage — so the baseline measurement is already an
  intake item, and Armstrong is a realistic "what good looks like" target.

Also a small reminder that the examples deck can carry more than taste:
Armstrong is a *structure* reference, a *mobile contact* reference, AND a
*performance* reference — one site doing three jobs.

## 2026-08-21 — Armstrong Legal, mobile: the sticky bottom "Call / Email" bar is the thing to highlight

Looking at <https://www.armstronglegal.com.au/> on mobile: the part worth
calling out is the **sticky bar at the bottom of the screen with "Call" and
"Email"** — always there, thumb-reach, and it feels genuinely easy to just tap
and call them right away. No hunting, no scrolling back up.

And this isn't a side case: as a general fact from Google Analytics across
sites, **roughly half of users (often more) are on a phone** — so the mobile
contact pattern may be the *main* case, not the secondary one. Worth pulling
League Law's own GA numbers during intake to confirm the split for their
audience (injury clients especially are likely on phones), and letting that
weight how much of the direction work is judged mobile-first.

Why it matters for League Law: Darren's rule is "contact information hits you
in the face from the instant you're on the page" — on mobile, that's not the
header (it scrolls away or shrinks), it's a **persistent bottom action bar**.
This is the mobile answer to his demand, and it pairs with the `tel:` defect
noted in `design-direction.md` (6 of 13 lawyer records have broken tel links
on the current site) — tap-to-call has to actually work.

Noting it for the direction boards / examples deck: when we show Armstrong,
show the mobile view too, because its mobile contact pattern is arguably a
stronger proof than its desktop grid.

## 2026-08-21 — Thought (unsure): a historic check — dig the old site in archive.org?

Not sure this belongs in the process, just noting it: should the intake
include a **historic check** — looking at the client's previous site versions
on archive.org (Wayback Machine) to see the progression, what changed between
redesigns, what they tried and dropped? Being aware of that history might
prevent repeating a mistake they already moved away from, or reveal something
they've kept constant for years (a motif, a structure) that is clearly part of
who they are.

Counter-thought: the future isn't in the archive — the direction comes from
the client's *current* words and brand, so this may not be important. Maybe it
sits as an optional, low-cost item on the intake checklist ("glance at the
Wayback history; note anything persistent or anything they abandoned"), not a
required step. Just a note.

## 2026-08-21 — A thought for discussion with Rian: is a website part art, part system? (automate the system, keep the art?)

Just a thought, not a claim — an opinion that may well be wrong, offered for
discussion: **I tend to see a website as partially art and partially a
systematic way to tell a story.** If that's roughly true, the process we're
building might treat the two halves differently:

- **The systematic part can — and should — be automated.** The inventory of
  what a site of a given type must contain (the website-type checklist idea),
  the intake steps, the criteria extraction from the client's own words, the
  example-search recipe, scoring against criteria, the single-ask format, the
  decision record — these are repeatable, written-down, runnable. This is the
  half Rian is pointing at with Scout and "parts of this get automated."
- **The art part is sense, taste, and merging** — how the pieces become *this
  client's* story (the league → hive, the orange → bee; which tension to
  resolve, which detail to keep). That is judgment, not procedure. It can't
  be automated out, and the process shouldn't pretend it can — but it can be
  *fed* by the automated half (good inputs, good options, a confirmed
  direction) and *bounded* by it (checklists, criteria, check-ins).
- So the process I'd argue for is a **merge**: automate the system so the
  designer's time and the client's attention go to the art — and make the
  hand-off points between the two explicit (where the system stops and a
  human judgment call begins, and who makes it).

For Rian: I'm not sure this framing is right, but if it is, it might explain
both of our instincts — the process/automation ambition and the designer's
pull to build the real thing — and could give us a way to decide, step by
step, which parts are "system" (write it down, run it) and which are "art"
(designer decides, client reacts). Happy to be argued out of it.

**Continuation — even the "art" half can follow steps.** The art isn't
formless; it starts from inputs that can be collected systematically. Before
any design judgment, a **brand-inputs checklist** (at minimum listed out;
later maybe partly automated):

- **Brand guide** — do they have one? Use it. If they don't (e.g. a brand-new
  website client), the suggestion might be to *create* one as part of the
  work — a light brand guide for developers, like the one we started for
  League Law (fonts, colours, signature shape, do-not-change list).
- **Logo** — files, versions, clear-space rules, how it's actually used.
- **Social media** — Facebook, Instagram (and LinkedIn where relevant): what
  visual language do they already use in public — colours, shapes, photo
  style, tone of voice. (League Law: the hexagon on Facebook posts, the car,
  the print — that's how the polygon surfaced.)
- **YouTube / video** — do they have a channel, what does it look and sound
  like, any recurring motif.
- **Office** — interior and exterior: materials, colours, signage, the
  physical brand (League Law's hexagons in the office; the new building across
  from the courthouse).
- **Print collateral** — business cards, letterhead, brochures: often the
  most disciplined use of the brand.
- **Existing site** — as a measurement artifact only (what the replica is
  for), not as a baseline.
- **Photography** — what exists, what's planned (League Law: November shoot
  — so placeholders + a shot brief).

Collecting these is system; what the designer *does* with them — which motif
becomes structural, which colour leads, how the story is told — is the art.
So the split might be: **the art has an intake that can be a checklist (and
later partly automated), and a judgment step that stays human.** Worth
listing out properly as part of the process, even if we don't automate any of
it yet.

## 2026-08-21 — Thought: Armstrong Legal's practice grid, but in hive shape

Looking at <https://www.armstronglegal.com.au/> (the closest existing match to
Darren's brief — phone top-right, practice-area tiles as the first thing on
the page, no banner): **what if League Law's version of that grid is the
hive?** The five practice areas as honeycomb cells — the brand hexagon doing
the triage job ("yes, that's my issue"), with the contact/phone cell sitting
among them or above.

Why it might work: it satisfies the four hard criteria *and* it's the "a
little different" Darren asked for, coming from information design (the
zones) rather than decoration — which `design-direction.md` says is the only
lever left. And it's the first time the league/hive idea would be structural
(teams as cells) instead of ornamental.

Just a thought — it belongs to the direction boards, not to a mockup, and only
after the examples ranking tells us where Darren sits. Parked.

## 2026-08-21 — Idea (parked): our own standards checklist per website TYPE, not just other people's sites

A thought while building the examples shortlist — **we rely too much on other
websites to define direction.** Examples are fine for taste, but we should
also have standards of our own. It stays low-fi, but somewhere in the process
there should be a **checklist**:

- If choosing a direction is like choosing a car (sedan / SUV / truck), then
  the first choice is the **website type** — and each type should come with
  **our own standard checklist** of what makes it complete.
- Start with ONE category: **"a law firm website."** What should it have?
  Probably hundreds of items across "must have" and "nice to have": privacy
  policy, FAQ (+ FAQ schema), schema markup generally, team page + team index,
  service pages + service index, phone number at real size / tap-to-call, blog
  post index, locations/offices, contact page, accessibility basics, legal
  disclaimers, reviews/proof, careers, etc. — the anatomy of a *normal* law
  firm website, so nothing gets forgotten and the direction work can point at
  "which of these zones go where" instead of reinventing the inventory.
- Not doing all of this now — just parking the thought. Could live next to
  `prototype.md` as a per-type checklist, and it fits Rian's automation idea
  (a written checklist is something an automated step can run).

## 2026-08-21 — Examples shortlist: findings + the deck I like (checking with Rian first)

First swing at the direction phase, done the way Rian asked: start from
Darren's own request — examples online he can rank. Draft v1 is internal at
`.logs/planning/examples-shortlist.md` (finalist screenshots in
`prototyping/examples-shots/`). **Nothing goes to Darren until Rian has seen
it — I'm checking with him first.**

**Findings I want to remember:**

- **The triage-first / no-hero law homepage is genuinely rare.** ~150 law
  sites checked; every BC / Vancouver Island regional firm runs a scenic hero;
  the "best law website" galleries are ~95% photo/video heroes. The clean
  examples come from government portals and legal-information nonprofits — so
  Rian's "look outside law" hypothesis held. That rarity *is* our
  differentiation argument (exactly what `design-direction.md` predicted).
- **Trades and insurance sites fail** in the same way every time: phone in the
  header, but a video/photo hero underneath. Don't look there again.
- **Both bookends should pass the functional rules** — then Darren's ranking of
  them isolates *taste*, not compliance. Smart framing; keep it for future
  projects.

**The deck I like (5 + 2):**

1. **armstronglegal.com.au** — phone top-right, five practice tiles first, no
   banner: the closest existing site to what Darren described.
2. **co-oplegalservices.co.uk** — menu-first and still looks current.
3. **usa.gov** — phone in the top bar, "How do I…" tasks, category grid, not a
   single photo: "how far would you go?"
4. **clicklaw.bc.ca** — BC legal topics as icon tiles (incl. Wills & Estates).
5. **hornecoupar.com** — a Victoria estates firm: typographic, sharp, no
   scenery — the *tone* axis, and a peer Darren may know.
- Too plain: **rayslawoffice.com** · Too styled: **cagoldberglaw.com**.

**Open with Rian:** format (a simple ranking page vs Scout — Darren is already
lead there), count (he said "a couple" — 5 + 2 proposed), and the timebox.

**Process question I want to raise with Rian too:** what does the examples
gate look like when the direction is something genuinely new that doesn't
exist online yet? My current answer (from talking it through with Claude):
examples rank *taste* on the axes; a rough low-fi board of the new idea sits
in the same deck and gets ranked against them; only when the *interaction*
itself is the idea do we need a small probe — and that's a pivot to flag
first, not a failure of the gate.

## 2026-08-21 — After Rian's review: I accept "a pivot is a check-in"

Rian reviewed (Slack + his handoff entry + the Process ruling in
`prototype.md`). **I accept the rule: pivoting away from an agreed approach IS
the moment to check in** — two lines to Rian, what's failing and what I'd try
instead, before hours go into the replacement.

Honest note to myself: if I forget it, it's probably because I don't *realize*
I'm pivoting in the moment — the work pulls me forward and the approach has
already changed before I notice. So this isn't only a rule to follow, it's an
awareness I need to build: catch the moment the agreed approach starts
changing, even when it feels like natural progress. I may not always be
sensitive enough to see it, but I'll try my best — and Claude should flag it
too when a session starts drifting from the agreed approach.

The good part: **this time we got an approved next step** (the direction
phase — the examples shortlist first) instead of getting lost the way some
previous projects went, where I overclocked and ran too far ahead. Need to
stay on track: direction before mockup, anchored on Darren's written input
(`.logs/planning/design-direction.md`), check in at every pivot.

## 2026-08-20 — Second meeting with Rian: fidelity approach under review — PAUSED

Met with Rian again. **He was not expecting me to do high-fidelity mockups** —
his expectation was still the pencil-wireframe approach from our first meeting.

**My reasoning, for the record:** high fidelity gives the idea *clearer*.
Because we are the designers — whoever the designer is — we can see whether a
design actually works much more clearly when it is not in too-low fidelity.
The low-fi experiments (see the 2026-08-20 fidelity-verdict entry below)
showed concretely how details get lost and how raw ideas can mislead.

**Addendum — where the miscommunication actually was (my mistake in
delivering the note):** on reflection, Rian's expectation is the **output of
a repeatable process** — the process itself (what `prototype.md` is
distilling) is the deliverable he's looking for, not the homepage mockup as
such. My position is that the only honest way to *produce* that repeatable
process is to actually run it once on a real thing — the homepage mockup —
and record every step and lesson into `prototype.md` as we go. The mockup is
the test bench; the process is the product. I don't think I communicated
that part well in the meeting, so what he saw looked like "Adi is building a
homepage" instead of "Adi is extracting the process by building a homepage."
That framing is what I need to make clear when he reviews.

**Status: PAUSED.** I'm stopping prototype work here and waiting for Rian to
review what's built when he has time. Everything is ready for his review at
<https://leaguelaw.demoing.info/wp-content/prototype/> (the hub lists every
piece: the option rounds, the canonical header + mega menus, the J2
scroll-pin hero with the minimizable form). The fidelity question is HIS
call to make after seeing it — if he prefers the wireframe route, the pencil
and mid-fi versions still exist in `prototyping/` for comparison.

## 2026-08-20 — Fidelity verdict: replica-first, improve in high fidelity

After testing three fidelities on the League Law homepage (pencil sketch,
mid-fi grayscale, 1:1 HTML replica), my conclusion as the designer:

**Low-fidelity wireframes carry a high risk of losing details** — the live
hero's 26% form width became a misleading 50/50 in the mid-fi, and details
like that are design decisions, not noise. Worse, low-fi output can
**mislead or overwhelm the client with raw / super-raw ideas that are not
ready to be presented.**

**What I prefer instead: high-fidelity wireframes that contain improvements
to the existing site.** The process (now written into `prototype.md`):

1. First step is an **HTML version of the old website** — a 1:1 replica with
   real assets, measured proportions, real copy.
2. Then we **improve the mockup from there**, part by part (header → hero →
   …), through option funnels, integrating each winner back into the page.

Rian's underlying intent from the 2026-08-19 meeting — keep the conversation
on layout, avoid premature fidelity debates — is preserved, just achieved
differently: instead of looking unfinished, every change is an explicit,
deliberate **diff against the replica**, so nothing is accidental and nothing
rawer than "the site as it already is" ever reaches the client.

## 2026-08-19 — Meeting with Rian: wireframe first, and who judges

**What Rian said:** we should have a **wireframing step** in the process —
sketch-like, pencil-like lines, deliberately *not* smooth or polished. The
point is to get the **layout** agreed before any talk of high fidelity,
correct colors, or other details that drag the conversation into discussions
we're not ready to have. High-fidelity mockups come later, of course — but
layout first, on drawings that *look* unfinished so nobody reviews them as
finished.

**What I want from this:** a systematic, atomic process for wireframing (this
goes into `prototype.md` so it's repeatable on future projects), with one hard
constraint — **don't overwhelm the client.** We are here to make the client's
life easy, not to make them busy like they work at a big marketing agency. We
do the work *for* them; there's a balance between involving them and burdening
them.

**Who makes the call:** where that balance sits — what to show the client,
how many options, when to decide without asking — is **my judgment as the
designer (Adi)**. The client reacts and approves; they should never have to
do design work.

## 2026-08-19 — Brand foundations for the modernization

Modernizing League Law means **keeping their branding** — so before prototyping
we need a **brand guide for developers**. Building that guide is a to-do in
`prototype.md`; this entry is the raw material for it.

### 1. Typography — keep the live site's fonts

The live site loads both from Google Fonts (verified 2026-08-19, full weight
ranges 100–900 + italics):

- **Headings: Raleway**
- **Body: Open Sans**

We stick with these. No font change is part of this modernization.

**Colors to maintain:**

| Role | Hex |
| --- | --- |
| Dark text (brand brown-black) | `#423C37` |
| Brand orange (the distinctive one) | `#EF6D3E` |
| Minor accent (teal) | `#46ADC8` |
| Background "white" | **not** `#FFFFFF` — use ~`#F9F9F9` |

**The white rule:** on the new site, white is never just white. Best practice
from design/art: *white is never white and black is never black* unless it's a
hard requirement. Old site backgrounds are plain `#FFF`; new site uses a soft
off-white (~`#F9F9F9`, exact value to be locked in the brand guide). Same
thinking applies if we ever need a near-black.

### 2. The polygon — their shape, bring it forward

`https://www.leaguelaw.com/wp-content/themes/total-child-theme/assets/images/polygon.svg`

The client uses this same shape everywhere at the same proportions: office,
car, website, print paper, Facebook posts. **It is what makes them unique**, and
it must carry into the new modern site.

Verified detail: the SVG is a **regular hexagon** (61×70, pointy-top), filled
with the brand teal `#46ADC8` in the original asset.

**My interpretation (not client-stated):** when Darren says they are a
*league*, I think of a **bee hive** — they don't work alone, they work as a
team. A hexagon is literally a honeycomb cell, so the shape fits that
philosophy perfectly. Darren never said this explicitly; it's my prediction as
the designer — but it's a strong lens for how to use the polygon in the new
design (cells that tile/cluster = teams, not lone lawyers).

### 3. Orange = the bee (my designer thinking, not client-stated)

The orange `#EF6D3E` is League & Williams' distinctive color. My personal
reading: it's the **color of a bee**, and with the honeycomb shape the story
completes itself — they do good work for their clients, producing quality
"honey" that never expires (as the saying goes, honey never spoils).

**Priority check:** the client's explicit wants come first, always — what
Darren wrote in the email thread and Rian's notes (`brief.md`, Scout's
`league-law-thread.md`) are the requirements. The bee/hive/honey framing is my
internal design metaphor to keep the visual language coherent; it never
overrides, and we never present it as something the client asked for.