How one designer runs an AI operating model

The website is not the product. The loop is.

This site is the visible part of a loop. Learn how the market speaks. Use that language to build the site. Use the site to attract people. Observe what they do. Learn, and adjust.

Today the loop runs on research and user interviews. Analytics is in place, but traffic is still too low to teach me anything. The loop closes for real when distribution starts.

Scale started with a spreadsheet

For years my career lived in slides, CVs and memory. Each telling was a little different. Nothing could be built on it.

Scale started the day my whole career fit in one spreadsheet: 18 engagements, 30 claims, 13 cases. Each claim is written twice, once in buyer words and once in recruiter words. Each figure lives in one cell, so it cannot get misaligned between pages or between languages. The site is generated from this sheet. I never edit a case-study page by hand. The workbook then became the seed of everything that followed. I always knew structure shapes surface; I have case studies about it. Working alone, at the scale of one person, I could see it directly on my own site.

Engineers will recognize the move. The finite element method takes a structure too complex to solve whole, cuts it into small elements, defines each element and its interfaces, then assembles them and solves the system. The workbook does the same with a career: engagements, claims and cases are the elements; their IDs are the interfaces; the generator assembles; the build solves. Without this spreadsheet-like clarity, engineering a workflow is almost impossible. You cannot automate what you cannot name.

Decide who does what

The oldest question in human-automation work is not “can a machine do this?” It is “who should?” Paul Fitts listed what people do better and what machines do better in 1951. Sheridan and Verplank described levels of automation in 1978. NASA’s Human Systems Integration practice calls this function allocation. I call this way of working calibrated collaboration: each function goes to whoever does it best, and trust follows the record.

My version is a small matrix with three columns:

Function	Who	Why
Meaning, positioning, taste, final decisions	Me	Judgment is the asset the site exists to sell
Research, drafts, implementation, investigation	AI	Fast, tireless, and checkable
Invariants: bilingual parity, client anonymity, link rules	Script	A fact a script enforces cannot get misaligned

The last row matters most. The rule is: if a script can enforce a fact, enforce it; write prose only for what cannot be enforced. Eight weeks of evidence back it. The bilingual system, checked by a script, did not get misaligned once. Prose descriptions of the stack got misaligned eleven times.

The goal is calibrated trust: trust in the AI that matches its record, task by task. Human-factors research calls this appropriate reliance (Lee and See, 2004). Too much trust ships errors. Too little wastes the tool.

Diagrams as an alignment layer

Words leave room for two readings. A diagram leaves less. I use diagrams to align the AI with me, and to align one AI session with the next, because each new session starts with no memory of the last. Current guidance points the same way: rich references, such as HTML mockups, often beat written descriptions (Claude, 2026). The Shape of Work, my notation, is this idea pushed further: a visual grammar for work itself.

Information management is the real craft

The hard problems were not visual. They were about where truth lives.

• Memory gets misaligned with reality. Notes describe the code; the code changes; the notes do not. When they disagree, the code wins, and the notes are fixed.
• Static versus dynamic. Rules are timeless and enforced. Preferences are current and expected to change. They live in separate sections so a taste never hardens into an architecture.
• Source to context. Information flows one way: workbook → data mirror → generator → pages. For the AI: rulebook → decision log → subsystem docs → code. Each layer is read in that order, and reading stops when the task has what it needs.
• Three stores, three jobs. The repository holds how and why. The project space holds thinking in progress. Memory holds only where we are.

I enjoy this part. It is a design problem with no screen.

From mockups to the repository

Until January 2026 I designed in Figma and built on Wix. In February I moved to code. Today I deliver directly to the repository, build my own graphic tools, and steer the project from a cockpit I built.

Tool	What it does	Status
The Shape of Design	Generates the diagrams for my design courses	In use
The Shape of Work	Notation and plotting tool for work as a system	In progress
Copy Monitor	Plans copy changes before they reach the code	In use
Project cockpit	A spreadsheet that steers the project at a glance	In use

What this means for a team

Most teams adopted AI tools without changing how work is organized. The tools are not the hard part. Naming the elements, allocating the functions and checking the invariants are the hard part. That is the work I am now offering to clients.

References

• Fitts, P. M. (Ed.) (1951). Human engineering for an effective air-navigation and traffic-control system. National Research Council.
• Sheridan, T. B., & Verplank, W. L. (1978). Human and computer control of undersea teleoperators. MIT Man-Machine Systems Laboratory.
• Lee, J. D., & See, K. A. (2004). Trust in automation: Designing for appropriate reliance. Human Factors, 46(1), 50–80.