Vibe Designing - UI/UX Masterclass

Overview: **Product design is the discipline of shaping a digital product around real human needs rather than around whatever looks good on a moodboard.** UI (user interface) is what a person sees and touches — buttons, screens, colors, type. UX (user experience) is everything they feel while trying to accomplish a goal — whether the app is fast, clear, trustworthy, and worth coming back to. The most important idea in this lesson is that a designer's first job is not decoration, it is problem-solving: every screen you will ever draw exists to help a specific person do a specific thing. UI vs UX, precisely: **UI is the visual and interactive layer — layout, color, iconography, motion, and the components a user directly manipulates.** UX is the full journey around that layer — onboarding friction, load times, error recovery, and whether the product's mental model matches what the user already expects. A beautiful UI on top of a confusing UX still fails; a plain UI that removes friction at every step often wins. Treat UI as the outfit and UX as the whole relationship. The designer's mindset: **Product designers work from constraints inward, not from inspiration outward.** Before opening Figma, a working designer asks who the user is, what job they are hiring the product to do, what business goal the screen must serve, and what technical constraints (platform, data, existing components) shape the answer. This is called "framing" the problem, and skipping it is the single biggest reason redesigns miss the mark. Jakob's Law and existing mental models: Jakob's Law states that users spend most of their time on other people's products, so they arrive at yours with expectations already formed — a cart icon means shopping, a hamburger icon means a hidden menu, pull-down means refresh. Good product designers borrow familiar patterns deliberately and save true innovation for the parts of the product that actually differentiate it, rather than reinventing basic navigation for its own sake. How this course builds the skill: Across five modules you will move from research and structure (Modules 1-2) into visual craft (Module 3) into interactive prototyping in Figma (Module 4) and finally into telling the story of your work as a portfolio case study (Module 5). Each lesson builds on the last, so the mindset habit you build here — always ask "whose problem am I solving and how will I know it's solved" — should follow you into every wireframe, every color choice, and every button you place for the rest of the course.

Overview: **No design decision means anything until you know precisely what problem you are solving and for whom.** This lesson is about separating a user's stated want from their actual underlying goal, and learning to write problems down in a form that can actually be tested against a design. The most important idea here is that a vague problem produces a vague design — precision at this stage saves weeks of rework later. Problems vs symptoms: Users usually describe symptoms, not root problems — "the app is slow" might really mean "I can't tell if my payment went through." Good researchers use the "5 Whys" technique, repeatedly asking why a stated frustration exists until they reach a cause a design can actually address. Confusing a symptom for the real problem leads to redesigns that look different but solve nothing. User goals vs business goals: Every product sits at the intersection of what the user wants (get a task done quickly, feel confident, avoid embarrassment) and what the business needs (revenue, retention, lower support costs). A strong designer states both explicitly for every feature, for example: "User goal: pay a bill in under 60 seconds. Business goal: reduce failed-payment support tickets by 20%." When the two goals conflict, that tension is exactly what design decisions need to resolve. Writing a problem statement: **A usable problem statement follows a simple structure: [user] needs a way to [need] because [insight], but [current obstacle].** This format, borrowed from design-thinking practice, forces you to name a real person, a real need, and a real barrier instead of jumping straight to a solution like "we need a new app." Keep it to one or two sentences — if it needs a paragraph, the problem hasn't been narrowed enough yet. Validating the problem before designing: Before sketching anything, check the problem against real signals — support tickets, app store reviews, analytics drop-off points, or five minutes of conversation with an actual user. Even informal validation (asking three people the same question) catches wrong assumptions cheaply, while designing first and validating later means the mistake is now baked into components, copy, and flows that are expensive to unwind.

Overview: **Personas and empathy maps exist to stop designers from designing for themselves.** It is dangerously easy to assume every user thinks the way you do; personas force a team to agree on who they're actually building for, and empathy maps force them to think in that person's context, not just their demographics. The most important idea in this lesson is that these tools are only useful when built from real observation, not guesswork. What a persona actually is: A persona is a composite, research-grounded profile representing a cluster of real users with shared goals and behaviors — not a fictional biography with a stock photo and a made-up favorite coffee order. A working persona includes a goal, key frustrations (pain points), relevant behavior (device used, tech comfort, context of use), and a representative quote. Skip invented details like hobbies or family status unless they genuinely affect product decisions — extra flavor text that doesn't inform a decision is just decoration. Building personas from evidence: **Strong personas come from interviews, support data, surveys, or analytics segments — never from a single designer's imagination.** If you can't point to where a trait came from, question whether it belongs. For a student project without access to real interviews, secondary research (forum threads, reviews of similar apps, published market data) is an acceptable substitute, as long as you cite it rather than presenting it as verified fact. Empathy maps: **An empathy map is a four-quadrant tool — Says, Thinks, Does, Feels — used to capture a user's context around a specific task rather than their whole life story.** "Says" and "Does" come from observable, quotable evidence; "Thinks" and "Feels" are informed inferences you make explicit so the team can challenge them. Empathy maps work best filled out immediately after a user interview or usability session, while details are fresh. Using personas without stereotyping: The risk with personas is turning a research tool into a cardboard stereotype that excuses lazy thinking ("our persona wouldn't like that" used to shut down debate instead of open it). Treat a persona as a living hypothesis: revisit and revise it as you learn more, and always be ready to say which specific research finding backs each trait on the page.

Overview: A user journey maps what a real person experiences over time as they try to accomplish a goal with your product — including the parts outside the screen, like discovering the app exists or getting frustrated enough to quit. The most important idea in this lesson is that journeys reveal problems screens alone can't show: drop-off points, emotional dips, and moments where the product fights the user instead of helping them. Anatomy of a journey map: A typical journey map has stages (Awareness, Consideration, Onboarding, Usage, Support, Renewal, for example), and for each stage it tracks the user's actions, their touchpoints (app screen, email, customer support, push notification), their thoughts, and their emotional state — often drawn as a rising and falling line. The emotional curve is the most diagnostic part: sharp dips point exactly to where redesign effort should go first. Stages vs screens: **A common beginner mistake is mapping journeys screen-by-screen instead of stage-by-stage.** A journey stage like "first payment" might span five screens, a push notification, and a wait for bank confirmation — map the stage as the user experiences it, then zoom into screens afterward during wireframing. Journey mapping happens before screen design specifically so structural problems get caught before visual work begins. Finding friction and moments of truth: **Every journey has "moments of truth" — points where the user decides whether to trust the product (a slow first load, a confusing permission request, a surprise fee).** Mark these explicitly on the map. These are the highest-leverage places to invest design and engineering effort, because a bad moment of truth early in a journey can undo good design everywhere else. From journey to backlog: **A completed journey map should produce a prioritized list of problems, not just a pretty diagram.** For each friction point, note its severity (does it cause drop-off or just mild annoyance?) and a rough fix direction. This list becomes the input to the wireframing work in Module 2 — you are not sketching screens yet, you are deciding which parts of the journey deserve a screen redesign first.

