Learning Objectives
By the end of this lesson, you'll be able to:
- 🎨 Distinguish between UI testing (looks) and UX testing (feels)
- 🖼️ Use Figma mockups as a source of truth for visual testing
- 🧭 Apply Nielsen's 10 heuristics as a UX evaluation framework
- 🐛 Identify and articulate UI vs. UX bugs clearly
The Big Idea
Pixels matter. And confused users are bugs.
A form that submits correctly but has its error message in a color that's invisible against the background — that's a bug. A checkout flow that technically works but has a confusing "Back" button that takes users to the wrong page — that's a bug.
UI/UX testing catches the issues that functional testing misses, because functional testing only checks what happens, not how it looks or how intuitive it is.
UI Testing vs. UX Testing
These two are often lumped together, but they answer different questions:
UI Testing (User Interface): Does it look the way it should?
- Alignment, spacing, padding — does it match the mockup?
- Typography — correct fonts, sizes, weights?
- Colors — correct palette, contrast ratio sufficient?
- Icons — correct icon, correct size, visible?
- Responsive behavior — does it work on mobile, tablet, desktop?
- Consistency — same-type buttons look the same across all pages?
UX Testing (User Experience): Does it feel right to use?
- Is the user journey logical from the user's perspective?
- Are error messages helpful (do they tell the user what to do next)?
- Are empty states clear (what does the user do when there's no content)?
- Are loading states visible (does the user know something is happening)?
- Is the flow forgiving — can the user easily undo or go back?
- Are labels and microcopy clear and action-oriented?
The key distinction:
- UI bug: button is 2px lower than in the Figma mockup
- UX bug: button is correctly positioned but labeled "Submit" on a form where "Save Draft" would make more sense
Figma as Your Source of Truth
When testing visual correctness, you need a specification. That specification is the design mockup — usually in Figma, Sketch, or Zeplin.
How to use Figma for UI testing:
- Open the design file and the actual app side by side
- Compare element by element: alignment, spacing, typography, colors
- Use Figma's inspect panel to get exact values (px, hex codes, font sizes)
- Flag deviations — even small ones. A 4px misalignment on a button is acceptable; a 40px misalignment is a layout bug
What you're looking for:
- ✅ Correct spacing and alignment
- ✅ Correct colors (use exact hex values from the design system)
- ✅ Correct typography (size, weight, line height)
- ✅ Correct component variants (primary vs. secondary button style)
- ✅ All states implemented (default, hover, active, disabled, error)
- ✅ Correct responsive breakpoints
Nielsen's 10 Heuristics — Your UX Checklist
Jakob Nielsen's 10 usability heuristics are the most widely used framework for evaluating UX. You don't need to memorize them — you need to know they exist and apply them.
| # | Heuristic | What to look for |
|---|---|---|
| 1 | Visibility of system status | Does the user know what's happening? (loading indicators, progress bars, confirmation messages) |
| 2 | Match between system and real world | Does the language match the user's mental model? (Not "null pointer exception" — "Something went wrong") |
| 3 | User control and freedom | Can users undo actions and easily navigate back? |
| 4 | Consistency and standards | Do same-type elements look and behave the same across the app? |
| 5 | Error prevention | Does the UI prevent errors before they happen? (confirmation dialogs, disabled states) |
| 6 | Recognition over recall | Can users find what they need without memorizing paths? (breadcrumbs, visible labels) |
| 7 | Flexibility and efficiency | Are there shortcuts for power users? (keyboard shortcuts, quick actions) |
| 8 | Aesthetic and minimalist design | Is every element earning its place? (no irrelevant information or decoration) |
| 9 | Help users recognize, diagnose, and recover from errors | Are error messages specific and constructive? |
| 10 | Help and documentation | When users need help, is it easy to find and action-oriented? |
Real-World Bug Examples
UI Bug: The "Confirm" button on the delete account dialog has a background color of #e0e0e0 (light gray), but the design spec shows #d32f2f (danger red). The button is functional but doesn't communicate danger visually.
UX Bug: After submitting the contact form, the page reloads and shows the same empty form — with no confirmation message. The user doesn't know if the submission succeeded. They submit again. Duplicate messages flood the support inbox.
Both are bugs. Both affect the user's experience in measurable ways. Neither is caught by functional testing.
Pro Tips
💡 Test on real devices, not just browser responsive mode. Browser DevTools simulate screen sizes, but they don't replicate real touch interactions, real font rendering, or real performance on mobile hardware.
💡 Read error messages out loud. If you feel awkward reading it, a real user will too. "An error has occurred" tells nobody anything. "Your session expired — please log in again" is actionable.
💡 Test empty states deliberately. New user accounts, empty search results, cleared carts — these are some of the most neglected states in product development and some of the most visible to real users.
Summary
- 🎨 UI testing = visual correctness against the mockup (alignment, colors, typography, components)
- 🧭 UX testing = intuitiveness, clarity, user journey logic
- 🖼️ Figma is your source of truth for UI — inspect exact values, compare element by element
- 📋 Nielsen's 10 heuristics give you a structured framework for UX evaluation
- 🐛 Both UI and UX defects are real bugs — not cosmetic nitpicking
Module 3 complete! 🔬 Next: Module 4 — Levels & Code Access. Let's explore boxes and stages. 📦