Google UX Certificate / Foundations of UX Design

Complete notes for Course 1 of the Google UX Design Professional Certificate, *Foundations of User Experience Design*. This course does not teach tools; it teaches thinking frameworks— it answers "what do UX designers actually do, what process do they follow, and who do they do it for". Will's Chinese notes have distilled the lecture videos into key points plus personal cases; this wiki reorganizes the content across modules by theme, rather than transcribing it in video order.

Significance for PMs: this "5-stage design thinking" framework is the same type of tool as the Yitang five-step method you are familiar with — both are structured processes for going from user problems to solutions, except the UX version leans more toward interactive interfaces and emphasizes "test before you build". Taking this course mainly helps you pick up collaboration language(the terminology used when talking with designers/researchers) and covers accessibility/equity, a blind spot PMs often overlook.

1. What makes good user experience: 4 qualities

UX (User Experience) = the user's experience when using a product. Note that the subject of this definition is the user, not the developer, not the designer, and not the experience the company wants. The term originated in the 1990s from cognitive psychologist Don Norman, but the concept is ancient (the course even draws an analogy to how Chinese feng shui focuses on spatial experience).

Good UX is hard to define in one sentence, but Google breaks it down into 4 evaluable qualities.These 4 are the acceptance criteria that run through the entire course; every subsequent design decision comes back to these 4 questions:

Quality	Definition	Evaluation question	Example
Usable	Clear structure and purpose; users can easily get started and complete tasks	Is the feature easy to find? Easy to understand? Can the task be completed?	An airline app's home page provides a clear direct entry for "book a flight"
Equitable	Provides help for people of different abilities/backgrounds, with special attention to overlooked groups	Does it accommodate diverse groups? Does it meet the needs of people who have traditionally been excluded?	A social app's emojis include different skin tones and gender-neutral avatars
Enjoyable	Not only functional, but also creates a positive emotional connection with users (not required, but a bonus)	Does it consider user feelings? Does it make people feel pleased/engaged?	A streaming service provides personalized recommendations based on viewing habits
Useful	Actually solves the user's real problem	Does it add value? Does it solve a real problem? Does it help achieve the goal?	A banking app has functions for transfers and bill payment

Usable ≠ Useful: usable emphasizes "how easy it is to operate", while useful emphasizes "whether it solves the problem". A feature that operates smoothly but no one needs is usable but useless.

Negative examples(three typical cases of bad UX):

Counterintuitive: Norman doors — they look like they should be pulled, but actually need to be pushed, leading to repeated mistakes.
Ambiguous icon meaning: icons are originally meant to save space and work across languages, but when their meaning is unclear users can only rely on trial and error.
Broken expectations: you add shoes to your shopping cart, and only at checkout are you notified they are out of stock — inconsistency = frustration.

2. Who are UX designers: role spectrum and collaboration

Generalist / Specialist / T-shaped

graph LR
  G["通才 Generalist<br/>一专多能,啥都做"] -->|积累 + 试错找方向| T["T 型 T-shaped<br/>一深 + 多广"]
  T -->|继续深耕| S["专才 Specialist<br/>单领域权威"]

Type	Meaning	Suitable environment	Advantages
Generalist	Takes on a broad range of responsibilities; drawing icons one day, doing research the next	Startups / design agencies / small companies	Quickly learns multiple skills, sees the full picture of UX, finds direction through trial and error
Specialist	Deeply focuses on a single direction (interaction/visual/motion)	Large companies	Clear responsibilities, abundant resources, becomes an authority, easy to build trust
T-shaped	Deep expertise in one area + broad knowledge across other areas	Universal ideal state	Combines depth with breadth for collaboration