Overview: **Information architecture (IA) is the practice of organizing and labeling content so people can find what they need without thinking hard about it.** It is invisible when done well and infuriating when done badly — think of a menu with three different places a user might reasonably look for "Settings." The most important idea in this lesson is that IA decisions made now determine how confusing or effortless every future screen will feel, so they deserve real research, not guesswork. Card sorting: Card sorting is the core IA research method — you write content items or features on individual cards (physical or digital, using tools like Optimal Workshop or Figma's own sorting templates) and ask real users to group them in ways that make sense to them. An open card sort lets users create and name their own categories, revealing their mental model from scratch; a closed card sort asks users to place items into categories you've already defined, which is useful for testing an existing structure. Run this with 5-15 participants for patterns to emerge reliably. Site maps and hierarchy: A site map is the resulting tree diagram showing how screens or sections relate — what's a top-level destination, what's nested underneath, and how deep a user has to click to reach something. Keep hierarchies shallow: research on navigation consistently shows users get lost faster in deep, narrow trees than in shallow, broad ones, so prefer more items at one level over many click-throughs to reach content. Labeling and language: Labels must match the user's own vocabulary, not internal company jargon — if users call it "My Orders" in an interview, don't rename it "Purchase History" in the UI to sound more formal. Test ambiguous labels with a tree test (asking users to find something using only the label hierarchy, no visuals) before committing to it in a wireframe. How IA feeds the next lessons: A validated site map becomes the skeleton for screen flow mapping and navigation pattern choices in Module 2 — you cannot design a tab bar or menu sensibly until you know what actually needs to live in it. Treat IA as the plumbing behind the walls: unglamorous, but the reason nothing leaks later.

Overview: **Mobile-first thinking means designing for the smallest, most constrained screen and context first, then expanding upward to tablet and desktop — not the reverse.** In markets like Kenya, where most users access the internet primarily or exclusively through a smartphone, this isn't a stylistic preference, it's a reflection of how the product will actually be used. The most important idea in this lesson is that constraints make you prioritize, and prioritizing on mobile makes every larger screen easier to design well. Why mobile-first, not mobile-only: Starting with the smallest viewport (roughly 360-430px wide for most Android and iPhone devices) forces hard decisions about what truly matters on a screen, because there is no room for everything. Once the mobile layout is solid, progressive enhancement adds content and secondary actions as screen space grows — this is far easier than starting with a spacious desktop design and then trying to cram it down into a phone, which usually just hides things behind more taps. Touch targets and thumb zones: Apple's Human Interface Guidelines and Google's Material Design both recommend a minimum touch target of roughly 44-48 points/dp, translating to about 44x44pt on iOS or 48x48dp on Android, so buttons and tap areas need real breathing room, not just visually-sized icons. Fitts's Law explains why this matters: the time to accurately hit a target depends on its size and distance from the current touch point, so small, far-apart buttons cause real, measurable mis-taps, especially for one-handed use where the thumb naturally reaches the bottom half of the screen more easily than the top. Connectivity and data constraints: Designing for markets with variable mobile data speeds and costs means treating performance as a UX feature: compress images, avoid auto-playing heavy media, design meaningful loading and offline states, and never let a slow network look like a broken app. A skeleton loading state or a clear "no connection" message communicates system status far better than a screen that silently hangs. Responsive vs adaptive: **Responsive design uses flexible grids and breakpoints so one layout reflows across sizes; adaptive design serves distinct fixed layouts per device category.** Most modern product teams default to responsive with a mobile-first breakpoint strategy (base styles for small screens, then min-width media queries adding complexity upward), which is also how Module 3's spacing and grid lessons will assume your layouts behave.

Overview: This checkpoint lesson pulls together every skill from Module 1 — problem framing, personas and empathy maps, journey mapping, information architecture, and mobile-first thinking — into a single research deliverable you can defend and later show in a portfolio. The most important idea here is that a checkpoint is not busywork; it is the first real test of whether your research actually holds together as evidence for the design decisions you're about to make in Module 2. What a strong checkpoint submission includes: A complete submission names a specific product and a specific, validated problem statement (from Lesson 1-2), a persona and empathy map grounded in cited evidence (Lesson 1-3), a journey map showing at least one clear emotional dip and moment of truth (Lesson 1-4), a site map or IA sketch showing your content hierarchy (Lesson 1-5), and a short note on how mobile constraints shape your priorities (Lesson 1-6). Missing any one of these leaves a gap a reviewer will immediately notice. The consistency check: The single biggest weakness in student checkpoints is internal contradiction — a persona described as impatient and mobile-only, but a journey map that assumes long desktop sessions; or a problem statement about speed, but an IA with six nested menu levels. Before submitting, read your own documents back to back and ask whether every artifact tells the same story about the same user. How reviewers evaluate this stage: **A tutor or peer reviewer at this checkpoint is not grading visual polish — there are no screens yet — they are grading reasoning.** Can you explain why this persona, why this journey stage matters most, why this IA structure over an alternative? Being able to say "I chose X over Y because of Z evidence" is worth more than a beautifully formatted document with no justification behind it. Setting up Module 2 for success: **Everything in Module 2 (sketching, wireframes, flows, navigation, forms, error states) will directly reference this research.** Treat this checkpoint as the brief you're handing to your future self — the clearer and more specific it is now, the less you'll have to guess or backtrack once you start drawing actual screens.

Overview: **Sketching is the fastest, cheapest way to generate and discard ideas before any pixel is placed in Figma.** The point of this lesson is not artistic skill — it's speed and volume, because the first idea is rarely the best one, and sketching lets you find that out in minutes instead of hours. The most important idea in this lesson is that low commitment breeds better ideas: a pencil sketch is easy to throw away, a polished mockup is not. Crazy 8s and rapid ideation: A widely used sketching exercise, popularized by Google Ventures' design sprint process, is "Crazy 8s": fold a sheet of paper into eight sections and sketch eight distinct variations of one screen or flow in eight minutes, roughly one minute per sketch. The time pressure is deliberate — it prevents overthinking any single idea and forces genuinely different directions instead of eight small variations of the same concept. What to sketch and what to skip: **Sketch structure and flow, not visual polish — boxes for content blocks, arrows for navigation, rough labels for buttons.** Skip color, exact spacing, and typography entirely at this stage; including them signals false precision and tempts you to fall in love with details before the underlying structure is validated. If you catch yourself picking a font in a sketch, you've moved past sketching into premature visual design. Sketching for flows, not just single screens: **Beyond individual screens, sketch the connections between them — draw a rough screen, an arrow, the next rough screen, labeling what action triggers the transition.** This catches structural problems (a dead end, a missing back path, a step that needs information you haven't collected yet) far earlier and cheaper than catching them in a Figma prototype. From sketch to selection: After a sketching session, don't pick a winner by personal taste alone — hold a quick "dot voting" round with teammates or your tutor, where each person marks the elements they find strongest across all sketches, even if it means combining pieces from different ones. The output of this lesson should be one or two chosen directions, annotated with why they were chosen, feeding directly into the low-fidelity wireframes in the next lesson.

Overview: Low-fidelity wireframes turn a chosen sketch direction into a cleaner, more precise structural layout — still without color, real copy, or final typography — so structure can be evaluated and agreed on before visual design begins. The most important idea in this lesson is that low fidelity is a deliberate choice, not a lack of skill: keeping wireframes rough on purpose keeps feedback focused on layout and hierarchy instead of color opinions. What belongs in a low-fi wireframe: Grayscale boxes, placeholder text (often labeled "Heading," "Body copy," or Lorem ipsum), simple line icons or labeled rectangles for icons, and basic proportions for buttons, cards, and images. The goal is to communicate what exists on a screen and roughly how important each element is relative to the others, established through size and position, not through color or decoration. Why fidelity level controls the feedback you get: Showing a stakeholder a polished, colorful mockup too early tends to generate comments about color and font choices, because that's what's easiest for a non-designer to react to — even if the underlying structure is broken. Showing a rough wireframe instead keeps the conversation on the right questions: does this layout make sense, is anything missing, is the priority order right. This is sometimes called the "fidelity trap," and deliberately staying low-fi protects a review session from it. Tools for low-fi work: **Figma's own shape and frame tools are enough for digital low-fi wireframes — rectangles, a default gray fill, and its built-in font at one or two weights.** Many teams also use dedicated wireframing kits or plugins, but the core discipline matters more than the tool: constrain yourself to grayscale and generic type even inside a full-featured tool like Figma. Annotating wireframes: Add short annotations next to non-obvious elements explaining behavior — "this card is horizontally scrollable," "this button is disabled until the form is valid." Annotations let a wireframe communicate interaction intent that a static image alone cannot, which matters most once you move into screen flow mapping in the next lesson, where these individual screens get connected into a full flow.

