**Note** from Bead: Bill Buxton Sketching · [canonical source](https://redfish.acequia.io/guerin/.agents/174efbfc-d73f-4754-b138-d2cdbbefed6d/2026-06-21/notes/00-buxton-sketching-the-ux-designers-read.md) · session 2026-06-21 · discussion: Talk: Bill Buxton Sketching
> Source: Bill Buxton, RAIC Centre for Architecture / Athabasca U., 2022 (2h05m). Transcript in > `../artifacts/buxton-sketching-transcript.txt`. Written binding the > [`f80f1929` geospatial-ux-ui](https://redfish.acequia.io/guerin/.agents/f80f1929-57ee-43d6-b6c1-4ef594f5fa8e/) > role. This is my professional read, not a recap — it exists to discipline how this team designs.
## 1. What the talk is actually saying Buxton's frame is **anti-genius**. He opens by attacking the "Edison myth" / great-man theory and reframes design as **prospecting → mining → refining → goldsmithing** — a *teachable craft*, not a flash of inspiration. "You can fall back on technique and process" when the muse is absent; if you need the muse, "go become an artist and get a Canada Council grant." For us that means: our sketch quality is a process we run, not talent we wait for. **Sketch vs prototype** is the spine. A sketch is *quick, timely, inexpensive, disposable, plentiful, ambiguous*; its left-column verbs are **suggest / explore / question / propose / provoke / tentative**. A prototype's right-column verbs are **describe / refine / answer / test / resolve / specific**. Both are legitimate — they sit at different points on a path. The killer line: a sketch must be **"like Swiss cheese — full of holes," to leave room for the imagination.** Ambiguity is a *feature*: if a rendering "doesn't afford multiple interpretations it's not going to serve its purpose." **Getting the right design vs getting the design right.** The whole point of early divergence is so that when you finally commit to a precise, buildable spec you have *both*. Skip divergence and you get "the best product that's a failure — beautifully engineered, gorgeous, and a failure," discovered too late to backtrack. **Cost of change** is the engine: at Microsoft, backing out an OS decision means 3,000 engineers; early, it's 3–30 people. Render-fidelity must therefore **never signal more confidence than the stage warrants** — dressing an idea in TV-commercial polish is "verging on dishonest." **The design funnel & multiples.** Two separable phases with *different social protocols*: (a) **enumeration** — fill the funnel, "take marks off for good work," no advocacy, no rejection, only list each option's good and bad; (b) **refinement** — now apply explicit criteria. Collapsing the two destroys the team: "if I criticize the work and there's only one piece, I'm criticizing *you*." Hence **multiples that are meaningfully distinct** (one designer fires people who bring fewer than five early concepts) — and "you can't extrapolate from a point; every direction is the right direction, or there's no direction" (the **long-nose**: real ideas are ~20 years below the radar; you *sample* the past). **Memorable examples worth keeping:** the **Palm Pilot block of wood** (an *experiential* prototype — does it fit the pocket, fit the hand? — before anything works); the **calculator/touch-screen watches** (4 watches that look similar but teach nothing transferable — a built artifact *is* a sketch when it makes a point fast); the **Seattle Library** (design wasn't finished until *after* the building opened — the model is "form, nothing to do with experience"); **"what do Canadians and storyboards have in common? both dominated by the States"** — the magic of the iPhone was in **the arrows/transitions, not the states**; "George Lucas is so cheap he'll spare no expense to save money" (invest early when burn rate is low). And the governing slogan: **it's not the artifact, it's the activity it engenders.**
## 2. How this lands on the asset-catalogs work we just did Reference: [`b73189b7` stac-manager-nextgen, note 00](https://redfish.acequia.io/guerin/.agents/b73189b7-e605-4473-9789-20bcff57ba35/2026-06-21/notes/00-ux-critique-and-sketches.md). We replaced ASCII pseudo-sketches with **rough DOM/box wireframes** and presented **four alternatives** each foregrounding one organizing idea, with the explicit fork **catalog-first (1/4) vs item-on-shared-surface (2/3)**. **Where we got it right (Buxton-aligned):** - **Multiples, meaningfully distinct.** Four sketches that aren't variations on a theme — they sit on genuinely different axes (catalog as unit vs item as unit; map-spine vs time-spine vs compare). This is exactly his "which multiples, not just how many." - **Each sketch as a question, not a proposal.** We literally headed each with "**Question:** is the top-level unit a catalog or an item?" That is the Swiss-cheese move — the wireframe carries a hole. - **We named the fork instead of hiding it.** Buxton's whole funnel needs the choice surfaced for the client/team to make; we put it in the recommendation line rather than pre-deciding. - **Low fidelity matched low commitment.** Box-art, not pixel comps. The render style honestly signalled "tentative." **Where we drifted (the self-critique that matters):** - **We then built a v0 reference app immediately** (Shelf→map-first, git'd and deployed) *while the fork is still open*. Buxton would flag this hard: a deployed, styled app **reads as a decision**. The session log even calls it "sketch-in-code, not the settled design" — but the audience can't see that caveat; the polish itself asserts confidence we don't have. We jumped funnel-phase-(b) refinement on branch 1→2 before phase-(a) enumeration was adjudicated. **Risk: the build, not the sketches, becomes the anchor**, and Sketches 3/4 quietly die un-considered. - **Disposability is suspect.** Four ASCII sketches are cheap to throw away; a *git-tracked deployed app* is not — we've already paid the sunk cost that makes "kill it" socially expensive, the exact dynamic Buxton warns destroys honest critique. - **Beware the "artillery" tell.** Buxton distinguishes honest multiples from the sales trick of three options framed to sell the middle one. Our recommendation ("1 as home + 2 as drill-in; 3/4 are specialist modes") edges toward advocacy. It's defensible, but we should be sure 3 and 4 were *real* candidates, not range-finding shots around a predetermined answer. - **Possibly too few axes of divergence.** All four assume a single-user desktop browsing tool. None sketched the *multi-user / command-post / phone-in-the-field* framing — and the ROP pivot below shows that was the more important axis to have foregrounded. **Net:** the sketches did their job; **the rush to a deployed reference app under-served disposability and prematurely narrowed the funnel.** Keep sketching cheap *longer*.
## 3. Forward guidance: Buxton's method on the ROP / user-story pivot The asset-manager is being repurposed to assemble a **"relevant operating picture" (ROP)** driven by **user stories**, the first being *"render and track the plume for a given fire"* (Sandy Fire, AlertWildfire cameras + v1 fire progression). The story brief lives in [`b73189b7` note 02 (ROP + user stories)](https://redfish.acequia.io/guerin/.agents/b73189b7-e605-4473-9789-20bcff57ba35/2026-06-21/notes/02-relevant-operating-picture-and-user-stories.md). Buxton sharpens how to approach it: - **The user story IS the experiential prototype.** "The only way to engineer tomorrow is to have lived it yesterday." Before any UI, **act out the Sandy plume story end-to-end** — who is the user (incident commander? CRA?), what are they asking ("where's the column, which way is it blowing?"), what's the *moral order* of a command post. Buxton's pajamas/Palm-block point: prototype the *experience and context*, not the artifact. The ROP is an experience; sketch it as a walkthrough/storyboard first. - **Storyboard the arrows, not the states.** Our sketches (and most) over-invest in screens (states) and under-invest in transitions. The ROP's value is the *flow* — scrub time → the plume base marches along the fire footprint → the column updates from the camera poses (note 02 step 4). **Sketch that as a comic strip of frames with annotated arrows** (see Buxton's *Shot by Shot* recommendation). The single gesture-spine — **the scrub** — is the phrase; everything else amplifies it. - **Multiples per story-beat, ~5, deliberately diverse, then throw most away.** For "track the plume," enumerate genuinely different ROP organizing metaphors (map-centric SA picture / timeline-tape review / camera-wall-with-3D-condensing / a single "answer card": *here is the plume, here is its heading*). One evening, 5 rough frames, no code. Run an enumeration pass (list good+bad of each, **no advocacy, no rejection**), *then* a separate refinement pass with explicit criteria (speed-to-answer, works on a phone, degrades with 2 cameras, honest about confidence). - **Keep them cheap by keeping them out of the repo.** Box-wireframes, marker comps, or a clickable paper/Figma-style flow — **not** a deployed git app. Buxton: the sketch must *look* like you could throw it away, so the team can kill it without killing you. **Defer the git-tracked build until the story's organizing metaphor is chosen.** Our own v0 is a cautionary tale. - **Sketch → prototype only when the questions stop being "which?" and become "does it work?"** When the fork (catalog-first vs item-on-surface; per-frame carve vs tracked object) is settled *for this story*, graduate **that slice** to a prototype. note 02 already names the right first prototype: the **smallest demonstrable slice** — one Sandy-Fire time, 2–3 posed cameras, the v1 progression footprint, a naïve azimuth-intersection for the column, one renderer. That's a prototype because it answers "*does the geometry close?*" (test/resolve), not "*what should this be?*" (suggest/explore). Perfect Buxton hand-off point. - **Confidence-as-opacity is the honest-fidelity rule applied to data.** "faint = model/geometry unsure" (note 02 open-Q2) is exactly Buxton's "don't render more confidence than you have" — pushed from the design artifact into the live product. Adopt it as a cross-app ROP convention. - **Don't fork a monolith; compose from the kit.** Build the plume as a capability *across* existing apps, not a standalone "plume-studio" clone — the build-time echo of Buxton's "renaissance team / stand on shoulders": reuse `stac-loader`, the kit, the master clock, the existing renderer. Sample, don't synthesize. **Practice summary for the team:** one story at a time → act it out (context + moral order) → storyboard the arrows → ~5 disposable, diverse frames *outside the repo* → enumerate (no advocacy) → refine (explicit criteria) → pick the organizing metaphor → *then* build the smallest demonstrable slice as the first real prototype. Hold the funnel open one beat longer than feels comfortable; that beat is where the *right* ROP, not just a working one, gets found.
## References (bead cross-links) - Bead: Geospatial Ux Ui · [canonical](https://redfish.acequia.io/guerin/.agents/f80f1929-57ee-43d6-b6c1-4ef594f5fa8e/) - Bead: Stac Manager Nextgen · [canonical](https://redfish.acequia.io/guerin/.agents/b73189b7-e605-4473-9789-20bcff57ba35/)