Last week we rebuilt the entire Text2Test app UI from scratch. Every page. Login, dashboard, test editor, plan wizard, results, settings, billing. We did the whole thing on Claude Design.
Not static mockups. Every page is fully interactive. Real states, real flows, real components you can click through end to end. A working prototype of the product, not a picture of it.
Claude Design generated a full handoff doc from the screens. Every component, every state, every flow, written down. We dropped it into Claude Code, our MCP server connected it to Text2Test, and 137 structural test cases came back in minutes. Each one prioritized as blocker, critical, or major. Each one categorized as happy path, edge case, or negative.
Why the interactivity mattered
A static mockup tells you what a screen looks like. An interactive prototype tells you what it does. That difference is everything for test generation.
When the login form is a real component with validation states, the model can see that an empty submit shows an error, that a malformed email is rejected, that the password field has a minimum length. Those states are the test cases. A flat image would have produced a handful of generic checks. The interactive build produced the edge cases too, because the edge cases were actually there to read.
The richer the source, the richer the coverage. Interactive components are a much richer source than screenshots.
Why the handoff doc mattered
Claude Design did not just give us a visual file. It generated a structured document describing every screen, every component, every interaction, every state transition. That is the artifact we fed to Text2Test, not the design file itself.
This matters because the handoff doc is portable. It can be read by Claude Code, by our MCP server, by any tool downstream. It is the bridge between design intent and machine-readable structure.
In effect, the design generated its own spec.
Why generating from the design matters
Test cases have always been written downstream of the product. A designer ships a mockup. An engineer builds it. A QA engineer reads the ticket, opens the design file, and translates what they see into test scenarios. Sometimes Gherkin. Sometimes plain text. Sometimes a scripted tool.
That translation is where coverage gaps come from. The designer knew what the empty state should look like. The engineer remembered. The ticket did not mention it. The QA engineer never wrote a test for it. The bug ships.
If the design itself is the source of truth, that translation step disappears. The test plan reflects the actual product, not someone's interpretation of it.
What actually happened
We finished the interactive redesigns on Claude Design. Every screen with real components and real states, not wireframes.
Claude Design generated the handoff doc. We dropped it into Claude Code, where our MCP server is wired up to Text2Test.
One prompt. Generate the test cases.
137 came back. Structured. Each with:
- Priority: blocker, critical, or major
- Category: happy path, edge case, or negative
- Steps: written in plain text, ready to execute
- Expected outcome: what the user should see
Things a QA engineer would have written after an hour at the screen. The MCP did it in minutes and did not skip the edge cases.
The real shift
Most AI testing tools today take a built product and try to write tests for it. They look at the live page, parse selectors, infer what matters. They are working from the output, not the intent.
When the test plan is generated from the design itself, you are working from the intent. The thing the team agreed should exist. The thing the engineer is supposed to build.
That is what we mean when we say connected AI-native testing. Your test suite is not separate from your product. It is generated from the same source the product is built from.
What is next
Claude Design is one source. Our roadmap covers Figma, Jira, GitHub, and OpenAPI specs through the same MCP layer. The principle is the same. Wherever the truth about your product lives, that is where your tests should be generated from.
If you are building a SaaS product and shipping fast, this changes what your QA loop looks like. Worth a look.