About 10 minutes to read.
What is up people!
Imagine asking AI to build a booking page for a weekend photography workshop. It produces a calendar, a handsome description, and a button for reserving a place. You can already picture the finished site. Then you show it to someone who asks whether the workshop is suitable for a beginner.
That answer is halfway down the page. The calendar is at the top. Before choosing a date, your visitor needs to know whether they belong there at all.
You could spend the next hour improving the calendar, or use AI to explore a different order: explain the workshop first, then offer a date. The second option gives you something useful to learn before you connect payments, write confirmation emails, or build the rest of the site.
Figma’s October 15 release makes this kind of exploration easier to share. Its code layers put working prototypes on a design canvas, where different versions can sit beside one another. The more useful habit, whether you use Figma or another tool, is deciding what question the prototype should answer.
An AI build can be valuable even when you throw most of it away. It needs to leave you with a better next decision.
📌 TL;DR
Choose the uncertainty before the features. Build enough to find out what you need to know, whether that concerns the experience, the underlying technology, or whether the idea is useful at all.
Compare meaningfully different versions. A different information order can test a design decision. Three colors of the same confusing page usually cannot.
Use observed behavior to choose the next build. AI can suggest problems to investigate. Someone trying the prototype can show you a problem you had not thought to ask about.
Build around the question you cannot answer yet
There is a wonderful example in a 1997 chapter by Stephanie Houde and Charles Hill, then at Apple Computer. Designers exploring a portable computer for architects put weight in a pizza box and gave it to an architect to carry on a building-site visit.
They watched how he carried it, what else he had with him, and the tasks he needed to perform. Its rigid shape and weight proved awkward alongside his other materials. That observation led them to consider a softer form, something closer to a shoulder bag.
The box could not run software. It could answer a question about carrying the proposed computer. The chapter describes a design example, not a controlled experiment showing how much better all prototypes perform. Its useful lesson is that the object you make should represent the part of the problem you need to understand.
For the workshop page, that part might be information order. Does a prospective attendee want to understand the class before choosing a date, or is the date the first constraint? Those are different starting points, and both have a reasonable case. Someone with a free Saturday may care about the calendar immediately; someone nervous about their camera skills may need reassurance first.
You do not need a complete business website to explore that choice. A believable description, the same available dates, and a way to move through each version may be enough. An account system, a blog, and a customer dashboard add little to that particular question.
Start by writing the decision in ordinary language: “Should visitors read about the workshop before choosing a date?” Then say what would make you change your current plan. If people repeatedly reach the calendar and cannot tell whether the workshop suits their experience, there is a reason to change what comes before it.
Sometimes the uncertainty sits somewhere else. Perhaps the booking software must prevent two people from claiming the last seat at the same time. A clickable picture of a calendar cannot settle that. You need a working test of the reservation logic, with the relevant competing requests. The smallest useful build may be technically demanding even if its screen looks boring.
This also gives you permission to skip a prototype. If the question is which dates the venue is available, call the venue. If an existing booking service already does everything you need, trying its normal setup may answer more than generating a replacement. Making something is one way to learn; it earns the time when the thing you make exposes a question that otherwise remains uncertain.
Make the alternatives different where it matters
Once you have the question, AI becomes useful at producing something you can inspect. Instead of asking for “a better booking page,” ask for two versions that take different approaches to the same decision.
In the first, visitors choose a date and then see the workshop details. In the second, they read a short explanation of the workshop, confirm that it suits their experience, and then choose a date. Keep the class description, dates, price, and visual treatment consistent enough that you can focus on the ordering.
If one version has attractive photos and the other has placeholder boxes, preference becomes harder to interpret. A person may choose the photos while you conclude they prefer the navigation. You do not need laboratory conditions for a useful early conversation, but you should know which differences you introduced.
Figma’s code layers announcement describes an environment suited to this work. Teams can duplicate working prototypes, compare them side by side, and leave feedback nearby. The feature can also bring in supported lightweight prototyping code from a local folder or GitHub. It is not a promise that any large application will import and work unchanged.
Code layers began rolling out in open beta on October 15 across all plans. Figma says it will use AI credits, with creating and editing free on paid plans through November 4. Check availability in your account before planning around it. These are the company’s published capabilities and access terms; this issue does not report a hands-on test.
The useful part of keeping versions together is that the first result remains available for comparison. You can change the information order without losing the earlier attempt, then see whether the new version solves the problem or merely moves it. A saved screenshot can preserve appearance, but a working version also preserves the sequence of choices.
Before involving someone else, walk through both versions yourself. Choose a date, go back, change the choice, and see what happens. If a button does nothing because the generated code is broken, fix that before interpreting another person’s hesitation as evidence about the design. If an action is deliberately simulated, make that boundary clear.
AI can help with this preparation. Ask it to identify missing states, ambiguous labels, or assumptions in the flow. Give it the actual prototype and a concrete task, then inspect its observations. “A beginner might not understand this label” is a useful hypothesis to check; a simulated beginner announcing that the page is easy is not a customer response.
There is no need to generate ten directions because ten is possible. Two versions that express different ideas can give you a useful comparison. After that, let a specific unanswered question justify another version. Otherwise, you may end up auditioning calendars for a workshop nobody has tried to book.
Let the person using it change your plan
For this hypothetical workshop, find someone who resembles the intended attendee. Give them a situation they can act on: they own a camera, know the basics, and want to join a suitable class on a weekend they are free. Let them use the page without explaining the route you hoped they would take.
You can ask what they are looking for or what they expect a button to do. Try to avoid helping them past every awkward moment. If you say “the beginner information is down here,” you have answered the question the page was supposed to answer.
Pay attention to what happens before asking which version they like. They may return to the description several times, look for equipment requirements, or stop at a label whose meaning seemed obvious to you. Their actions give the conversation something specific to examine.
Suppose they choose a date easily in both versions, but ask whether they need to bring a camera. Your original date-first question may be less important than a missing practical detail. Add that information and check whether the uncertainty clears. A useful test is allowed to reveal that you were working on the wrong question.
Keep the conclusion close to what you actually observed. One person’s confusion can expose a defect worth fixing. Their successful booking attempt does not establish how most visitors will behave, what percentage will pay, or whether the workshop will sell. For a larger decision, you may need more people, different circumstances, or evidence from a real service.
Likewise, a confirmation screen only shows that the prototype displayed a confirmation screen. If you used sample data and a simulated reservation, the test says nothing about charging a card or storing a booking. Those jobs need their own working implementation and checks before you rely on them.
Write down the result while the details are fresh. For example: “The visitor found a date without help but could not tell whether a camera was required. Add equipment requirements before the booking control. Payment and seat availability remain untested.” This is enough to give the next build a reason, without turning a small observation into a grand verdict.
Figma’s new Specs feature offers a place for that explanation beside the design. Specs can combine written decisions with canvas material such as diagrams and frames, and pass context to a coding agent through Figma’s connector. A simple shared document can also hold the decision. What matters is that the next person, or the next AI session, can distinguish the change you chose from a suggestion nobody has examined.
Once the question is answered well enough for the next decision, move on. Keep the version and the observation, then build the part that now deserves the work. You can return to testing when a new uncertainty appears; there is no prize for keeping a prototype permanently in rehearsal.
Also this week
Written plans can sit beside the work they describe. Figma’s Specs release is beginning its open-beta rollout on paid plans across web, desktop, and mobile. The agent can read and respond to comments in a spec. That could help a team keep an unresolved question attached to the relevant design instead of burying it in a separate chat. Access is rolling out, so an announcement does not mean the feature is already visible in every account.
A working screen can become editable design material. The same code layers release includes “Extract designs,” which brings a screen or flow into editable Figma layers. That gives teams another way to inspect or refine a prototype visually. Treat it as a way to continue the design conversation; extracting a screen does not establish that the underlying application is ready for customers.
Try this on a decision you have postponed
This is a suggested exercise, not a workflow tested for this issue. Choose a small page or interaction you understand well enough to review, and use fictional data while you explore it.
Name the choice holding up the work. Write one question whose answer would change what you build. “Is this good?” is hard to act on. “Can a new attendee tell whether this workshop suits them before choosing a date?” gives you a person, a task, and something observable.
Define what needs to work. Describe the interaction required to answer that question and the parts you will simulate. If the test concerns navigation, a local interactive page may suffice. If it concerns whether a service can save a record, a mock success message will not.
Ask for a small comparison. Have AI build two versions that differ in the decision you are examining. Keep the original available. Try the basic paths yourself and repair defects that would prevent someone from experiencing the intended alternatives.
Invite an intended user to try it. Explain that it is a prototype, provide the task, and leave room for them to choose their own route. Record what they did and asked. If nobody suitable is available yet, use AI critique to prepare questions and keep user validation marked as unfinished.
Choose the next action from the observation. Fix a specific confusion, test a newly discovered question, or continue with the version that now has a defensible reason behind it. If neither version helps, reconsider the premise before adding features.
Here is a starting request you can adapt:
Build a small interactive prototype to help answer this question: should a new photography-workshop attendee read about the workshop before choosing a date? Create two versions using the same fictional workshop details, dates, and price. One starts with the calendar; the other starts with the workshop information. Let me move through the booking choices, go back, and change my selection. Use sample data, show that confirmation is simulated, and do not connect payments, send messages, or publish the page. Before building, tell me which parts of this question the prototype can help examine and which require evidence from someone using it.
The final sentence gives you a chance to catch a mismatch between the question and the proposed build. Read that answer before approving a long feature list. If your real uncertainty is whether people want the workshop, a smoother calendar is unlikely to settle it.
🧰 Tools to try
Code layers, if Figma is already part of your work. The new release is worth exploring for side-by-side interactive versions and feedback in one place. Use the current access and credit terms linked above, and start with a supported small prototype.
The tool you already use to preview a page. If your AI environment can create and preview a simple interactive page, you can try the same exercise there. For a question about wording or order, even paper screens may be enough. Choose the least elaborate representation that lets the person attempt the relevant task.
Return to that workshop visitor for the next revision. Put the equipment requirement where they needed it, reopen the page, and ask them to try again. You now have a specific change to examine. The payment integration can wait until the booking experience gives you a reason to build it.
P.S. An AI wrote these sentences from this week’s primary sources and earlier design research. Payton set the editorial standards and what good looks like. He wants to be transparent when AI wrote the issue.