Building and Submitting the Group Project Prototype

Delivering a group design project is never simply a matter of producing individual screens and stitching them together at the last moment. A successful Figma prototype submission demands structured planning, disciplined collaboration, rigorous self-review, and a willingness to incorporate external feedback. This topic brings together every skill covered throughout the module — components, styles, auto layout, prototyping connections, and shared libraries — and applies them inside a real team workflow with a defined deliverable at the end. The sections below walk through each phase of that process in the order a team would encounter it: scoping the work, dividing it sensibly, checking quality, setting up peer review, receiving and acting on feedback, and finally preparing the file for submission.

Project Scope and Screen Inventory

Before a single frame is created, the team must agree on exactly what the prototype will contain. A screen inventory is a structured list of every frame the finished prototype needs, together with notes about which user task or flow each frame serves. Writing this list down — even as a simple table in a shared document or a sticky-note cluster on a Figma canvas — forces the team to think about the product holistically rather than jumping straight into visual work.

The most productive way to build the inventory is to trace the core user journey first. Ask: what is the single most important thing a user should be able to accomplish with this product? Every screen that sits on that path is tier-one priority. Screens that support secondary tasks, edge cases, error states, or settings belong to a second tier that the team only builds after the primary journey is complete and working. This sequencing is practical: if time runs short, the prototype still demonstrates its central value proposition rather than being a collection of disconnected secondary screens.

Each entry in the inventory should carry a shared definition of done. For a Figma project this typically means: all text uses a named text style from the shared library; all colours use a named colour style; all repeating elements use a published component rather than a copied frame; and the screen has at least the prototype connections required by the flow it belongs to. Agreeing on this definition before work starts prevents the situation where one team member considers a screen finished while another sees it as barely sketched.

A screen inventory table might look like this in practice:

Reviewing the inventory at every team check-in — even briefly — surfaces blockers early. If S-04 is still not started two sessions before the deadline, the team can redistribute work or descope S-06 and S-07 before the crunch. An inventory that is only checked on the final day is barely more useful than having no inventory at all.

Dividing Work Across Team Members

Figma allows multiple editors to work in the same file simultaneously, which is powerful but also a source of chaos when roles are not clearly defined. The most reliable strategy is frame ownership: each team member is assigned specific pages or frames and is the only person who makes structural edits to those frames. Others may add comments or suggest changes, but they do not move, resize, or redesign frames they do not own without coordinating first. This avoids the disorienting experience of returning to a frame you were halfway through building to find that a teammate has rearranged it.

Ownership does not mean isolation. Every team member must draw from the shared component library rather than building ad-hoc elements. If Maya needs a button, she drags an instance from the library. If James needs a card, he uses the published card component. Nobody recreates a button from scratch on their own canvas because they find it faster in the moment. Ad-hoc elements are the most common source of visual inconsistencies in group projects: two buttons that are almost-but-not-quite the same size, two shades of blue that are close but not identical. Using shared components eliminates this class of problem entirely.

Teams should schedule a regular sync — ideally at the start or end of every working session — where each member briefly demonstrates their current frames on a shared screen. This is not a lengthy critique session; it is a five-minute visual check to catch obvious inconsistencies before they compound. A common inconsistency that emerges at this stage is spacing: one team member has been using 16 px internal padding on cards while another has been using 12 px. Catching this in session two is a two-minute fix; catching it in the final hour before submission is a major headache.

Figma comments are the correct channel for asynchronous questions and review requests. Instead of sending a message outside the tool saying "I'm not sure the navigation bar looks right," a team member clicks the comment icon, pins a comment directly to the navigation bar frame, and tags the relevant teammate. This keeps feedback attached to its context, creates a searchable record of decisions, and does not disrupt the file structure. Teams should agree at the start of the project on a simple convention for comment status — for example, using the heart reaction to indicate a comment has been read and using the resolve button only when the issue is fully addressed.

Self-Review and Design QA

Before the prototype is shared with anyone outside the team, the team itself must conduct a thorough quality assurance pass. This is not casual browsing; it is a systematic check against a defined checklist. Rushing this step is the single most common cause of an embarrassing prototype presentation where a button goes nowhere or a screen still says "Lorem ipsum."

The first and most critical check is prototype connection completeness. Open the prototype panel and, starting from the designated start frame, click through every interactive element on every screen. Any element that is supposed to trigger a navigation — a button, a tab, a back arrow, a card — must have a connection to the correct destination frame. A frame that a user can reach but cannot leave is called a dead end, and it immediately breaks the evaluator's ability to experience the flow. A practical technique is to assign one team member the role of "evil user" during QA: their only job is to click everything on every screen and report anything that does not respond as expected.

The second check covers style consistency. Open the Figma selection panel and click through every text element on every screen. If any text shows a raw hex value or a font size that is not tied to a named text style, it must be corrected. Do the same for fills and colours. The design panel makes this straightforward: locally applied styles show up differently from library-linked styles. Any element that does not use a named style is a compliance failure against the shared definition of done.

The third check confirms component integrity. Select every element that should be a component instance. If the panel shows "Frame" rather than a component name, the element has been detached or was never made into a component instance. Detached copies will not update when the library is changed, and they are a signal that shortcuts were taken. Reconnecting a detached element usually means deleting it and replacing it with a fresh instance from the library.

The fourth check is a content audit. Every screen should use realistic, representative copy rather than placeholder text. "Lorem ipsum dolor sit amet" tells an evaluator nothing about the product and actively undermines their ability to judge the design. Replace placeholder headlines with actual product names, placeholder body copy with realistic descriptions that fit the available space, and placeholder user names with plausible examples. Realistic content also exposes layout problems that placeholder text hides: a realistic product name that is 40 characters long may overflow a card that looked fine with "Product Name" in it.

