Email Design System
Standing On Google's Shoulders
A commission for the system behind the screens, not the screens:
Here is what I want to do for design- I want to be SMART about how we do it. Look at ALL our design tools- the Five Lenses, the Design Plans, how the design plans tie into the Campaign/Projects/Run Books systems, all our framing, and KPs, and CXs- I want you to look at the work we have already done with our Calendar and Contacts Apps- we have done extensive work on the UIs for both of those- but I also want you to look at Gmail- we do not need to reinvent anything- Google has done a good job of figuring out SO much for us. Obviously we are not stealing code or anything like that, but we can take models and patterns and ideas for how to handle email- we will use all of those that we find- it's like panning for gold on Gmail- and we will use them as a kicking off point for our own design. We will climb up on the shoulders of Google and start from there. They won't even know we are standing there.
Please RCR on that. At the end of the RCR, write up a first-version plan for what you come around to for how we can build our email app's UI- tell me what it looks like and how we can build it- not so much how the email app will look like, but how the DESIGN SYSTEM for the email app will look like. That is how I want to make this thing- like the system it is. Blocks, blocks of blocks, blocks of blocks of blocks, Block^N. 4C, FWW(C). Grocery Stores. Barcelona's city grid design. No black boxing, and have everyone get involved- all 16 members plus Crux. No compression either- I want everyone to fully contribute. I want Margaux and Renata on lead. You have all the context you need in this session, so, again, don't compress anything. Load up heavy with CX and KX and SX and run a good Kaleidoscope, with an additional Steep hit of molly and LSD. Compose in some of our Great Speakers lenses, including mine, because I want you to be brutally pragmatic about how we can actually build something that is useful. Make sure you look up all the things here so you are fully in compliance. Make this beautiful, find the Simplicity Yield and ride it all the way through to the perfect solution space.
Run a hand off here and now and then, after the hand off, pick this work right up, so stage a good solid to-spec hand off and Ignition Block. Again, make sure both are fully to-spec.
— Shea Gunther · operator drop, 10.2006
The operator is emphatic about the level: he wants the design system, not the layout — the machinery that will produce consistent screens, built like the system it is. And the method is stated plainly: study Gmail for patterns and ideas (never code), stand on that work, and build up.
The operator wants to be smart about design — so he asks not for email screens but for the design system that will generate them. He points at all the design machinery the project already has, at the UI work already done for the Calendar and Contacts apps, and at Gmail: study what Google figured out, take the models and patterns (explicitly not the code), and use them as a starting point. “We will climb up on the shoulders of Google and start from there. They won't even know we are standing there.”
The tell is the insistence on level. Twice he distinguishes the design system from the screens: “not so much how the email app will look ... but how the DESIGN SYSTEM for the email app will look.” That is the operator's characteristic move — build the thing that builds the thing — stated as blocks of blocks of blocks, and closed with a request to hand the work off cleanly and then immediately resume it, so the plan survives the seam between sessions.
The wider frameBuild the thing that builds the thing: a design system, not a screen — panned from Gmail's patterns and stacked up as blocks of blocks of blocks.
“how the DESIGN SYSTEM for the email app will look” — The level — stated twice, on purpose: the system that generates screens, not the screens. The operator's build-the-builder move.
“it's like panning for gold on Gmail ... we are not stealing code” — The method and its boundary — study the patterns and models, reuse ideas, never the code. Stand on the prior art openly.
“Blocks, blocks of blocks, blocks of blocks of blocks, Block^N” — The substrate — the design expressed as named blocks that compose, scaled as wide as the system needs.
“Run a hand off here and now and then ... pick this work right up” — The continuity request — a to-spec handoff and Ignition Block so the plan crosses the session boundary intact.
The prompt is written in the working vocabulary of the methodology. Here is what the shorthand means:
- Five Lenses
- The methodology's generative design instrument — five sequential lenses run over a design surface before anything is drawn.
- CX
- The context-exchange reflex — gather what a task needs across the trust ladder (byte-truth first) before a load-bearing move.
- KX
- A provisioning reflex: pull in the specific Knowledge Packs a task needs before starting, so the work rests on the right domain grounding.
- SX
- The spec-checking reflex — fetch a thing's own operative spec and run from it, rather than from memory.
- Kaleidoscope
- A vantage-assembly move that hands the board several deliberately different standpoints to reason from — a way into creative headspace before hard design work.
- Steep
- A Loop MMT convention: a named instruction to shift the instance into a looser, more associative thinking mode before converging. The operator expresses it in his own voice through a sensory metaphor; it is a request for a register, not a literal act — the same kind of internal control word as RCR or Kaleidoscope, and it is disclosed here for exactly that reason.
- Block^N
- Scaling the Block Principle across many parallel items at once — the same named-blocks-and-joints discipline applied N-wide.
- FWW(C)
- “Fun, Whimsy, and Weird (and Chaos)” — the methodology's rule that play and surprise are load-bearing, not decoration.
- Great Speakers
- A lens family that reasons a problem the way a specific great thinker would — composed in to sharpen a particular kind of rigor.
- Simplicity Yield
- The methodology's term for the compression at the end of thinking — the point where a storm of input resolves into one clean idea.
- Crux
- The Dev Crew's first-pass line-finder — the named hand who reads a problem's line and finds its crux move, as distinct from the advisory board.
- Ignition Block
- The copy-pasteable primer at the end of a handoff that launches the next session already aimed at the right thread.