Overview: Screen flow mapping connects individual wireframes into a navigable diagram showing every path a user can take through a product — the digital equivalent of a floor plan with doors and hallways. The most important idea in this lesson is that a flow diagram exposes structural problems (dead ends, missing back paths, screens with no way in) that are invisible when you only look at screens one at a time. Building the flow diagram: Lay out each wireframe as a node and connect them with labeled arrows showing the action that causes the transition — "tap Continue," "swipe left," "payment succeeds," "payment fails." Branch points (like a payment succeeding or failing) should show both outcomes as separate arrows, because designing only the happy path and forgetting the failure path is one of the most common and costly mistakes at this stage. Happy path vs edge cases: **The happy path is the ideal sequence where everything goes right — form filled correctly, network available, payment approved.** Map that first for clarity, then deliberately map at least the most important edge cases: what happens on a validation error, a timeout, an empty state, or a permission denial. Each edge case you map now is one fewer surprise gap when the flow reaches development. Entry points and exits: A flow needs more than one entry point mapped realistically — users can land on a product screen from a push notification, a shared link, a search result, or the home screen, not only from a fresh app launch. Similarly map exits: where can a user back out, cancel, or abandon a flow, and does the product handle that gracefully (saved draft, confirmation dialog) or just lose their progress? Tools and conventions: **Figma (using its own frames connected with arrows, or FigJam for a looser diagram), Miro, and Whimsical are common tools for flow mapping.** Use consistent shapes — rectangles for screens, diamonds for decision points, arrows labeled with the triggering action — so anyone reading the diagram, including a developer later, can follow it without you narrating it out loud.

Overview: **Navigation is the system that lets users move between the destinations mapped in your information architecture and screen flows.** Choosing the right navigation pattern is a structural decision, not a visual one — the wrong pattern makes even well-organized content feel lost. The most important idea in this lesson is that navigation choice should follow the shape of your content and the platform's own conventions, not personal preference. Common mobile patterns: A bottom tab bar (2-5 top-level destinations, always visible, following Jakob's Law expectations from apps like Instagram or M-Pesa) works best for a small number of frequently-used top-level sections. A hamburger menu hides more destinations behind one icon, trading discoverability for screen space — appropriate for secondary or infrequently used items, but risky for anything a user needs often, since hidden items get used less simply because they're hidden. A hybrid pattern (visible tab bar plus a "More" tab that opens a fuller list) is common when there are more sections than a tab bar can comfortably hold. Hierarchical vs flat navigation: Hierarchical navigation nests content in parent-child relationships (category > subcategory > item), matching a deep site map; flat navigation puts more destinations at one level, trading depth for fewer taps. Given what Lesson 1-5 covered about users getting lost faster in deep trees, default toward flatter structures unless the content genuinely has strong natural hierarchy, like an e-commerce catalog. Platform conventions matter: iOS and Android have different default patterns and back-navigation behavior (iOS commonly favors a bottom tab bar with a top navigation bar showing a back chevron; Android's system back gesture/button changes what an in-app back button even needs to do). Departing too far from platform convention forces users to relearn basic navigation, which fights Jakob's Law directly. Signaling current location: Whatever pattern you choose, always give users a clear "you are here" signal — a highlighted tab icon, a breadcrumb, a page title — since Nielsen's heuristic of visibility of system status applies directly to navigation. A user who can't tell where they are in an app loses trust quickly, even if every individual screen is well designed.

Overview: Forms are where products most often lose users, because every additional field or unclear instruction adds friction at the exact moment a user is trying to commit to an action. This lesson is about designing forms and their many states so they guide rather than obstruct. The most important idea in this lesson is that a form's default (empty), focused, filled, error, and disabled states all need to be designed on purpose, not left to whatever the browser or framework does by default. Field reduction and grouping: The single highest-leverage form improvement is usually removing fields, not styling them better — ask whether each field is truly required now, or could be collected later or inferred. Group related fields logically (name fields together, address fields together) and order them in the sequence a person would naturally think of them, since Hick's Law shows that more choices and more fields presented at once increase decision time and abandonment. Labels, placeholders, and input types: Use persistent labels above fields rather than relying on placeholder text alone — placeholder text disappears once a user starts typing, which removes context exactly when they might need to double-check what a field wants, especially on longer forms. Match input types to the data (a numeric keypad for a phone number field, a date picker for dates) so mobile users aren't fighting the wrong keyboard. Validation timing: Validate on blur (when a user leaves a field) or on submit, not on every keystroke, since flagging an email as "invalid" while someone is still mid-typing it feels punishing rather than helpful. Inline, field-level error messages that explain exactly what's wrong and how to fix it ("Enter a valid phone number, e.g. 07XX XXX XXX") perform far better than a generic banner at the top of the form saying "there were errors." Disabled and loading states: A disabled submit button should visually read as disabled (lower contrast, no hover affordance) so users don't wonder if it's broken, and it should become active the moment requirements are met — not require an extra unrelated action. During submission, show a loading state on the button itself (spinner, "Submitting..." label) so the system status stays visible, directly supporting Nielsen's heuristic that systems should always keep users informed of what's happening.

Overview: **Feedback and error states are how a product communicates its own status back to the user — success, failure, loading, or emptiness.** Designing these deliberately, rather than leaving them as an afterthought for developers to improvise, is directly tied to Nielsen's heuristic of visibility of system status: users should always know what's happening, what just happened, and what to do next. The most important idea in this lesson is that silence is the worst state a product can be in — an unlabeled blank screen or a frozen button reads as broken even when it technically isn't. The four core states: **Every data-dependent screen needs at minimum a loading state, an empty state, a success state, and an error state designed on purpose.** Loading states (skeleton screens, spinners, progress bars) reassure users something is happening during a wait; empty states (a first-use screen with no data yet) should explain what belongs there and how to add it, not just show blank space; success states confirm an action worked, often briefly, before moving on; error states explain what went wrong in plain language and, wherever possible, a concrete next step. Writing good error messages: **A good error message names the problem specifically and avoids blame or jargon — "We couldn't reach the server.** Check your connection and try again" beats "Error 500" or "Something went wrong." Where the cause is on the user's side (like an invalid field), point directly at it; where the cause is on the system's side, don't imply the user did something wrong. Empty states as an opportunity: A well-designed empty state does more than say "nothing here" — it can explain the feature's value and offer a clear first action, functioning as a small piece of onboarding at exactly the moment a user needs direction. A to-do app's empty task list, for instance, is a natural place for a prominent "Add your first task" prompt rather than a bare, unexplained blank list. Toasts, banners, and inline feedback: Match the feedback mechanism to the severity and scope of the event — a small, temporary toast for a low-stakes confirmation ("Saved"), a persistent banner for something the user must act on (an expired session), and inline, field-level feedback for form-specific issues. Overusing intrusive modals for minor feedback trains users to dismiss dialogs without reading them, weakening feedback for the moments that truly need attention.

