WCAG 2.2 sets a minimum contrast ratio of 4.5:1 for normal text in its standard contrast criterion (W3C’s contrast requirements). That gives a concrete visual check, but it does not make a prototype production-ready.
This week: use Figma Code Layers to review whether the real, running prototype communicates the intended design and interactions. Before handoff, document missing states, review repository changes, and check the browsers the project actually supports. Arrange a Mac review only if Safari or another macOS-specific check is part of the acceptance scope.
This guide is for UI and product designers turning Figma work into a code-driven prototype, product managers reviewing states, and small teams deciding who signs off on code and browser behavior.
Last updated October 18, 2026. The Code Layers and Git workflow status was checked against Figma’s Code Layers help documentation, Figma’s Git workflow guide, and Figma’s product updates. Availability and feature behavior can change; check the current documentation and account access before planning a review.
1. Define what the prototype is being accepted for
Figma describes Code Layers as a way to create code-driven interactive prototypes on the canvas. Its documentation also describes connecting a GitHub repository as part of the workflow. Those capabilities can help a team explore and discuss an experience, but they do not certify that an application is complete, secure, accessible, or ready to ship.
The public Beta status and feature access can change. Check the latest Code Layers documentation and product updates before promising a workflow to a client or team. Treat the prototype as a review artifact unless the development team separately accepts the code under its own process.
Start by naming the review outcome. Is the team deciding whether a design direction is understandable? Is it reviewing a user journey? Is it checking a browser-specific issue? Or is a developer being asked to assess implementation changes? These are different decisions, and a single preview cannot answer them all.
Before anyone reviews it, record:
- Purpose: design exploration, stakeholder review, or a development handoff.
- Review owner: the person who decides whether the design intent is clear.
- Open questions: behaviors and screens the prototype does not yet represent.
- Acceptance boundary: what this review can approve, and what it cannot approve.
This framing answers a common handoff problem: a prototype may be useful to developers without being a finished implementation that they can merge or release.
2. Check the visual evidence, not just a single screenshot
A static image can hide problems that appear when text wraps, content changes, or an interaction reveals another view. Review the running Figma Code Layers prototype on representative pages that show the design’s important layout patterns. Compare the result with the intended design and note differences in hierarchy, spacing, typography, component appearance, and content fit.
Do not assume that moving a design into code layers automatically preserves every detail. The thing under review is the prototype as it currently runs, not a guarantee of lossless conversion from a design file.
A useful visual record links each observation to a page or state and describes what was seen. For example:
Page or state: Account settings, validation message shown
Observed: Supporting text wraps into the primary action area
Expected: Action remains visually separate from the message
Impact: Review the layout before handing this state to development
This is a record format, not a claim that the example issue exists in a particular prototype. Keep the language observable: “label wraps to a second line” is easier to verify than “spacing feels wrong.”
Check contrast when text or controls may be difficult to distinguish. The WCAG 2.2 contrast criterion specifies a 4.5:1 minimum for normal text and a 3:1 minimum for large text under that criterion. Use the standard as a defined check, not as proof that the whole design is accessible. Keyboard use, focus visibility, labels, and other requirements need their own assessment.
A visual acceptance note should separate three things: what matches, what differs, and what the team has not reviewed. This makes the handoff useful without implying that an isolated screenshot proves the full interface works.
3. Trace the interaction and state coverage
A prototype can demonstrate a smooth path while leaving important states unrepresented. Test the main actions in the order a person would use them, then check the states that matter to the product discussion: empty content, loading, invalid input, errors, success, and any confirmation or recovery behavior.
The goal is not to claim exhaustive software testing. It is to confirm that the prototype expresses the behavior the team intends to review. If a state is absent, write it down as an omission or follow-up. Do not treat a successful click-through as evidence that all paths have been considered.
For each important action, capture:
- What starts the action, such as a button press or form submission.
- What visible response follows.
- Whether the user can recover, cancel, or try again.
- Whether the response matches the design intent and product requirements.
- Which states remain unrepresented in the prototype.
This is how to check interaction states in a Figma Code Layers prototype without confusing a design review with a full quality-assurance pass. A designer can confirm what the prototype communicates; the development team must still assess the implemented behavior in the actual application.
If the prototype has no way to show a required state, make that limitation explicit in the review notes. A reviewer can then decide whether the team needs another prototype state, a written behavior specification, or a separate implementation review.
4. Review responsive behavior against the project’s real use
A layout that looks acceptable at one canvas size may overflow or become difficult to use when the window changes or content grows. Resize the prototype to the window sizes that matter for the product, and try content changes that reflect real use: longer labels, an error message, or a fuller list.
Record visible outcomes rather than predicting compatibility across every device or browser. Note overflow, clipped text, overlapping controls, unexpected line breaks, and changes in hierarchy. A result observed at one size is evidence for that size and scenario; it does not establish behavior at every viewport.
When Safari is in scope, use an appropriate Safari environment to review the relevant pages and interactions. WebKit describes how its responsive design mode supports responsive testing, but a responsive view is still not a substitute for checking the actual browser behavior required by the project. Confirm the project’s supported browsers first, then test the relevant conditions there.
Separate the review question from the tool used to answer it:
- Layout question: Does the page adapt acceptably when its window and content change?
- Browser question: Does the product behave as required in the named target browser?
- Remote-access question: Is the remote display comfortable enough to inspect the result?
A clear remote view can help a designer inspect a page. It does not, by itself, show that the application passed browser compatibility checks.
5. Make repository changes traceable before handoff
When Code Layers is connected to a GitHub repository, verify that reviewers are looking at the intended repository and branch. Then compare the changes with the prototype behavior and the team’s review rules. Figma’s Git and code layers workflow documentation describes the supported workflow, including repository-related actions; it does not promise that every generated or edited change can be merged as-is.
For a designer who does not work in a terminal every day, the useful question is simple: what changed, where did it change, and who is responsible for reviewing it? A developer or code owner should determine whether those changes are appropriate for the project.
If command-line access is part of the team’s workflow, these read-only commands can help a reviewer see the current working tree and a summary of changes:
git status --short
git diff --stat
The first command lists changed paths in the current working tree. The second summarizes the size of the current diff; neither command proves that a change is correct or safe to merge. For repository history, GitHub’s commit comparison guide explains how to compare commits. For a proposed change, follow the team’s pull request review process and any rules for protected branches.
A practical handoff note should name the repository and branch, summarize the reviewed change, link the relevant prototype state, and identify the code owner. If a pull request is available, its presence means there is a proposed change to review; it is not an approval or a production acceptance decision.
FAQ: Decisions teams often need to make
Can a Code Layers prototype go straight to developers?
It can be handed over as a reference for intended design and behavior. It should not be described as production-accepted solely because it runs on the canvas. Include known gaps, the states reviewed, any visual issues, and the repository or branch under review. The development team still needs to assess the code and decide whether it meets the project’s own implementation, testing, and merge requirements.
How can designers check the prototype’s interaction states?
Follow the main user journeys and inspect the outcomes that the product team needs to discuss, including empty, loading, and error views where relevant. Record absent states as gaps rather than silently treating them as passed. If a state cannot be represented in the prototype, agree whether a written specification or another review artifact is needed before the team accepts the design direction.
Is a Safari test required for every prototype?
No. First check whether Safari is among the product’s supported browsers or a specific client or project requirement. If it is not in scope, a Safari review may not help answer the current acceptance question. If it is in scope, test the relevant page and interaction in Safari; do not infer its behavior from a canvas preview or from a different browser.
What should be checked after a GitHub connection is set up?
Confirm the repository and branch, then review the actual change set using the team’s normal process. Compare the changes with the prototype’s intended behavior and make sure a designated code owner reviews the proposal. A connection, commit, or pull request provides a way to inspect changes; it does not establish that the code is ready to merge or release.
Use these comparison tables to choose the next review
The tables below separate prototype review from browser testing and code acceptance. They are decision aids, not claims that one environment or workflow is universally sufficient.
| Review option | What it can establish | What it cannot establish alone | Choose it when |
|---|---|---|---|
| Figma Code Layers canvas review | Whether the current prototype communicates the intended design and interaction | Production readiness, complete test coverage, or compatibility in every browser | The team is exploring or reviewing a design direction |
| Repository and pull request review | Which changes are proposed and whether they follow team review rules | That the visible prototype matches every requirement | Code changes need assessment by their owner |
| Target-browser review | How the relevant product behavior appears in the browser under test | Behavior in untested browsers or conditions | That browser is in the supported scope or risk needs confirmation |
| Acceptance dimension | Record during review | Escalate when |
|---|---|---|
| Visual fidelity | Page or state, expected result, visible difference | A difference changes hierarchy, readability, or task completion |
| Interaction states | Action, response, recovery path, omitted state | A required state is missing or behavior is ambiguous |
| Responsive behavior | Window or content condition and observed issue | Content clips, overlaps, or makes a key action hard to use |
| Repository traceability | Repository, branch, change summary, reviewer | The change cannot be tied to the reviewed prototype or owner |
| Browser scope | Required browser and environment checked | A required browser has not been reviewed |
| Current approach | Common limitation | When a Mac review helps |
|---|---|---|
| Review only in the design canvas | The review does not establish behavior in the target browser | Safari or a macOS-specific browser condition is explicitly in scope |
| Use only the available Windows browser | Safari-specific rendering remains unverified | The team needs to inspect the page in Safari |
| Ask developers to infer missing states | Intent and acceptance responsibility may be unclear | A Mac can provide the required environment, but it does not replace a clear review plan |
A handoff process that produces a useful decision
Use the following sequence before closing a design review:
- Name the decision. State whether the team is approving a design direction, reviewing behavior, checking a browser, or assessing a code change.
- Choose representative pages. Select the pages and states that expose the important layout and interaction patterns.
- Run the primary journeys. Capture what starts each action and what the prototype shows afterward.
- Vary the viewing conditions. Resize the window and vary realistic content to reveal visible layout issues.
- Write down gaps. Mark unrepresented states, uncertain behavior, and visual differences as unresolved until an owner accepts them.
- Trace code changes. Confirm the repository, branch, change set, and code reviewer when the workflow includes a repository.
- Check the target browser. Use the browser required by the project; add Safari review only when it is in scope.
- Record the boundary. State what the review accepted and what still needs development, accessibility, or browser testing.
The sequence makes the handoff auditable without turning a design prototype into a promise about the finished application. For teams comparing access options, NodeMini’s Mac service information can help establish whether a remote Mac is relevant to the required browser check.
Choose a Mac review only when the acceptance question calls for one
A Mac is useful when the project specifically requires a Safari or macOS browser check and the team does not otherwise have access to that environment. It is not necessary just because the prototype was made in Figma, and it does not automatically resolve missing states, code review, or product testing.
Compared with a Mac review, relying only on the current Windows setup can leave Safari behavior unverified, make it difficult to reproduce a Mac-specific issue, and force the team to defer a required browser check. Those are genuine limits—but they matter only when the target browser is part of the acceptance scope.
Buying a Mac may make sense for sustained work, repeated browser testing, or projects that need local hardware and peripherals. For a short review or a temporary test environment, renting can avoid an immediate hardware purchase while providing access to a Mac for that specific task. NodeMini offers a remote Mac option to consider if the team has confirmed that Mac access is actually needed. The next step is to define the browser requirement first, then choose between existing equipment, a rental, or a dedicated Mac based on how often the same review will recur.