Figma Specs and Code Layers Bring QA Into Product Discovery

TL;DR: Figma's new Specs and open-beta code layers put written decisions beside working prototypes on a shared canvas. The useful opportunity for product and QA is not generating more screens. It is comparing competing behaviors before one becomes a requirement. Use the prototype to expose a decision, the spec to record it, and a separate test plan to establish what the eventual product must prove.

A CSV import prototype accepts a file, shows a green confirmation, and looks ready for development. Then QA asks a simple question: what happens when three rows are invalid?

The designer expected the valid rows to import. The product manager expected the entire file to be rejected. The prototype silently chose the first answer. Nobody actually made that decision.

That is the kind of disagreement worth finding before implementation. Figma's October 15 announcement makes a more collaborative way to find it worth considering: Specs holds written context on the canvas, while code layers brings interactive, code-backed prototypes into the same workspace.

This is source-backed analysis, not an executed experiment. The import example below is a proposed workshop using synthetic data, not a test of Figma's capabilities or a customer result.

What Changed in Figma

Figma Specs is a collaborative home for Markdown and the work it describes. A spec can embed canvas content such as frames and diagrams, sit beside a prototype, and carry context to a coding agent through Figma's MCP server. MCP is the connection that lets supported AI tools read or act on Figma context.

Code layers puts running code on the design canvas. Teams can duplicate prototypes, try alternatives side by side, and comment where the work lives. Figma documents several starting points, including existing designs and imports of supported, lightweight prototyping codebases. That is not a promise to run any production application unchanged.

The distinction matters. Specs makes the thinking easier to inspect; code layers makes the proposed behavior easier to experience. Neither makes a product decision correct merely by placing it on a canvas.

As checked October 19, Figma's availability guide describes both as open beta with access rolling out over the following weeks. Code layers is rolling out across plans, with education restrictions and edit-access requirements. Specs includes Professional, Organization and Enterprise access, plus Education and Government in its detailed eligibility section. Check your account rather than assuming every teammate has access. Code sources in libraries remain closed beta; centralized design systems remain a preview.

The launch has also received independent TechCrunch coverage. That establishes industry attention, not proof that these features improve delivery speed or product quality. We report no measured benefit here.

Bring QA to the Decision, Not Just the Finished Prototype

The practical change is when QA contributes.

In a late review, QA asks whether an implementation follows the agreed behavior. In discovery, QA can help the team decide what that behavior should be by exposing situations the first design did not consider.

For the import flow, put two alternatives beside the same question:

• All or nothing: reject the file if any row is invalid. Explain the errors and let the person try again.

• Partial success: import valid rows, identify rejected rows, and provide a way to retry only those rows.

Neither is universally better. All-or-nothing behavior may be easier to explain when records must remain consistent as a group. Partial success may be useful when each record is independent and fixing one row should not delay the others.

The prototype's job is to make those trade-offs discussable. It is not to decide the business policy because one implementation was easier to generate.

Have product, design, QA and an engineer review the same synthetic file. Ask what a person would believe happened after each version, what work they must do next, and which mistakes would be expensive to reverse. If the team cannot answer those questions, polishing the confirmation screen is premature.

Give Every Prototype Three Truth Labels

A working prototype combines intentional decisions with convenient shortcuts. Separate them explicitly before handing its context to an agent.

These are proposed team conventions, not built-in Figma statuses or enforcement features.

The third label is easy to skip. A timer can be a useful way to explore loading feedback. It says nothing about processing a large file, cancelling an in-flight request, or recovering after a network interruption.

Similarly, a convincing permission screen can help explain an interaction without proving that a server rejects an unauthorized import. Keep prototype usefulness separate from implementation evidence.

Run a Workshop That Produces a Decision

Start with one disputed behavior, not an entire application. Use synthetic records and an approved workspace. Do not import a customer dataset or private repository simply because an integration makes it convenient.

A compact session can follow this sequence:

1. Write the question first. For example: should one invalid row block every valid row? Name who will make the decision and who must advise.

2. Make the alternatives comparable. Use the same fictional records, starting state and user goal. Change the import policy, not the visual polish of one version.

3. Give QA contrasting cases. Try a fully valid file, a mixed file, an entirely invalid file and a duplicate record. These are proposed cases, not executed findings.

4. Watch the interpretation. Ask reviewers what was imported, what remains unresolved, and what they would do next. Record confusion separately from a broken interaction.

5. Classify what you learn. Is it a product-policy disagreement, an unclear explanation, a prototype shortcut, or a defect in the prototype itself? Different findings need different owners.

6. Record the decision and the remaining questions. Keep the rejected alternative and the reason for rejecting it. Mark any unresolved policy as a stop condition for implementation, not an invitation to guess.

The useful output is a decision record tied to an inspectable example. A product owner should be able to explain why the chosen behavior fits the user; an engineer should be able to identify what is still simulated; QA should know which claims need later tests.

This workshop does not establish that customers will prefer the chosen flow. Internal alignment and usability research answer different questions. When comprehension is the uncertain part, plan an appropriate user study rather than treating stakeholder agreement as validation.

Keep Discovery Acceptance Separate From Release Acceptance

Suppose the team chooses partial success. Discovery may establish that the proposed summary communicates the difference between imported and rejected rows clearly enough to take into further research. It has not established that the production system imports exactly the intended records.

Translate the decision into separate implementation questions:

• Does the stored result match the preview the person confirmed?

• Can a retry create duplicates?

• Does cancellation stop new work, and what happens to work already completed?

• Can someone without the required permission trigger the underlying operation?

• Can the person recover the rejected rows without losing the original input?

Those questions belong in engineering and QA's test plan. They may need API, data-integrity, accessibility and browser tests. A successful prototype walkthrough does not replace them.

Avoid turning every unfinished prototype detail into a defect ticket, too. A simulated progress indicator may be completely adequate for discovery. The problem is failing to label it, then allowing someone downstream to mistake it for a tested implementation.

Shared Context Needs a Decision Owner

As agents turn shared design context into code, an unresolved product question can become implemented behavior before anyone explicitly chooses it.

More context is not automatically better context. A canvas might contain a rejected prototype, an old comment and the current decision. The team must make their relationship clear rather than expecting the agent to infer which one wins.

Separate approved decisions, open questions, and prototype shortcuts in the spec now, and name the person who can move an item from one category to another.

For the import example, give the approved policy a stable identifier, link the chosen prototype, and mark the other version as rejected with a reason. Ask the implementing agent to surface contradictions and stop on unresolved behavior. These are workflow instructions your team must enforce, not guarantees supplied by Specs or MCP.

The opportunity is earlier disagreement, made visible while changing direction is still part of the exercise. That is a more useful goal than counting how many prototypes an agent can generate.

Carry the Decision Into the Browser Review

Once the chosen flow exists as a standalone browser build, keep the approved decision beside any observed mismatch. If retrying rejected rows imports a duplicate, the receiving engineer needs both the intended policy and the path that exposed the problem.

Try CSS Selector & XPath Finder by Samelogic to deliberately record that browser path, replay the sequence and inspect the relevant element. Review the captured steps and sensitive content before sharing, and attach the decision identifier manually. This is a proposed connection between discovery and browser review, not a Figma integration or a claim that the extension captures code-layer internals, diagnoses the cause, or proves backend correctness.

Sources

• Figma's October 15 launch overview

• Introducing Figma Specs

• Designing together with code layers

• Config India feature availability and access

• TechCrunch's independent launch coverage