Overview: This checkpoint tests whether your Module 2 work — sketches, low-fi wireframes, screen flows, navigation choices, forms, and feedback states — forms one coherent, navigable structure grounded in the Module 1 research. The most important idea here is that a wireframe set is only successful if a stranger could follow it end to end without you explaining anything out loud. What a strong submission includes: A complete flow diagram covering at least one full happy-path journey plus its major edge cases, low-fidelity wireframes for every screen in that flow, an explicit navigation pattern choice with a one-line justification tied to your content and platform, at least one form screen with its states (empty, error, disabled, success) designed, and at least one non-form screen with loading/empty/error states designed. The walkthrough test: Before submitting, do a cold walkthrough — hand the wireframes (or a link) to someone who hasn't seen the project and ask them to narrate what they'd tap and why, without your help. Every place they hesitate, ask "what happens if...," or guess wrong is a real structural gap, not a taste disagreement, and it should be fixed before adding any visual polish in Module 3. Tracing back to research: A strong checkpoint explicitly ties structural decisions back to Module 1 evidence — "bottom tab navigation was chosen because the persona is a frequent, task-focused mobile user," not just "it looked cleaner." Reviewers at this stage are checking whether your structure actually serves the problem you defined, not whether it resembles an app you admire. What NOT to fix yet: Resist the urge to add color, real typography, or brand personality at this stage even if you're tempted — that's Module 3's job, and doing it now reintroduces the "fidelity trap" from Lesson 2-2, where surface polish distracts reviewers from remaining structural gaps. A wireframe checkpoint that's still gray and rough, but flawless, is a stronger submission than one that looks pretty but hides broken flows underneath.

Overview: **Typography carries most of the information in any interface, so it deserves the same systematic thinking as layout or color, not last-minute font-picking.** The most important idea in this lesson is that a type system — a small, deliberate set of sizes, weights, and line heights — reads as more professional and is far easier to maintain than a page where every heading was sized by eye. Type scale and hierarchy: A type scale is a limited set of font sizes (commonly following a ratio like 1.125 or 1.25 between steps, e.g. 14/16/18/20/24/32/40px) used consistently across an interface so headings, body text, and captions stay visually distinct and predictable. Hierarchy is communicated through size, weight, and color together — a heading doesn't need to be huge if its weight and spacing already separate it clearly from body text, and over-relying on size alone often produces headlines that dominate a screen more than the content warrants. Line height, line length, and readability: Body text generally reads best with a line height (leading) of around 1.4-1.6x the font size and a line length of roughly 45-75 characters per line — lines that are too long make it hard for the eye to track back to the start of the next line, and lines that are too short break reading rhythm. On mobile, where columns are narrow by default, line length is rarely the problem, but line height and paragraph spacing still need deliberate values rather than defaults. Font pairing and choosing typefaces: Most interfaces work well with one or two typefaces total — a single versatile family (like Inter, Roboto, or SF Pro) used across weights is often enough, and if pairing two, contrast them clearly (a geometric sans for headings, a humanist sans or serif for body) rather than choosing two similar fonts that look like a mismatch rather than an intentional choice. Prioritize typefaces with strong legibility at small sizes and full character support if your product needs it, since local language or currency symbols can expose gaps in a font's character set. Accessibility in type choices: Keep body text at a minimum of 16px equivalent on mobile web to avoid iOS auto-zoom-on-focus behavior and general legibility issues, avoid setting large blocks of text in all-caps or fully justified (which creates uneven word spacing), and make sure font weight differences are strong enough to read clearly at small sizes, not just barely distinguishable at 100% zoom.

Overview: Color in interface design is a functional system, not just a brand decision — it signals state, hierarchy, and meaning, and it must remain usable for people with low vision or color blindness. The most important idea in this lesson is that a defensible color system is built from a small palette with clear roles, tested against real contrast ratios, not chosen purely by eye. Building a color system: A working UI palette typically includes a primary brand color, one or two secondary/accent colors, a neutral gray scale (5-9 steps, from near-white to near-black, used for text, borders, and backgrounds), and semantic colors for success, warning, and error states. Each color should exist in a small set of tints and shades (often expressed as numbered steps like 100-900) so the same blue used for a button can also appear as a lighter background or a darker pressed state without introducing a new, uncoordinated color. Contrast and WCAG standards: WCAG 2.2 sets minimum contrast ratios of 4.5:1 for normal text against its background and 3:1 for large text (roughly 24px regular or 18.66px bold and up) at the AA level, with 7:1 and 4.5:1 respectively for the stricter AAA level; non-text UI elements like icons and input borders need at least 3:1 against adjacent colors. Check every text/background and icon/background pairing against these ratios using a contrast checker before finalizing a palette — a color that looks readable to a designer on a bright monitor can still fail these numeric thresholds. Don't rely on color alone: Never use color as the only signal for meaning — a red border on an invalid field should be paired with an icon and text message, because color-blind users (affecting a meaningful percentage of men in particular, most commonly red-green color blindness) may not perceive the difference at all. This is also a core WCAG success criterion (Use of Color), not just a nice-to-have. Light and dark modes: If a product supports dark mode, colors need re-mapping, not simple inversion — pure white text on pure black background actually reduces readability for many users due to halation, so dark-mode UI typically uses off-white text on a dark gray (not pure black) surface, and saturated colors often need desaturating slightly since they can appear to vibrate against dark backgrounds.

Overview: Spacing and layout grids give an interface its sense of order and calm — most of what reads as "clean design" is actually just consistent, deliberate spacing rather than any single visual flourish. The most important idea in this lesson is that spacing should follow a system (a base unit and its multiples), not arbitrary pixel values chosen per screen. The spacing scale: Most modern design systems build spacing from a base unit, commonly 4px or 8px, with all padding, margins, and gaps chosen as multiples of it (4, 8, 12, 16, 24, 32, 48, 64px). This constraint makes layouts feel intentional and makes it trivial to keep components aligned to the same rhythm across an entire product, and it maps cleanly onto Figma's own spacing and Auto Layout gap values. Grids and columns: A layout grid divides a screen into consistent columns with defined gutters (space between columns) and margins (space at the edges) — a common mobile grid uses 4 columns with 16-20px margins, while desktop layouts often use 12 columns with wider margins, giving both a consistent structure to align content against. Figma's Layout Grid feature (in the right-hand Design panel) lets you overlay these grids directly on a frame while designing, so alignment can be checked visually as you work rather than guessed. White space as a design tool: Generous white space (negative space) isn't wasted space — it groups related elements, separates unrelated ones, and gives important elements room to stand out, directly applying the Gestalt principle of proximity (elements placed close together are perceived as related). Cramming more content into a screen to "use the space" usually reduces scannability rather than adding value, especially on mobile where visual clutter compounds quickly. Auto Layout and consistent spacing in Figma: Figma's Auto Layout feature lets you set fixed spacing values (gap, padding) on a frame that automatically apply as content is added, removed, or resized, which is the practical mechanism for actually enforcing a spacing scale rather than just intending to follow one. Setting up components with Auto Layout early avoids the common problem of spacing quietly drifting inconsistent across dozens of screens as a project grows.

Overview: Buttons and other reusable components are the vocabulary of an interface — get their states and variations right once, and every screen that uses them inherits that quality automatically. The most important idea in this lesson is that a component isn't finished when it looks good in one state; it's finished when every state (default, hover, pressed, focused, disabled, loading) has been considered. Button hierarchy: Interfaces typically need at least three button levels — primary (the single main action on a screen, strongest visual weight), secondary (an alternative action, lower visual weight, often an outline or ghost style), and tertiary/text buttons (low-emphasis actions like "Cancel"). Using more than one primary-style button on a screen undermines the whole point of hierarchy, because it forces the user to make a decision the design should be helping them avoid — this connects directly to Hick's Law, where more equally-weighted choices slow decision-making. Component states in Figma: **Figma's Variants feature groups related versions of a component (e.g.** Button/Primary/Default, Button/Primary/Hover, Button/Primary/Disabled) into a single component set, letting designers swap between states from one dropdown in the right panel instead of managing dozens of disconnected duplicate layers. Combined with Interactive Components (prototyping variant swaps triggered by hover, press, or click directly in prototype mode), this lets a button convincingly demonstrate its hover and pressed states inside a clickable prototype. Building with Auto Layout for resilience: **Buttons and cards built with Auto Layout resize gracefully when their label text changes length (a button that says "Continue" vs.** "Continue to payment" should stretch, not overflow or clip), which matters enormously once real copy replaces placeholder text later in the project. A component that only looks right with the exact original sample text is fragile and will break in production. Disabled and loading states specifically: A disabled button should be visually distinct (typically reduced opacity or a muted fill) and never rely on color alone per accessibility guidance, and cursor/interaction should communicate it's inactive. A loading state (spinner replacing or accompanying the label) should preserve the button's original size so the layout doesn't jump when the state changes — a small detail that meaningfully affects perceived polish.

