High-Fidelity UI & Mini Design System

What you'll produce

The polished, on-brand high-fidelity UI for FreshCart's key checkout screens — built not as one-off pixel art, but from a mini design system: a small kit of reusable tokens (color, type, spacing), components (buttons, inputs, cards), and the rules for using them. You'll define the kit in Figma, then assemble the redesigned browse → cart → checkout screens from it, with accessibility-grade contrast and a deliberate visual hierarchy that points a first-timer straight at the next action. This is the artifact that turns "I have a wireframe" into "I can ship product." It proves the Topic 8–9 skills hiring managers screen hardest for: thinking in reusable components, defending color/type/spacing choices, and producing UI that is consistent, accessible, and fast to change — the difference between a junior who decorates screens and one who builds systems.

Instructions

1. Lock your tokens before you touch a screen. Define them as named Figma styles/variables so every component references the token, not a raw value. Minimum set:
   • Color: 1 brand primary, 1 accent for the single most important action, a 4–5 step neutral grey ramp, plus semantic success / error / warning. Name them by role (color/action-primary), not by hue (green-500).
   • Type: one or two readable families and a scale of 5–6 sizes with named roles (Display / H1 / H2 / Body / Caption) and line-heights. Restraint beats variety.
   • Spacing: an 8px-based scale (4, 8, 12, 16, 24, 32, 48). Pick from the scale; never type arbitrary numbers like 13 or 27.
2. Check contrast on every text/background and text/button pair. Use a WCAG checker. Body and UI text must hit 4.5:1; large text (≥24px or 19px bold) must hit 3:1. Record the ratio next to each pairing. If a token fails, fix the token, not the instance.
3. Build the components as true Figma components (the master + instances, so one edit propagates). For each, define its variants and states — a button isn't done until it has Default / Hover / Pressed / Disabled / Loading. Build at minimum: Button (primary, secondary, ghost), Text Input (default / focus / error-with-message), and Card (product card, order-summary card).
4. Assemble the hero screens from components only. Take 3–4 critical screens from your tested flow (e.g., Cart, Delivery & Address, Payment, Order Confirmation) and lay them up in hi-fi using instances of your components — no detached, hand-styled elements. If a screen needs something the kit lacks, add it to the kit first.
5. Direct the eye with hierarchy on each screen. Apply the squint test: the single most important action (the primary CTA) should be the loudest thing on the screen via size, your accent color, and isolation/spacing. Demote everything secondary. One primary CTA per screen.
6. Bake in the usability fixes from Deliverable 4. Each issue you found in testing should be visibly resolved in the hi-fi — and call it out. Use the heuristics as your checklist: visible system status (a progress indicator, a loading button state), error prevention/recovery (inline input validation with plain-language messages), recognition over recall (saved address shown, not re-typed).
7. Write the one-page "how to use this kit" guidelines — the rules a teammate needs: when to use primary vs. secondary buttons, the contrast floor, the spacing scale, and the type roles. A kit without rules isn't a system.
8. Annotate for handoff. On at least one screen, label the tokens/components in use (e.g., "Button/Primary", "color/action-primary on color/surface", spacing values) so an engineer — and an interviewer — can see the system underneath the screen.

Rubric

The app's AI scores the learner's submission against these criteria and gives feedback. Levels: Needs work (1) / Solid (2) / Excellent (3). Passing = every criterion at Solid or above.

• Token system (color / type / spacing) — 1: raw values scattered on screens, no named styles · 2: a defined, role-named token set with a restrained palette, type scale, and spacing scale · 3: tokens are systematic, semantically named, and demonstrably reused (changing one token would update the UI everywhere).
• Reusable components with states — 1: hand-styled, detached elements · 2: true components (button, input, card) used as instances across screens · 3: components include the real-world variants and states (hover/pressed/disabled/loading, focus/error) and screens are assembled only from instances.
• Accessibility-grade contrast — 1: contrast not checked; failing greys present · 2: key text/background pairs meet WCAG 4.5:1 (3:1 large) and ratios are recorded · 3: every pairing verified, failures fixed at the token, and the contrast rule is written into the guidelines.
• Visual hierarchy & on-brand polish — 1: everything competes; no clear focal point · 2: one clear primary CTA per screen, consistent spacing/alignment, coherent brand feel · 3: passes the squint test on every screen — the eye lands on the right action first, secondary actions are deliberately demoted, and the result looks shippable.
• Usability fixes carried through — 1: hi-fi ignores Deliverable 4 findings · 2: the main tested issues are visibly resolved in the screens · 3: each fix is resolved and annotated, mapped to a heuristic (system status, error recovery, recognition over recall).
• System thinking & coherence — 1: pretty screens with no underlying kit or guidelines, or details that contradict earlier deliverables (e.g., currency/price/product that no longer matches D1/D3) · 2: a kit plus usage guidelines, traceable to the prior deliverables' flow, with prices, currency, and product consistent across every screen · 3: a genuine mini design system — annotated for handoff — that an engineer or teammate could pick up and build new screens from consistently, and the hero screens visibly continue the same FreshCart basket the learner priced earlier (one currency, numbers that reconcile end to end).