The job search section of the final certificate course "Design a UX for Social Good & Prepare for Jobs" — how to strengthen your portfolio, write case studies, build a resume, pass interviews, and find a job.Ways to accelerate all of this with AI tools are covered in Google UX Certificate / Using AI for UX and Job Search(there are AI versions for resumes/cover letters/interviews); what is covered here is the underlying craft(methods that hold up even without relying on AI).
Relevance for PMs:① Portfolio interview presentation template(the Problem→Process→Impact framework) is actually a universal narrative structure for "how to talk about a project", usable for performance reviews/reporting/competency interviews. ② The 7 elements of a case study heavily overlap with the structure you use for project retrospectives. ③ The STAR method + valuing company culture over fame is universally applicable to any job search.
I. Before strengthening your portfolio: two design perspectives
4C principles of cross-device design
To deliver a unified experience across devices, first select the primary device(based on which device users use most) + understand device differences(touch vs. keyboard & mouse, screen size), then adhere to the 4Cs:
| Principle | Meaning | Example |
|---|---|---|
| Consistency | Unified style across devices, sense of familiarity | Google profile picture is always in the top right corner |
| Continuity | Operations continue across devices | Save an email draft on computer, continue writing on phone |
| Context | Adjust features based on usage scenario | On a watch, email only supports quick view/brief reply |
| Complementary | Devices work together, each playing to its strengths | Browse on desktop → continue viewing on mobile and enhance with mobile-specific features |
Mobile-first: Design for phones first, then expand to larger screens (starting with core features). Benefits: fast loading (weaker phone performance forces you to streamline), cross-device consistency. It is projected that 72% of people will only use phones to access the internet by 2025. Google Search changed its ranking for this reason — mobile users searching for restaurants are prioritized with address/navigation rather than reviews. (See details in Google UX Certificate / Visual Design · Design Systems · Responsive Design Responsive)
Design for Social Good
On the basis of "solving user problems", focus on problems that make society better — pay attention to unprofitable, easily overlooked groups, and promote equal access to education/healthcare/environmental protection. 3 Google examples: Community electronic bulletin board (Google Home voice broadcasts community events to help isolated elderly people stay connected), Seeing Music (converts sound to graphics/colors so hearing-impaired people can "see" music), Simple (records blood pressure medical history in 20 seconds, managing 500,000+ hypertension patients).Including such projects in your portfolio can demonstrate your ability in equitable/sustainable/inclusive design + sense of social responsibility.
II. Portfolio
Website best practices + website builders
The best portfolio format is a personal website(to showcase case studies). You can use website builders (such as Wix/Squarespace, etc.) to build it quickly. Planning key points: homepage states who you are + 2–3 representative cases + about me + contact information.Tailor to the target position type — if applying for a research role, highlight research cases; if applying for an interaction role, highlight interaction work.
Case Study (7 elements)
A case study = a project summary presentation that communicates your role, thinking, and outcomes. Complete structure:
- Your role
- Project goal
- Target audience
- Key challenges & constraints
- Design process(research → insights → wireframes → prototype → testing → iteration)
- Final product
- Impact(data + feedback + whether launched)
A good case study demonstrates comprehensive ability in "planning/strategy/execution/integrating user feedback", not just posting pretty interfaces.Process > Results.
Portfolio interview presentation template (universal narrative for presenting projects)
Recommended structure for verbally presenting your portfolio in interviews (also usable for PM performance reviews):
graph LR
A["封面<br/>姓名+定位标语"] --> B["关于我<br/>背景+核心技能+价值主张"] --> C["项目概览<br/>2-3个+一句话结果"] --> D["逐项目"] --> E["Key Takeaways<br/>设计方法论"] --> F["FAQ<br/>预判问题"] --> G["Thank You<br/>联系方式"]
Present each project in a fixed five-part structure:Problem → Process → Final product → Impact (data/Design ROI) → Learnings + next steps. Keep the same narrative structure across multiple projects for easy comparison. Use quantified results ("task completion rate +28%") to prove value.
III. Resume
The resume itself is a visual design work, apply design principles:Information hierarchy(quickly identify key points),grid alignment, color + white space, personal branding(original Logo/color scheme/typography). Common presentations:
- Two-column layout(better for alignment and quick scanning than single-column)
- A splash of brand color to emphasize name/title (black and white is also fine, but avoid low-contrast combinations like light yellow on white background)
- Personal Logo(not required; if used, e.g., initials "ZB", reuse across portfolio/business cards)
- Bullet points for sections (small brand-colored icons can replace black dots)
- Typography hierarchy(prominent name, light/gray secondary information) — highlight key points without harming readability
Tool workflow: Start with Word/Google Docs for the base (complete information) → then polish with Figma/InDesign (like wireframe → mockup).Submit in the format required by the job posting (PDF/Docx); wrong format may lead to being directly ignored. Have someone proofread spelling and grammar after every major revision.
Typical UX resume elements + Google recruiter advice can be found in course examples (resumes of Yang/Shabi/Zachary). AI resume revision (basic version + position-tailored version) see Google UX Certificate / Using AI for UX and Job Search §IV.
IV. Interviews
Interview process + three key presentation points
UX interviews usually have multiple rounds (initial screening → portfolio presentation → behavioral/skills interview → possible whiteboard challenge). Hiring manager Jay's 3 key points:
- Adaptability: The focus is not what you ultimately delivered, but how you went from concept to delivery — proposing ideas → testing → listening to feedback → iterating, and defining and correcting the problem.
- Passion: Clearly state which part of the design process interests you most (empathy/interaction/interface/testing).
- Learning Mindset: What you learned from the project.
When job hunting,look at company culture, not company name: Prioritize places with strong mentorship support, clear feedback mechanisms, and room for growth — the first few years shape your identity as a designer.
STAR + Whiteboard Interview
- STAR method for answering behavioral questions: Situation/Task/Action/Result (see details in Google UX Certificate / Using AI for UX and Job Search, can practice with Gemini Live).
- Whiteboard Interview: Given a design problem on the spot, think and draw at the same time, assessing your thinking process and communication(not the perfection of the final solution). Think aloud, clarify constraints first, draw user flows/wireframes.
- Prepare thoughtful questions to ask the interviewer; after the interview,follow up with thanks; respond to offers rationally. Overcome Impostor Syndrome(instructor Catherine) — common for new designers, don't let it stop you from applying.
V. Career Path and Collaboration
UX specializations + company types + common positions
- UX specializations: Interaction designer / Visual designer / Motion designer / UX researcher / UX writer / UX engineer / UX PM (see details in Google UX Certificate / UX Design Fundamentals §II).
- Company types: Large companies (fine division of labor, specialists, many mentors) / Startups (one person with multiple skills, generalists) / Design agencies / Freelance.
- Freelance: Need to write a Business Plan(positioning/pricing/client acquisition);finding the first client often starts with doing free work for small businesses/nonprofits in exchange for portfolio pieces + recommendations, then gradually charge fees + write a UX Proposal.
UX communities + collaboration with engineering
- Participate in UX communities(ADPList mentors, Creative Mornings, various niche communities) — networking is one of the most effective job search channels (see Google UX Certificate / Using AI for UX and Job Search §IV).
- Collaborate with engineering teams: Bring engineering in early in design to assess feasibility; when delivering, provide clear specs + edge cases + accessibility notes (see details in Google UX Certificate / Testing · Iteration · Design Review · Handoff §IV Handoff).
Glossary of Key Terms
| English | Chinese | One-line explanation |
|---|---|---|
| 4 Cs | 4C Principles | Consistency/Continuity/Context/Complementary, cross-device experience |
| Mobile-first | Mobile-first | Design for phones first, then expand to large screens |
| Design for Social Good | Design for Social Good | Solve problems that make society better |
| Case Study | Case Study | Role/Goal/User/Challenge/Process/Outcome/Impact |
| Portfolio Presentation | Portfolio Presentation | Problem→Process→Final→Impact→Learnings |
| Personal Brand | Personal Branding | Logo/color scheme/typography that reflects your style |
| STAR Method | STAR Method | Situation/Task/Action/Result |
| Whiteboard Interview | Whiteboard Interview | Draw on site, tests thinking process and communication |
| Impostor Syndrome | Impostor Syndrome | Feeling you don't deserve it, common among new designers |
| Business Plan / Proposal | Business Plan/Proposal | Freelance positioning & pricing / proposal document for clients |
<!-- Video gap: This topic includes Capstone portfolio guide videos (2 large files, 3GB total, compressed and archived) + interviews with multiple recruiters/designers (Jay/Juan/Kartik/Dane/Tim/Olga, etc.) — core advice is covered in text; Capstone demo footage is not transcribed, as it is operational demonstration. -->
Appendix: Stop Decorating, Start Storytelling — Portfolio Narrative Framework (supplement from Will's Design Notes)
Source batch: 5 articles from Will's Design Notes "Guide to a Successful UX Portfolio" (a "Don't vs Do" experience post from a designer who got into Google).Sections I~V above cover what "elements" a case study should have (structural checklist); this section supplements another angle — with the same elements, why most people end up with "decorations" instead of "evidence that tells a story", and what senior interviewers are actually looking for behind each page. Treat it as the "anti-patterns + narrative polishing" layer on top of the previous template.
Core thesis: A portfolio is not about arranging interfaces prettily (decorating), but about telling the story of "how you think, how you saved the project" (storytelling). With limited cognitive resources, interviewers scan your portfolio for "hire/reject evidence"; any place where they have to piece together logic themselves or guess relationships is friction, and friction directly equals no chance.
1. Let the persona run all the way through, don't let it disappear right after introduction
Many people treat "personas" as a checkbox item in bootcamp templates: they spend three pages at the start talking about Sarah's pain points, then never mention her again once the high-fidelity mockups appear — the story breaks, and the signal senior interviewers read is "your research didn't drive the design; it was just pasted on afterward to look professional."Do: The final solution must explicitly respond to the pain points established at the opening; when presenting high-fidelity mockups, directly point out "which of Sarah's pain points this UI decision addresses" (e.g., she suffers from information overload → how the new dashboard simplifies her information view). Why: What hiring managers want is "someone who can make decisions based on real user problems," not someone who can draw interfaces; the closed-loop mapping from pain point to decision is the only proof that "research actually drove the design."
2. Present designs as a "coherent user flow," don't build a Dribbble brick wall
The "waterfall/brick wall" layout of images influenced by Dribbble/Pinterest looks cool, but it forces interviewers to guess for themselves "what the relationship is between this page and the next" — a classic case of prioritizing aesthetics over logic.Do: Present a continuous flow with arrows, state transitions, and logical relationships (if space is limited, use a few seconds of animation to walk through the complete flow), demonstrating your thinking about spatial models, microinteractions, and state transitions. Why: A coherent flow lets interviewers understand your design along the user's mental model, and use that to assess your ability to handle complex interactions; a scattered grid only proves you can produce visuals, not that you are designing a complete journey.
3. Clarity over complexity: zoom out for the big picture, then zoom in on key points
Cramming in a 30+ step journey map shrunk down to a blurry rectangle just to look like you "did a lot of research" is a point deduction — information existing ≠ information being communicable.Do: First present a clean, simplified overall skeleton to establish context, then devote most of the space to "high-resolution close-ups," focusing on the "critical moments" where users actually got stuck and where research prompted a directional shift. The same applies to industry jargon (PNR sync/latency buffering): bridge it with analogies everyone understands (compare the complex ticketing system to the order fulfillment sequence at a busy coffee shop). Why: Being able to extract key signals from noise and explain complex things simply is precisely the mark of senior-level communication; the moment an interviewer has to stop and ask for a definition, that segment has failed.
4. Treat "failures" as selling points: roadblocks are evidence of problem-solving ability
A perfect project that goes from A to B without a single hitch is actually suspicious — either it lacked real business complexity, or problems were hidden (real product work always involves budget shortages, technical constraints, and failed solutions along the way).Do: Specifically talk about moments when you judged wrong, constraints that forced the solution to change, and obstacles that almost derailed the project — who you solved them with, how you came up with workarounds, and what you learned. Why: Hiring managers would much rather see how you think under pressure; being willing to talk about missteps elevates you from "an execution designer who only pushes pixels" to "a problem-solver who can keep delivering even when plans fall apart."
5. Connect the dots: tie every insight to specific pixels
"Users said X, so I changed Y" only proves you did work, not value; the template-style layout of one chapter for research and one chapter for design forces interviewers to flip back and forth and guess for themselves which insight maps to which UI change.Do: Use "counterfactual thinking" — first state what the team almost did wrong based on internal assumptions, then present the concrete data evidence that overturned the wrong assumption, reframing the design from "polish and beautification" to "project rescue" (not "I made it better," but "I prevented a costly mistake"). Why: Explicit lines connecting insights ↔ decisions hand interviewers the core evidence for "why you should be hired" directly, saving them the cognitive effort of piecing the story together themselves.
6. The strategic thinking trio: technical tradeoffs / team collaboration / T-shaped focus
(a) Don't present "Blue Sky" fantasy solutions that ignore platforms/APIs/timelines; document the technical tradeoffs you made (when you changed the solution due to technical constraints, how you worked with engineering to find a middle ground that was feasible without sacrificing user value) — proving you are a strategic partner to engineering rather than someone who only hands off Figma files. (b) Don't write the process as a "lone-wolf personal hero's journey"; at companies like Google, design is a team sport, so you need to highlight how you resolved opinion conflicts (specifically explain how you used a quick usability test or a piece of analytics data to persuade a room full of people who disagreed) — proving you lead through influence rather than positional authority. (c) Don't introduce yourself as "good at everything" (listing UX/research/logo/front-end all at once); claiming to be all-capable often means you haven't mastered any one thing; instead, talk about your T-shaped core strength plus your value to this specific team. Why: For senior positions, hiring teams look for three things: "the ability to deliver under real-world constraints, the ability to drive cross-functional work, and a clear value proposition". All three point to "a professionally credible profile that can be vouched for". Being a generalist without deep expertise or having only ungrounded, theoretical ideas will leave the team unable to tell which role gap you can fill.
7. Prove impact with evidence: both accessibility and design systems need to be "moved with reason"
(a) Don't treat accessibility as an afterthought tacked on at the end (freezing up when asked about color contrast/screen reader order/tap targets); weave inclusive design into core decisions and back it with evidence (show interfaces where you deliberately adjusted contrast, flows simplified for users with motor impairments or high cognitive load, and that you actually went into phone/computer accessibility settings). (b) Unless you are applying for a Design Systems role, don't spend three pages showing off a UI Kit you didn't build (it is assumed you know how to use components); instead, show "when the system couldn't solve a specific user problem, why you extended it or consciously broke from it." Why: Both of these upgrade the message from "I can use basic skills" to "I can apply them with judgment" — maturity is reflected in your ability to clearly explain "why you designed it this way / why you made an exception," rather than piling up things you are expected to know by default.
8. A portfolio you can't explain yourself won't get you interviews: Action Titles + self-sufficiency
Don't assume "I'll explain why I did this when I get to the interview" — the primary job of a portfolio is to help you get the interview in the first place; if it can't explain the logic on its own, you may not even get an interview opportunity.Do: Create a document that holds up even when you aren't there and can be quickly scanned (looking at each page for only a few seconds), writing every chapter title as a conclusion (Action Title) rather than a category name: "User Research" → "Research found 60% of users drop off at the payment step"; "Ideation Sketches" → "Reducing cognitive load by simplifying navigation"; "Final Design" → "A one-stop solution for busy moms." At the same time, name each chapter as a direct answer to the interviewer's "silent question" (if you know the company values data-driven work, name the section "How I used qualitative + quantitative data to adjust design direction"). Why: Interviewers scan, they don't read closely; if they can get "what you did and why it's valuable" just from the titles, you are effectively checking the boxes on their mental evaluation checklist for them; portfolios where titles only list category names are, at their core, just "collections of pretty pictures."
9. Live presentation: tell the case as "a real day in the life," turn monologue into conversation
Don't read word-for-word off the slides (interviewers read faster than you can speak, and will zone out in five minutes), and don't be so nervous that you mechanically deliver a one-way output.Do: Tell the case like a "Day in the Life" blog post — shift the focus from "what you did" to "how you did it," letting the audience step into your perspective, with real people appearing in the story ("how I communicated with the tech lead" rather than "the team decided"); break the ice proactively and turn the presentation into a conversation (the author even started a Google interview by teaching everyone how to pronounce his name, and when talking about a health project asked in return, "Have you ever wanted to eat healthy but didn't know where to start?"). Why: Interviewers aren't only judging the quality of your work; they are also judging "whether you would be good to work with"; a real, dynamic, interactive presentation style both demonstrates your real-time problem-solving process and lets the other person imagine "what it would be like if this person joined our team" — making people want to work with you is what gets someone advocating for your hire.