Discovery
Prototypes
Your agent builds a prototype and publishes it to Roko Platform. The team compares its flavors, comments on elements, and links the prototype to the goal it informs.
A prototype lets the team learn something about the product before anyone writes production code. Teams build prototypes to:
- Test usability. Find out whether a user can finish a task without help.
- Present options to a client. Put two or three approaches side by side, and let the client choose.
- Make an idea tangible. Give the team and the stakeholders one concrete thing to discuss instead of several mental pictures.
- Answer an open question. Settle a question about use that blocks a decision on the roadmap.
A prototype does not need to be pixel perfect. It needs enough fidelity to learn from.
Roko Platform hosts a project's prototypes as static HTML, CSS and JavaScript bundles. Your agent builds each prototype and publishes it over MCP. The team opens it in the browser and comments on it.
Versions and flavors
A prototype belongs to one project. It holds versions, numbered v1, v2 and so on. Each version is one round of attempts and holds one or more flavors. A flavor is one option in that round, with a key such as a, b or c. The full name of a flavor is the version and the key, for example v1a.
First round: three different approaches.
Built from the comments on v1.
| Use | When |
|---|---|
| A new flavor | You want another option in the same round |
| A new version | The comments on the last round taught you something, and you start again from that lesson |
| A new prototype | You want to learn something different |
Build one
Ask your agent to build the prototype. Tell it what you are trying to do and why, the fidelity you need, how many flavors you want, and the project to publish to. Ask it to raise its questions before it starts.
I want to show our suppliers how they could see which documents are still missing from their registration, and learn which approach they understand without help.
Fidelity: realistic content and the real steps, with plain styling. It does not need to be pixel perfect.
Build three flavors that differ in approach, not in layout details. Publish them to the Roko Platform project northwind / vendor-onboarding.
Ask me any questions before you start.The agent answers your questions first, then builds each flavor as a self-contained bundle, publishes the version to the project, and gives you the link. Review the prototype on the platform. Ask the agent to read the project's code first when the prototype must match the real product.
View and comment
Open Prototypes from the Discover group in the project navigation, then open a prototype. The version menu lists every version. Select a flavor's pill to show it, or select View all flavors to tile every flavor of the version side by side.
To comment on an element, select Add a comment or press C, then click the element. To comment on the whole version, write in the comment field without picking an element. Write what you saw, not what to build: "I did not notice this was a link" beats "make it a button".
Your agent reads every comment before it builds the next version.
Link it to the work
A prototype is evidence for a decision. In a goal's Links section, select Link in the Prototypes group, then pick the prototype. A change request has no prototype field, so link the prototype in the change request's text and record the flavor you chose.
Best practices
- Know what you want to learn. Write down the purpose before you build: the usability you want to test, the options the client should compare, or the idea the team should see.
- Build the lowest fidelity that you can learn from. A sketch is enough to compare page flows. A usability test needs realistic content and the real steps. A client review needs something close to the product. Higher fidelity costs more and teaches different things, not the same things better.
- Use real content and real context. Real names and realistic amounts of data expose problems that placeholder text hides. A variant inside the real page tells you more than the same variant on a blank page.
- Build three flavors that differ in approach. A checklist, a summary page and inline markers are three approaches. Three checklists with different padding are one. Name the flavors neutrally.
- Give testers a task, not a tour. Watch what they do, not what they say. Five sessions usually show the main usability problems.
- Start each round fresh. Build the next version from what the comments taught you. Do not patch the last one.
- Do not ship prototype code. Never grow a prototype into the product. Keep the comments and the decision, and build the chosen design properly from a change request.