Site coherence pass: panels, measurement and owner calls
Purpose: make a whole website read as one site after many pages were built separately or in parallel. Worked out on 13 and 14 October 2026 on a recipe and cooking-lessons website, and written up by the agent that ran the pass. Status: method under trial, run several times on that one site (see Runs), with no measured effect on users; neither whole-site pass recorded before and after audit numbers. The Design review playbook owns the review of one screen, and How to do UX and UI owns persona panels; this document owns the pass over a whole site. To run a pass step by step, follow the Skill: run a site coherence pass. The rules a pass checks against are in Principles, from "One focal path per screen" onward, plus Principle 10: WCAG 2.2 A and AA are requirements, not calls.
When to use it
After a burst of building by several people or agents, before a launch, or when the owner says the site does not feel like one site.
Not for reviewing one screen (use the playbook) and not for copy alone (use Principles: evidence-based website, product and agent-facing copy in the sibling organization Copy and Messaging Principles). For one first screen that is "good and overwhelming at once", use the fit pass below.
The problem it targets: each page can look right on its own while the site, compared page by page, draws the same thing three ways, spaces sections differently and repeats pictures. Reviewers judging pages one at a time miss this; a comparison and a measurement catch it.
The shape of a pass
Capture once: one run screenshots every screen at 1440 by 900 and 390 by 844, first screen and full page, in three views: visitor (signed out), editor (signed in, draft mode off) and draft (signed in, draft mode on), on the integration branch that holds every open change. It writes an index of the shots. Every lens reviews the same set.
Panel 1: three or four lenses walk the whole site and report findings.
Merge: one plan, with build batches split by file area so builders run in parallel.
Owner calls: decisions, mockups and wording go to the owner in batches.
Build: outside this method.
Panel 2: the same lenses re-walk the built site, and a consistency auditor measures it.
Fix and measure again: re-run the audit and record before and after numbers.
Panel 1: lenses with distinct jobs
Each lens is one agent with the shared brief and its own lens paragraph. Lenses overlap on purpose at the edges; their jobs do not.
| Lens | Job | What it returns |
|---|---|---|
| Persona on real errands | Walks the site's main journeys as a real visitor: arrives from a social video, finds a dish, cooks it, saves it, comes back | Where it lost them, at which step, with the screen |
| Designer who measures | Measures spacing, type sizes, card anatomy and buttons at both capture widths, and proposes tokens and rules | Measured values and the token or rule each should become |
| Editor | Reads every visible sentence and builds an old-to-new sentence table and a glossary, marking who must approve each row | The sentence table, the glossary and a voice rule |
| Returning member or learner | Uses the signed-in and learning areas and checks the links between kinds of content (lesson to recipe, course to lesson) | Missing next steps and broken relationships between kinds |
A pass over every screen of a built site can run with three lenses on one capture set instead: calm and hierarchy (one focal path, one action row, decoration and pictures per screen), reader journeys (each journey end to end, including both ends of a shared one) and cross-page coherence (labels, arrows, headings, picture styles and repeats across pages). Its first run is under Runs, 16 October 2026.
The shared brief
Every lens gets the same brief, then its lens paragraph. The brief gives:
Hard limits: read only: change no code or content and start no servers of your own; no sign-ups or forms with real addresses; write nothing outside the lens's own folder.
How to see the site: the shared capture set and its index first. A lens loads a page itself (a signed-in editor state in a headless browser) only to check a state the set lacks, and says so. Every finding names its view (visitor, editor or draft) and its width: 390 by 844 or 1440 by 900; pages are captured to the end; screenshots are looked at, not only the DOM read.
Context: the goal journey, the primary reader and the others, the site's message, what exists, the content the author still owes (never propose inventing it), and mockups already decided.
What is already decided: the owner's rulings, the picks already built and the pull requests still open, each in one line. A lens that is not told re-proposes them, and its findings then cost a sorting round.
The standing rules: the owner's design rules, quoted. In panel 2, also the design system as it now is in code (tokens, card anatomy, heading and button rules), with the line "anything that deviates from these is a finding".
Accessibility: WCAG 2.2 A and AA hold on every page (Principle 10). Every lens reports a failure it sees, and every change to colour, size, focus or motion is checked against the criteria before it goes to the owner.
The finding format: page, view and width; the screenshot file; what the user sees; a concrete fix (component, value, exact wording); size (S, M or L); who must decide (the owner for money, legal, names and brand voice, the content author for content).
Two closing lists: a remove-or-merge list (what adds noise and should go), and what works and must be kept.
An owner's example calibrates better than a rule. Panel 2's brief carried one owner screenshot with six named problems and the instruction "find every problem of this kind on every page".
Delivery
In the agent setup these runs used (October 2026), reviewer agents did not write report files, and long final messages were cut off. Where that holds, each reviewer sends its findings as messages in parts of about 5,000 characters, labelled "<lens> 1/N", then ends with a short message naming its top five, and the coordinating agent saves the parts into one findings file per lens.
Merge into one plan
One plan, citing each finding by lens and number.
Batches split by file area (routes and components), so parallel builders never edit the same files. A design-system batch (tokens, card anatomy, heading and button rules) runs after the page batches land.
One slice per pull request. Each builder takes one slice, works in its own branch and opens one pull request, so builders never collide and each change can be reviewed and reverted alone. A local integration branch that merges every open slice shows the owner the combined state before anything lands.
Each batch lists what it does not build and why: an owner call, or content the author owes.
Two closing lists: numbered calls for the owner, and content for the author.
New visible wording collected per batch in old-to-new tables, for one approval.
Panel 2: re-walk and measure
The same lenses re-walk the built site and mark every panel 1 finding fixed, partly fixed or still broken, with what is left. The same readers judging old and new makes the change visible.
Add a consistency auditor that measures computed styles: an inventory, not impressions. It records headings, cards, rows, pictures and gaps per section on every page at two widths and two views (visitor and draft), and flags the same kind drawn two ways, off-scale headings, uneven end space, repeated pictures and video frames shown outside their ratio. The Skill: run a site coherence pass specifies the tool.
The auditor ends with a proposal for one presentation per kind: one grid card specification with a table of what changes per kind (picture ratio, label, meta), one compact row specification, and small pure functions for rules that cut across pages, such as assigning pictures so that none repeats.
Owner decisions
Mockups: alternatives on one page, using the real fonts, colours and content, with the team's pick marked.
Calls: numbered yes or no questions, each with the team's pick.
Wording: all new visible wording approved as one batch, in an old-to-new table, each row marked with who approves it.
Kept with the owner: brand, money, legal, names, and writes to production content.
Delegated picks: when the owner hands the picks for a pass to the team, whoever runs the pass picks, builds and shows the result instead of asking first. Every new sentence still goes into the old-to-new wording table for approval (see Wording), and anything that changes the voice or a promise is also listed separately for the owner to check at a glance.
Drafts: publishing a draft also publishes its other pending edits. Compare the draft with the live version before asking for a publish or doing one.
Attention heatmaps
How they are made. A vision model looks at a screenshot and names the first three fixations as boxes, each with a reason. The prompt describes a first-time visitor's first two seconds and names no design principle, so the model is not led to a textbook answer. Three independent runs are averaged. A script draws a soft heatmap from the boxes onto the unchanged screenshot and labels it "modelled attention, not observed". An image model never paints the heatmap: it would redraw the design and give no coordinates to score or compare.
Validation, 14 October 2026. 30 desktop web pages from UEyes (Jiang and others, CHI 2023, doi.org/10.1145/3544548.3581096; dataset zenodo.org/records/8010312, licence CC BY 4.0; both read 2026-10-29). In UEyes, people looked at static screenshots on a lab monitor with no task to do, which is not a visitor arriving with a goal. Each modelled map was scored by normalised scanpath saliency (NSS: the map's average standardised value at the places people looked in the first second; 0 is chance, higher is better):
| Map | NSS, first second |
|---|---|
| Centre bias | 0.37 |
| Model boxes, three runs averaged | 0.80 |
| Mean fixation map of the other 29 pages | 1.08 |
The model beats centre bias on 23 of 30 pages, but loses to the dataset's mean fixation prior, a layout-blind average of where people look on web pages. The first box is fairly stable from run to run; the second and third vary more. No phone screens were tested. The prompt asks about the first two seconds, while the score uses the first second. The vision model, its version, the prompt and the per-page scores are not recorded here, so a new model or prompt needs a new validation.
How to use them. A heatmap is a critique aid for comparing compositions of the same content and for checking whether a screen has one focal path. It is never evidence of where users look and is never cited as user evidence (Principle 14). In the first use it was still useful: on a recipe page the dish picture came before the title in most runs, reversing the intended path, and on an About page a face filled the first view and no run reached the action buttons.
Fit pass: does the first screen fit together
When to run it: the owner says a page feels "good and overwhelming at once": each part is liked, yet the whole asks too much of the eye. It is a tuning pass on one first screen, usually the landing page, not a redesign. It keeps what the owner likes and asks what to quiet, usually the chrome around the content rather than the content itself. The rules it checks against are in Principles under "One focal path per screen" and "Quiet chrome before content".
Three lenses in parallel. Each is one read-only agent with the same brief: the owner's words unchanged, what to keep, which files will ship, and how to load the real page. Lenses agreeing on a cause is the signal; in the first run all three named the header, not the hero.
| Lens | Job | What it returns |
|---|---|---|
| Hierarchy and weight | Ranks every element above the fold by size, contrast and colour weight; counts the voices and the accent's uses; tries quieter versions | Ranked causes with measurements, and the CSS that fixes each |
| First visitor on a phone | Arrives at 390 pixels wide as a stranger and reports where the eye goes and how far down the first real content starts | The first screen as a stranger sees it, in pixels and in percent of the screen |
| Editorial references | Measures three to five strong sites in the same domain on the same points: header height and rows, where the first content starts, wordmark to headline size | A comparison table and the pattern that fits |
Measure on the live page, never by eye. Read positions and sizes with getBoundingClientRect, type and colour with getComputedStyle, and count pixels in screenshots for colour weight (for example the share of strong accent pixels and which element they come from). Give every position in pixels and as a share of the screen height.
Try every change on the real page. Inject each candidate as CSS (page.addStyleTag in a headless browser) on the running page, using the site's own tokens and naming any new value. Screenshot before and after at 1440 by 900 and 390 by 844, light and dark, and measure again, so each change carries its own number. No hand-drawn mocks.
When the screen moves, vary size and motion together. For a first screen with moving pictures, try each tile size with each motion mode (loop, play once, play on hover) and each pause control, as a small grid of candidates. Screenshot every candidate while playing and at rest, and count the clips that play at once: a smaller tile lets more clips into view, so it can add motion. Then tune the rest of the top (decorations, extra lines, captions) against the picked motion.
One review page for the decider. Real before and after screenshots; the open question (for example one navigation row or two) shown as options side by side; numbered yes or no calls, each with the team's pick and its measured effect. Record the ruling in the product's own decision document.
Then build for real. Rebuild the agreed layout in the components (a grid with named areas, not the absolute positions or negative margins an injected stylesheet gets away with), and pin the measured numbers in browser tests (header height, where the first content starts at each width, wordmark size), so a later change that makes the screen loud again fails a test.
Worked example: a recipe site's landing, 14 October 2026. The owner liked the hero, its subline, the button, the three checks and the dish video row, yet felt the page was "both a little bit overwhelming and good at the same time". Measured at 1440 by 900: a two-row header 121 pixels tall on a band only slightly lighter than the page (#fffdf8 on #faf7f0) drawn by two hairlines, so it read as a toolbar; a 30 pixel wordmark above a 63 pixel headline, 2.1 to 1; the first dish at 538 pixels, against about 150 on NYT Cooking (cooking.nytimes.com) and Ottolenghi (ottolenghi.co.uk), both measured on 14 October 2026; about 12 accent spots and 19 small controls above the fold, with 84% of the strong accent coming from brush strokes in the pictures. On a phone the dishes started 59% down the screen. The owner said yes to all five calls: one header row from 1100 pixels wide, the header on the page's own colour with one hairline, a 25 pixel wordmark, a quieter dish row (play marks in the text colour, no arrows in the name chips) and a tighter phone top. Measured with the injected CSS: the header from 121 to 73 pixels at 1440, the whole dish row inside the first screen, and on a phone the dishes from 500 to 435 pixels. The ruling and the review page stay with the product. Status: all five changes were built and merged into the site's code on 15 October 2026; a browser test holds the header at 73 pixels at 1440 by 900. The effect on visitors is not measured.
Worked example: a recipe site's hero, 16 October 2026. The owner loved the moving dish clips but found the hero "so much happening". Candidates crossed tile size, motion mode and pause control, then decorations, a reasons line and a caption. The pick: smaller tiles, each clip plays once for at most five seconds and rests on its still, no pause button (WCAG SC 2.2.2 asks for one only above five seconds), no floating decorations, no reasons line, no caption. The whole dish row and every dish name then fit the first screen at 1440 by 900, where the row had run to 118% of the screen height. Clips cut from finished Shorts rest on burned-in captions, so loops come from the original footage. Rules: Principles, "A motion budget for the first screen".
How far these rules reach: "Chrome before content", "Count the voices above the fold" and "Accent budget" are general, measurable and domain-free, but each is confirmed on one site so far; the toolbar band and wordmark rules are the most specific to that site. A second site should confirm them before they count as settled.
Lessons from the runs
Ask reviewers to quote exact values: sizes in pixels, font and weight, exact wording. "Too big" cannot be built; "a section heading drawn at 23 pixels beside section headings at 37" can.
Two lenses agreeing raises confidence. A finding from one lens alone is a candidate.
Every reviewer finding needs a screenshot. A finding without one costs a second walk.
Re-run the measuring audit after the fix and record before and after numbers, so that "fixed" is a measurement.
Feed the owner's catches into the next brief. In the first run the owner caught a problem the first panel had itself proposed (numbered step chips instead of named steps); it became the principle "Recognise, don't recall".
Capture once, review with several lenses. One capture set read by three lenses costs one walk, not three, and lets lenses compare the same screen. Lenses that each capture also drift apart on state and width.
Tell every reviewer what is decided. List the rulings and open pull requests in the brief, so reviewers spend their findings on what is still open.
Capture on the integration branch with draft mode on and off. On 16 October 2026 a recipe with parts crashed only on a test deployment, because of a relative canonical address; a capture of the combined state in both modes catches such a bug before the owner does.
Check both ends of a shared journey. The journey lens found that the two halves of cooking together did not meet: inviting a friend was buried, and a shared link did not tell the friend to pick a part. Walk the inviter's path and the invitee's path as one journey.
Runs
13 and 14 October 2026, a recipe and cooking-lessons website. Panel 1: four lenses (visitor on errands, designer, editor, learner). The merged plan had five build batches and a design-system batch, built by parallel builders. Panel 2: the visitor and learner lenses re-walked, and a consistency auditor measured 23 pages at 390 and 1440 in two views. The visitor lens marked its 18 panel 1 findings as 8 fixed, 8 partly fixed and 2 still broken. Before and after audit numbers: not recorded.
14 October 2026, the same website: a fit pass on the landing's first screen with three lenses (hierarchy and weight, first visitor on a phone, editorial references). Five calls, all accepted; header 121 to 73 pixels at 1440, phone dishes 500 to 435 pixels. See the section "Fit pass".
15 October 2026, the same website: two fit passes in cook mode. "Your part" moved from its own centred row into the top bar beside Settings, since step changes scrolled it under the sticky bar; a step's item icon moved after its word, smaller and raised like a footnote marker.
16 October 2026, the same website: a fit pass on the moving hero. Tile size, motion and pause crossed as candidates, then the top of the screen; owner-delegated pick built in one pull request. See the worked example under "Fit pass".
16 October 2026, the same website: a pass over every screen. 116 screenshots at 1440 and 390 in one capture set, three lenses (calm and hierarchy, reader journeys, cross-page coherence), then one builder per slice. Findings that became rules: one action row per screen; no picture twice on one page, prevented by choosing a different dish, with name tiles only for a dish without a picture; one label per destination ("Find a recipe"); arrows only on links to another page; headings match their tabs; one picture style per role; one photographed object and one handwritten line on the error page; no scattered decoration around a centred column. The journey lens found that inviting and arriving did not meet. Six pull requests, one per slice: labels and arrows; sign-in, finish and error pages; the recipe action row and pictures; the home page picking other dishes; the account People tab; and a shared recipe link that opens cook mode on choosing which part to cook. The owner delegated the picks. Before and after audit numbers: not recorded.