Two appointment pages look tidy. Both have a date field and a Save button. On the first, a dialog changes the appointment; on the second, a separate page opens. Which version is better? A screenshot helps with colours and spacing. It shows only to a limited extent whether people understand the flow.
On 15 October 2026, Figma opened up Code Layers as a beta. Supported prototypes can be developed further with code and compared on the shared design canvas; existing code can be brought in under the documented conditions. From an editorial point of view, the interesting aspect is working on behaviour together. A prototype thereby becomes the subject of a decision instead of merely showing its attractive result.
First the same task, then different interfaces
Our own example is a club event. The person is supposed to change the date, read the condition of participation and then either save or cancel. Both versions get the same title, the same date and the same longer note. If one version showed only a short placeholder title, the comparison would already be skewed.
The dialog keeps the appointment overview in the background. A separate editing page offers more space. These are different design decisions, not judgements of quality. It gets interesting at the transitions: where is the person after saving? What happens to input they have started when they cancel? Which information remains visible during the change?
A state model makes behaviour something you can discuss
First describe the flow without programming syntax. The appointment is visible. Edit opens an input. Invalid input leads to an explanation, and the valid entries are kept. Save shows the confirmed state. Cancel returns to the unchanged state. These are requirements for our example, not a promise about built-in Figma features.
View → Edit → Input
Input → valid → Save → Confirmation
Input → invalid → Hint + input kept
Input → Cancel → original viewWith this small model, each version can be examined in a targeted way. Perhaps the dialog looks excellent but loses the hint text when an error occurs. Perhaps the separate page is less elegant but makes the way back easier to understand. The assessment is then about observable behaviour, not about a general preference for dialogs.
Feedback needs a shared point of reference
A useful comment reads: “After cancelling, I couldn’t tell whether my new date had been saved.” It names the place, the action and the uncertainty. “Doesn’t feel modern enough”, on the other hand, does not yet provide a question anyone can work on. When drafts and comments sit on the same canvas, the link to the version being looked at can be preserved.
For every change, note which uncertainty it is meant to remove. For example, change the confirmation first, rather than changing the typeface, colours and navigation at the same time. That makes it easier to understand why a second version comes across differently. This is not a controlled usability study, but it is a sensible working discipline for the design phase.
The decision is transferable; the code is not automatically
At the end there should be a short handover note: the preferred version, the task it supports, the relevant states and the remaining questions. An interactive draft with sample data is not yet a real booking platform. Sign-in, stored data and actual permissions have to work separately in an application.
For a small client-side addition to a KENJTEC page, the decision can then be implemented as your own HTML, CSS and JavaScript. The KENJTEC WebSiteBuilder ai offers a developer mode for this, with an isolated preview and its own code publishing step. You transfer the relevant component yourself; this does not mean a Figma import or hosting for any application of your choice.
As of the documented status, Code Layers remains a beta. Availability, supported starting projects and conditions should be checked again before any specific how-to guide. The method holds up regardless of the tool, though: don’t just compare two attractive screens. Compare two traceable answers to the same question of how something is used.
Sources and status
Research and documentation as of 25 October 2026. Design together with code layers on the canvas.
