.jpeg)
.jpeg)
.jpeg)
A practical starting point
Start with one task someone needs to finish.
For this example, a visitor wants to book a 20-minute demo of a research-notes app. They need to understand the offer, choose a time, enter their details and know whether the booking worked. That is enough to expose useful design questions before you build a real scheduling system.
The free UI/UX starter setup
Use Figma Starter for screen layouts and click paths, then a small browser prototype when real inputs and errors matter. Observe someone trying the flow over a personal Google Meet call and keep written notes. You do not need a paid research platform to start this exercise.
| Job | Tool and free allowance | Where the limit matters |
|---|---|---|
| Agree on the task | A plain-text brief and observation notes. Copy the filled examples below. | No tool will decide what the visitor needs to accomplish. Define that first. |
| Wireframes and click paths | Figma Starter: free; 3 Design and Sites files combined in the team folder, up to 3 pages per team file, plus unlimited drafts. | Pages are not screens: put several frames on one page. Draft sharing is view-only; co-editing requires moving the file into the team folder or changing plan. |
| Type, submit and recover | The browser example on this page: no login, payment or external service required. | It simulates responses. It cannot send an email, create an appointment or prove a backend works. |
| Observe a participant | Google Meet with a personal account: up to 100 participants. On a computer, 1:1 calls can last up to 24 hours; calls with 3 or more people have a 60-minute limit. | A moderator, participant and silent observer count as 3. Ordinary free personal accounts do not include native recording or “Take notes for me.” |
Plan limits checked against official documentation on November 10, 2026. This setup can cost $0 in software with an existing computer and connection; recruiting people or offering an incentive is a separate cost. Figma’s Starter overview and page limits explain the design-file allowance.
What equipment do you actually need?
Use the computer you already have, a reliable connection and a microphone or headset that lets you hear the participant clearly. If the flow is meant for phones, include an actual phone in the session. The mobile screenshots below are browser viewport checks at 390 pixels wide; they do not tell you how comfortable the flow feels on a real handset.
Wireframe the decisions before styling the screen
In Figma, create three frames on one page: Choose a time → Your details → Confirmation. Connect the main action in each frame to the next and provide a way back. Basic frame connections and prototype flow starting points are available on all Figma plans.
Keep the first version plain enough to change quickly. Give the time, duration and timezone more attention than the button color. Ask for an email address, make the name optional, and show the selected time again before confirmation. A click-through can help you check the order and wording; it does not establish that real form validation or data saving works.
These screenshots show our own browser-built wireframe, not Figma’s interface or a purchased UI kit. The same screen plan is easy to recreate as Design frames. On the phone layout, the offer sits above the choices instead of being squeezed beside them.
Sharing caveat: on Starter, someone viewing a prototype can open its source design. Paid plans offer prototype-only sharing that hides the source. Use fictional details in a public example; do not put private customer information in the file. See Figma’s sharing rules.
Try the booking prototype
Choose Tuesday at 15:00 UTC and use alex@example.com. Then try leaving the email blank or entering an invalid address. Under “Explore the response states,” you can make the next confirmation fail or remove all available times.
Use the sample address rather than your own. Entries stay in this page while it is open. The example has no calendar, email service, database or payment connection.
- 1 Time
- 2 Details
- 3 Confirmed
STEP 1 OF 3
Choose an example time
These are fixed sample dates for the exercise, not live availability.
You can reset the sample dates to continue the exercise.
STEP 2 OF 3
Where should the example confirmation go?
Use Alex Example and alex@example.com. This prototype keeps entries only while the page is open and sends nothing.
STEP 3 OF 3
Example booking confirmed
You reached the end of the prototype. No appointment or email was created.
- When
- Duration
- 20 minutes
- Example email
Explore the response states
These controls simulate conditions for the exercise. They do not contact a server.
What worked, and what needed fixing
The first browser walkthrough caught a small but real problem: pressing Enter after a valid email did nothing. The repaired version triggers confirmation, shows a busy state and reaches the receipt. That is the kind of behavior a static screen cannot demonstrate.
| Check | Observed result | Why it matters |
|---|---|---|
| No time selected | A specific message appears and focus moves to an available time. | The visitor gets a route forward rather than an unexplained failure. |
| Blank or invalid email | An inline message identifies the issue and focus returns to the field. | The person can fix the entry where the problem occurs. |
| Enter to confirm | Initially failed. After the repair, Enter starts the simulated response and opens confirmation. | Mouse-only checking had missed a keyboard interaction. |
| Time becomes unavailable | The chosen time is disabled. The visitor can choose another without retyping the contact details. | A recoverable error should preserve work already done. |
| No available times | An explicit empty state replaces the choices, with a reset for this exercise. | A real product would need a useful alternative, such as another date or a notification request. |
| Desktop and mobile | The 1280px and 390px views fit the viewport. The mobile route reached confirmation with the selected UTC time and sample email. | A responsive layout still needs its task checked, not just its first screen. |
These are agent-run functional checks of a fictional example, not findings from human participants, a full accessibility audit or evidence of higher conversions.
Run a user test that answers a real question
A useful first question is: Can someone understand the demo offer, choose the intended time and recognize the confirmation without help? Invite a person who plausibly evaluates this kind of product. Before the session, explain the purpose, who will observe, how notes will be used and whether you want to record. Get permission before you start.
For the free setup, plan to take written notes. Meet’s native recording feature requires an eligible paid edition or subscription. You can learn from a session without recording it.
Read this task without naming the buttons:
“You lead customer research and want to see how this app handles interview notes. Arrange a 20-minute walkthrough for Tuesday, 17 November 2026 at 15:00 UTC. Use Alex Example and alex@example.com. Tell me when you think you have finished.”
Ask the participant to think aloud, then mostly watch and listen. If they pause, try “What are you looking for?” rather than telling them to click Continue. Note any help you give. Keep the deliberately forced error exercise separate from the main task so it does not masquerade as a natural failure.
Write down the behavior before the explanation. For example, “participant returned to the time screen twice” is an observation; “the timezone is confusing” is an interpretation to investigate. The GOV.UK moderated-testing guide explains realistic tasks, neutral instructions and observation-led follow-ups.
| Record | What to write in your notes |
|---|---|
| Task and location | The intended outcome and the screen or step where the issue occurred. |
| Observed behavior | The action or exact words, including any help you gave. |
| Possible explanation | Your interpretation, kept separate from what you observed. |
| Next design change | One change to try and what you will look for in the next session. |
Copy the brief, session script and test checklist
Paste the brief into your project document, a design task or your coding tool. Replace the audience, goal and sample dates with your own. Keep the outcome and error states specific; “make it intuitive” is not a testable requirement.
Read and select the full text
PROJECT BRIEF — DEMO BOOKING FLOW Product: a fictional B2B app for collecting interview notes, linking quotes and sharing research findings. Reader: a research lead deciding whether a 20-minute product walkthrough is worth booking. Job to support Let the visitor choose an example time, provide contact details and recognize that the example booking is complete. The three screens 1. Choose a time. Explain the 20-minute duration, timezone and purpose of the call before the visitor commits. 2. Enter details. Show the selected time again. Ask for an email address; make the name optional. 3. Confirm. Repeat the time, timezone, duration and email. State what would happen next in a real service. Fixed exercise data - Tuesday, 17 November 2026, 15:00–15:20 UTC. - Wednesday, 18 November 2026, 10:00–10:20 UTC. - Demo contact: Alex Example, alex@example.com. - These are fictional sample dates, not live appointments. Behavior to include - No time selected: explain the missing action and focus an available choice. - Empty or invalid email: a specific message beside the field; keep the selected time and name. - Confirmation pending: a visible busy state and protection against duplicate activation. - Time no longer available: keep the entered details and provide a route to another time. - No available times: a useful empty state with a next action. - Back/edit: preserve the visitor's choices unless they explicitly reset the example. Constraints Design for a 390px phone and a 1280px desktop. Use visible labels, keyboard focus and controls large enough to select. Enter in the email field should activate confirmation. Keep the timezone visible at selection and confirmation. For this prototype, send no email, create no calendar event, take no payment and store no personal data outside the open page. Use only the example contact in a walkthrough. Deliverable Produce a low-fidelity wireframe and a clickable or browser prototype. List the assumptions and distinguish simulated behavior from connected services. Do not invent user-test findings or conversion results.
A neutral session script
Use this as your moderator’s notes. It includes the task, follow-up questions and a place to separate observations from assumptions.
Read and select the full text
MODERATED USABILITY SESSION — DEMO BOOKING Before inviting someone Choose a participant who plausibly evaluates this kind of product. Explain the purpose, what you will observe and how notes will be used. Ask permission before observing or recording. A video-call account does not automatically include recording. Opening "We are checking the design, not testing you. Please work as you normally would and tell me what you are thinking. You can stop at any time. I'll mostly listen while you try the task." Task — read this without naming the buttons "You lead customer research and want to see how this app handles interview notes. Arrange a 20-minute walkthrough for Tuesday, 17 November 2026 at 15:00 UTC. Use Alex Example and alex@example.com. Tell me when you think you have finished." Observe before helping - What does the person believe the call offers? - Which time do they choose, and how do they interpret UTC? - Where do they hesitate, go back, miss information or ask a question? - What do they think the confirmation means? What do they expect next? Neutral follow-ups "What are you looking for?" "What were you expecting to happen?" "What tells you that you have finished?" Avoid coaching Do not say "click Continue", explain a label before they use it, praise a correct route or ask "Was that easy?" If they become stuck, note the point before giving help. Record any help you provided. After the main task Ask what they expected next and what, if anything, was unclear. Ask them to change the chosen time if that behavior matters to your product. Exercise error states separately so a forced error does not become a supposed measure of natural task success. Observation note — repeat for each finding Task / expected outcome: Observed action or exact quote: Where it happened: Help given: Possible explanation (not a fact): Design change to try: What to observe in the next session: Report only what happened. A small qualitative session can reveal a misunderstanding; it does not establish a population success rate or conversion uplift.
Before you invite a participant
Run through this checklist yourself first. The participant should be trying the design, not discovering that the example cannot load.
Read and select the full text
BOOKING-FLOW TEST CHECKLIST SET UP [ ] The visitor, task and expected outcome are written down. [ ] The example uses a realistic offer, visible duration and explicit timezone. [ ] The prototype is accessible to the participant before the session. [ ] Prototype permissions do not expose confidential source material. [ ] The phone layout is opened on a real phone where possible, not only a scaled desktop image. [ ] The participant understands observation/notes and has given any needed permission. FUNCTIONAL WALKTHROUGH — BEFORE A PARTICIPANT SESSION [ ] Continue with no time selected: a useful message appears and the time choices can be reached. [ ] Select a time: the details screen repeats the same date, time, timezone and duration. [ ] Go back: the selected time remains selected. [ ] Submit an empty email and an invalid email: specific, visible messages appear beside the field. [ ] Correct the email: the previous field error clears. [ ] Use Tab, Shift+Tab, radio arrow keys and Enter: the intended controls work with visible focus. [ ] During confirmation, the busy state is visible and repeated activation is prevented. [ ] Simulate an unavailable time: entered details are kept and another time can be chosen. [ ] Simulate no availability: a useful empty state and next step appear. [ ] Reset during a pending response: the old response does not overwrite the reset screen. [ ] Confirm: the final summary matches the chosen time and entered example email. [ ] The prototype states which services are simulated. No real appointment, email or payment occurs. OBSERVE THE PARTICIPANT [ ] Read the neutral task rather than a click-by-click instruction. [ ] Watch actions and expectations before explaining the interface. [ ] Note hesitations, wrong turns, questions and any help given. [ ] Ask what tells them the task is finished and what they expect next. DECIDE WHAT TO CHANGE [ ] Separate observed behavior from your interpretation. [ ] Pick a specific change tied to an observed problem, then test that part again. [ ] Keep agent functional checks, human participant observations and real conversion data separate. This checklist is a starter for this example, not a complete accessibility or production-readiness audit.
Where AI helps, and when to pay
AI can make a first layout or help implement a response state. It still needs the audience, task and constraints in the brief. Check the generated result against those requirements instead of assuming a polished screen is ready to test.
Figma Starter currently includes 150 AI credits per day, capped at 500 per month. Both limits apply; they are not a guaranteed number of prompts. The Figma agent can edit your own Drafts on Starter. Agent edits in shared files require a Full seat and edit access, and some features require paid plans. See the current credit rules and agent permissions.
Figma Make is a separate prompt-to-app tool, not the same thing as connecting native Design frames. Its Starter AI allowance does not mean every publishing or backend capability is free. Likewise, Meet’s “Take notes for me” needs an eligible Workspace or Google AI plan; it is not part of the ordinary free personal setup above.
Pay when a specific constraint blocks your work: collaborative editing beyond the Starter allowance, a reusable team library, source-hidden prototype sharing or an eligible recording feature. A prettier screen alone is a weak reason to expand the stack.
Next: build the flow you have learned from. If you are moving into code, use the tested UI-library comparison to choose components. For dashboard layouts, compare dashboard UI kits and their free metric cards. If you need a public marketing site rather than an app, start with the Webflow vs Framer comparison.
About the example: Superfounder’s agent built and checked this original browser flow on November 10, 2026, using fictional data. Screenshots are actual browser renders at 1280px and 390px viewport widths. The wireframe is a low-fidelity view of the same code, not a screenshot of Figma. Free-plan and AI conditions come from official documentation; no Figma Starter account trial or human participant study is claimed.