Portfolio Case Study — UX/UI Designer Capstone — SkilsMVP

What you'll produce

The single most important artifact in your job hunt: a portfolio-ready case study that weaves Deliverables 1–5 into one narrative — problem → research → process → solution → testing & outcome — for the FreshCart redesign. This is the piece you link from your resume and walk a hiring manager through line by line. It is not a gallery of pretty screens; it is the story of how you think, told in the language of the craft (Topic 10). Done well, it proves you can do the real job: turn a vague business problem ("58% of new shoppers abandon their first order") into evidence, structure that evidence into flows and screens, test your work instead of trusting your taste, and ship UI that is both polished and accessible. A reviewer should finish it able to say what the problem was, what you did, why you made each call, and what changed because of it.

Instructions

Open with a one-screen summary block (a hiring manager spends ~30 seconds before deciding to read on). Include: project title, your role, the timeframe, the tools, and a single outcome line with a number (e.g., "first-order completion rose from 40% to 60% (2/5 → 3/5) in the first prototype test"). Put this above the fold — never bury the result. Only claim what you measured: if a fix hasn't been re-tested yet, say so — the honest line ("3/5 placed the order; re-test of the fix pending") is more credible than an unverified "5/5."
State the problem and the brief in 3–5 sentences: the business pain (the 58% drop-off), the target user, and the explicit goal ("a first-timer places an order in under three minutes"). Frame it as a question you set out to answer, not a task you were handed.
Tell the research chapter (from Deliverable 1): your method, your primary persona in one tight profile, and 3–5 sharp insights — and explicitly label facts vs. assumptions. Quote one real user sentence if you have it; verbatim quotes are the most persuasive line in any case study.
Show the process — the messy middle (Deliverables 2–3): the IA decision and why, the user-flow before/after, and at least one option you explored and rejected, with the reason. When you cite a number, make it traceable: the happy-path screen count must match your Deliverable 2 flow map and the wireframe count must match Deliverable 3 — don't invent a tidy "before/after" the artifacts don't show. The honest structural wins (a forced step removed, two screens merged) are more convincing than a rounder number you can't point to. Reviewers hire the process; a case study with no discarded options reads as luck, not skill.
Present the solution (Deliverable 5): the key high-fidelity screens, and for each, name the design decision and the principle behind it (hierarchy, contrast, error recovery, familiar pattern). Caption every screen — an uncaptioned screen says nothing about your thinking.
Prove it with testing (Deliverable 4): the task you gave ~5 users, 2–3 specific things you observed (hesitations, wrong turns), the severity-ranked issues against heuristics, and the prioritized fixes you made. Show a before → after for at least one fix. "I tested this and here's what I changed" is the most credible sentence a designer can write.
Close with outcome, reflection, and next steps: the measured result, one honest thing you'd do differently, and what you'd test next. Reflection signals seniority; pretending it was flawless signals the opposite.
Make it scannable and on-brand: clear section headers, generous whitespace, consistent type scale, captions on every image. Remember Topic 10 — a designer's case study is itself a design sample. Sloppy layout is disqualifying.
Write a 60–90-second verbal version as a closing note for yourself: the same arc, spoken, for the portfolio walkthrough interview. The artifact and the story must match.

Worked example

(The complete FreshCart case study, condensed to its load-bearing sentences. In your real submission each chapter becomes a section with the actual screens embedded.)