Advice for new entrants(from instructor Erika's personal experience): start as a generalist to build foundations and experiment, then switch to a specialist after finding the direction you are most interested in. Erika went from being a generalist designer at Waze → a visual design specialist at Google; what she enjoys most is "colleagues actively coming to her for advice because they trust her expertise".

More entry paths (instructors' personal experiences, confirming "career changes / transferable skills"):

Karen (Interaction Designer): previously worked in event planning / business analysis / marketing / legal assistant —the transferable skills of "being detail-oriented + organized"made it easy for her to lead projects later; she took an "information design" night class where she needed to make an interactive infographic, searched online, stumbled across "interaction design", and entered the field (working full-time while building a portfolio to apply for graduate school).

Paolo (Lead UX for YouTube Ads): first-generation Filipino immigrant, fine arts undergraduate (painter / illustrator), "back then there wasn't even a word for UX"; he encountered usability engineers at Oracle and discovered the world of "understanding how users think" (cognitive psychology), going Oracle → Microsoft (games) → Netflix → Google. His quote:"If you turn your hobby into a job, you will very likely lose that hobby"; after 25 years in the industry he still feels "the more I do this, the more I realize how little I know".

7 job roles related to UX design

In small companies one UX designer does everything; in large companies work is split into different positions. Remembering these roles is so you know who to ask for what.

Visual Designer: product appearance — icons, typography, color palettes, white space, materials, ensuring aesthetics + brand consistency.
Interaction Designer: how the product is used, focusing on functions and interaction methods.
Motion Designer: the experience when users "move/operate" within the product.
Production Designer: ensures drafts match final deliverables, hands off assets to engineering.
UX Writer: text in the product (prompts, instructions).
UX Engineer: turns design intent into a working experience.
UX PM: ensures smooth communication and on-schedule progress.

Cross-functional collaboration

The core value of a UX designer is integrating outputs from all parties, acting as the "gatekeeper of user experience" + "bridge for team collaboration". Common counterparts:

Role	What they give you	Key action
Engineers	Judge technical feasibility, implement the design	Bring them in early in the design process, this guarantees project success
UX Researchers	Insights into user needs	In small companies you do research yourself; in large companies you use their outputs
Program Managers	The "fulcrum" for scheduling, budget, and progress	Go to them for coordination when things get stuck
Product Leads	Define core goals and deliverables	They interface with stakeholders so you can focus on design solutions
Other designers	Brand guidelines, experience	Good opportunity to ask questions + learn

Stakeholder: people who have a business interest in the product outcome. A major purpose of wireframes/prototypes is to communicate design intent to stakeholders and win their support.

4 entry paths

Path	Duration	Paid?	Characteristics
Internship	A few months	Not necessarily	Short-term, light responsibilities, may convert to full-time
Apprenticeship	1–2 years	Paid	Long-term, mentored, builds solid skills
Freelancing	Flexible	Project-based	Can start by working for small businesses/nonprofits for free to build a portfolio + get references, then charge for work
Entry-level	—	Yes	The most common starting point; a good certificate + portfolio can offset the "1 year of experience" requirement

3. User-centered design: 4-step cycle

User-Centered Design = putting the user in the most important position. Google co-founder Larry Page:"There is no substitute for personally observing and listening to real users" — which later became Google's core value "Focus on the user, and all else will follow".

Why: to solve users'real problems, not the problems designers think exist — to avoid "designer bias".

graph LR
  U["1 理解 Understand<br/>研究用户怎么用"] --> S["2 明确 Specify<br/>定位最该解决的问题"]
  S --> D["3 设计 Design<br/>想方案 + 做出来"]
  D --> E["4 评估 Evaluate<br/>真用户测,是否解决"]
  E -.迭代 Iterate.-> U

Iteration — continuously improving on existing versions — is an essential step. Example: 5 years ago Google Photos was only for storing and organizing photos; later the team found users wanted to "relive memories", so they rebuilt the search/find features using user-centered design.

4. Accessibility / Equity / Inclusion: the blind spot PMs overlook

This area is the easiest for product peers to miss. More than 1 billion people globally have a disability; in the United States, 1 in 4 adults does. Accessibility is not "catering to a minority", it is about improving the experience for everyone — captions, dark mode, and voice input were all originally designed for people with disabilities, and now everyone uses them.

Three stages of evolution: Universal → Inclusive → Equitable

Stage	Philosophy	Problem / Breakthrough
Universal Design	One product fits everyone ("one size fits all")	❌ Like a "one-size-fits-all hat", it seems to fit everyone but in reality many people can't wear it, and ends up excluding users
Inclusive Design	Provides different solutions for different needs, invites overlooked groups to participate	✅ Core idea "Design for one, extend to many" (features designed for blind/deaf people also help other people)
Equity-focused Design	Goes a step further on the basis of inclusion, specifically designing for groups that have been historically overlooked/underrepresented	✅ Three steps: ① Clarify the product ② Identify groups that were excluded in the past ③ Always center them

Equality vs Equity(classic analogy): Equality = giving everyone boxes of the same height to stand on; people of different heights still have different views. Equity = giving boxes of different heights according to height, so everyone can see the same view.

AT (Assistive Technology)

Any product, device, or system that helps people with disabilities learn/work/live. The best way for designers to build empathy is to experience AT firsthand.

Color adjustment(high contrast/dark mode) · Voice control / switch devices(replacing keyboard and mouse) · Screen readers(reads aloud text/buttons/image descriptions, most commonly used by people with visual impairments) · Alt Text(text description of images) · Speech-to-text.
Core advice from instructor Elise (Google Accessibility Lead, deaf since age 10):Start from edge cases — treat users with differences as a regular consideration, not an afterthought add-on;Diversify your network, proactively get to know people different from yourself.

Real lesson: Google Assistant was originally trained only on male voices + native English speakers, which made it hard to recognize female voices and accents —if you don't test with diverse users, product quality will inevitably suffer.

5. Cross-platform design

Platform = the medium through which users experience the product (desktop/laptop/phone/tablet/watch/TV/smart display). Users expect a similar experience + consistent brand across any device.

4 dimensions where design changes by platform:Screen size · Interaction method(desktop keyboard & mouse / mobile touch gestures / accessibility screen readers) · Content layout(desktop landscape multi-column / mobile portrait scrolling / watch extremely small) · Functionality(desktop complex multitasking / mobile short single-task / wearable lightweight notifications).

Priority principle: when building a new product,first focus on one platform best suited to your target users, expand after you succeed. Don't go all-platform from the start.

Mobile best practices: Average mobile session lasts 72 seconds vs. 150 seconds on desktop — mobile users have clear goals and focus on a single task. Therefore: ① Place CTAs (call-to-action buttons, e.g., sign up / purchase) in prominent positions ② Keep only the most important options in menus ③ Use familiar gestures ④ Account for both portrait and landscape orientations ⑤ Reduce distracting elements. Also consider Low-end phones have poor performance and slow network speeds— support offline use and adaptive layout (multi-column on desktop → automatically single column on mobile, i.e., Responsive Web Design).

VI. Design Thinking: A 5-Stage Framework (the overarching thread throughout)

Design Thinking = a user-centered UX framework with 5 stages. This is the main thread running through the entire certificate program.It is not linear, but iterative— you may return to earlier stages at any point based on user feedback.

graph LR
  E["共情 Empathize"] --> D["定义 Define"] --> I["构思 Ideate"] --> P["原型 Prototype"] --> T["测试 Test"]
  T -.迭代.-> E

5 core principles: ① User-centered ② Solve real problems ③ Cross-team collaboration ④ Validate designs ⑤ Continuous iteration.

Stage 1 · Empathize

Goal: Truly understand how users feel and think, and set aside your own biases. Treat users as unique individuals rather than "consumers". Three methods:

Interviews: Surveys / in-person / phone / video. First define what information you need → assess available resources → choose the method.
Empathy Map: Organize interview findings by answering 5 questions — who the user is / what they say / what they think / what they do / how they feel.
Persona: A fictional character representing a group of users, turning complex information into a memorable archetype.

Case study (bakery example used throughout the course): The bakery assumed "older adults don't shop online", but research found they do shop online — they just feel that calling is faster and lets them chat with staff— this is the real insight uncovered through empathy. The fictional persona Berta = a regular elderly customer with poor eyesight who prefers ordering by phone.

Stage 2 · Define

Goal: Analyze what was learned during empathy, identify the most important problem to solve and articulate it clearly. Three deliverables:

Tool	Template	Perspective	Berta example
User Story	As [user], I want to [action] so that [benefit]	User perspective, focused on a single need	"As an elderly customer with visual impairment, I want to place orders by phone so that I can order easily and stay connected with the staff"
User Journey	A sequence of experiences to reach a goal (current vs. future)	Reconstruct the process to reveal pain points / gaps	Current: phone + direct messages (fast and personal) → Future: website ordering (needs to replicate that convenience and warmth)
Problem Statement	[Persona] is a [type] who needs [experience] because [benefit]	Designer perspective, more detailed than a user story	"Berta needs a website ordering system that accommodates her vision and simulates the warmth of a phone call……"

Key point: Write a problem statement for every persona to ensure you cover different users and do not bias toward a single user type.

Stage 3 · Ideate

Goal: Generate many solutions, do not stop at the first idea. Principle: first generate without judgment, then compare and filter. Common methods:

HMW "How Might We?": Reframe problems as open-ended questions ("How might we make online ordering as friendly as chatting with a friend?").
Rapid sketching / Crazy Eights: Fold a sheet of paper into 8 sections, spend 8 minutes, draw 1 idea per minute → 8 sketches. Focus on communicating ideas, not artistic skill.
Competitive Audit: Study what competitors offer, their strengths and weaknesses → gain inspiration, avoid mistakes, find opportunities, save costs.
SCAMPER: SCAMPER: 7 directions for improving existing solutions — Substitute / Combine / Adapt / Modify / Put to other use / Eliminate / Rearrange.

Stage 4 · Prototype

Goal: Not to build the final product, but to build a tangible, testable model. Progress from low to high fidelity:

graph LR
  IA["信息架构 IA<br/>+ 网站地图 Sitemap"] --> WF["线框图 Wireframe<br/>纸质 / 数字"] --> LF["低保真原型 Lo-Fi<br/>可点击模拟跳转"] --> HF["高保真原型 Hi-Fi<br/>接近终品的交互"]

Information Architecture (IA): Organize information so users can understand and navigate easily.Sitemap Shows hierarchy (primary/secondary topics) and sequence (moving from the homepage down through levels).
Wireframe: A sketch of page layout. Paper (cheap, fast, easy to iterate) / digital (Figma/Adobe XD, grayscale + placeholder text Lorem Ipsum).
Lo-Fi (Low-fidelity): Assembled from wireframes, can simulate navigation; used early to test flows and save resources.
Hi-Fi (High-fidelity): Close to the final product in interaction and content, used to gather detailed feedback.

Stage 5 · Test

Goal: Validate whether the prototype actually solves the problem. Conducted interleaved with the prototype stage. 6 elements of a test plan:

Who Who: Early on you can recruit friends and colleagues; later recruit real users who match target characteristics.
What What: Choose test methods (different methods gather different feedback).
When and where When/Where: In-person face-to-face or online remote, depending on budget / time.
Why Why: Validate earlier decisions + identify usage barriers.
How to participate How (inclusive): Ensure everyone (including people with special needs) can participate.
How to collect How: Observe, interview, record the process, collect data directly from the prototype.

When evaluating prototypes refer back to the problem statement from the Define stage: Can Berta place an order smoothly? Does the website have the same warmth as ordering by phone?

VII. Design Sprints: 5-Day Focused Breakthroughs

Design Sprint = A time-bound (typically 5 days, 8 hours per day), highly structured process that uses design + prototyping + testing to quickly answer key business questions. Created by former Google designer Jake Knapp (author of the book *Sprint*).

Design Sprint ≠ Design Thinking (key differences)

Dimension	Design Thinking	Design Sprint
Nature	Overall philosophy / methodology, continuous and flexible	A specific implementation plan targeted at a particular challenge
5 stages	Empathize → Define → Ideate → Prototype → Test	Understand → Ideate → Decide → Prototype → Test
Timeline	Runs throughout the entire product lifecycle, open-ended	Strictly 5 consecutive workdays
Relationship	The overall path (missing a step may prevent you from finding the real problem)	Can be broken into segments and embedded into a stage of Design Thinking (e.g., use a sprint format to complete Empathize in 5 days)

Restaurant analogy(original from Will's notes): Design Thinking = the full process of opening a restaurant (research customers → decide cuisine → plan menu → make samples → invite taste testers); Design Sprint = an investor says "Come do a tasting next week!" — lock in one dish in 5 days (Monday Understand / Tuesday Ideate / Wednesday Decide / Thursday Sample / Friday Tasting).

5 sprint stages (one stage per day)

Understand (cross-functional + expert briefings,user first) → Ideate (brainstorming + start recruiting test users) → Decide (vote for the best solution, draw a blueprint) → Prototype (build a sample "real enough to test") → Test (real users test it, get first-hand feedback).

When to use a sprint(meet any one of these): Are there multiple possible solutions? / Do you need cross-functional collaboration? / Is the problem big enough to justify a week?

A newcomer's role in a sprint: You are not the lead, but important in every stage— listen, learn, provide feedback, and especially contribute the user perspective.

7 planning steps + Sprint Brief + Retrospective

7 planning steps: ① Conduct user research ② Invite experts ③ Find a suitable venue (whiteboards / soundproofing / comfortable and adjustable) ④ Prepare supplies (markers / sticky notes / snacks and water) ⑤ Set rules (e.g., no phones) ⑥ Icebreaker (recommended: have everyone share "a bad customer service experience" → shift into user perspective) ⑦ Post-sprint preparation (take photos, collect sticky notes and sketches, document discussions).

Sprint Brief(document sent to everyone before the sprint starts) 7 parts: Design challenge / Key deliverables / Logistics (time, place, people) / Decision approver / Resource allocation / Project overview / Daily schedule.

Retrospective: Held right after the sprint while memories are fresh.Do not discuss design content; discuss "what went well / what could be improved". The atmosphere should be open and encourage sharing, with no blame.

Retrospective golden rule:Focus on the issue, not the person— if you need to discuss someone's performance, say it privately, not in the team retrospective. "Unspoken ideas are useless" — encourage everyone to speak up.

VIII. The Real Starting Point: Business Requirements

Real projects often do not start with empathy; they start with an assignment.

Business Requirements = Goals + Parameters

Business Goals	Business Parameters
Who are you designing for? (Target users)	What constraints exist? (Budget / time / scope)
What do you want to achieve? (Outcomes)	What tools must be used? (Systems that must be compatible)
What should it look and feel like? (Vision for appearance and functionality)	What standards must be met? (Rules)

Business requirements evolve as the project progresses, and designers must adjust flexibly. The Empathize stage is where you verify and complete the incomplete user information in the business requirements.

IX. UX Research: Three Types of Research + Bias Defense

This chapter is the bridge from Course 1 to Course 4 (the dedicated research course). Detailed research methods are covered in Google UX Certificate / UX Research and Empathize-Define; here we lay the foundation.

Categorized into three types by "where they fall in the product lifecycle"

Type	Timing	Core question answered	Common methods
Foundational research(strategic / generative)	Before design(before brainstorming)	What should we build? What is the user's problem?	Interviews, surveys, focus groups, competitive audits, field studies, diary studies
Design research(tactical)	During design	How should we build it?	Usability studies, A/B testing, guerrilla research, card sorting, intercept interviews
Post-Launch research	After release	Were we successful?	A/B testing, usability studies, surveys, log analysis

Two orthogonal classification sets

Primary(conducted yourself: interviews / surveys / usability) vs Secondary(using data compiled by others: books / articles / journals).
Quantitative(numbers / measurements, answers "What" and "how many") vs Qualitative(observation / small-scale interviews, answers "Why" and "how come").

How to choose: If you want to know "how many people / how many issues" → quantitative (surveys); if you want to know "why / how come" → qualitative (interviews, usability).

Quick reference: pros and cons of 4 methods:

Method	Pros	Cons
Secondary research	Convenient, saves time and money, can support primary research	Cannot observe real interactions, cannot get feedback specific to your product
Interviews	Deep understanding of "why", allows follow-up questions	Time-consuming and expensive, small sample size, weak representativeness
Survey	Cheap and fast, large sample size	Shallow feedback; poorly designed surveys can lead to bias
Usability studies	Directly observe interactions, reveal real problems	Only focuses on usability, high cost, lab environment ≠ real-world scenarios

3 traits of a good researcher:Empathy(standing in the user's shoes),Pragmatism(focusing on feasibility and results),Collaboration(working with all kinds of people).

6 types of research bias (must memorize)

Bias = a tendency / preconception when information is limited, often unconscious. It cannot be eliminated, but it can be recognized, reflected on, and reduced.

Bias	What it is	How to counter it
Confirmation bias	Only looking for evidence that supports your own hypothesis	Ask more open-ended questions, listen to dissenting views, diversify participants
False consensus	Assuming others think the same way you do	Write down assumptions and check them often, expand your sample
Recency bias	Only remembering the last thing you heard	Take notes / record audio, review the full process
Primacy bias	Being most impressed by the first participant	Ask everyone the same questions, document each one systematically
Implicit bias	Unconsciously holding bias / asking stereotypical questions about a group	Acknowledge that everyone has bias, ask others to point it out, invite people from diverse backgrounds
Sunk cost fallacy	Being too invested to abandon a bad solution	Break work into small steps, review regularly, only do what benefits users

8 anti-bias practices in data collection:① Use neutral wording (do not ask "Do you like the improved layout?"; instead ask "How do you feel about the layout?" — to prevent framing effect) ② Write down answers individually before discussing (to prevent bandwagon effect) ③ Provide an "Other" option / use rating scales (to prevent restrictive confirmation) ④ Let users explore freely without guidance (to prevent false consensus effect) ⑤ Proactively confirm the meaning of body language (to prevent implicit misinterpretation) ⑥ Researchers should maintain a neutral tone (to prevent social desirability bias) ⑦ Plan ahead instead of recruiting participants at the last minute (to prevent availability bias) ⑧ Spread out interview times + involve colleagues + take detailed notes (to prevent primacy/recency bias).

Instructor Case: Researcher Deana — "When you choose to interview someone, you are also excluding everyone else." In the early stages of Google's food ordering service, the team focused only on consumers and overlooked merchants; they later filled in the system perspective. Bias exists not only when interpreting data,choosing who to interview can itself be biased.

Quick Glossary of Key Terms

English	Chinese	One-sentence explanation
Persona	User persona	A fictional character representing a group of users
Empathy Map	Empathy map	A five-question framework for organizing interview findings
Problem Statement	Problem statement	[Persona] needs [experience] because [benefit]
Information Architecture (IA)	Information architecture	The organization / categorization / structure of a website
Sitemap	Sitemap	A structure diagram showing hierarchy and order
Wireframe	Wireframe	A sketch of page layout
Lo-Fi / Hi-Fi Prototype	Low-/high-fidelity prototype	A model for testing, progressing from rough to detailed
Stakeholder	Stakeholder	A person who has a business interest in the product
CTA (Call-to-action)	Call to action	A button that prompts the user to take action
KPI	Key performance indicator	A metric for measuring progress toward a goal
HMW (How Might We)	How might we	Turning a problem into an open-ended question
Assistive Technology (AT)	Assistive technology	Products/devices that help people with disabilities
Alt Text	Alternative text	A text description of an image (for screen readers)