A high-fidelity mockup shows what an interface will look like; a functional prototype shows what it will do. In this topic we examine that shift: what actually makes a prototype "functional," why polished static screens are not enough once real users sit down with your design, and how to decide when your team is ready to move from visual design tools into interactive or coded builds.
The practical pressure point is usability testing. If a participant taps a region that was never wired up, or needs data that your mockup only fakes with a screenshot, the test stops producing useful findings and starts producing apologies. That is why scoping matters: you do not build everything, you build the paths your test tasks require, at a fidelity that lets participants behave naturally and lets you observe where they struggle.
As you watch the videos below, keep three questions in mind. First, which parts of a design are being made real versus merely depicted? Second, what kinds of user behavior can each level of fidelity reveal, and what does it hide? Third, how would you trim a full product vision down to a testable slice that still implements the core features from your own project requirements?
Part of the Google UX Design Certificate series, this video walks through moving from lower-fidelity work into high-fidelity design, incorporating visual design elements, type, color and layout into new iterations of your screens. It is framed as a step in a larger design process rather than an endpoint, so it shows what a high-fidelity mockup actually delivers and where it sits in the workflow. Expect practical guidance on building polished iterations that are ready to be made interactive.
It gives you a clear, industry-standard picture of what a high-fidelity mockup is and is not, which is the necessary baseline for understanding the limitations discussed in this topic, and it comes from a widely used professional certificate program.
A beginner-oriented Figma tutorial focused specifically on the prototyping features of the tool: connecting frames, defining interactions and transitions, and turning static artboards into something a person can click through. It demonstrates the hands-on mechanics of adding behavior to screens you have already designed. The tutorial format means you can follow along with your own project files.
This is the most direct demonstration of the mockup-to-interactive transition, showing exactly which behaviors prototyping tools can simulate and, by implication, where you will need coded implementation instead.
A short, focused overview placing usability testing as the validation stage that follows prototyping in the design thinking process. In four minutes it introduces why testing happens after you have something users can interact with and what the step is meant to validate about earlier design decisions. It frames testing as a check on prior assumptions rather than a final rubber stamp.
It connects prototype readiness directly to the purpose of testing, which is the reasoning behind both transition-readiness criteria and prototype scoping, and its brevity makes it a useful conceptual anchor for the rest of the module.
Together these videos trace the arc of the module. The Google Certificate video establishes what a high-fidelity mockup contributes and where it stops, and the Figma prototyping tutorial supplies concrete technique for making those screens interactive, both supporting MO1 as you build a prototype that implements your project's core features. The usability testing overview supplies the rationale for MO2 by showing what the testing stage is meant to validate, which in turn shapes the task scripts and data you plan to collect. Taken as a set, they also inform MO3: knowing what a functional prototype must support before testing is exactly the standard against which you verify your build against the specified interface requirements.
These videos were chosen from YouTube on October 3, 2026. Each has captions; the player turns them on. Videos on YouTube can be changed or removed — if one no longer plays, tell your instructor. If a player does not appear, use its Watch on YouTube link.
Moving from a polished mockup to working code is one of the most error-prone steps in interface development. Designs that look complete on a canvas often leave gaps: What happens when a field is empty? What exactly is the spacing between list items? Which screen comes next after a failed login? Transition strategies from design to code are the practices that close those gaps before coding begins, and that keep the build honest once it is underway.
In this module you are building a functional prototype of your own design, so you are both the designer and the developer handing off to yourself — or to a teammate. Four practices matter here: preparing assets and specifications so nothing has to be guessed, building reusable components first rather than screen-by-screen, reviewing the build against the design in short cycles, and catching design drift when implementation choices quietly diverge from the agreed interface.
The videos below demonstrate these practices in Figma, the tool most commonly used for this workflow. As you watch, pay attention to what information the designer deliberately attaches to a file — annotations, flow diagrams, spacing values, exported assets, naming conventions — and ask whether your own project file carries enough of that information for someone to code from it without asking you questions. Also notice how components and styles in the design map onto reusable units in code; that mapping is the backbone of a component-first build.
A long-form walkthrough of developer handoff in Figma, covering how to prepare a design file so that engineers can read specifications, measurements, and assets directly from it. Based on its title and description, it likely addresses file organization, naming, styles and components, and exporting assets for implementation. Expect practical, tool-centered demonstration rather than abstract theory.
Jesse Showalter is a well-known design/front-end educator whose handoff tutorials are widely used, and this video maps directly onto the Design Handoff and Asset Preparation subtopic while touching on component structure.
A short, focused look at how one designer preps a finalized file before giving it to engineers, emphasizing user flows and written annotations rather than isolated screens. The description makes the core argument explicit: individual screens do not capture the full user journey, so flows and notes are needed to communicate states, transitions, and edge cases.
It targets exactly the information that usually goes missing in handoff — flow context and annotated behavior — which is the main source of design drift once coding starts, and at under eight minutes it is an efficient companion to the longer tutorials.
An overview of Figma's Dev Mode, the feature set built specifically for the design-to-code transition. It likely demonstrates inspecting elements for measurements and generated code snippets, marking sections as ready for development, and tracking changes between design and build.
Dev Mode is the concrete mechanism most teams now use for iterative build and continuous review, so this video shows how component specs and updates flow to developers and how drift between file and code can be detected.
Together these videos support MO1 by showing how mockups, components, and assets are prepared and inspected so that a functional prototype can be coded from them with fidelity to the original interface design. The emphasis on flows, annotations, and documented states also feeds MO2, since the same flow documentation that guides developers becomes the basis for realistic task scripts in a user testing plan. Finally, the inspection and review practices demonstrated — comparing built screens against annotated specifications and marking work ready for development — give you a concrete method for MO3, verifying that the prototype actually meets the specified interface requirements before participants ever see it.
These videos were chosen from YouTube on October 3, 2026. Each has captions; the player turns them on. Videos on YouTube can be changed or removed — if one no longer plays, tell your instructor. If a player does not appear, use its Watch on YouTube link.
Before you can build a functional prototype, you need a place to build it. A development environment is the combination of tools you install and configure on your own machine — a language runtime, a framework, an editor, a package manager, a version control system, and a way to preview your work as you change it. Setting this up deliberately, rather than improvising, saves hours of confusion later and makes it possible for teammates to run the same project without surprises.
In this course the environment matters because your prototype has to be reachable by real test participants. That means choosing a technology stack you can actually finish in the time available, tracking your work in version control so changes are recoverable and attributable, running a local server with live reload so you can iterate quickly on interface details, and finally deploying a build somewhere participants can open it on their own devices.
The videos below approach this from three angles: a hands-on front-end setup walkthrough, a conceptual map of back-end options, and a focused look at isolating project dependencies. As you watch, pay attention to the setup steps themselves — what gets installed, what commands are run, what a project folder ends up looking like — and to the reasoning behind each tool choice. Ask yourself which parts your team's prototype actually needs and which are unnecessary complexity for a prototype that only has to survive a usability session.
Together these videos give you the practical foundation for MO1: you cannot develop a functional prototype without a working stack, a running local server, and a project structure that your team can share and rebuild. The backend overview helps you scope your technology choices realistically so the core features in your requirements are achievable, while the React setup walkthrough and the virtual environment tutorial establish the reproducible local workflow you will use throughout the build. That same reproducibility underpins MO3 — being able to run, rebuild, and deploy a known version of your prototype is what lets you check it against the interface requirements before participants see it, and a deployed, stable build is the precondition for executing the testing plan you design under MO2.
These videos were chosen from YouTube on October 3, 2026. Each has captions; the player turns them on. Videos on YouTube can be changed or removed — if one no longer plays, tell your instructor. If a player does not appear, use its Watch on YouTube link.
Before a participant ever touches your prototype, you need to know something about them. A user proficiency survey is a short pre-test instrument that captures a participant's background, their familiarity with relevant technology, and their knowledge of the task domain. Without it, usability data is hard to interpret: a confusing task result might reflect a flawed interface, or it might simply reflect a participant who has never used software of that kind before.
In this topic you will decide which proficiency dimensions actually matter for your project (for example, frequency of use of similar tools, years of domain experience, device preferences, accessibility needs), then write questions that measure those dimensions without leading, biasing, or confusing the respondent. You will also think about structure and administration: question order, response scales, survey length, and when and how the survey is delivered relative to the test session.
The three videos below come from UX practitioners and focus on the craft of asking questions well. As you watch, pay close attention to the specific wording problems they flag — leading questions, double-barreled questions, vague scales, assumptions baked into the prompt — and keep a running list of fixes you can apply directly to your own pre-test survey draft.
This video looks at why surveys are such a popular UX research method and then walks through the common mistakes that produce unreliable data. Based on its description, expect coverage of flawed question wording, poor survey design choices, and the kinds of errors that lead to results you cannot trust. It is framed around diagnosing and avoiding problems rather than simply praising surveys as a method.
It speaks directly to the "writing effective survey questions" and "structuring and administering the survey" subtopics, and the mistake-focused framing gives you a practical checklist to review your own proficiency survey against before you send it to participants.
Maze, a research and testing platform company, offers five tips for creating effective user research questions and points to a free question bank you can draw from. The video's premise is that research quality is capped by question quality, so it concentrates on asking the right things in the right way. The accompanying question bank gives you concrete phrasing examples to adapt.
The tip-based format and the downloadable question bank are immediately useful when you are drafting items for proficiency dimensions such as technology familiarity and domain experience, and the producer builds research tooling used in industry.
This video focuses on user interview questions: which ones to ask, which to avoid, and how phrasing shapes the answers you get. Although it is framed around live interviews rather than written surveys, the underlying principles of neutral, non-leading, answerable questions transfer directly. It also helps you see when a question is better asked face-to-face than on a form.
It reinforces question-writing discipline from a second angle and helps you decide how to administer your proficiency screening — as a written pre-test survey, as a brief verbal intake, or as a combination of both.
These videos support MO2 most directly: a proficiency survey is one of the data collection instruments in your user testing plan, and the responses you gather also inform your participant criteria and screening decisions. Learning to write neutral, precise questions means the background data you collect will actually explain patterns in your test results rather than muddy them. Indirectly, this work also supports MO1 and MO3, since knowing your participants' skill levels clarifies which prototype features must be functional and verifiable before testing begins.
These videos were chosen from YouTube on October 3, 2026. Each has captions; the player turns them on. Videos on YouTube can be changed or removed — if one no longer plays, tell your instructor. If a player does not appear, use its Watch on YouTube link.
A usability testing protocol is the written plan that makes a user study repeatable. It spells out who you will recruit, what tasks participants will attempt, what the facilitator will say at each stage, what data you will capture (time on task, errors, completion, think-aloud comments, satisfaction ratings), and the practical details of where and how sessions will run. Without this document, two facilitators running the "same" study will produce results you cannot compare.
In this course, the protocol is the bridge between the prototype you are building and the evidence you will collect about it. Your task scenarios must be realistic and goal-oriented rather than instructions that give away the interface; your script must keep you neutral so you do not accidentally coach participants toward success; and your logistics plan must account for consent, recording, timing, and backup options if the prototype breaks. Pilot testing the whole package with one or two people almost always exposes confusing wording and tasks that take far longer than you estimated.
As you watch, pay attention to the exact phrasing facilitators use when introducing a session, the order of steps a moderator follows, and the distinction between testing a product's usability and testing whether users want the product at all. Try to map what you see back to specific sections of the protocol document you will write for your own project.
A short demonstration from Nielsen Norman Group showing how a facilitator greets and orients a participant at the start of a usability test session. The description indicates it draws on a facilitator's script to cover the points that should be stated up front, such as explaining the purpose of the session and setting expectations before tasks begin.
It models the opening portion of a facilitator script, which is exactly the subtopic on developing facilitator scripts, and it comes from NN/g, a long-established usability research organization.
A checklist-style video presenting ten things a moderator should do when running a usability study. It walks through the sequence of steps a facilitator follows during a session and connects following that sequence to getting usable research findings.
A moderator checklist is essentially the procedural backbone of a testing protocol, so it supports both the anatomy-of-a-protocol and session-logistics subtopics in a compact, memorable format.
Kerev Design compares user testing and usability testing as two distinct activities within UX research, explaining what each one asks and when each is appropriate. The video situates both within the broader research process introduced in the channel's earlier UX research material.
Knowing which question you are actually answering determines how you write task scenarios and what data you plan to collect, so this conceptual distinction helps students scope their protocol correctly before drafting it.
Together these videos target MO2 most directly: the NN/g demonstration and moderator checklist give concrete models for the facilitator script, session sequence, and logistics sections of a testing plan, while the comparison video helps students frame the right research question so their task scripts and data collection instruments measure the right thing. Because the protocol defines what participants will be asked to do, writing it also forces students to confirm that the prototype actually supports those tasks, which feeds back into the prototype development and verification work in MO1 and MO3.
These videos were chosen from YouTube on October 3, 2026. Each has captions; the player turns them on. Videos on YouTube can be changed or removed — if one no longer plays, tell your instructor. If a player does not appear, use its Watch on YouTube link.
Up to this point in the module you have been building a functional prototype and drafting a user testing plan as if they were two separate deliverables. In practice they are one system: every task you ask a participant to perform must be supported by something that actually works in the prototype, with realistic data already loaded and the interface in a known starting state. Integrating prototype and testing preparation means walking through your protocol task by task and confirming that the build can carry it, trimming scope where it cannot, and deciding in advance what the prototype should look like the moment a participant sits down.
This topic covers three practical concerns. Aligning prototype scope with test tasks is about mapping each task script step to a screen, control, or flow that exists; anything unsupported either gets built, faked deliberately, or cut from the protocol. Preparing test data and prototype state covers seeding accounts, sample content, and default settings so sessions are comparable, plus the reset procedure between participants. Coordinating team roles across development and testing means naming who finishes the build, who facilitates, who takes notes, and who owns the pilot run that catches problems before real participants arrive.
The three videos below approach preparation from complementary angles: a research-practice checklist of pre-session work, a designer's end-to-end walkthrough of one usability study, and a set of best practices for running sessions well. While watching, keep your own project in mind and note anything that implies a prototype requirement — a piece of test data, a reset step, a role to assign, or a task you may need to narrow.
A short checklist-style video from Nielsen Norman Group covering ten things to do before you actually run a usability study. Based on its title and description, it should walk through planning steps such as clarifying research goals, writing and reviewing tasks, recruiting the right participants, and preparing materials and logistics in advance. It is presented as the first of a two-part set, with this half focused entirely on preparation rather than execution.
NNgroup is a long-established usability research organization, and a checklist framing maps directly onto the preparation work this topic requires. It is the most direct fit for aligning prototype scope with test tasks, since the checklist items tell you what must exist and be verified before testing day.
A practitioner walkthrough in which the creator explains her own process for planning, conducting, and synthesizing a usability testing session. Expect to see how a study is set up end to end, likely including preparing the test material and tasks, running the session, and turning observations into findings. Because it follows one project, you can see how the planning decisions connect to what actually happens in the session.
Seeing a complete start-to-finish example helps you understand why preparation choices matter downstream, which reinforces the idea that the prototype and protocol are built together. It is a useful model as you assemble your own task script and data collection instruments.
Maze presents five best practices intended to help teams gather accurate, ethical, and actionable usability insights. The description suggests coverage of things like framing tasks and questions neutrally, treating participants ethically, and avoiding common mistakes that distort results. Practices of this kind usually depend on groundwork done before the session begins.
Best-practice guidance highlights the conditions a session needs in order to produce trustworthy data, which in turn drives how you seed test data and set the prototype's starting state. It also helps clarify facilitation expectations, useful when dividing roles across your team.
Together these videos bridge MO1, MO2, and MO3. The NNgroup checklist and the Maze best practices give you concrete criteria for a defensible testing plan with task scripts, participant criteria, and data collection instruments (MO2), while also surfacing the pre-session verification work that confirms your prototype can support every planned task (MO3). The practitioner walkthrough shows the whole cycle in context, helping you judge which core features your build must genuinely implement versus simulate (MO1), and reinforcing that prototype readiness, test data, prototype state, and team role assignments should all be settled before the first participant arrives.
These videos were chosen from YouTube on October 3, 2026. Each has captions; the player turns them on. Videos on YouTube can be changed or removed — if one no longer plays, tell your instructor. If a player does not appear, use its Watch on YouTube link.