wonderblok
Get early access

Turn a spec into screens people can click.

A product manager can describe a feature to an agent connected to Wonderblok and get linked screens with empty, loading and error states, then share a clickable prototype for feedback before engineering starts. Notes on a layer reach the agent, which fixes them and reports what changed.

Get early accessSee pricing
MCPNotesPrototypeShare links

WHO THIS IS FOR

Sound familiar?

A spec in words is read in as many ways as there are readers. A mockup arrives after a week and answers a different question. You need something in between: screens, fast enough to be part of the conversation, specific enough that engineering and design argue about the right things.

With an agent on the canvas you can describe the flow in the meeting, see it appear, leave a note on a layer, and watch it change. The prototype link goes to stakeholders the same day.

  • Ambiguity in the spec

    Words skip states: what happens when the list is empty or the payment fails?

  • Design is a queue

    Waiting for a mockup slows every decision that depends on it.

  • Feedback scattered across chats

    Comments live in threads, not on the screen they are about.

AN EXAMPLE WEEK

From a written spec to a prototype people can click, in a week

A scenario, not a customer story: what a week can look like when your agent works on the canvas with you.

  1. Monday

    The spec becomes a flow

    You own a refund requests feature for a subscription product. The spec is two pages. You connect Claude Code, paste the main section and ask for the flow. By the end of the morning there are six linked frames on the canvas: the entry point, the reason picker, a confirmation, a status screen, an empty list and a failed submission.

  2. Tuesday

    You read the states the spec skipped

    The spec said what happens when a refund is approved. It did not say what the screen shows for a refund that was already requested, or for someone who is not eligible. Both are on the canvas now. You write the two open questions on the frames where they belong.

  3. Wednesday

    The meeting changes the screens

    In the review with design and engineering you leave notes on three layers as people talk: the reason list is too long, the button label is vague, the status needs a date. The agent applies them and tells you what it changed. You keep two changes and revert one, and the discussion moves on to the real trade-off.

  4. Thursday

    You check the screens against the criteria

    You paste the acceptance criteria and ask what the screens do not cover. The agent lists two gaps: no way to cancel a request, and no message for a late request. You add both. The list is now the first draft of the test plan.

  5. Friday

    Stakeholders click it

    You link the frames in order and send the prototype as a link to the head of support and a finance lead. They click through instead of reading. Their questions are about the flow, not about what the spec meant. You take the comments back to the canvas.

  6. Next week

    Design and engineering start from something specific

    You export the screens as PNG or PDF for the ticket and keep the change history as a record of what moved and why. Design refines the screens instead of inventing them. Engineering starts with a flow that has every state named.

BEFORE AND AFTER

What changes once your agent has a canvas.

WITHOUT A DESIGN FILE

  • A spec in words is read in as many ways as there are readers.
  • Empty, loading and error states are discovered during build, when changing them is expensive.
  • A mockup takes a week and answers a question that was already out of date.
  • Feedback is scattered across chat threads and has no connection to the screen it is about.
  • Stakeholders approve a document and are surprised by the product.

WITH WONDERBLOK

  • The flow appears on a canvas the same day, specific enough to argue about.
  • Every state the agent added is a visible decision you can accept or change.
  • Feedback is a note on the layer, and the agent acts on it and reports what changed.
  • You can ask which acceptance criteria the screens do not cover, before engineering starts.
  • Stakeholders click a prototype link and react to the flow, not to a paragraph.

HOW IT WORKS

Product managers: the workflow, step by step.

Each step shows what you ask for, what you get, and the features behind it.

  1. 01

    Connect your agent

    Wonderblok sets up the MCP connection for Claude Code, Codex and Claude Desktop. Your agent can then read the file and add frames, text, components and tokens. The file stays on your device.

    MCPLocal files

    You get: Your agent can draw on the canvas you will review.

  2. 02

    Write down the ground rules

    A few lines in the file's guidelines save you repeating yourself: the product's tone, the words you use for things, which screens are in scope. The agent must read the current version before it may edit.

    GuidelinesRead-before-edit

    YOU SAY

    Read the design guidelines. Then tell me which words in the spec below do not match the product's vocabulary.

    You get: Screens that use your product's language, not generic labels.

  3. 03

    Turn the spec into a flow

    Paste the section of the spec or describe the journey in plain words. Ask for the flow first, since it is cheaper to delete a box than a screen. Then ask for the screens of the flow, linked in order.

    Frames and auto layoutUniverse (Pro)

    YOU SAY

    Turn this spec into a five-screen flow with a state for an empty list and a failed payment, and link the screens in order.

    You get: Linked frames you can read like a storyboard.

  4. 04

    Read every state the agent added

    Look at the empty, loading and error screens as a user would. Each one is a decision the spec did not make. Accept it, change it, or write the open question on the frame so the right person sees it.

    Components and variantsNotes

    YOU SAY

    For each frame in the refund flow, add empty, loading and error variants, and list the questions each one raises for the spec.

    You get: A list of decisions that were hiding in the spec.

  5. 05

    Check the screens against the acceptance criteria

    Paste the criteria and ask the agent to compare them with the frames. The answer is a list of what is covered and what is not. It is a prompt for you to look at the screens, not a verdict.

    MCPChange history

    YOU SAY

    Compare the prototype with the acceptance criteria below and list anything the screens do not cover.

    You get: A coverage list to take to engineering and design.

  6. 06

    Change it in the meeting

    Leave notes on layers as feedback comes in. The agent reads them, acts on them, reports what it changed and marks them done. Open the change history to keep each change or revert it.

    NotesChange history and revert

    YOU SAY

    I left three notes on the Checkout frame. Apply them and tell me what you changed.

    You get: Feedback lands on the screen it is about, and you decide what stays.

  7. 07

    Share the prototype and the screens

    Link the frames, play the prototype in the app to check the flow yourself, and share it as a link. For tickets and documents, export the screens as PNG or PDF.

    PrototypeShare linksExport PNG, SVG, PDF

    You get: A link people can click, and images for the ticket.