Setting Up for Peer Evaluation

A prototype that is technically complete but poorly shared is still a poor submission. Setting up for peer evaluation requires deliberate configuration of several Figma settings.

First, set the prototype start frame. In Figma's prototype panel, only one frame can be designated as the starting point — the frame that opens when someone follows the prototype link. This should be the most logical entry point for a new viewer, which in almost every case is either a splash screen, an onboarding screen, or a login screen. Do not leave the start frame set to whichever frame happened to be selected last during editing; set it intentionally.

Second, configure the share settings correctly. The prototype link should be shared with "can view" access and, importantly, with comment access enabled. Peer evaluators need to be able to add comments without being able to edit the file. If comment access is not enabled, evaluators are forced to send their feedback through a separate channel, which makes it far harder to attach observations to specific frames.

Third, include a written context note. Evaluators should not have to guess what the product is or who it is designed for. A two- to four-sentence description — either in the Figma file description field, on a cover page frame at the beginning of the file, or in the body of the message used to share the link — is sufficient. It should describe the product concept, the target user, and the specific flow the prototype demonstrates. For example: "This prototype represents a mobile app for independent musicians to track live performance bookings. The core flow demonstrates how a new user signs up, searches for available venues, and submits a booking request. The prototype is optimised for a 375 × 812 px mobile viewport."

Fourth, and critically, test the link before sharing it. Open an incognito or private browser window — one that has no Figma login — and paste the prototype link. If the prototype opens and is interactive, the share settings are correct. If the page asks for a login or shows an error, the link is not publicly accessible and evaluators will not be able to view it. This single test takes thirty seconds and prevents a very common and avoidable problem.

Conducting and Receiving Peer Evaluation

Peer evaluation is valuable precisely because external eyes notice things that creators, who are deeply familiar with their own work, have stopped seeing. Evaluators need to approach the prototype with structured discipline rather than vague impressions, and they need to communicate their findings in a way that is useful to the receiving team.

Figma comments pinned to specific frames are far more useful than general notes delivered outside the tool. When an evaluator notices that the back button on the product detail screen does not return to the listing screen, they pin a comment directly to that button on that frame. The receiving team can then open the comment, see exactly what element is being discussed, and resolve it with precision. A comment that says "some of the navigation feels broken" is nearly useless; a pinned comment on the specific broken element is immediately actionable.

Evaluators should inspect the prototype across two distinct dimensions and keep their feedback separated accordingly. The first dimension is interactive flow completeness: can the user complete the stated task from start to finish without hitting a dead end or being forced off an unintended path? The second dimension is visual design quality: is the hierarchy clear, are the styles applied consistently, does the layout feel considered, does the content feel realistic? Conflating these two dimensions leads to feedback that is difficult to triage. A flow problem is critical; a colour preference is cosmetic.

Every piece of evaluator feedback should include at least two constructive suggestions alongside any identified issue. Pointing out that a button is hard to find is useful; suggesting that the button could be made more prominent by increasing its contrast ratio or repositioning it above the fold is genuinely helpful. The goal of peer evaluation in a learning context is not to produce a grade — it is to generate specific, actionable insights that the receiving team can use to improve their work before final submission.

Teams receiving feedback should resist the impulse to defend or explain their design choices in the moment. The evaluator's experience of the prototype is data. If an evaluator could not find the navigation, the navigation may need to be reconsidered — regardless of whether the designer believed it was clearly placed. Note every comment, thank the evaluators for their time, and then triage privately.

Iterating Based on Feedback

Not all feedback is equal, and treating it as such leads either to paralysis (too many things to fix) or to poor prioritisation (fixing cosmetic issues while navigation remains broken). The first step after receiving peer feedback is triage.

Feedback falls broadly into two categories. Critical issues are anything that prevents a user from completing the intended flow: a broken prototype connection, a screen with no exit, an interaction that triggers but navigates to the wrong frame, or a missing screen that the flow depends on. These must be resolved before any other work is done. A prototype with a polished colour palette but a broken core flow is a failed prototype. A prototype with slightly imperfect spacing but a complete, navigable flow is a functional prototype.

Cosmetic improvements — inconsistent spacing, a font weight that does not quite match the style guide, a component that could use a more refined shadow — are addressed after all critical issues are resolved. They matter, and they should be addressed before final submission if time allows, but they are never the priority over functional completeness.

Every change made in response to feedback should be documented. This documentation does not need to be elaborate: a simple log noting the feedback received, what was changed, and why is sufficient. For example:

This documentation serves two purposes. Practically, it ensures that no piece of feedback is lost or accidentally ignored. Academically, it provides the evidence base for reflection: a written record of what was improved, why, and how demonstrates design thinking and professional practice far more convincingly than a polished file alone.

Once revisions are complete, the updated prototype link — which is the same link, since Figma links reflect the live state of the file — should be shared again with the evaluators. A brief notification is courteous and useful: "We have addressed the feedback from the peer review session. The updated prototype is now available at the same link. Thank you for your comments — they led to significant improvements in the booking flow." This closes the feedback loop and demonstrates that the evaluation was taken seriously.

The final submission, then, is not simply a Figma file. It is the end product of a structured process: a scoped screen inventory, a clearly divided and well-coordinated build phase, a systematic QA pass, a correctly configured prototype link, an external evaluation with documented findings, and a revision phase that prioritised function over aesthetics. Each of these steps reinforces and depends on the others, and together they constitute the kind of design delivery process used in professional product teams.