Google UX Design common mistakes
Google UX Design · Understand the traps and how to avoid them.
Treating UX as visual styling: when asked what a UX designer does first on a new project, the candidate jumps to choosing colors, fonts, or a Figma layout instead of user research, problem framing, and understanding business goals.
Candidates come from graphic design or self-taught tool backgrounds, so the most familiar activity feels like the safe answer. Course vocabulary like 'user-centered design' gets memorized as a slogan without being mapped to an actual sequence of activities.
What to do instead
Drill the project lifecycle as an ordered chain: empathize, define, ideate, prototype, test, iterate. For any 'what comes first' item, eliminate answers that are production artifacts (mockups, style guides, final UI) and keep answers that produce understanding (interviews, personas, problem statements, competitive audits).
Confusing the roles and deliverables of UX designers, UI designers, UX researchers, and interaction designers, e.g. saying the UX designer's main deliverable is the visual mockup or that researchers own the final prototype.
The roles overlap heavily in small teams and job postings blur them, so candidates answer from personal workplace experience rather than from the exam's role definitions.
What to do instead
Build a small comparison table: responsibility, typical artifact, and who they hand off to. Anchor UX design to the end-to-end experience and problem definition, UI design to visual and interactive surface detail, and research to data collection and synthesis. Practice by assigning each of 15 artifacts (journey map, persona, wireframe, usability report, style guide) to its owner.
Writing research questions or interview questions that are leading, closed, or about hypothetical future behavior, such as 'Wouldn't you prefer a one-tap checkout?' or 'Don't you find the menu confusing?'
Candidates write questions the way they would talk to a colleague, seeking confirmation of a solution they already like. Under time pressure, closed questions feel efficient because they seem to produce quick answers.
What to do instead
Apply a three-part filter to every question: open-ended (how, what, tell me about), behavior-focused (what did you actually do last time), and neutral (no embedded preference). Rewrite each suspect question aloud and check that it cannot be answered yes or no. Add a follow-up probe like 'Why is that?' to every draft question.
Skipping synthesis and going straight from raw interview notes to a solution, or producing personas and problem statements that are generic and unsupported ('busy professionals who want a simple app').
Synthesis is the slowest, least visible step, and candidates worry they are falling behind. Personas feel like a formality, so they are filled with plausible-sounding traits instead of observed data.
What to do instead
Practice the full chain on a small dataset: affinity diagram the notes into themes, write an empathy map, derive a persona with goals and frustrations traceable to specific quotes, then write a problem statement in the form '[persona] needs [need] because [insight]'. Check every persona attribute against a note; delete anything you cannot source.
Producing low-fidelity wireframes that are actually polished visual designs, or the reverse: wireframes with no hierarchy, no annotations, and no clear entry point, so they cannot be evaluated or handed off.
Candidates equate effort with quality and add color and imagery to make the work look impressive. Others treat wireframes as rough doodles without labels, then cannot explain the interaction they intended.
What to do instead
Adopt the rule that low fidelity means grayscale boxes, real-ish text placeholders, and explicit annotations for interactions and states. Practice building a paper prototype and a digital wireframe of the same screen, then write the annotation set (tap target, navigation, error state, empty state) for each. Ask whether a stranger could use the wireframe to complete a task without asking you questions.
Building a prototype that demonstrates the happy path only, with no entry point, no way to recover from errors, and dead ends, then calling it ready for testing.
Candidates design the screens they are proud of and forget the connective tissue. Prototype tools make it easy to link forward and tedious to link back, so back-navigation and dead-end handling get skipped.
What to do instead
Before testing, walk the prototype as a participant would: start at the entry point, attempt the main task, make a deliberate mistake, and try to go back. Fix or document every dead end. Include at least one error state and one empty state in the flow, and write a short task script with a start screen and a success condition.
Running a usability test with leading prompts and no defined tasks or metrics, then reporting opinions ('users loved it') instead of observed behavior and severity-rated findings.
Candidates want participants to succeed and unconsciously coach them. Without a test plan, the session drifts into a demo and the notes contain praise rather than evidence.
What to do instead
Write a test plan first: goal, research questions, participant criteria, 3-5 task scenarios phrased as goals ('find a gift under $30'), and success metrics (completion, time, errors, satisfaction). During the session use neutral prompts only ('What are you thinking?', 'What would you do next?'). Afterward, synthesize into findings with severity ratings and tie each recommendation to observed evidence.
Treating high-fidelity Figma work as pixel-pushing: no components, no variants, no auto layout, inconsistent spacing, and no documented design system, so the file cannot scale or be handed off.
Candidates learn Figma through tutorials that build one beautiful screen and never cover component architecture. Under exam pressure, naming and structure feel like optional polish.
What to do instead
Practice a repeatable build order: define color and type styles, build components with variants for states (default, hover, disabled, error), apply auto layout to every frame that contains a list or button row, then assemble screens from instances only. Name layers semantically and keep a separate page for the component library. Be able to explain why a component with variants beats a duplicated frame.
Designing one screen and stretching it to other breakpoints, ignoring responsive layout mechanics such as grid columns, breakpoints, reflow, and touch target sizing.
Candidates think of responsive design as resizing rather than as a set of layout rules. Adobe XD's artboard workflow encourages copying a desktop layout and shrinking it.
What to do instead
Learn the vocabulary and apply it: define a column grid per breakpoint (mobile, tablet, desktop), decide what stacks, hides, or reflows, and check touch targets against a minimum size. Practice taking one screen from mobile to desktop and writing a short rationale for each layout change. Be ready to explain how responsive differs from adaptive and why content priority drives the breakpoint decision.
Answering social-good and job-readiness items with generic sentiment ('design should be accessible and help people') instead of naming concrete practices such as inclusive research recruiting, accessibility checks, ethical data handling, portfolio case-study structure, and interview preparation.
These domains feel softer, so candidates prepare less and rely on values statements. Portfolio and interview questions are also treated as separate from design knowledge rather than as an application of it.
What to do instead
Convert each value into a practice you can name: accessibility means contrast checks, alt text, and keyboard navigation; inclusive design means recruiting participants from underrepresented groups; ethics means informed consent and data minimization. For the job domain, prepare one case study in problem-goal-research-iteration-outcome form and rehearse explaining a design decision and a failure you learned from.