# Long-form Interface Study Method

This method turns a live article into a dated, reproducible design study. It is deliberately stricter than collecting screenshots. The goal is to explain how the interface helps a specific reader stay oriented, understand the story, and act afterward.

## 1. Qualify the source

Study a page only when it passes all four gates:

1. **Real audience:** The page serves an identifiable reader with a real job, question, or emotional need.
2. **Meaningful length:** The experience requires sustained attention, not a short landing-page skim.
3. **Designed delivery:** Layout, type, imagery, interaction, or pacing materially shape comprehension.
4. **Current access:** The page can be loaded and evaluated on desktop and mobile without inventing missing evidence.

Record the URL, publisher, article title, capture date, and any access limitation before analysis.

## 2. Capture the evidence set

Use the gstack `/browse` runtime. Collect the same six images for every source:

- `desktop-hero.png`, 1440 by 1000, first viewport only;
- `desktop-body.png`, 1440 by 1000, one meaningful in-article viewport;
- `desktop-full.png`, a full-scroll overview strip;
- `mobile-hero.png`, 390 by 844, first viewport only;
- `mobile-body.png`, 390 by 844, the same or nearest equivalent in-article beat;
- `mobile-full.png`, a full-scroll overview strip.

Dismiss cookie banners and ads when they block the article, but preserve meaningful navigation, progress, subscription, share, or sticky reading controls. Scroll through image-heavy stories once before the final capture so lazy media loads.

The browser compresses extremely tall full-page captures to a narrow overview. Use them to discuss pacing, color, and section rhythm, not text detail. The hero and body captures preserve readable evidence.

Never present a screenshot as timeless. Captions include the source and capture date.

## 3. Extract rendered facts

Collect, where available:

- heading order, size, weight, and family;
- body family, size, line height, and approximate reading measure;
- foreground, background, link, and accent colors;
- article width and major grid behavior;
- image/video count and placement modes;
- persistent navigation, progress, table of contents, citations, sharing, and related-story modules;
- console/network errors and rough performance timings;
- touch targets, focus treatment, zoom behavior, and reduced-motion support.

Rendered evidence outranks assumptions about the source code.

## 4. Read the story as a sequence

Map the page in order. Use functional names, not generic section numbers:

1. **Promise:** What does the first viewport ask the reader to care about?
2. **Orientation:** How are author, publisher, date, topic, and expected effort established?
3. **Entry:** What makes the first paragraph approachable?
4. **Development:** How do headings, images, quotes, data, or scene changes reset attention?
5. **Climax or synthesis:** Where does the page deliver its strongest evidence or emotion?
6. **Exit:** What does the reader do next, and does that action respect the story that just ended?

## 5. Compare desktop and mobile as editorial decisions

Do not stop at “columns stack.” Record what changes in priority and experience:

- Does the title scale or recompose?
- Does metadata move, collapse, or disappear?
- Does media crop differently or change order?
- Are side notes promoted into the reading flow?
- Do progress, share, or navigation controls change location?
- Does the reading measure stay comfortable?
- Do motion and sticky elements become quieter for touch and battery constraints?
- Is any meaningful content lost?

Classify the adaptation:

- **Reflowed:** Same hierarchy, resized and stacked.
- **Recomposed:** Same content, deliberate new order or emphasis.
- **Reauthored:** Media, copy, or interaction changes for the smaller context.

## 6. Score with evidence

Score each category from 1 to 5. A score without a cited observation is invalid.

| Category | 1 | 3 | 5 |
|---|---|---|---|
| Readability | Friction blocks sustained reading | Generally readable with local issues | Type, measure, and rhythm disappear behind the story |
| Orientation | Reader loses place or context | Basic title/author/nav present | Location, progress, and next action stay clear throughout |
| Narrative pacing | Unbroken wall or arbitrary effects | Some effective resets | Form and story beats reinforce each other throughout |
| Responsive adaptation | Desktop squeezed into mobile | Clean reflow | Mobile is deliberately recomposed or reauthored |
| Media integration | Decoration or interruption | Useful supporting media | Media carries evidence or emotion at the right beat |
| Accessibility | Serious barriers | Common baseline met | Inclusive choices are visible in the core composition |
| Performance restraint | Heavy work with little reader value | Acceptable tradeoff | Media and motion earn their cost and degrade well |
| Transferability | Mostly brand-specific | Several reusable tactics | Clear system others can adapt without imitation |

Overall score is the rounded mean, but the category profile matters more than the single number.

## 7. Write two kinds of statements

Use explicit labels:

- **Observation:** Directly visible, measured, or extracted from the rendered page.
- **Inference:** A reasoned explanation of why the choice may help or hurt the reader.

Avoid invented intent. “The publisher wanted…” is not an observation unless the source says so.

## 8. Separate pattern from signature

Every report ends with two lists:

- **Transferable pattern:** A design mechanism that can serve another article.
- **Do not copy:** Brand assets, proprietary type, one-off art direction, or a pattern whose cost only makes sense for this story.

Credit and link the original source. The field guide teaches systems; it does not redistribute the article.

## 9. Refresh loop

1. Run `pnpm run queue` monthly.
2. Re-capture sources due within 14 days or whose page changed visibly.
3. Compare the new evidence with the previous study.
4. Update observations, scores, `capturedAt`, and `nextReviewAt`.
5. Add a short change log to the learning file.
6. Run `pnpm run refresh` to fingerprint captures, rebuild the pages, and validate the collection.
7. Inspect the rebuilt index and representative reports in both desktop and mobile viewports before sharing the collection.

## 10. Discovery loop

Keep a candidate backlog in `learnings/EXTRA-EXAMPLES.md`. Promote a candidate when it offers a pattern missing from the current library, serves a distinct audience, and is accessible enough to study honestly.

Prefer evidence from actual article pages over award galleries. Popularity is a weak proxy; fit between reader job and interface is the selection standard.

## 11. Performance evidence ladder

“Best performing” must not be inferred from visual polish. Record evidence in three separate layers:

1. **Reader outcome:** completion, engaged time, return rate, subscription, comprehension, or task success supplied by the publisher. If private analytics are unavailable, mark this layer **unknown**.
2. **Public delivery quality:** URL- or origin-level Core Web Vitals when a public field-data source has sufficient samples. Keep the date, geography, and device scope beside the number.
3. **Session diagnostics:** resource weight, request count, console failures, animation cost, and rough lab timings from the capture session. Label these as one-run diagnostics, never audience outcomes.

Awards, backlinks, social activity, and search visibility may nominate a candidate; they do not prove that the interface helps readers. Promote a pattern into the library only when the page serves its audience job well in the observed experience and the evidence layer is stated honestly.

At each 90-day review, compare the previous and current captures, note material interface changes, re-check the public delivery layer, and preserve the earlier fingerprint in version history. If publisher analytics become available, add them as a separate outcome appendix rather than retrofitting them into the heuristic score.