ExecutionNew·Falk Gottlob··8 min read

Figma's Agent Made Three Prototypes From 'Surprise Me.' Kill the Brief. Write the Rubric First.

Figma's workflow lab briefs its agent with 'surprise me,' picks the option the designer likes, and writes the spec last. Write the rubric before the prompt.

DesignFigmaFigma agentcode layersMari Kongprototypingdesign rubricDesign Operating ModelLoredana CrisantournamentKill List
Helpful?

Execution Falkster cover on teal: three cream phone screens in a row, a cream speech bubble above the middle one struck through by a bold orange diagonal line, and a small cream card with three short navy lines beside each phone.

Figma's workflow lab this week is a good demo of code layers and the Figma agent, and it is also the clearest picture yet of the step design still owns, because the workflow skips it. This is a Kill List entry.

The short version

Mari Kong's November 4 workflow lab shows a designer cloning an app's repo onto the Figma canvas as a code layer, prompting the agent for three variations of a delivery-address button with the first an omnisearch field and "surprise me with the other two," clicking through address search, map-based selection, and saved-address shortcuts side by side, and, after some exploration, deciding they are happy with the omnisearch option. Then the craft: a heading's font size, a label's spacing, the button renamed "Choose delivery address," a teammate's grid view merged in by prompt, and at the end a prompt asking the agent to describe the changes and flag what needs a developer, which the post calls the technical spec. The spec is the last artifact and it describes what was already chosen. The pick is where the judgment was, and it is the one step with nothing written down. The Design Operating Model's rule is that the rubric is the spec, the only form of taste that executes when you are not in the room, written by extraction from thirty real outputs and scored pass or fail with severity. One of the three options cannot be settled on a canvas at all: saved-address shortcuts win or lose on the share of orders that go to a repeat address, which the order data has and the side-by-side does not. Kill "surprise me" as the brief and "happy with" as the pick. Three lines per variation before the prompt, the score beside each code layer, and the spec opened first.

What the workflow does

The lab follows a designer adding a button to a fictional marketplace app called Pickup: select a delivery address from the map view. Code layers moved to open beta the same day, and the post is the pitch for them, the shared canvas where teammates compare working prototypes side by side instead of mailing links from separate vibe coding tools.

The steps, as Figma published them. Clone the Pickup repo from a connected GitHub account into a code layer. Select the layer and prompt: make three variations of this and add a new delivery button to the map page, the first one an omnisearch address field, but surprise me with the other two. The agent returns three interactive layers: an address search field, map-based selection by moving the map, and saved-address shortcuts with a current-location option. The designer clicks through each. Teammates can try them and comment on the canvas.

After some exploration, the designer decides they are happy with the omnisearch option.

Then the craft, which the post does well. Duplicate the layer to keep the original. Open the code editor, bump a banner heading's font size by hand rather than by prompt, because the designer already knows the tweak. Extract designs to turn the product card into editable layers and add space around the Delivery options label. Record the flow, see the screens laid out, and rename the button to "Choose delivery address" so users know what to expect before clicking. Update the code layer. Merge a teammate's grid view, which clusters nearby items on the map, by selecting both layers and prompting for a combined one.

And last: a prompt asking the agent to describe the changes in the combined layer against the original and flag anything with implementation implications a developer should review. The post calls the result the technical spec, and the path to production runs from there to a branch or a pull request.

The step with nothing written down

Read the pick again. Three working prototypes, side by side, in the same shared space, with comments. And the record of why one of them won is "happy with."

That is the step design owns, and the workflow spends it in a clause. Everything after it is craft on a decision already made, and the spec, which is where the decision should live, arrives at the end describing the output. 17x the Code, 1.3x the Releases. Design's Job Is the Spec Now. was about Figma shipping a spec editor for agents while its design chief reported, as TechCrunch carried it, 17x more code and 1.3x more releases. Generation stopped being the bottleneck. Deciding what is good enough to ship is the bottleneck, and it has always been design's. The workflow lab is that argument in one sample flow: the agent made the three options in one prompt, and the only human decision in the piece has no artifact.

The Design Operating Model's chapter The Rubric Is the Spec has the rule I run instead. A rubric is the only form of taste that executes when you are not in the room. You do not write it from first principles on a good afternoon, because that rubric comes out with clarity, consistency, and delight on it, scores everything a 4 out of 5 forever, and stops being opened. You write it by extraction: grade thirty real outputs on gut feel, one sentence each, find the phrases that repeat in your own reasoning, keep only the dimensions where failing costs something. Then score pass or fail with a severity, because given a five-point scale two reviewers both write 3 for different reasons and leave the room believing they agreed, which is worse than no score.

For a variation brief, that compresses to three lines per option, written before the prompt. What it must never do. What a failure costs the user. And the one data question the canvas cannot answer.

The question the canvas cannot answer

That third line is the one the workflow cannot produce, because the canvas does not have the data.

Stop Picking Winners. Design the Tournament. is the portfolio exercise for cheap prototyping, and its third question is which ideas cannot be settled by a prototype at all. The address-entry choice is one of them. Saved-address shortcuts, option three, win or lose on the share of orders that go to a repeat address. If most orders go home, the shortcut is the whole feature and the search field is the fallback. If the app is mostly first-time addresses, the shortcut is a dead button. The order data has that share. Three code layers side by side do not, and no amount of clicking through them will produce it.

