Prototyping Fundamentals

Introduction

A prototype is an interactive representation of a proposed product, service, or interface. It allows designers, developers, clients, and users to experience a design before the final product is built. In Figma, prototyping connects frames and defines what happens when a user interacts with an object. A prototype may be simple and low-fidelity, such as a sequence of wireframes, or highly realistic, including animation, overlays, scrolling, device frames, and presentation controls.

Prototyping is not merely the addition of visual effects. Its central purpose is to model user behaviour: what the user wants to accomplish, which path the user follows, what feedback the interface provides, and what happens when an action succeeds or fails. A good prototype therefore represents both the structure of the interface and the logic of interaction.

Learning Objectives

By the end of this chapter, you should be able to:

• define a user flow and distinguish it from a screen sequence;
• identify triggers, actions, transitions, and destinations in Figma;
• connect screens using navigation and interaction principles;
• configure overlays, scrolling behaviour, and device settings;
• use presentation controls to communicate and test a prototype;
• select suitable interaction patterns for common interface problems;
• evaluate prototype quality, accessibility, and ethical implications.

1. User Flows: The Logic of Experience

A user flow is the ordered path a person takes through an interface to complete a goal. For example, an online purchase flow may be:

1. Open product catalogue.
2. Select a product.
3. Add the product to a cart.
4. Review the cart.
5. Enter delivery information.
6. Confirm payment.
7. Receive confirmation.

A flow is different from a collection of screens. A screen describes a state of the interface; a flow describes movement between states in response to user intention and system feedback. One screen may support several flows, and one flow may include alternate routes for errors, cancellation, or returning users.

A useful way to model an interaction is:

Trigger → Action → Transition → Destination state

A button tap is the trigger, navigation to another frame is the action, an animation such as “Smart Animate” is the transition, and the new frame is the destination state.

Figure: A simplified purchase flow represented as connected interface states.

Mapping a flow before building it

Before connecting frames, write the user goal, entry point, successful outcome, and possible interruptions. For each step, ask:

• What does the user see?
• What action is available?
• What system response is expected?
• Can the user undo, cancel, or go back?
• What happens if information is missing or invalid?

This method reduces accidental “dead ends”—screens from which no meaningful next action is possible. It also reveals where a prototype needs additional states, such as loading, empty, error, permission, or success states.

2. Figma’s Interaction Model

In Figma, prototype connections are created from objects or frames in the Design and Prototype workflows. A connection generally includes four parts.

The exact available options can vary with the selected object, frame, device, and current Figma features. The conceptual model remains stable even when the interface changes.

Triggers

A trigger is the event that initiates a response. Common triggers include:

• On click/tap: appropriate for buttons, links, cards, and controls.
• While hovering: useful for desktop menus, tooltips, and visual feedback; it is not sufficient for touch-only devices.
• While pressing: useful for press states or temporary interaction feedback.
• Key/gamepad: useful for keyboard navigation, kiosks, and interactive demonstrations.
• After delay: useful for splash screens, timed banners, and automatic transitions.
• Mouse enter/leave: useful for desktop pointer behaviour.

Use the least surprising trigger. A primary action should generally be activated by a clearly labelled control rather than by an arbitrary area of the screen. Hover interactions should not carry essential information because many users do not have a pointer device.

Actions

Actions determine what happens after a trigger. Common actions include:

• Navigate to: changes the current frame to another frame.
• Back: returns to the previous history position.
• Scroll to: moves to a target layer within a scrollable frame.
• Open overlay: displays a temporary layer above the current frame.
• Swap overlay: replaces one overlay with another.
• Close overlay: dismisses a menu, dialog, or tooltip.
• Open link: launches an external or internal web address when appropriate.
• Change to: switches between variants in a component set, such as default and selected states.

A prototype should distinguish navigation from temporary interruption. A full-page checkout is usually navigation; a confirmation dialog or filter menu is usually an overlay.

3. Navigation and Transitions

Navigation defines how users move through the information architecture. Typical patterns include:

• Forward navigation: moves to the next task step.
• Back navigation: returns to the previous context without losing appropriate data.
• Persistent navigation: tabs, navigation bars, or sidebars remain available across major sections.
• Hierarchical navigation: users move from broad categories to detailed content.
• Modal navigation: a temporary decision interrupts the current task.

A prototype should preserve orientation. Labels, page titles, selected navigation states, and visible back controls help users understand where they are.