Overview: Cards, lists, and tables are the three most common ways interfaces display collections of content, and choosing the right one — and designing it to handle real, messy data — is a distinct skill from designing a single hero screen. The most important idea in this lesson is that these components must be designed for their worst-case content (long titles, missing images, huge numbers), not just the clean sample data used in a mockup. When to use cards vs lists vs tables: Cards work well for visually distinct, browsable items where an image or thumbnail matters (products, articles, profiles) and users are scanning rather than comparing precisely. Lists suit denser, more linear content where users scan top to bottom quickly (notifications, chat threads, simple settings). Tables suit structured, comparable data with multiple attributes per row (transaction history, admin data, anything users might sort or filter by a specific column) — using a card grid for data that's really tabular usually makes comparison harder, not easier. Designing for real content: Always test a component with a long title that wraps to two lines, a short title, a missing thumbnail (does a placeholder or initials avatar appear?), and an unusually large number (KSh 1,250,000 vs KSh 50) to see whether the layout holds up. This is where Auto Layout's resizing behavior (Lesson 3-3, 3-4) becomes essential — a card built to only fit exactly the sample text will visibly break the moment real content is loaded. List and table density: Density (how much vertical padding surrounds each row) is a deliberate trade-off — dense rows show more content per screen but are harder to scan and tap accurately on mobile (reconnecting to Fitts's Law and touch target sizing from Lesson 1-6); looser rows are easier to scan and tap but show less at once. Match density to the platform and task: a mobile app usually needs looser rows than a desktop admin table used by a power user. Empty, loading, and overflow states for collections: Every card grid, list, or table needs its own empty state (Lesson 2-6) distinct from a single record's empty state, a loading skeleton that mimics the eventual layout's shape, and a defined behavior for overflow — pagination, infinite scroll, or a "show more" action — chosen deliberately based on how users are likely to browse that specific type of content.

Overview: Responsive UI decisions are about how a single design adapts as available screen width changes, from a narrow phone up through tablets to wide desktop monitors, without the underlying structure or content falling apart. The most important idea in this lesson is that responsiveness is a layout strategy decided during design, not something left entirely to whoever writes the code afterward. Breakpoints: A breakpoint is a defined screen width where the layout intentionally changes — common reference points are roughly 360-430px (mobile), 768px (tablet), and 1024-1440px+ (desktop), though exact values should be driven by where your specific content actually breaks, not copied blindly from a generic list. At each breakpoint, decide explicitly what changes: column count, navigation pattern (bottom tab bar becoming a top nav or sidebar), image sizing, and how much secondary content becomes visible versus hidden behind a tap. Fluid vs fixed elements: Some elements should scale fluidly with available width (body text columns, image containers, card grids reflowing more columns as space allows), while others should stay fixed regardless of screen size (touch target minimums, base font size, maximum reading line length for long-form text). Mixing these correctly, rather than either fully fixed or fully fluid, is what makes a responsive layout feel considered instead of just stretched. Figma's tools for responsive design: Auto Layout combined with constraints (pinning elements to left/right/center/scale within a frame, set in the right-hand Design panel) lets a single Figma frame preview reasonably how a layout behaves at different sizes, and creating separate frames per breakpoint (mobile, tablet, desktop) as needed lets you show intentional structural changes rather than just a stretched version of one layout. Figma's Variables feature can also drive responsive sizing tokens (spacing, radius) consistently across these frames. Content priority across breakpoints: The content and actions that matter most on mobile (Lesson 1-6) should stay the most prominent even as more space becomes available on desktop — resist the temptation to fill extra desktop space with lower-priority content just because there's room, since that can bury the primary task under decorative padding or secondary widgets that dilute focus rather than adding value.

Overview: This checkpoint tests whether your visual design work — typography, color, spacing, components, collections, and responsive behavior — comes together as a coherent, accessible design system applied consistently across your Module 2 flow, not just a single pretty screen. The most important idea here is that visual design quality is judged by consistency and legibility across many screens, not by how good any one hero screen looks in isolation. What a strong submission includes: A short style reference (type scale, color palette with roles, spacing scale) applied consistently across every screen in your flow, a component set (buttons, cards, form fields) built with Variants and Auto Layout showing their key states, at least one collection (card grid, list, or table) tested with realistic content lengths, and at least two breakpoints (mobile and one larger size) showing a deliberate, not just stretched, layout change. The accessibility check: Run your actual color pairings through a contrast checker and confirm your key text/background combinations meet at least WCAG AA (4.5:1 normal text, 3:1 large text and UI components) — this is not optional polish, it's a baseline your design should meet before being called finished. Also confirm no meaning depends on color alone (error states, required fields, status indicators). Consistency over cleverness: Reviewers at this stage are looking for whether the same button looks and behaves the same way on every screen, whether spacing values repeat from a defined scale rather than drifting, and whether type hierarchy is legible and consistent — not for a single visually daring screen that doesn't match the rest of the flow. A system that is 90% consistent and slightly plain will usually score better than one wildly creative screen next to four inconsistent ones. Preparing for Module 4: Because Module 4 turns these screens into a clickable Figma prototype, components built loosely now (not using real Variants, not using Auto Layout, inconsistent naming) will cause real friction later when trying to wire up interactive states. Treat this checkpoint as an opportunity to clean up component structure, not just visual appearance, before prototyping begins.

Overview: A well-organized Figma file is the foundation everything else in this module depends on — messy files with unnamed layers and scattered frames make prototyping, handoff, and collaboration painfully slow. The most important idea in this lesson is that file structure is a design skill in its own right, not just tidiness for its own sake. Pages, sections, and frame organization: A typical project file separates work into pages (using the left sidebar's Pages panel) such as "Cover," "Design System," "Wireframes," and "Final Screens," and within a page, Figma's Sections feature groups related frames visually (e.g. "Onboarding flow," "Checkout flow") with a labeled header, which is far easier to navigate than one long page of loose frames. Name every frame descriptively and consistently ("Checkout / 02 Payment / Error" beats "Frame 47"), since names are what show up later in prototype connections, comments, and dev handoff. Styles and shared libraries: Rather than repeating raw hex codes and font sizes across every frame, define color and text Styles (or, more powerfully, Variables for colors, spacing, and other tokens) once and apply them everywhere — this means a single palette change propagates across the whole file instead of requiring manual updates on every screen. For team or multi-file projects, publishing a shared Library lets components and styles stay in sync across separate files, which is how real product teams keep a consistent design system across many product areas. Setting up frames for real devices: Use Figma's built-in frame presets (iPhone, Android, common desktop widths) as a starting point, matching the breakpoints decided in Lesson 3-6, and keep consistent canvas positioning so related screens read left-to-right or top-to-bottom in the order a user would experience them — this alone makes a file dramatically easier for a reviewer or teammate to follow without narration. Version history and collaboration hygiene: Figma auto-saves version history, but naming key milestones (via the version history panel, accessible from the file's top-left menu) makes it possible to return to a specific known-good state later, which matters once multiple people or multiple work sessions start touching the same file. Establishing this discipline before building components (Lesson 4-2) and prototypes (Lesson 4-4) prevents rework caused purely by file chaos rather than design decisions.

Overview: Reusable components are what let a design system scale — build a button, card, or input field once as a true Figma component, and every instance of it across dozens of screens can be updated from a single source. The most important idea in this lesson is the distinction between a main component and its instances, and why editing discipline matters enormously once a file has hundreds of instances depending on it. Main components vs instances: A main component (marked with a purple diamond icon in Figma) is the original, editable source; every copy placed elsewhere in the file is an instance (marked with a filled purple diamond, linked back to the main component). Editing the main component pushes that change to every instance automatically; editing an individual instance directly only overrides that one copy, which is intentional for one-off exceptions but a problem if done accidentally at scale, since it silently breaks the connection to future updates. Variants and component properties: Group related components (a button in primary/secondary styles, at small/medium/large sizes, in default/hover/disabled states) into a single component set using Figma's Variants, selectable from a dropdown in the right-hand panel rather than hunting for separate, disconnected components. Component Properties go further, exposing swappable text, boolean visibility toggles (show/hide an icon), and instance swaps (swap which icon appears) directly in the right panel, so a designer using the component doesn't need to dig into its internal layers to customize it correctly. Naming and organizing components: Use a consistent naming convention with forward slashes to create automatic groupings in the Assets panel ("Button/Primary/Large," "Icon/Navigation/Home"), which keeps a growing component library searchable and prevents duplicate, near-identical components from being created by accident because an existing one wasn't easy to find. Why this matters for Module 4's later lessons: Auto Layout (Lesson 4-3) and interactive prototyping (Lesson 4-4) both depend on components being built cleanly now — a button component with proper Auto Layout and well-named Variants can demonstrate real hover and pressed states in a prototype, while a set of loose, duplicated rectangles cannot. Time invested in clean components here pays off directly in how convincing the eventual clickable prototype feels.

Overview: Auto Layout is Figma's system for building frames that behave like real, responsive code — rather than a static arrangement of shapes, an Auto Layout frame reflows its children automatically when content, spacing, or resizing changes, much like CSS Flexbox. The most important idea in this lesson is that Auto Layout is what makes a Figma design resilient to real content, not just accurate for the one piece of sample text used while designing. Core properties: An Auto Layout frame has a direction (horizontal or vertical stacking), a gap (space between children, following your Lesson 3-3 spacing scale), padding (space inside the frame's edges), and alignment (how children align on the cross-axis). These four properties, set in the right-hand Design panel once a frame has Auto Layout applied (shortcut Shift+A), replace what would otherwise be dozens of manually-positioned, individually-adjusted elements. Resizing behavior: Each child inside an Auto Layout frame can be set to Fixed (stays its set size regardless of content), Hug contents (grows or shrinks exactly to fit its content, useful for buttons and tags), or Fill container (expands to take up all remaining available space, useful for input fields or content that should stretch). Choosing the right resizing behavior per element is what makes a card handle a two-line title gracefully instead of clipping or overflowing. Nested Auto Layout: Auto Layout frames can be nested inside other Auto Layout frames (a card containing an Auto Layout row of tags, inside an Auto Layout column of card content, inside an Auto Layout grid of cards), letting complex, real-world layouts stay fully responsive at every level rather than only at the outermost frame. This nesting is also what lets a single component like a card resize correctly when placed inside different contexts, like a narrow mobile column versus a wider desktop grid. Auto Layout and Variables together: Combining Auto Layout's gap and padding values with Figma Variables (numeric tokens for your spacing scale) means a global spacing change can propagate through every nested Auto Layout frame that references that variable, which is the closest a static design tool gets to true design tokens used in production code — directly setting up the handoff quality developers expect in Module 4's later, more interactive work.