So the pick in the workflow lab was made without the number that decides it, and the spec written afterwards cannot contain it either, because the spec was asked to describe changes, not to say what good was.

The Kill List entry

Kill "surprise me" as the brief. Kill "happy with" as the pick.

Keep everything else. The three variations in one prompt, the side-by-side, the duplicate-and-refine, the teammate's layer merged in, the extract-and-edit. Code layers are a good tool, and the lab is a good demo of it.

The replacement is three moves, all on the canvas the lab already uses.

Before the prompt, three lines per variation: never, cost, and the data question. They can be written in a minute if the rubric exists, and the rubric exists if the thirty-output afternoon has happened.

Beside each code layer, the score. Pass or fail per line, with the severity, as a comment on the frame, so the pick has the same visibility as the prototypes it chose between and the teammate who disagrees has something to disagree with.

The spec first, not last. Open it before the prompt, carrying the three lines. Then the agent's end-of-flow document, the description of changes with the developer flags, becomes a diff against the spec. That is what a spec is for. Writing it last turns it into a changelog.

This is the AI Product Management thesis at the canvas: the cost of making the three options collapsed, and the part nobody trained for is saying in writing which one was good and why. Scoring Your Own Work(coming Nov 18) is the chapter on who holds the pen.

This week, if your team has turned on code layers: before anyone types "surprise me," write the three lines for the feature you are about to brief, and find the one number the canvas cannot show you. Put both on the canvas before the prompt.

Related answer: Should you brief a design agent with 'surprise me' and pick the variation you like?

Sources: Mari Kong, "Workflow lab: Test ideas with code layers and the Figma agent," Figma Blog, November 4, 2026, read in full; every step, prompt, and quoted phrase is as Figma published it, and the Pickup app is Figma's fictional example. Falk Gottlob, "17x the Code, 1.3x the Releases. Design's Job Is the Spec Now.," where Loredana Crisan's 17x and 1.3x are as TechCrunch reported them; "Stop Picking Winners. Design the Tournament."; and the Design Operating Model chapter "The Rubric Is the Spec."

Share this post

Also on Medium

Full archive →

Frequently asked

What does Figma's workflow lab on code layers and the Figma agent show?+

Mari Kong's November 4, 2026 post follows a designer adding a delivery-address button to a fictional marketplace app. They clone the repo onto the canvas as a code layer, prompt the agent for three variations with the first an omnisearch field and 'surprise me with the other two,' get address search, map-based selection, and saved-address shortcuts side by side, click through them, and after some exploration decide they are happy with the omnisearch option. They then refine a heading size and a label, rename the button to 'Choose delivery address,' merge a teammate's grid view by prompt, and finally ask the agent to describe the changes against the original and flag anything a developer should review, which the post calls the technical spec. Code layers moved to open beta the same day.

What is wrong with 'surprise me' as a brief for a design agent?+

Nothing is wrong with asking for range. The problem is what happens next: the designer picks one of three working prototypes and the record of why is 'happy with.' The pick is where the judgment was, and it is the one step in the workflow with nothing written down, while the spec is written last and describes the choice already made. A rubric is the only form of taste that executes when you are not in the room, and it has to exist before the prompt to score the variations the prompt returns.

How do you write the rubric before the prompt?+

By extraction, not invention. Grade thirty real outputs on gut feel, one sentence each, find the phrases that repeat in your own reasoning, and keep only the dimensions where failing costs something. Score pass or fail with a severity, because given a five-point scale two reviewers both write 3 for different reasons and leave believing they agreed. For a variation brief that compresses to three lines per option: what it must never do, what a failure costs the user, and the one data question the canvas cannot answer.

Which design choices cannot be settled by a prototype?+

The ones that turn on a number the prototype does not contain. In Figma's example, saved-address shortcuts win or lose on the share of orders that go to a repeat address; the order data has that share and a side-by-side comparison on a canvas does not. The tournament post's third question is exactly this: which ideas cannot be settled by a prototype at all, and so should not be decided by one.

Where does the score go?+

On the canvas, as a comment beside each code layer, so the pick has the same visibility as the prototypes. The spec opens first and carries the three lines, which turns the agent's end-of-flow document into a diff against the spec rather than the spec itself.

THE SHORT ANSWER

The Product OS HandbookPrototype Before You SpecWhy the fastest way to get alignment, test ideas, and advance your career is to build something people can touch - and exactly how to do it in 2 hours.

PART OF

AI Product Management

About the author

Falk Gottlob

Falk Gottlob

Product Executive · Founder, Falkster.AI

Thirty years shipping product, from Microsoft Research and Adobe to Salesforce, where he grew Quip into what became Slack Canvas. Four startup exits, including a $6B healthcare merger and a company Microsoft bought. Four-time Chief Product Officer. Now founder of Falkster.AI, building Heidi, the company brain for AI-native businesses. This notebook is written from inside the build, not above it.

Comments (0)

Sign in with LinkedIn to leave a comment.

Sign in with LinkedIn
  • Be the first to comment.

Keep Reading

Posts you might find interesting based on what you just read.