Choosing transitions

Transitions communicate continuity and hierarchy. An instant transition suggests that the old state has been replaced. A dissolve suggests a simple change. A slide may indicate movement between adjacent pages. Smart Animate can communicate a transformation when matching layers have compatible names and structures.

Motion should support meaning rather than decorate every interaction. Excessive animation can slow task completion, create distraction, and cause discomfort. Keep duration appropriate to the task, provide a reduced-motion alternative in the real product, and avoid implying a relationship that does not exist.

A useful design question is: “What should the user understand from this movement?” If the answer is nothing, a simpler transition may be better.

4. Overlays and Temporary States

An overlay is a layer displayed above the current frame. Examples include menus, dialogs, bottom sheets, tooltips, date pickers, and confirmation messages. Overlays are valuable because they preserve the user’s underlying context while presenting a focused task.

Important overlay decisions include:

• position: centred, top, bottom, or attached to a control;
• background treatment: transparent, dimmed, or visually blocked;
• dismissal: close button, outside click, Escape key, or completion;
• interaction with the background: allowed or prevented;
• size and scrolling: fixed, content-sized, or independently scrollable.

A destructive confirmation dialog should state the consequence clearly and provide distinct actions, such as “Delete” and “Cancel.” Do not make accidental dismissal the only way to leave an important decision.

Overlays can also be misused. If users must repeatedly open a modal to compare information, full-page navigation or an expandable section may be more appropriate. Modals that interrupt users without necessity create friction and may conceal important information.

5. Scrolling and Long Content

Scrolling allows a frame to represent content larger than its visible viewport. In Figma, the frame must be configured with suitable overflow behaviour, and the content must extend beyond the frame’s visible region. Common patterns include vertical scrolling for feeds, horizontal scrolling for carousels, and fixed-position elements such as headers or bottom navigation.

When designing scrolling prototypes, check:

1. The viewport is the correct device or frame size.
2. Content extends beyond the viewport in the intended direction.
3. Overflow is configured consistently with the interaction.
4. Fixed elements do not obscure essential content.
5. The user can identify that additional content exists.
6. Keyboard and touch expectations are not contradicted by the design.

A long page should have a clear information structure. Headings, spacing, grouping, and progressive disclosure help users maintain orientation. A prototype that scrolls technically but lacks visual hierarchy does not necessarily provide a good experience.

6. Components, Variants, and Reusable Interaction Patterns

Interactive components reduce inconsistency. A button component may contain variants such as default, hover, pressed, disabled, and loading. Variant changes allow a prototype to model local state without navigating to an entirely different page.

For example, a checkbox may change from unchecked to checked when clicked. A tab component may change its selected variant and reveal the relevant content. A menu component may open an overlay and then close when an item is selected.

Use components when the interaction pattern repeats. Reuse improves maintainability, but it does not remove the need for usability testing. A technically consistent component can still contain poor labels, inadequate contrast, or an inappropriate trigger.

7. Device Settings and Presentation Controls

Device settings influence how a prototype is experienced. In presentation or preview mode, designers may select a device frame, orientation, background, scale, and starting point. These settings are useful for communicating intended context—for example, a mobile banking flow should be viewed at a mobile proportion rather than only as an unframed desktop canvas.

Presentation controls commonly include:

• selecting the starting frame or flow;
• previewing interactions in a separate window or presentation mode;
• changing device frame and orientation;
• controlling scale and fit-to-screen behaviour;
• sharing a prototype link with suitable permissions;
• restarting the flow during a demonstration;
• inspecting hotspots or interaction connections during testing.

Presentation is not the same as validation. A polished walkthrough can conceal usability problems. Testers should be allowed to attempt tasks without being guided through every click, and the facilitator should record confusion, errors, hesitation, and workarounds.

8. A Practical Prototyping Workflow

A reliable workflow moves from purpose to detail:

Step 1: Define the task

State the user goal in observable terms, such as “Find a blue jacket and save it for later.” Avoid vague goals such as “Explore the app.”

Step 2: Identify the minimum flow

List the essential screens and states. Include at least one successful route and important failure or cancellation routes.

Step 3: Prepare frames and components

Name frames clearly, organise them by flow, and use shared components for repeated controls.

Step 4: Connect primary actions

Start with major navigation, submission, back, and close actions. Confirm that every required screen is reachable.

