The stages after a design is produced: determining when it counts as "done", how to iterate based on feedback, how to run design critique meetings, and how to hand off the design hand off the design to developers. The methodology of usability studies itself is covered in Google UX Certificate / UX Research and Empathy-Define §6; this section covers what to do after you receive test results.
Significance for PMs:Design critique This set of rules — "3 roles + describe problems without giving solutions + turn feedback into action" — can be applied almost directly to your requirement reviews/solution reviews— especially the two rules "reviewers only describe problems, do not redesign for the other party" and "after the meeting, categorize feedback into adopt/defer/needs clarification", which can immediately improve the review quality in your team.
1. Three criteria for judging a design "done"
After finishing prototypes, testing, critiques, and revisions, designers often wonder "is it really done?". Don't use "time/budget ran out" as the only standard. Ask these 3 questions; if all answers are "yes", it is ready to hand off:
- Does it deliver the intended user experience? Can users complete core operations smoothly?
- Has all temporary content been replaced with final content? Are all text/icons/images real (not placeholders)?
- Can users understand it without instruction? If you are not there to explain, can users figure out how to use it on their own?
Mindset: don't chase perfection.Products continue to iterate after launch(updates every few weeks/months); the key is to make progress each time. New designers feel anxious about "stopping changes"; with experience you will naturally know when to hand off.
2. Iterating high-fidelity designs
After the second round of usability testing, update the design in Figma based on feedback.Key time-saving tip: high-fidelity prototype iteration is time-consuming; prioritize revising static mockups to solve problems first, then add interactions afterward..
Real case (second-round insights from a dog-walking App):
- Insight "users struggle to select dates from the calendar" → replaced the scroll wheel picker with a dropdown menu + pop-up full calendar (showing day/month/day of week), restyled using an off-the-shelf calendar component from the Figma Community.
- Insight "users only see the price at the end of the flow" → after the rating/distance on the dog walker cards on the homepage added the price(using Material Design's "$" icon), so users can compare prices earlier.
Iteration flow: move old pages out → replace with new pages in the user flow → retest the complete flow.
3. Design Critique (core)
An organized meeting where the team gives feedback on a design together. Kunal (Google Material team) uses the metaphor: "it's like wearing new clothes and showing them to friends, letting them say if they look good". Value: prevents designers from getting stuck in details, brings in external perspectives, builds presentation and judgment skills.Regardless of seniority, everyone acts as both Presenter and Reviewer.
3 (+1) roles
| Role | Responsibilities |
|---|---|
| Facilitator | Controls process/time, keeps focus on goals, ensures everyone has a chance to speak (can be omitted in small critiques) |
| Presenter | Presents the design + the logic behind it, listens actively, asks clarifying questions (does not defend on the spot) |
| Reviewer | Gives constructive feedback,describes problems and suggests optimization directions, does not give solutions directly(usually multiple people) |
| (Optional) Notetaker | Records all feedback so the Presenter can focus on the conversation |
4-step process + 5 preparation questions for the Presenter
Process: ① Facilitator introduces goals (clarify critique focus, e.g. "critique the booking flow, not icon details") → ② Presenter showcases (target user/context/logic/interface flow) → ③ Reviewers give feedback (recommended to structure in phases:Likes → Questions → Potential issues) → ④ Wrap-up (confirm if goals are met, note key points, plan next steps).
Before presenting, the Presenter organizes their thoughts with 5 questions(present the thinking, not just pages): ① Who is this design for? ② What problem does it solve? ③ How does the design solve it? ④ What stage is it at? ⑤ What kind of feedback are you looking for? For complex designs, send the prototype in advance for pre-review; if time is limited, only cover key points + only show the parts you most want feedback on (don't show the homepage but ask for feedback on the cart).
Tips for giving / receiving feedback
Receiving feedback: treat feedback as a "gift", not an attack; listen to the thinking behind the "problem" rather than taking it as personal rejection; you don't have to adopt all of it, extract what is valuable.There must be action after the meeting— design is like a ship, feedback is the compass.
3 tips for giving feedback:
- Consider the audience: use language the other person understands, whether they are PM/engineer/designer, junior/senior.
- Explain "why": don't say "I don't like this color", say "this color is not friendly to color-blind users, they may not be able to distinguish it".
- Describe the problem, don't give solutions: ✅"The position of this button may make it hard for users to notice" ❌"You should put the button in the top right corner".
Student exercise: share your work and invite suggestions → record feedback + mark whether you will adopt it and why → reflect optimizations in the next round → take turns playing designer/reviewer to practice both ways.
Turning feedback into action (6 categories of judgment)
Review notes after the meeting, judge the value of each item, and list action items.The core is categorization — not all feedback requires changes:
| Feedback type | Handling |
|---|---|
| Wording suggestions not supported by design principles ("who is going for a walk" → "which dog is going for a walk") | "Nice-to-have",can be left unchanged |
| New features requiring cross-role coordination (support walking multiple dogs separately) | Contact PM/operations to assess feasibility, send an email to schedule a discussion |
| Clear experience gaps (flow only covers one dog) | Directly build additional screens to support it |
| Consistency issues (inconsistent button size/position) | Check and unify one by one in Figma (align x/y coordinates) |
| Unclear feedback ("simplify top icons" — does this refer to color or text?) | Go back and ask for clarification before making changes |
| Quantifiable standards (contrast ratio of orange CTA) | Test with WebAIM, replace with a darker orange if it does not meet the standard #D53E0B; use Figma "Selection Colors" to batch replace |
4. Development Handoff
After the high-fidelity prototype is complete, most development specs are already in Figma. However,two categories need to be documented separately for developers:① Edge Cases(error states, empty pages, offline state) ② Accessibility considerations(for assistive technology users).
Two handoff models (depends on company size)
| Small company / design agency | Large company (e.g. Google) | |
|---|---|---|
| Metaphor | Relay race— designers sprint to completion, pass the baton to engineering, and move to other projects | Parallel collaboration— after the design is mostly complete, engineering may still make small adjustments when taking over; while engineering builds the profile page/cart, designers continue refining the homepage/navigation |
| Design completion level | High, designer involvement during development is low | Ongoing collaboration, possible rework, communication is key |
Figma Handoff preparation
Design is team collaboration: PMs leave comments with suggestions, copywriters revise text, researchers share prototypes for testing, developers check details/copy code/download assets. Key points:
- Thumbnail: 1920×960, the middle 1600px is always visible; place current status/team info/spec links there (right-click canvas "Set as thumbnail").
- Permissions: Edit (modify the file) vs View (comment/download assets/view prototype, free).
- When to invite developers: early on to ask "can this be implemented", later when "ready to hand off".
- View mode: has an inspection panel (view layers/styles/code) and an export panel (download icon assets).
How to write portfolio case studies is covered in Google UX Certificate / Portfolio, Resume, Interview, Job Search— the "create a portfolio case study" content from this course is merged there.
Key terms glossary
| English | Chinese | One-line explanation |
|---|---|---|
| Design Critique | Design critique | An organized meeting where the team gives feedback on a design |
| Facilitator / Presenter / Reviewer | Facilitator/presenter/reviewer | The 3 critique roles, taken in turn regardless of seniority |
| Action Items | Action items | Executable tasks after categorizing feedback |
| Iterate | Iteration | Improve based on feedback, prioritize revising static mockups |
| Handoff | Developer handoff | Hand over design specs to engineering for implementation |
| Edge Cases | Edge cases | Special scenarios such as errors/empty pages/offline state, need to be documented separately |
| Specs | Design specifications | Sizes/styles/code needed for development, built into Figma |
| Selection Colors (Figma) | Selection Colors | Select an area to batch replace colors |
<!-- Video gap: This topic includes demo videos of a Mock Crit Session + Figma iteration/handoff operation demos — the demo content is fully covered in text; a small number of raw lecturer interview clips were not captured. -->