FreshCart — Redesigning the first-order experience Role: Sole UX/UI Designer (research → tested high-fidelity UI) · Timeframe: 3 weeks · Tools: Figma, Maze, FigJam Outcome: In moderated testing with 5 first-time shoppers, the redesigned guest-first flow raised first-order completion from 2/5 (40%) on the old app to 3/5 (60%) — and the redesign removed the forced account-creation wall entirely (guest-first), the single screen that had blocked 41% of the drop-off, and merged the old two separate "address" then "delivery-slot" screens into one. But the first test still surfaced a checkout-summary blocker, so only 1/5 beat the 3-minute goal. I shipped the prioritized fix (an order-summary screen); the re-test that should push completion to 5/5 is scheduled, not yet run. (Honest, measured numbers beat a polished claim I can't back up.)

The problem. FreshCart, a 4-year-old grocery-delivery startup, was losing first-time shoppers: analytics showed 58% of new users abandoned their very first order between browsing and checkout, and App Store reviews repeatedly called the app "confusing" and the checkout "a maze." I was hired as their first dedicated designer to answer one question: why do first-timers drop off, and how do we get them to a placed order in under three minutes?

Research (what I learned). I combined the quantitative drop-off funnel with 5 moderated interviews of people who had recently abandoned a first grocery order, asking about real past behavior ("walk me through the last time you tried to order groceries on your phone"), never pitching. The interviews converged on one primary persona — Maya Cohen, 31 — "the time-boxed first-timer" (carried straight from Deliverable 1): she just moved to a new city for a job, has no time to shop in person, and is trying FreshCart for the first time during a 15-minute break — one-handed on her phone, no learned shortcuts, no patience for setup. She wants one order placed before her break ends, then she'll decide if FreshCart is worth keeping. Five insights, facts vs. assumptions labeled:

(Fact, analytics) 41% of the 58% drop-off happens on the account-creation screen — before users ever reach payment.
(Fact, interview) 4 of 5 users hit a forced "Create an account" wall and 2 quit there; one said, "I just wanted to see if you delivered to me — why do you need my password first?"
(Fact, interview) Users couldn't tell which items were already in the cart; 3 re-added the same item, confused by no running total.
(Assumption, to validate) Promo-code field at checkout makes people leave to hunt for a code and not return.
(Fact, reviews + interview) The 6-step checkout had no progress indicator, so users never knew how close they were to done — the "maze" feeling.

Process (the messy middle). The research pointed at structure, not paint, so I started with IA and flows (not screens). I relabeled navigation in the user's words ("Shop," "Cart," "Checkout" — not internal terms) and collapsed the old 7-item menu into a 4-tab bar (Shop · Cart · Orders · Account), with checkout pulled out of the tabs and into a focused in-flow sequence so a first-timer can't wander off mid-purchase. Most importantly, I moved account creation to after the order is placed (guest-first checkout), since the data and the quotes both blamed the upfront wall. Two structural changes did the real work on the flow: the forced account wall came out entirely (a whole blocking screen removed, not relabeled), and the old two separate "enter address" then "pick a slot" screens merged into one "Delivery" screen. The redesigned happy path to a placed order is 6 screens — Shop → Product detail → Cart → Delivery → Payment → Review — and I added a visible Cart · Delivery · Payment · Review progress indicator across checkout so users always know how far they are from done (the old 6-step checkout had none — that absence was the "maze"). I marked the two old sticking points right on the flow map: the account wall and the invisible cart. Option I explored and rejected: a single-screen "everything on one page" checkout. I sketched it, but it crammed address, payment, and review into one scroll with no progress sense — re-creating the overwhelm reviews complained about — so I kept a short, signposted multi-step checkout with the progress indicator instead. I wireframed every screen in the redesigned flow (9 frames, including the search-results, account-gate, and confirmation states) in grey boxes first (to argue about structure, not color), then linked them into a clickable Figma prototype a person could tap through to place a test order.

Solution (key screens, and the decisions behind them).

Cart screen — a persistent running total and an item-count badge fix the "did I add this?" confusion (heuristic: visibility of system status; principle: hierarchy puts the total and primary "Checkout" button highest-contrast on the screen).
Delivery screen (address + slot, merged) — guest-first: no account required; the old two-screen "enter address, then pick a slot" sequence is now one screen, with the Cart · Delivery · Payment · Review step indicator at the top so users always know how close they are to done (heuristic: visibility of status; familiar pattern from every checkout they already know).
Confirmation — order summary plus a single, optional "Save your details for next time?" prompt — account creation, now offered after the win, not as a gate. All screens were built from a small reusable component kit — color/type tokens, one button component, inputs, and a cart card — with AA-contrast text and one accent color reserved only for the primary action, so the next step is never ambiguous.

Testing & iteration. I gave 5 first-time shoppers a three-part task — add items for a simple dinner, set a delivery slot, then place the order — think-aloud, no rescuing. The honest result: they could add items (5/5) and reach checkout (5/5), but only 3/5 actually placed the order, and just 1/5 came in under the 3-minute goal. The redesign moved the drop-off rather than erasing it — it now concentrated at the delivery-slot step and the final confirm. Issues, ranked by severity against heuristics:

(Severity 4 — catastrophic) No order summary before "Place order." One tester abandoned outright; two others scrolled back to hunt for a total, because the button jumped straight to confirmation with no visible price, item list, or address to check. Heuristic: visibility of system status + error prevention. Verbatim: "Wait — how much is this? I'm not hitting that without seeing the total."
(Severity 3 — major) Delivery-slot chips read as decorative, not selectable: 4/5 stalled because the flat grey chips had no selected-state, so users couldn't tell they had to pick one or which they'd picked. Heuristic: visibility of system status + consistency.
(Severity 3 — major) Search hidden behind an unlabeled magnifying-glass icon: one low-confidence tester spent 1:42 browsing categories, never realizing she could search. Heuristic: recognition over recall.

Prioritized fixes I made (and what I'd re-test). I inserted an Order Summary screen — itemized list, subtotal, delivery fee, total, address and time, all above the button — to kill the catastrophic blocker; restyled the slots as clear buttons with a filled selected-state and a "Selected: Today 6–7pm" line; and replaced the bare icon with a pinned "Search products" bar. The order-summary screen is the clearest before → after in the case study: cart → blank confirm became cart → a full summary you can verify before paying. I'm deliberately explicit that I have not yet re-run the test — the fixes are shipped to the prototype, but the number that turns "3/5 placed, 1/5 under goal" into the targeted "5/5, ≥4/5 under goal" is a goal for the next round, not a result I can claim today.

Outcome & reflection. The redesign moved the structural levers the research pointed at: guest-first checkout (forced account wall removed), the two-screen address+slot step merged into one, and a visible progress indicator across a 6-screen happy path — with completion up from 2/5 to 3/5 in the first test and the re-test of the summary fix still pending. What I'd do differently: I tested with 5 users on a prototype — solid for a portfolio, but I'd want a larger quantitative A/B on the live funnel to confirm the account-wall removal holds at scale, and I'd test the empty-cart and out-of-stock states I didn't cover. I'd also have caught the missing order-summary screen before the first session if I'd dry-run the golden path against my own flow map one more time. Next: run the scheduled re-test, then validate the promo-code assumption with real codes in a live test.

(Verbal walkthrough version, ~75 sec, for the interview: "FreshCart was losing 58% of first-time shoppers before checkout. Research — five interviews plus the funnel — showed the killer was a forced account-creation wall and an invisible cart, not the visuals. So I restructured first: guest-first checkout that removes the account wall completely, the two old address-and-slot screens merged into one, and a visible progress bar across a clean six-screen path. I prototyped all nine screens, tested with five users, and completion went from two-in-five to three-in-five — but the test caught a missing order-summary screen, so I shipped that fix and the re-test to confirm five-in-five is scheduled, not done. The honest headline is a real structural win plus an in-flight metric, not a finished number I can't back. What I'd do next is run that re-test, then confirm it with a live A/B test.")

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.

Narrative arc (problem → research → process → solution → testing → outcome) — 1: a screen gallery or missing chapters · 2: all chapters present and in order · 3: a tight, compelling story where each chapter clearly sets up the next.
Problem & outcome framing — 1: vague ("made it better"), no numbers, or a metric the work doesn't support · 2: clear problem and a stated result · 3: sharp problem tied to the brief, with an above-the-fold outcome line and a real, measured metric (e.g., 2/5 → 3/5 completion with a re-test pending, or a named structural win like "forced account wall removed") — no inflated or untested number.
Shows the thinking, not just the result — 1: only final screens · 2: explains key decisions · 3: shows the messy middle — IA/flow reasoning, at least one explored-and-rejected option with its reason, and facts-vs-assumptions discipline carried in from research.
Decisions tied to principles & heuristics — 1: "it looks nicer" · 2: decisions named · 3: each major decision named and justified by a craft principle (hierarchy, contrast/accessibility, visibility of status, error recovery, familiar pattern).
Evidence of testing-driven iteration — 1: no testing or "users loved it" · 2: a test with observations · 3: specific observed behaviors, severity-ranked issues, prioritized fixes, and a concrete before → after.
Coherence across Deliverables 1–5 — 1: disconnected artifacts, or numbers that contradict the source work (e.g., a "4-screen final flow" that appears in no flow map or wireframe set) · 2: linked, with screen/step counts that match the deliverables · 3: one visible thread — a research insight shapes the IA, the screens, what's tested, and the final UI — and every count in the case study traces to the actual artifact (the happy-path screen count to the Deliverable 2 flow map, the wireframe count to Deliverable 3), so a reviewer can check the math.
Presentation & craft (the case study is itself a design sample) — 1: sloppy, unscannable, uncaptioned · 2: clean, captioned, readable · 3: scannable, on-brand, consistent type/spacing, every screen captioned with its decision — portfolio-ready and interview-walkable.