Step 5: Add state and feedback

Model loading, validation, selected, empty, error, success, and disabled states where they affect the task.

Step 6: Add transitions and overlays

Choose motion and overlays to clarify relationships. Avoid adding animation before the flow itself works.

Step 7: Configure scrolling and device context

Set the viewport, overflow behaviour, fixed elements, device frame, and starting point.

Step 8: Test and refine

Run the flow as a user would. Test normal, error, back, cancel, and restart paths. Share with others and revise based on evidence.

Worked Example: A Mobile Appointment Booking Flow

Consider a fictional illustrative scenario: a community clinic wants a prototype for booking an appointment.

Background: Patients currently telephone the clinic, and staff spend considerable time answering routine scheduling questions.

Problem: The proposed mobile interface must allow a patient to select a service, choose a time, confirm details, and receive clear feedback.

Analysis: The essential flow is:

Home → Select service → Choose date and time → Patient details → Confirmation.

Additional states are required for unavailable times, missing details, network delay, and cancellation.

Approach: The designer creates frames for each major state. The “Book appointment” button uses an On click trigger with Navigate to. The calendar uses Change to for selected dates. A time-selection error appears as an overlay or inline message, depending on whether the user must remain in the same context. The confirmation screen uses a clear success message and provides a route back to Home. A bottom sheet presents available services without forcing the patient to lose the current context.

Outcome: The prototype allows staff to observe whether patients understand the booking sequence before development begins. Testing reveals that users interpret “Continue” as saving rather than proceeding, so the label is changed to “Review appointment.” It also reveals that unavailable times need a visible explanation rather than simply appearing disabled.

Learning points: The value of the prototype lies not only in its clickable screens. It exposes ambiguous wording, missing states, and incorrect assumptions about user expectations. The final prototype therefore includes explicit feedback, cancellation, back navigation, and a confirmation summary.

9. Quality Evaluation and Common Problems

A prototype can be evaluated against five practical criteria:

Common problems include dead-end screens, links attached to the wrong object, missing back behaviour, overlays that cannot be dismissed, transitions that obscure the destination, and flows that work only when the facilitator explains them. Another problem is prototype inflation: building every possible feature before testing the central task. A smaller, focused prototype usually produces more useful evidence sooner.

10. Accessibility, Ethics, and Professional Practice

Prototype decisions can imply the behaviour of the final product, so accessibility must be considered early. Use meaningful labels, sufficient contrast, logical focus order, and alternatives to hover-only interactions. Do not assume colour alone communicates state. Motion should not be essential for understanding, and users should be able to complete important actions without precision pointer movements.

Ethically, prototypes should not mislead participants about what is functional, what data is real, or what will happen after a test. If a prototype simulates payment, health information, or identity verification, use fictional data and explain the simulation. Obtain appropriate consent when recording sessions. Avoid collecting unnecessary personal information in shared prototype links.

AI-assisted design tools may generate layouts, copy, or interaction suggestions, but designers remain responsible for accuracy, accessibility, privacy, copyright, and bias. Generated content should be reviewed rather than accepted as evidence of user need.

Contemporary Practice

Modern prototyping increasingly combines design files with component systems, accessibility checks, developer handoff, and usability research. Variables, reusable components, conditional states, and richer interaction logic can make prototypes more realistic. However, fidelity should be proportional to the question being investigated. A low-fidelity flow is often best for testing information architecture; a high-fidelity prototype is more appropriate for evaluating motion, content hierarchy, or stakeholder confidence.

Chapter Summary

Prototyping represents interactive states and the relationships between them. A user flow begins with a user goal and maps the screens, actions, feedback, and alternative paths required to achieve it. In Figma, interactions are structured through triggers, actions, destinations, and transitions. Navigation connects major states, while overlays preserve context for temporary tasks. Scrolling represents content beyond a viewport, and components and variants support reusable local states. Device settings and presentation controls help communicate intended context, but presentation quality does not replace usability testing. Effective prototypes include error recovery, clear feedback, accessible interaction, appropriate motion, and realistic constraints. The professional objective is not to make every screen clickable; it is to learn whether users can understand and complete meaningful tasks.

Key Terms

User flow: The path a user follows to accomplish a goal.

Prototype: An interactive or static representation of a proposed product.

Frame: A bounded design area that can represent an interface screen or state.

Trigger: An event that initiates an interaction.

