Yes—designers can build the behavior, too.
A functional prototype lets someone do a task with working logic. They can type their own information, submit a form, change a filter, and see the application respond. It helps you investigate questions that static screens cannot fully answer: Is this field necessary? Does the status label make sense after a change? Can someone recover after an error?
You do not need to learn an entire engineering stack before you begin. You do need to understand the small piece you are building, describe its behavior, and verify what the generated code actually does. Start with one useful interaction, then add complexity only when the learning question requires it.
Choose the level your question needs
| Level | What it can help you test | What you must not imply |
|---|---|---|
| Clickable mockup | Navigation, content order, and comprehension of a proposed journey. | Clicking through preset screens proves that real data or rules work. |
| Functional local prototype | Form rules, calculation, filtering, state changes, and saving within one browser. | Entries are backed up, shared, or synced between devices. |
| Connected prototype | A real service or database interaction with a deliberately limited test audience. | A successful test establishes reliable permissions, recovery, or readiness for all customers. |
| Maintained product | Ongoing use under defined operating and support conditions. | Publishing once removes the need for monitoring, updates, and a responsible owner. |
Start with a question, not a stack
“Can a freelance designer estimate a project quickly?” could become a calculator with a few editable inputs. “Can a reader retrieve a recommendation?” could become a local reading list. “Can a workshop visitor choose a useful session?” could become a schedule filter. These are excellent early prototypes because the central behavior can be tested without accounts or a live payment flow.
Write the task, inputs, rules, and result in plain language. For a calculator, define how the total changes and what invalid values mean. For a list, define what counts as a duplicate and what removal does. Use made-up names and examples. Do not connect confidential client or customer data just to make a demo feel realistic.
Bring more than a screenshot
A screenshot communicates appearance. Pair it with component states, text content, interaction rules, spacing and type choices, mobile behavior, and explicit scope. Tell your AI partner which parts of the design are intentional. Explain what to preserve and what it may propose changing. Ask it to identify ambiguity before generating a large application.
For example: the title field is required, saving preserves the author, successful submission returns focus to the title, and an invalid entry leaves the typed information available for correction. Those details give the builder something concrete to implement and you something concrete to evaluate.
Choose a workflow you can inspect
If you work in Figma, Figma Make can use existing designs as context for interactive applications and lets you edit the generated result. Check its current seat and plan requirements before committing to a workflow. Read Figma’s official Make guide.
If you want control of an existing codebase, work with a coding assistant inside that repository. Ask it to explain the entry point, how to run the project, the files it plans to change, and the smallest verification step. Keep changes in version control. If the task fits one page, a simple HTML/CSS/JavaScript prototype may be enough; a framework should solve a need you actually have.
Learn five concepts as you build
- Components: repeatable pieces of interface with a clear purpose.
- State: what is currently true, such as a selected filter or open dialog.
- Events: actions that trigger a change, such as submitting a form.
- Data: the records the experience displays and changes.
- Persistence: what survives a reload and where it is stored.
Ask the AI to show each concept in your actual project. A short explanation tied to a working interaction is more useful than a tour of every available technology.
TRY THIS BUILD BRIEF
Act as my implementation partner. I am a designer building one functional prototype to test [user task]. Use [design context]. Inputs: [fields]. Rules: [validation and calculations]. Expected result: [observable behavior]. Data is [fictional / browser-local / a named test source]. Explicitly exclude [features]. First identify missing decisions, explain the simplest implementation, and propose one small build step. After each step, explain what changed and give me a keyboard, invalid-input, and reload check. Do not describe simulated behavior as a live integration.
Keep simulation visible
A “Send” button that only displays a success message is a simulated submission. A booking screen without a calendar connection does not reserve a time. Label those boundaries near the action so testers know what to expect. In your research notes, distinguish a test of the interface from a test of an operational service.
Test the awkward parts early
Try a blank field, a long title, a second click, an empty result, a narrow screen, and keyboard-only operation. Reload after saving. Block storage or use a controlled failure state in your own copy. Ask someone to complete the task without explaining the interface to them. Record where they hesitate and what you changed afterward.
Turn the prototype into an asset
A useful prototype can support a product proposal, a client discussion, a usability study, a portfolio case study, or a decision not to build a larger product. Preserve the source, the brief, and the findings together. If customers will depend on it, plan permissions, data handling, monitoring, support, and recovery before presenting it as a finished service.
Build your first functional prototype
The reading-list project gives you a working reference, editable source, a walkthrough, and a Project Passport for your evidence.
Start the reading-list project