This topic is where everything you have practiced in Figma comes together as a team deliverable. Rather than learning a new tool feature in isolation, you will plan the scope of your group project, agree on a screen inventory, split the build across team members, and then move through a structured cycle of self-review, peer evaluation, and iteration before submitting a shareable prototype link.
The practical challenge in group prototyping is consistency. When four people build screens in the same file, buttons drift in size, colors multiply, and flows stop connecting. Shared libraries, reusable components, and a clear naming and page structure are what keep a multi-person file coherent, and they also make design QA much faster because you can check one component instead of twenty copies of it. Equally important is the collaborative side: mapping flows together before anyone starts pushing pixels, and giving and receiving feedback in a form your teammates can actually act on.
As you watch, look for three things. First, how shared components and libraries let a team work in parallel without the design falling apart. Second, how to safely test and update a component after feedback arrives, so iteration does not break screens other people built. Third, how a collaborative whiteboard can be used up front to agree on scope, user flows, and task assignments, and later to collect peer evaluation notes in one visible place.
Part of Figma's official learning series on prototyping as a product person, this lesson focuses on libraries: collections of shared styles and components that can be published and reused across a file or team. Expect coverage of why you would build a library, how publishing and consuming shared assets works, and how this supports consistency in a lightweight prototype.
Produced by Figma itself, so the workflow shown matches the current product, and libraries are the single most useful mechanism for letting several group members build different screens that still look like one product.
A short official Figma video on updating and testing design system components, using branching as a space to explore changes before they are applied to the main file. It walks through the idea of trying a component update in isolation, reviewing it, and then merging it back.
This maps directly onto the iterate-based-on-feedback subtopic: it shows a safe, reviewable way to act on peer evaluation comments without breaking screens your teammates are still working on.
A beginner tutorial from CharliMarieTV introducing FigJam, Figma's collaborative whiteboard, and the tools it offers for brainstorming and building user flows. It covers the basic toolset and how to assemble a flow diagram with a team.
It fits the planning and feedback ends of this topic, giving your group a shared space to define project scope, lay out the screen inventory and flows, divide work, and later gather peer evaluation notes where everyone can see them.
Together these videos support the module outcomes by addressing the parts of prototyping that only show up in team work. The FigJam tutorial helps your group agree on flows and screens before building, which feeds directly into constructing an interactive prototype (MO1) with coherent interactive flows (MO3). The libraries lesson supports consistency and visual hierarchy across screens built by different people (MO2) and reinforces component-based construction (MO3). The component update and branching video closes the loop, showing how to apply peer feedback to shared components without destabilizing the prototype, so your final submission remains a working, realistic simulation of user interaction (MO1, 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.