Overview: Interactive prototypes turn static screens into a clickable, testable experience — connecting frames with triggers, actions, and transitions so a stakeholder, tutor, or real user can navigate the product as if it were built, without a single line of code. The most important idea in this lesson is that a prototype's job is to make the flow feel real enough that problems surface before development, not to be visually perfect. Triggers, actions, and transitions: In Figma's Prototype tab (right-hand panel), a connection between two frames is defined by a trigger (what the user does: Click/Tap, Drag, While Hovering, While Pressing, Mouse Enter, or Key/Gamepad), an action (what happens: Navigate to, Open Overlay, Swap Overlay, Scroll To, Open Link, Change to a component's Variant), and a transition (how it animates: Instant, Dissolve, Smart Animate, Move In, Push, Slide). Smart Animate is especially powerful because it automatically animates matching layers between two frames (same layer name and structure) — it's how a button convincingly appears to shift from default into a pressed or loading Variant, or how a tab indicator slides between tabs. Overlays and interactive components: Overlays let one frame appear on top of another without a full navigation (used for modals, dropdown menus, bottom sheets, toasts) and can be configured to close on an outside click, which matters for realistic modal behavior. Interactive Components (built on the Variants from Lesson 4-2) let a single component demonstrate its own internal state changes — a checkbox toggling checked/unchecked, a button showing its pressed state — directly within the prototype, without needing separate connected frames for every micro-interaction. Scroll behavior and fixed elements: Setting a frame's scroll behavior (vertical, horizontal, both) combined with fixing specific elements (like a sticky header or bottom tab bar) to stay in place while content scrolls underneath makes a prototype behave convincingly like a real mobile app rather than a flat, static image with clickable hotspots. Testing the whole flow, not just one screen: Use the Present mode (top-right Play button) to click through your entire Module 2 flow end to end, checking that every branch from your screen flow map (Lesson 2-3) — including error paths, not just the happy path — is actually wired up and navigable, since an unconnected screen or dead-end button undermines the realism the whole prototype is meant to provide.

Overview: Microcopy is the small pieces of interface text — button labels, error messages, placeholder text, tooltips, confirmation dialogs — that quietly shape how confident and understood a user feels at every step. Empty states are a specific, high-leverage type of microcopy moment. The most important idea in this lesson is that words are a UI material exactly like color or spacing, and sloppy microcopy undermines even a well-structured, well-styled prototype. Principles of good microcopy: Effective microcopy is specific rather than generic ("Payment declined by your bank" beats "Something went wrong"), written in the user's own vocabulary rather than internal system language (avoid raw error codes or backend terms), and consistent in tone and terminology across the whole product (don't call the same thing "Delete" on one screen and "Remove" on another). Button labels should describe the action's actual outcome, not just a generic verb — "Send KSh 500" is clearer than a bare "Confirm." Writing for different states: Building on Lesson 2-6's feedback states, write actual final copy (not placeholder Lorem ipsum) for at least one loading message, one success confirmation, one specific error message, and one empty state per major screen in your prototype — this is where structural planning becomes a real, testable user experience, and where hidden ambiguity in a flow (what exactly should this message say?) tends to surface. Designing strong empty states: A strong empty state answers three questions in a short space: what belongs here, why it's currently empty, and what the user should do next (often a single clear call-to-action button). An illustration or icon can support the message but should never replace clear, specific text — a beautiful empty-state graphic with no explanation still leaves a first-time user confused about what to do. Microcopy and localization awareness: **For a Kenyan audience, be deliberate about currency formatting (KSh with comma separators, e.g.** KSh 12,500), phone number formats, and date conventions, and keep sentences short and direct rather than relying on idioms that may not translate cleanly if the product later supports Swahili or other local languages — clear, simple English microcopy now also makes future localization work significantly easier.

