Doğan Kutbay
Home
Back · Recent wins

Home Recent wins Inside my design factory

AI-assisted design · Figma systems

Inside my design factory

A brief goes in. A reviewed Figma file comes out. Between them sit focused workers, strict checks, and a long memory for old mistakes.

47

specialist roles

26

reusable pipelines

20

guardrail hooks

22

rule files

~250

memory notes

154

logged incidents

Why I built it

AI can make a nice-looking screen very quickly. Then it can ignore the design system, forget an error state, and invent a button nobody can build.

I built a pipeline to stop that. Small workers handle separate jobs. Other workers review them. Scripts block bad changes before they reach Figma. Every useful failure becomes a note, and repeated failures become rules.

It grew into 47 specialist roles, 26 reusable pipelines, 20 guardrail hooks, 22 rule files, around 250 memory notes, and 154 logged incidents. This page explains how the pieces work together.

The goal is not to replace a design team. It is to remove repeated work, keep the boring rules honest, and give designers a better starting point.

Design workflow moving from a written brief through flow mapping, Figma building, independent review, quality checks, handoff, and a memory loop
The picture is the short version. The actual pipeline below includes the stops, reviews, and boring checks that make it useful.

The parts

Mostly text files and lessons

Nothing magical here. Claude Code runs it, but the useful part is the structure around the model. Each piece has one job.

47 roles

Workers

Each worker has one narrow job: map the flow, prepare a screen, review the result, check quality, or write the handoff.

26 pipelines

Recipes

A pipeline decides who runs, in which order, what each worker receives, and what must be true before the next step starts.

22 files

Rules

The house rules are plain text. Use real components. Bind colors to tokens. Do not invent a font because it looks nice today.

20 hooks

Guardrails

Small scripts inspect actions before and after they happen. Some warn. Some stop the work completely until the problem is fixed.

~250 notes

Memory

When something breaks, we write down the useful part. Workers read the relevant notes before they start another job.

Real tools

Connections

Figma is where it builds. The browser checks prototypes. Amplitude brings product data. Memory search brings old lessons back.

One real run

A brief moves through seven stops

One role builds. Another role checks. The pipeline moves only when the work passes the gate. Trusting a worker that says “done” did not go very well, so now we read the result back.

  1. 01

    Map the flow

    builder

    The UX worker lists every screen and state, including empty, loading, error, and the other boring ones people forget.

  2. G1

    Check the coverage

    gate

    Every requirement needs a place in the flow. If something is missing, the job stops here.

  3. 02

    Split the work

    builder

    The lead role turns each screen into a small build brief with the right components, layout, and words.

  4. 03

    Build in Figma

    builder

    The UI worker uses real design-system components and binds the correct tokens. No fake button made from a rectangle and hope.

  5. 04

    Review it

    reviewer

    A separate role checks hierarchy, spacing, copy, states, and touch targets. The builder does not approve its own work.

  6. G2

    Run quality control

    gate

    Hardcoded colors, missing text styles, and homemade copies of existing components are blockers. The pipeline does not politely ignore them.

  7. 05

    Write the handoff

    builder

    The last step prepares specs, explains the happy path in normal language, and gives engineering the decisions behind the screen.

The guardrails

The AI does not get the last word

A clever prompt helps once. A rule helps every run. These three ideas made the largest difference.

Block the bad change early

A hook checks a Figma write before it happens. Wrong token or fake component? The change is refused, with a reason.

The builder is not the judge

Building and reviewing are separate jobs. The reviewer has no reason to defend the work and can be properly annoying.

A repeated failure becomes a rule

One mistake becomes a note. The same mistake again means the system needs a stronger rule or an automatic check.

“Run degraded” is not a diagnosis. Name the failure, fix it, then write the rule that stops it coming back.

The memory

A mistake should be useful at least once

The system keeps short Markdown notes for each product. Seventeen real products use it, but their local lessons stay separate. Only a lesson that really applies everywhere becomes a shared rule.

  1. 01

    Before work, read the notes for this product and search for anything close to the new task.

  2. 02

    During work, write down a new problem while the details are still fresh.

  3. 03

    After the run, classify what failed and add it to the incident log.

  4. 04

    When a problem repeats, promote the note into a rule or a hook.

The connections

One output feeds the next job

The design scan, tokens, prototypes, handoff, and campaign work do not live in separate little worlds. They reuse the same source.

Scan design system
Export tokens
Build prototype
Design from brief
Prepare handoff
Audit quality
Build brand rules
Generate graphics
Create campaign work

Start smaller

You do not need 47 workers

Mine grew because real work kept finding new ways to break it. A useful first version is much smaller.

  1. 1

    Pick one boring job you already repeat. Give it one clear input and one clear output.

  2. 2

    Write down the rules you keep correcting by hand.

  3. 3

    Let one pass build and a different pass review.

  4. 4

    Add one script that blocks the worst mistake automatically.

  5. 5

    Keep a failure log. When the same thing breaks twice, improve the system.