USE CASES

Six jobs you can hand to your agent this week.

  • A new feature from a spec

    You have a spec and a deadline for the first review, and the designer is booked for two weeks.

    PROMPT Turn this spec into a five-screen flow with a state for an empty list and a failed payment, and link the screens in order.

    Result: A linked flow with its failure states, ready for the first review.

    MCPPrototype

  • Finding the states nobody wrote

    The spec describes the happy path. The questions come later, from engineers, one at a time.

    PROMPT For each frame in the refund flow, add empty, loading and error variants, and list the questions each one raises for the spec.

    Result: The missing states on the canvas, and a list of open questions for the spec.

    Components and variantsNotes

  • Checking coverage before engineering

    You wrote acceptance criteria and you want to know if the screens can meet them.

    PROMPT Compare the prototype with the acceptance criteria below and list anything the screens do not cover.

    Result: A list of gaps to fix on the screens or in the criteria.

    MCP

  • Feedback from people who do not use design tools

    Support, finance and sales have opinions that matter, and none of them will open a design file.

    PROMPT Link the refund screens in order, starting from the account page, so they can be clicked through as a prototype.

    Result: A prototype link they can click, so feedback is about the flow.

    PrototypeShare links

  • Changing screens while people talk

    The review meeting produces ten small changes and nobody remembers them by Thursday.

    PROMPT I left five notes on the Status frame. Apply them, tell me what you changed, and mark each note done.

    Result: The changes are made and reviewable, and the notes are closed.

    NotesChange history

  • Two options to decide between

    The team is split between a one-page request form and a three-step one, and each side is arguing from imagination.

    PROMPT Draw both versions of the refund request, one as a single page and one as three steps, and link each into its own prototype so we can compare them.

    Result: Two clickable options, so the argument is about something the team has seen.

    FramesPrototype

WHAT TO LOOK AT

The features that matter most to you.

  • MCP connection

    You describe the flow in plain words and your agent puts it on the canvas, so you do not wait in a design queue to start the conversation.

  • Frames with auto layout

    Screens resize and reflow like the real thing, so a prototype is a believable preview.

  • Components and variants

    Empty, loading and error states are variants of the same screen, so adding one is a sentence.

  • Notes on layers

    Feedback sits on the screen it is about. The agent reads each note, acts on it and marks it done.

  • Playable prototypes

    People click the flow instead of reading about it.

  • Share links

    A stakeholder gets the prototype as a link and can click through it.

  • Change history and revert

    An agent edits fast. You can see what changed since you last looked and undo any of it.

  • Guidelines the agent must read

    Your product's vocabulary and rules apply to every screen without you repeating them.

  • Export PNG, SVG and PDF

    Screens go into the ticket, the doc or the slide as images.

  • Universe patterns

    The agent starts from structures proven in shipped apps, such as sign in, onboarding or checkout. Part of Pro.

QUESTIONS

Straight answers.

Can I turn a product spec into screens?

Yes. Describe the flow to your connected agent and it drafts linked screens, including empty, loading and error states, that you can review and change.

Do I need to know how to design?

No. Universe patterns give the agent a good starting structure, and you steer with plain language and notes.

How do stakeholders see it?

Share the prototype as a link and they can click through it.

Can I leave feedback for the agent?

Yes. Notes on a layer are read by the agent, which can act on them and mark them done.

Is the Free plan enough to try this?

Free includes 100 MCP calls a week. That is enough to turn one spec into a flow and a few states with your agent. If you do this for several features a week, Pro has a much higher limit and adds Universe patterns.

Can my team edit the same file?

Not yet. Team workspaces are coming soon, and today a file lives on one person's device. You can share a prototype as a link and export screens as images, but there is no real-time collaboration.

Does a prototype replace design and engineering?

No. It shows the flow and every state so the team can argue about the right things earlier. It is not working software, and a designer can still improve the screens a great deal.

HONEST LIMITS

What to know before you start.

  • Wonderblok runs on macOS today. Windows, Linux and Android and iOS tablets are coming soon.
  • Team workspaces are coming soon; today a file belongs to one person's device.
  • A prototype shows the flow, not working software.

ALSO FOR

More in Build a product and every other group on the Solutions page.

Try it on one real job.

Download for macOS and start on Free. Windows, Linux and tablets are coming soon. No card needed.

Get early accessSee pricing