Action: The operation performed after a trigger.

Destination: The target frame, layer, variant, or position reached by an action.

Transition: The visual change between interface states.

Navigate to: An action that moves the user to another frame.

Overlay: A temporary layer displayed above the current frame.

Scroll: Movement through content that exceeds the visible viewport.

Variant: A version of a component representing a different state.

Smart Animate: A transition method that animates compatible matching layers.

Viewport: The visible portion of a larger interface or content area.

Dead end: A state from which the user cannot continue or recover meaningfully.

Error state: Interface feedback indicating that an operation failed or input is invalid.

Presentation mode: A view used to preview or demonstrate a prototype.

Progressive disclosure: Revealing information or controls as they become relevant.

Usability testing: Observing representative users attempting realistic tasks.

Review Questions

Short Answer Questions

1. What is the difference between a user flow and a sequence of screens?
2. Define a trigger and give two examples.
3. When is an overlay more suitable than full-page navigation?
4. Why should hover-only interactions not carry essential information?
5. What is the purpose of a prototype starting point?

Long Answer Questions

1. Explain the relationship between triggers, actions, destinations, and transitions in a Figma prototype.
2. Describe a systematic workflow for creating and testing a task-based prototype.
3. Compare navigation, overlays, and component variants as ways of representing interface state.
4. Explain how scrolling, fixed elements, and device settings influence prototype realism.
5. Discuss accessibility and ethical responsibilities when sharing and testing prototypes.

Analytical / Application Questions

1. Design a user flow for a food-delivery checkout. Identify the successful path, two error states, and the appropriate Figma action for each major step.
2. A mobile filter menu opens as a full page, causes users to lose their search results, and has no clear close control. Analyse the problem and propose an improved interaction model.
3. During testing, users repeatedly press a disabled time slot because they do not know why it is unavailable. Recommend changes to the prototype’s state, copy, feedback, and flow, and justify each change.

Multiple Choice Questions with Answers

Question 1

Which sequence best represents the basic logic of a prototype interaction?

A. Destination → trigger → action → transition

B. Trigger → action → transition → destination

C. Transition → destination → trigger → action

D. Action → destination → trigger → transition

Correct Answer: B. Trigger → action → transition → destination

Question 2

Which Figma action is most appropriate for displaying a temporary filter menu while preserving the current page?

A. Open overlay

B. Navigate to

C. Scroll to

D. Open link

Correct Answer: A. Open overlay

Question 3

What is the main purpose of a user flow?

A. To define the colour palette

B. To list every visual asset in a project

C. To represent the path a user follows to achieve a goal

D. To specify the final software architecture

Correct Answer: C. To represent the path a user follows to achieve a goal

Question 4

Which interaction is least appropriate for essential information on a touch-only device?

A. Tap

B. Swipe

C. Hover

D. Press a clearly labelled button

Correct Answer: C. Hover

Question 5

Which action is generally appropriate for switching a checkbox from unchecked to checked within the same component?

A. Change to

B. Open link

C. Back

D. Scroll to

Correct Answer: A. Change to

Question 6

What is a dead end in a prototype?

A. A frame with a device setting

B. A state from which the user cannot continue or recover meaningfully

C. A frame containing an overlay

D. A screen with a long scrolling area

Correct Answer: B. A state from which the user cannot continue or recover meaningfully

Question 7

Which transition is most likely to communicate movement between adjacent pages?

A. Slide

B. Instant only

C. Random delay

D. Close overlay

Correct Answer: A. Slide

Question 8

Why are loading, error, and success states included in a realistic prototype?

A. To increase the number of frames regardless of purpose

B. To represent important system feedback and alternative paths

C. To replace all usability testing

D. To make every interaction modal

Correct Answer: B. To represent important system feedback and alternative paths

Question 9

Which practice best supports accessible prototyping?

A. Relying on colour alone to communicate state

B. Using hover as the only way to reveal essential controls

C. Providing meaningful labels and alternatives to pointer-only interaction

D. Adding animation to every transition

Correct Answer: C. Providing meaningful labels and alternatives to pointer-only interaction

Question 10

What does presentation mode primarily allow a designer to do?

A. Compile production software

B. Preview and demonstrate prototype interactions in a chosen context

C. Automatically validate all user needs

D. Replace component organisation

Correct Answer: B. Preview and demonstrate prototype interactions in a chosen context