Overview: **Usability testing is how you find out whether your prototype actually works for real people, rather than just for you and your assumptions.** The most important idea in this lesson is that watching someone struggle silently through a task teaches you more than any amount of internal debate about whether a design "feels right." Planning a test: Write 3-5 realistic task scenarios phrased as goals, not instructions — "You want to send KSh 500 to a friend" rather than "Tap the Send button" — since instructing the exact steps defeats the purpose of testing whether the flow is discoverable on its own. Recruit 5 participants where possible; usability research popularized by Jakob Nielsen has long shown that around 5 users typically surface most of a design's major usability problems, with diminishing returns from testing many more at once, making it realistic for a student project with limited time. Moderated testing with a Figma prototype: Share your prototype's Present-mode link and ask the participant to think aloud — narrating what they're looking at, what they expect to happen, and what confuses them — while you observe without helping or hinting, even when you can see them heading toward a wrong path. Figma's own commenting and observation tools can capture notes directly on frames where issues occurred, which keeps findings tied precisely to the screen and element involved rather than a vague general impression. What to record: For each task, note whether it was completed, how long it took, how many wrong turns or hesitations occurred, and the participant's own words about confusion or frustration — direct quotes are often more persuasive to a reviewer than a designer's paraphrased summary of the same moment. Distinguish between a fatal error (task not completed) and a minor friction point (completed, but with visible hesitation), since they warrant very different levels of fix priority. From findings to fixes: **After testing, group findings by severity and frequency — an issue that stopped 4 of 5 participants outranks a minor visual quibble raised by one person.** Update the prototype based on the highest-priority findings and, where time allows, retest the changed flow, since usability testing is most valuable as a short, repeated loop rather than a single one-off event done right before a deadline.

Overview: This checkpoint tests whether your Figma file, components, and prototype come together as a genuinely clickable, testable product experience — not just a set of connected static screens. The most important idea here is that a strong prototype checkpoint should survive being handed to a stranger with zero explanation and still make sense. What a strong submission includes: A cleanly organized Figma file (Lesson 4-1) with named pages, sections, and frames; a component library (Lesson 4-2) built with real Variants and Auto Layout (Lesson 4-3); a fully wired prototype (Lesson 4-4) covering your complete Module 2 flow including at least one error path, using Smart Animate or overlays where they genuinely improve realism rather than just for decoration; final microcopy (Lesson 4-5) replacing all placeholder text; and a short usability test summary (Lesson 4-6) with at least 3 participants, their key findings, and what you changed in response. The cold-share test: Before submitting, send only the Present-mode link (no verbal walkthrough, no screen share narration) to someone unfamiliar with the project and watch whether they can complete your core task scenario unaided. Any point of confusion here is a real, fixable problem — and finding it now, inside a controlled checkpoint, is far cheaper than finding it after the project is considered "done." Demonstrating iteration, not just output: Reviewers at this stage specifically want to see evidence of change — what did usability testing reveal, and what did you actually do differently because of it? A prototype that looks identical before and after testing (or a testing summary that reports zero findings) usually signals the testing wasn't looked at critically enough, not that the design was already perfect. Setting up Module 5: Because Module 5 turns this whole project into a portfolio case study, keep clean before/after screenshots and a written note of every meaningful design decision and its reasoning now, while it's fresh — reconstructing your own reasoning weeks later from memory alone is far harder than capturing it in the moment.

Overview: The capstone brief is the foundation of your entire portfolio case study, so choosing well matters more than most students expect — a weak or vague brief produces a weak case study no matter how polished the final screens look. The most important idea in this lesson is that a strong capstone brief has a real, specific problem, a defined user, and enough constraint to force meaningful design decisions rather than open-ended exploration. What makes a brief strong: A strong brief names a specific product type and context (not "a social app," but "a savings-groups app for Kenyan chama members to track contributions"), has a believable user with real constraints (limited data, older Android devices, low tech confidence, or the opposite — power users who want speed and shortcuts), and has enough real-world complexity to require actual trade-offs, like balancing simplicity against a genuinely feature-rich task. Overly broad or overly simple briefs ("redesign Instagram" or "design a single settings screen") tend to produce shallow case studies because there isn't enough real problem-solving to narrate. Sources for a good brief: Strong capstone ideas often come from a real frustration you or someone you know has experienced with an existing product (a genuine "why is this so hard" moment), a local business or organization that would realistically benefit from better digital design (a matatu sacco, a small clinic's booking system, a school's fee payment flow), or a deliberate redesign of an existing product's specific weak flow, chosen because you can point to concrete evidence of the problem, not because it "needs a facelift." Scoping for the time available: Choose a brief scoped to roughly 5-8 core screens covering one complete, meaningful user flow end to end, rather than trying to design an entire multi-feature app shallowly. A smaller flow designed deeply — with real research, considered edge cases, and a tested prototype — makes a far stronger portfolio piece than a large app sketched thinly across many screens. Writing the brief document: Document your chosen brief in the same problem-statement format from Lesson 1-2, plus a one-paragraph scope statement naming exactly which flow and screens are in scope and, just as importantly, what's explicitly out of scope — this scope boundary is what will keep the project achievable and is itself a piece of professional judgment worth showing in the final case study.

Overview: A before-and-after comparison is one of the most persuasive things a portfolio can contain, because it makes your specific design decisions and their impact visible at a glance, rather than asking a reviewer to take your word for it. The most important idea in this lesson is that a convincing before-and-after needs a fair, honest "before" and a clearly explained reason for every visible change — not just a prettier version of the same screen. Choosing a fair baseline: If redesigning an existing product, screenshot the real current flow honestly, at the state it actually exists in, rather than cherry-picking its worst possible moment to make your redesign look better by comparison — a before-and-after that feels manipulated undermines credibility with anyone reviewing it, including a future employer. If your capstone brief was a new concept without an existing product to compare against, use your own early low-fidelity wireframes from Module 2 as the "before," showing your own evolution instead. Annotating what changed and why: For each significant change, write a short caption naming the specific problem it solved, tying back to real evidence where possible — "Reduced the signup form from 9 fields to 4, based on the drop-off pattern found in Lesson 1-4's journey map" is far stronger than "Made the form cleaner." Reviewers and interviewers respond to reasoning, not adjectives; avoid vague claims like "more modern" or "better UX" without a specific mechanism behind them. Measuring impact where possible: If you ran usability testing (Lesson 4-6) on both versions, or even just the redesigned version against your task scenarios, report concrete before/after numbers — task completion rate, time on task, number of errors — since specific data is more convincing than a subjective before/after visual comparison alone. If real numbers aren't available, be honest that the comparison is qualitative rather than inventing statistics to sound more rigorous. Layout for the comparison: Present before-and-after screens side by side at matching scale and cropping, ideally with matching viewport sizes, so the visual comparison itself is fair and the viewer's eye can move directly between equivalent points on each screen rather than needing to mentally resize or reorient between two differently-framed images.

