No Designer Should Have to Think Alone
A Figma plugin that acts as a principal-level design thinking partner — not a linter, not a fixer, but a second brain that helps designers reason better about their work.
A Theatrical Hour
Design labs at MoonPay weren't working. Designers presented because they felt they had to, not because they had hard questions. "Does this make sense? Is there anything you'd change?" Generalised questions that invited generalised answers. The feedback was surface-level — aesthetics, wording, flow. Problems that could have been solved in the canvas, independently, before anyone opened a calendar invite.
The genuinely hard problems — the subjective, strategic, ambiguous decisions that need human debate — never surfaced because easy problems consumed all the oxygen. It was a theatrical hour. Show and tell dressed up as collaboration.
People were already trying to fix this themselves — screenshotting designs and sending them to ChatGPT for feedback. But everyone was doing it independently, with different prompts, different standards. The feedback wasn't grounded in any shared knowledge, and it was limited to whatever fit in a screenshot.
Pair Design for Everyone
I'd already built a custom GPT grounded in UX principles and content rules. It changed how I made decisions — grounding gut feelings in real principles, backed by science. But it was fractured. Screenshots pasted into ChatGPT, no awareness of the canvas or the design system. It could be so much more in the tool.
I always loved paired designing — like paired programming. Thinking out loud with someone who pushes back. But it's a luxury most teams can't afford. Designers spend long stretches working alone, and when you're alone, the easy problems pile up and the hard problems fester.
Claude Code gave every engineer a senior pair programmer. I wanted to give every designer a principal-level thinking partner.
The concept crystallised into something simple: Claude is a principal-level engineer sitting with you in your codebase. This is a principal-level designer sitting with you in your canvas.
The goal was clear: not a linter, not an auditor — a thinking partner that asks the question you hadn't thought to ask, names the principle you were feeling but couldn't articulate, and pushes back when your rationale is thin.
I built the full V1 in a single session — fourteen source files, Anthropic's API with vision and tool use, a chat interface themed to Figma's design language. It produced feedback grounded in real principles. But it wasn't conversational yet, and what happened next is the part I almost got completely wrong.
But, I Built a Linter by Accident
I started building intelligence. The copilot would provide feedback — "this hidden layer should be a boolean prop" — and then offer to fix it. Rename layers, toggle visibility, add boolean properties, restructure component sets. Feedback and action in one flow. The feedback part was working. The action part was hard — so many edge cases, so many Figma API gotchas. Every one I solved felt like progress.
But I was going down rabbit holes. So many things the plugin could do, so many edge cases to handle. The bigger problem wasn't the engineering. It was the product.
Then I stopped and looked at what I'd actually built: a linter. And a linter is not going to help you become a better designer. It's going to do the work for you.
The muscle memory of setting up variants, structuring boolean props, connecting variables, building complex auto-layout components — these things take time and require thought. Passing it off to a linter makes designers technically faster, but less talented at using the tool. They stop learning. They stop understanding why the component is structured that way.
This is exactly what's happening with Claude Code and engineers who don't know how to write code well. Claude writes beautiful code for them. Some of them learn over time. Most of them won't, because Claude is doing the work. The craft atrophies.
I wanted this tool to make people smarter, not dumber. So I scrapped it. Every metric tool, every action card, every fix-it-for-you shortcut. All of it, deleted.
The Pivot: A Thinking Partner, Not a Checker
I stepped back and wrote two documents that redefined the entire direction.
The first was a knowledge stack — a four-layer architecture for what the copilot knows and how it reasons:
Layer 1 — The Eyes. What it can see from Figma. Selection, node tree, component structure, visual relationships. Already built.
Layer 2 — Universal Knowledge. What it always knows regardless of project. Visual design principles, UX laws, interaction patterns, accessibility fundamentals, content rules, flow and narrative. Baked into the system prompt and tools.
Layer 3 — Contextual Knowledge. What it knows about this team and product. Design system, brand voice, principles, product context.
Layer 4 — Taste. The hardest layer. The difference between correct and good. Opinionated. Willing to push back. Distinguishes personal preference from principled critique.
The second document was a character definition — the kind of designer I'd want reviewing my own work. Direct. Downstream-aware. Never a yes-and machine. Twelve core opinions about what makes a product designer good — from "understand what the system gives you for free before you break it" to "go back to first principles before you go anywhere near the canvas." On every interaction, the copilot runs a reasoning sequence — See, Situate, Interpret, Evaluate, Respond — and decides whether to question, observe, or give feedback based on what's most useful.
What It Sees
The custom GPT could only see screenshots. The plugin sees two representations of every selected node, and the combination is what makes it genuinely useful.
The node tree gives precision. Auto-layout direction, spacing values, padding, hierarchy depth, token bindings, component usage, layer names. This is how it catches "this button uses 14pt instead of the body token" or "there's a DSInfoBanner component that does exactly this."
A rendered screenshot gives intuition. Visual balance, crowding, hierarchy as a human perceives it. Structure alone might say "the spacing is correct" while missing that the screen feels cramped.
Neither is sufficient alone. Together, the LLM gets structural precision and visual understanding in the same request.
And it's not limited to what's selected. The plugin has awareness of the entire design file — every page, every frame, every component. Select a button on one screen and ask how it compares to the same pattern three pages over, and it knows. The custom GPT could only see what you showed it. The co-pilot sees the whole document.
What It Knows vs How It Thinks
The system prompt defines how it thinks. Character, reasoning model, question logic, seniority calibration — a full personality embedded in every request.
Tools define what it knows. Knowledge domains exposed as callable functions. The model invokes them when relevant, not every time. This means the knowledge base scales without bloating the context.
Five knowledge domains, queried on demand:
- UX principles — Hick's, Fitts's, Miller's, Jakob's, Tesler's, aesthetic-usability. As practical lenses, not academic references.
- Content design rules — the same codified ruleset from the content governance work.
- Platform conventions — iOS, Android, cross-platform. Navigation patterns, system behaviours, standard controls.
- Figma conventions — naming, component architecture, auto-layout, variables. The technical knowledge a principal Figma user carries.
- Project rules — team-specific conventions, brand voice, terminology. Configurable per-project.
The builder agent in SystemIQ uses the same knowledge tools. Same sources, two delivery mechanisms.
Teaching It to Converse
The architecture was right. The conversation quality wasn't. Getting the LLM to behave like a thinking partner took eight rounds of prompt iteration. Vague questions triggered full audits — seven observations covering every element on screen. A senior designer would ask clarifying questions first.
So I added question logic. The LLM asked questions and gave feedback in the same message. I added a hard stop. The questions appeared, but as generic templates — "What stage is this at?" Intake questions for an audit, not questions that help a designer think. Round by round: questions must come from the design, not a template. Ban process intake questions. Read the designer's answers as a prioritisation signal. Go deep, not wide. Principle citations as inline badges, not textbook name-dropping.
Same screen. Same question. Before and after eight rounds of prompt tuning:
“Before: "what do you think of this view?"”
“After: "what do you think of this view?"”
The before version produced 22 bullet points covering every element on screen — missing states, loading spinners, colour contrast, touch targets. Generic observations applicable to almost any screen. It name-dropped the Von Restorff Effect. It suggested adding haptic feedback. None of it was wrong. But none of it identified the actual problem with the design.
The after version asked three questions and within two turns had identified the core issue: the screen frames a security feature as a limitation. "Select your bank" sets an expectation of choice, then the info card contradicts it. The fix isn't a missing loading state — it's reframing the mental model entirely. That's the difference between an auditor and a thinking partner.
Everyone a Level Above
The principle underneath all of this: it makes everyone a level above where they actually are.
Juniors get coaching without relying on senior availability. Many teams, even large design teams, don't hire juniors because they can't afford the coaching time. This is that coach. Mid-levels gain confidence — they stop second-guessing, make decisions backed by principles, move faster. Seniors catch blind spots they hadn't considered, not fundamental ones.
And then there are the people who aren't product designers at all. PMs, engineers, marketers with editor seats doing "product designy things" out of necessity. Giving these people a co-pilot is like giving a designer access to Claude Code. Genuine superpowers, if it works well.
It's not a gatekeeper. The designer has final say, always. The moment a tool like this feels like a gatekeeper, people stop using it. It's a thinking partner grounded in the product they're building — the design system, the content rules, the UX principles, the platform conventions. Not just a screenshot and a prayer.
Full Circle
We systematised the components, the generation, the sync, the content. The last thing left was the thinking.
- The design system — systematised structure into code
- The builder — made the system accessible through conversation
- The bridge — made the system bidirectional between code and Figma
- The content rules — systematised the words
- The co-pilot — systematised the thinking
Each one asked the same question: is this knowledge that should live in a person's head, or in a system?
The answer was always the same. Put the repeatable expertise in the system. Free the people for the work that only people can do. Design critique that's actually about hard problems. Reviews where the easy stuff is already handled. Conversations that start at a higher altitude because no one had to spend twenty minutes on spacing.
The co-pilot doesn't replace the designer. It raises the floor so the ceiling is the only thing left to worry about.
Systematise expertise. Democratise access. Keep teams lean.