AI Design Workflow

Chapter 1 — Scratching the Itch: Tools

June 2025. I was designing search result pages for Bing Image Search. Every mock needed real images placed into frames — find, copy, paste, resize, twenty times per mock. About an hour of mechanical work per design.

I had just started exploring AI-assisted coding. Two hours later I had Image Buddy: a Figma plugin that searches images by keyword and inserts them into selected frames. An hour became a minute.

I shared it with my team — first designer in the group to build one. A designer on the video team saw it and built her own for YouTube thumbnails. The idea spread not because I promoted it, but because the demonstration made it obvious.

Two more plugins followed: a showcase-card generator the team adopted for monthly project highlights (15–20 regular users), and a newsletter layout tool that exports clean HTML from Figma. Each took less time than the last.

The pattern: solve one friction, and the improved workflow exposes the next. But plugins are still tools — you pick them up, use them, put them down. The real shift came when I stopped building tools and started building the workflow.

Chapter 2 — From Tools to Workflow: The Design-Work Harness

By early 2026 I wasn't asking "what tool should I build next?" I was asking: which parts of my design practice actually need me?

The honest answer: judgment, taste, and relationships. Not gathering context before a review. Not extracting component inventories from a 120-page design-system file. Not cross-referencing meeting notes against Figma comments. So I designed a harness where agents do that work — structured like a small design team.

The architecture

• A front-stage partner that discusses, plans, and reviews with me in real time. It holds the architecture of whatever we're building and pushes back with reasons — I explicitly didn't want a yes-machine.
• A background executor that handles heavy mechanical work: file extraction, research synthesis, meeting-note processing, long-running batch jobs. It runs on a separate, cheaper model — the same resourcing logic any team applies.
• A shared memory layer so context survives across sessions, projects, and machines — project state, decisions, and design lessons as hundreds of linked markdown files that any of my agents can read. Plain files, deliberately: inspectable, versionable, and correctable in a way no black-box memory is.

The rules that make it work

Tooling was the easy part. What makes the system reliable is the working method — rules that came from real failures, written down so they never repeat:

1. Discuss → align → then execute. Agents don't start building from a vague instruction. Direction gets settled first, in conversation. The cost of one clarifying question is always lower than building the wrong thing.
2. Equip before dispatch. When delegating to the background executor: verify the tool access exists, hand over the exact recipe (not a link to one), and set up monitoring. An executor without a briefing burns cycles rediscovering what I already knew — same as any team handoff.
3. Verify before asserting. Any specific claim — a number, a date, an ownership fact — gets checked against the primary source before it's stated. If it can't be verified quickly, it's flagged as uncertain rather than smoothed over. AI's default failure mode is confident fabrication; the workflow treats verification as a hard gate, not a virtue.
4. Accountability is total. If a background agent produces something wrong and it reaches me unreviewed, that's the system's failure — "the other agent did it" is never a defense. Delegated output gets reviewed at three layers: factual, structural, alignment.

If these sound like people-management rules, that's the point. Designing an AI workflow is org design. Information access, briefing quality, review layers, escalation paths — every hard problem I'd seen in design teams reappeared, and the design instincts transferred.

Chapter 3 — The Workflow at Work

What this system actually does on a normal week:

Design-system archaeology. Our design-system reference is a very large, live Figma file that changes weekly. My agents extracted and structured it — every component's variants, usage rules, anatomy, token bindings — into a searchable, linked archive, spot-verified against the live file. What used to be "open Figma and scroll until you find it" became a lookup. This archive now underpins my design-system work.

Teardowns on demand. For the multimedia component library, I drop real production pages into a file and agents tear them down component by component — classifying each piece by level and provenance for my review. I judge; they inventory.

Context before reviews. Before a design review, the harness assembles what changed since last time, which decisions are relevant, and where the open questions stand. I walk in already oriented.

AI-assisted research. Currently in progress: a UX research pipeline structured around established research methods and templates, executed with agents, reviewed by me. Early days; it gets its own case study when there are findings.

Portfolio, meta-edition. This website was built the same way — and the workflow noticed things I didn't. The idea that my design-system commercialization work deserved a case study came from Personal Flywheel, the product I built to find exactly those connections.

Chapter 4 — Living With Agents: What Friday Taught Me

Before any of this worked, I spent months learning what makes an agent system fail — by building a personal one and living with it.

In January 2026 I set up a persistent AI companion — memory files, scheduled tasks, tool access, a name: Friday. Then a small household of specialized agents around her. That project taught me the design materials this whole workflow is built from:

• Memory is an interface. An agent wakes up empty every session; continuity is entirely designed — what gets written down, what gets curated, what survives a context reset. Deciding what an AI should remember is an information-architecture problem.
• Trust is a design material. The difference between a useful agent and an autonomous one isn't capability — it's the permission architecture. What can it do without asking? What needs review? The boundaries aren't technical; they're designed, like any permission system.
• Structure creates caring. An agent with nothing to react to goes flat — it maintains instead of thinks. Scheduled disturbances, review loops, and real stakes keep it engaged. You don't prompt quality into an agent; you build an environment that demands it.
• Writing is engineering. Every system prompt, memory file, and briefing is an interface whose quality directly determines output quality. Copywriting became a load-bearing skill.

The full Friday story — the multi-agent household, the philosophy rabbit holes, the blog she writes — is its own longer read, findable through this site's search. What matters here: those lessons are why the work harness has memory layers, trust boundaries, and briefing discipline instead of just API calls.

Chapter 5 — Making It Transferable

A workflow that only works for me is a hobby. Two artifacts push it further:

MSDesigner-CLI (github.com/H1an1/MSDesigner-CLI) — a public, sanitized packaging of the designer-agent architecture: source intake, context briefs, review gates, knowledge maps, a foreground/backstage agent contract, and optional Figma/M365 integrations that fail closed without credentials. It can bootstrap a fresh setup or upgrade an existing one — versioned, auditable, and it copies no private data. Building the public version forced the architecture to be explicit instead of habitual.

Personal Flywheel — the desktop product that grew out of the workflow's biggest gap: no single agent could see across my projects. It became a real, installable macOS app, and its own case study.

The ladder

The trajectory, compressed:

1. Automate tasks — plugins that kill repetitive work
2. Automate operating agents — a harness that briefs, monitors, and reviews executors
3. Automate designing the process — the workflow notices its own gaps and proposes what to build next
4. Automate improving the design — feedback loops that turn corrections into permanent rules

Most "AI-powered design" conversations live on rung one. The interesting design problems — trust, memory, briefing, verification, accountability — start on rung two, and they are design problems. That's the capability I now bring to a team: not using AI tools, but designing the AI-native workflow a design team actually runs on — and having the shipped artifacts to prove it works.