Overview: Case study storytelling is the skill of turning a folder of screens and research documents into a narrative a stranger can follow and find compelling in a few minutes, which is exactly how most reviewers and hiring managers actually engage with a portfolio. The most important idea in this lesson is that a case study is a story about your thinking and decisions, not a gallery of final screens with captions. A reliable structure: A strong case study generally follows: Context (what is this product, who is it for, in one or two sentences), Problem (the specific problem statement from Lesson 1-2 or 5-1), Process (a condensed view of research, key decisions, and at least one meaningful pivot or rejected direction), Solution (the final screens, organized by flow, not dumped as a random grid), and Outcome/Reflection (what you learned, what you'd do differently, and any real results from testing). Skipping Process is the single most common weakness in student case studies — it reduces the whole project to "here are some screens," with no visible reasoning behind them. Showing process, including what didn't work: Include at least one rejected direction or early idea that changed significantly, along with why it changed — this is often the most credible and interesting part of a case study, because it demonstrates real iterative thinking rather than a suspiciously perfect first attempt. A case study that shows only the polished final result reads as less trustworthy to experienced reviewers than one that shows a believable, messier path to that result. Writing style: Write in plain, direct language and keep each section genuinely short — a busy reviewer skimming a portfolio will read the first paragraph of each section closely and skim the rest, so put the most important sentence first in every section rather than building up to a conclusion. Avoid unexplained jargon (referencing "Fitts's Law" or "Hick's Law" is fine, but briefly say what it means in context so a non-designer reader isn't lost). Visual pacing: Alternate text and visuals rather than long blocks of either — a paragraph of reasoning followed by the specific screen or diagram it refers to keeps a reader oriented and makes claims verifiable at a glance, which matters more for credibility than any single beautifully composed screen.

Overview: Exporting screens and assets correctly is what turns a Figma file into a portfolio people can actually view without opening Figma, or that a developer could realistically use for handoff. The most important idea in this lesson is that export settings should be chosen deliberately per use case, not left at whatever default Figma suggests. Export formats and when to use them: PNG is the default choice for portfolio screenshots and UI mockups because it's lossless and supports transparency, useful for isolated components on a transparent background. JPG suits photographic content where file size matters more than pixel-perfect edges, but should be avoided for UI screens with flat colors and text, since JPG compression introduces visible artifacts around sharp edges. SVG is the right format for icons, logos, and simple vector illustrations that need to stay crisp at any size, since it's resolution-independent rather than a fixed pixel grid. PDF suits printed or presentation-style deliverables, like a printable one-pager of your case study. Resolution and scale: In Figma's Export panel (bottom of the right-hand Design panel, when a frame or object is selected), set export scale multiples (1x, 2x, 3x) to control output resolution — 2x or 3x exports are standard for anything that might be viewed on a high-density (Retina-class) display, which includes essentially all portfolio website usage, so avoid exporting flat 1x screenshots that look soft on modern screens. Handoff-ready exports for developers: If your case study or checkpoint includes a developer handoff component, use Figma's Dev Mode to inspect exact spacing, color values, and generated CSS/code snippets per element, and export any needed assets (icons, images) at the resolutions and formats a developer actually requested, rather than guessing — asking "what formats and sizes do you need" is a real, professional habit worth demonstrating even in a student project. Organizing exported files: Name exported files clearly and consistently ("vd-capstone-onboarding-01.png," not "Untitled 4.png"), and keep them organized in folders matching your case study's flow structure — this file hygiene becomes directly visible the moment you start assembling the presentation deck in the next lesson.

Overview: A presentation deck is how your case study gets seen in real settings — a portfolio review, a job interview, a client pitch — and it has different constraints than a scrollable web case study, since it's often walked through live and needs to work as a spoken narrative, not just a read document. The most important idea in this lesson is that a deck should support you talking, not replace you talking — dense slides fight against a live presentation rather than helping it. Slide structure mirroring the case study: Follow the same Context, Problem, Process, Solution, Outcome structure from Lesson 5-3, but compress ruthlessly — a strong capstone deck is often 10-15 slides, with one clear idea per slide rather than paragraphs of text. A title slide, one problem slide, two or three process slides (including at least one showing a rejected direction), several solution slides organized by flow, and a closing outcome/reflection slide is a reasonable target structure. Designing slides using what you already know: Apply the same typography, spacing, and color principles from Module 3 directly to the deck itself — a consistent type scale, a clear visual hierarchy per slide, and generous white space make a deck easier to follow live than one crammed with small text and multiple competing ideas. Treat each slide as its own small piece of interface design, since the skills transfer directly. Showing screens at readable size: When placing UI screens on a slide, size them large enough to actually read on a shared screen or projector rather than shrinking several screens onto one slide — it's usually better to show one flow across two or three slides at real, legible size than to compress it into a single busy slide nobody in the back of a room can actually read. Practical tools and export: Figma Slides (Figma's own presentation tool) is well suited here since it can pull directly from your existing Figma screens and component library without re-exporting into a separate tool, keeping a consistent visual system between your product screens and the deck presenting them; alternatives like Google Slides or PowerPoint work too, as long as the same discipline around simplicity and legibility is maintained regardless of tool.

Overview: A portfolio review is a structured opportunity to get honest, critical feedback on your case study before it goes in front of real employers or clients, and how you prepare for and respond to that feedback is itself a professional skill being assessed. The most important idea in this lesson is that a portfolio review works best when you actively steer it toward the feedback you actually need, rather than passively waiting to hear whatever a reviewer happens to mention. Preparing specific questions: Walk into a review with 2-4 specific questions rather than a general "what do you think" — for example, "Does the Process section explain my reasoning clearly, or does it read as an afterthought?" or "If you only had 30 seconds, would you understand what problem this solves?" Specific questions produce specific, actionable answers; open-ended requests for feedback often produce vague, hard-to-act-on comments. Presenting vs. narrating: Practice walking through your case study in the time you'll realistically have (often just a few minutes), leading with the problem and your reasoning rather than diving straight into visuals — a reviewer who understands the problem in the first 30 seconds evaluates everything that follows more generously and accurately than one who's still trying to figure out what they're looking at. Receiving feedback without over-defending: When a reviewer raises a concern, resist the urge to immediately explain why it's not actually a problem — first make sure you've fully understood the concern, then decide afterward, with distance, whether it changes anything. Feedback that feels wrong in the moment is sometimes the most valuable, precisely because it reveals an assumption you didn't realize you were making. Acting on feedback: Not every piece of feedback should be applied — weigh each comment against your actual problem statement and user, and be ready to explain, in the final case study, both the feedback you incorporated and the feedback you consciously chose not to, along with why. This closing judgment call is itself a strong thing to include in the reflection section of your case study, since it shows a designer who can evaluate input critically rather than simply complying with the last thing anyone said.

Overview: This final checkpoint is the graduation deliverable — the complete case study, assembled from every module of the course, submitted as a professional artifact ready to show a real employer, client, or design community. The most important idea here is that this checkpoint is judged as a finished professional piece, not as a class assignment, so it should read as something you would genuinely be proud to link from a CV or LinkedIn profile. What a complete submission includes: A capstone brief and scope statement (Lesson 5-1), a fair and well-annotated before/after comparison (Lesson 5-2), a full case study following the Context/Problem/Process/Solution/Outcome structure (Lesson 5-3) with correctly exported, readable assets (Lesson 5-4), a presentation deck version of the same story (Lesson 5-5), and a short written reflection incorporating what you learned from your portfolio review (Lesson 5-6), including feedback you accepted and feedback you consciously declined. The full-course consistency check: Trace the thread from Module 1 through Module 5 explicitly in your reflection — does the final design actually solve the problem statement from Lesson 1-2, does it reflect the persona and journey map from Module 1, does the flow match your Module 2 structure (or explain deliberately where and why it diverged), and does the visual system stay consistent with Module 3's principles? A case study that can trace this thread end to end demonstrates a complete design process, not just a nice-looking final screen. Final presentation quality bar: Before submitting, check every exported image for resolution and cropping issues (Lesson 5-4), read the entire case study for typos and unclear sentences, and time yourself presenting the deck version to make sure it fits realistically within a short review window — small polish issues are exactly what separate a genuinely portfolio-ready piece from one that merely fulfills the assignment's requirements. What happens after graduation: This case study is meant to keep working for you after the course ends — update it as your skills grow, add real usability data if you later get access to it, and be ready to talk through every decision in it in an interview, since the process behind the work, more than the final screens themselves, is usually what a hiring conversation actually probes.