Practical Projects & Portfolio

Project 1 · Improve credit-card application completion

Problem brief

A card issuer's digital application converts only 42% of starts to submissions and 19% to activated cards. Leadership asks you to raise submissions by 5 points in two quarters without increasing fraud or credit risk.

Learning objectives

Funnel and segment analysis · onboarding UX for regulated products · prioritisation with risk partners · experiment design · stakeholder communication with risk/compliance.

Stakeholders

Head of Acquisition (sponsor) · Risk/Credit policy · Compliance/Legal · Fraud operations · KYC vendor manager · Engineering (mobile, web) · Design · Customer support · Marketing.

Research approach

1. Quantitative: funnel by step × device (dataset); time-on-step; error logs at document upload.
2. Qualitative: 8 interviews with recent abandoners (consented), 5 usability sessions on mobile web.
3. Secondary: support tickets tagged “application”; vendor SDK error reports.

Analysis of the dataset (model solution)

Insight: if mobile web reached Android's upload pass rate (66%), submissions there would rise from ~4,422 to ~5,600 (≈ +1,200/month, ≈ +2.4 points overall), holding later steps constant — half the goal from one fix.

Templates to use

PRD (Templates library) · Experiment plan · Stakeholder map · Launch checklist · Decision log.

Step-by-step implementation

1. Frame: problem statement and goal with guardrails (fraud, early-delinquency indicators, complaints).
2. Diagnose: funnel by device; upload error codes; 5 usability sessions → findings (low light, file size limits, no camera guidance, timeouts).
3. Ideate & prioritise: camera guidance/auto-capture, file-size compression, save-and-resume, status tracker, pre-fill (with consent), soft-eligibility messaging (compliance check). Score with weighted criteria incl. risk and compliance effort.
4. PRD: for “Camera guidance + save-and-resume (mobile web)”.
5. Experiment: A/B on mobile web; primary = submit/start; secondary = upload pass rate; guardrails = fraud flags, manual-review backlog, complaints.
6. Launch plan: staged rollout, support macros, compliance sign-off.
7. Readout & next steps.

Model PRD excerpt

Problem: mobile-web applicants fail at document upload (52% pass vs 80% iOS). Goal: upload pass ≥ 66% and submit/start ≥ 35% on mobile web within 8 weeks. Requirements: live camera guidance (edge detection, glare warning); automatic compression to vendor limits; retry without losing data; save-and-resume link (consented, expires in 7 days, no PII in URL); accessible alternatives (upload from gallery). Out of scope: changing KYC policy. Risks: fraud via altered images → vendor liveness checks unchanged; data retention → follow policy.

Experiment plan (model)

• Hypothesis: guidance + compression raises upload pass from 52% to ≥ 62%.
• Unit: applicant session (new applications only). Split 50/50.
• Sample: baseline 52%, MDE +6 pts → ≈ 1,075 per arm at α 0.05, power 80% (computed with Module 7 formula) — ~1 week of mobile-web traffic; run 2 full weeks.
• Guardrails: fraud flag rate, manual-review queue time, complaints.

Deliverables

Funnel analysis (chart + table) · research synthesis (affinity map) · prioritised opportunity list · PRD · experiment plan · stakeholder map · launch checklist · 8-slide readout.

Review criteria

Correct funnel maths and segmentation · evidence-based problem choice · risk/compliance considered explicitly · testable requirements · powered experiment with guardrails · clear recommendation and trade-offs · honest labelling of synthetic data.

Portfolio presentation guidance

Title: “Finding a 2-point lift in one step: mobile-web document upload.” Show: the device funnel chart, three user quotes (from your own interviews if you run them), the redesign concept, the experiment plan, and what you'd do next (status tracker → activation). State clearly that data is synthetic.

Project 2 · Improve food-delivery checkout conversion

Problem brief

A food-delivery app wants to raise checkout conversion this quarter. You have event data, an order table, a backlog with rough estimates and budget for one experiment.

Learning objectives

SQL funnels · customer research · RICE with sensitivity · experiment analysis · readout writing.

Stakeholders

Growth lead · Checkout engineering · Design · Payments · Analytics · Support · Finance (fees).

Research approach

SQL funnel (Module 7 queries) → 6 interviews with recent abandoners → review mining → usability test of fee display.

Step-by-step with model solution

1. Funnel (dataset): app_open 792 → view_menu 716 (90.4%) → add_to_cart 423 (59.1%) → checkout_start 322 (76.1%) → payment_success 284 (88.2%). Biggest relative loss: menu → cart; but checkout → payment is closest to revenue and cheaper to fix.
2. Research synthesis (hypothetical): fee surprise (6 of 8), payment failure dead ends (4 of 8), slow menus (3 of 8).
3. RICE (rice_backlog.csv): fee early 32,000; order-again 28,000; payment retry 14,400; saved addresses 12,500; dark mode 8,000; voice 600. Sensitivity: fee early drops to 20,000 at 50% confidence.
4. Choose: run the A/B test on early fee display; schedule payment retry next.
5. Analyse (ab_test_checkout.csv): 70.0% vs 72.5% → +2.5 pts, z = 3.91, p ≈ 0.00009, 95% CI [+1.25, +3.75]; complaints 1.18% vs 1.21%.
6. Readout & decision: ship with 5% holdout; monitor fee-estimate accuracy.

KPI tree (model)

Deliverables

SQL notebook or queries with outputs · research synthesis · RICE table with sensitivity · experiment readout (template) · roadmap (Now/Next/Later).

Review criteria

Correct SQL and definitions · RICE assumptions documented · sensitivity check · correct statistics with CI · guardrails · clear recommendation.

Portfolio guidance

Show one chart per step (funnel, RICE, result), the decision, and what you'd test next. Keep the story to 6–8 slides.

Project 3 · Improve a collaboration platform's channel-creation UX

Problem brief

Teams create duplicate channels and can't find existing ones; leaders want healthier, more discoverable channel structures.

Learning objectives

Heuristic evaluation · usability testing · task metrics and SUS · redesign with wireframes · B2B experiment design (workspace-level randomisation).

Stakeholders

Product lead for collaboration · Design · Engineering · Admin/IT customer advisory board · Customer success · Analytics.

Research approach

Heuristic evaluation (3 evaluators) → moderated usability test (8 participants, 3 tasks) → analytics (duplicate-channel rate, channel-message share).

Baseline usability results (model solution from dataset)

Step-by-step implementation

1. Heuristic evaluation of current flow (visibility, recognition vs recall, error prevention).
2. Usability test (scripts in Module 5); synthesise findings by severity.
3. Redesign: similar-channel suggestions at creation; naming templates; purpose pre-fill; improved directory search (see wireframe in Case 7).
4. Prototype in Figma; re-test with 6–8 new participants; target ≥ 7/8 on “find existing channel”.
5. Define metrics and A/B at workspace level.

Model findings and redesign rationale

• Find existing channel fails because search ranks by recency, not relevance (heuristic 6: recognition rather than recall) → show similar channels at creation and improve search ranking.
• Set purpose errors: field hidden after creation → prompt purpose in the creation dialog with a template.
• SUS 62.8 → target ≥ 70 after redesign.

Experiment plan

Unit: workspace (to avoid contamination within teams). Primary: duplicate-channel rate. Secondary: channel-message share, search success. Guardrails: channel creation time, admin complaints. Duration: 4 weeks.

Deliverables

Heuristic report · usability findings with clips/quotes · redesigned wireframes/prototype · metric definitions · experiment plan · stakeholder update.

Review criteria

Severity-ranked findings tied to evidence · design addresses root causes · accessible design · B2B-appropriate experiment unit · clear success metrics.

Portfolio guidance

Before/after screens, task-success chart before vs after re-test, three key insights, and the experiment plan. If you completed similar Slack channel-UX work in your own projects folder, link it here as the hands-on artefact.

Project 4 · Design an AI-powered support assistant

Problem brief

A fictional card issuer wants an in-app assistant that answers common questions from approved policies, routes sensitive cases to humans, and never leaks data or gives unsuitable advice.

Learning objectives

AI problem framing · RAG design · evaluation sets and severity · guardrails and HITL · AI PRD · launch gates.

Stakeholders

Head of Customer Service · Compliance · Information Security · Data Protection Officer · Disputes and Hardship teams · Engineering/ML · Design · Support agents.

Research approach

Ticket-reason analysis; listen to 20 support calls; agent interviews (what's repetitive, what's risky); policy-owner interviews (freshness, conflicts).

Step-by-step implementation

1. Intent inventory with risk tiers: answer (card block guidance, fees, statements, rewards), route (disputes, fraud, hardship), refuse (investment advice, other customers' data).
2. Knowledge base: the six snippets in kb_policy_snippets.csv with effective dates and owners.
3. RAG design: chunk = one policy section; metadata = doc_id, effective_date, product; retrieval top-3 with permission filter; citations required; “not found → offer agent”.
4. Prompt (system) draft with refusal and routing rules; delimit retrieved text as data.
5. Evaluation: run the 60 questions; score correctness, citation, routing, refusal; tag severity.
6. HITL: agent handoff with conversation summary; confidence and risk-based routing.
7. AI PRD (Templates library) incl. intended/prohibited uses, eval gates, fallback, latency and cost targets.
8. Pilot plan and launch gates.

Model AI PRD excerpt

Intended use: answer informational questions about card features and policies for authenticated customers. Prohibited: investment/credit advice; account actions; discussing other customers. Sources: POL-001…POL-006 (owner: Policy team; review monthly). Behaviour: cite doc_id; if POL-003 (disputes) or POL-005 (hardship) applies → route to human with summary. Eval gate: ≥ 90% correct with citation on answerable; 100% correct routing on dispute/fraud/hardship test cases; 0 data-leak or injection successes. Latency: p95 < 4 s. Cost: < $0.02 per answer (hypothetical budget). Fallback: “I'm not sure — let me connect you with an agent.” Rollback: kill switch; revert to FAQ links.

Model evaluation scoring sheet

Example hypothetical result (as in Module 10): 52/60 overall; one critical injection failure in a test environment → blocker; three missed hardship/dispute escalations → add intent examples and re-test.

KPIs and launch gates

Self-service resolution · CSAT · time to answer · correct routing of high-risk intents (≥ 98%) · unsuitable-advice incidents (0) · privacy incidents (0) · cost per resolved contact.

Deliverables

Intent/risk matrix · RAG architecture diagram · system prompt draft · eval sheet and results · AI PRD · pilot plan with gates · risk register.

Review criteria

Risk tiers sensible · permissions enforced outside the model · eval covers adversarial and sensitive cases · severity-weighted decision · realistic HITL and rollback.

Portfolio guidance

Present it as a responsible-AI design case: the risk matrix, architecture, eval results table, and a clear launch-gate decision. Don't claim real-world performance; label results as evaluation on synthetic cases.

Project 5 · Launch a subscription SaaS product

Problem brief

You are PM for RetroLoop, a tool that helps small product teams run retrospectives and track action items. Define the strategy, MVP, pricing, launch and retention plan for the first two quarters.

Learning objectives

Segmentation and positioning · MVP scoping · pricing analysis · GTM and launch checklist · activation and retention metrics · roadmap.

Stakeholders

Founder/CEO · Engineering · Design · Marketing · Customer success · Finance.

Step-by-step implementation with model solution

1 · Strategy and positioning. Beachhead: product/engineering teams of 5–20 in software companies already running sprints. Positioning: For agile teams who forget retro action items, RetroLoop turns retros into tracked commitments in 15 minutes. Unlike whiteboards and docs, it reminds owners and reports follow-through.

2 · MVP scope (MoSCoW). Must: run a retro (templates), vote, create action items with owners, reminders, Jira/Slack link-out. Should: follow-through report. Could: AI theme summary. Won't (now): enterprise SSO, custom workflows.

3 · Pricing analysis (dataset).

Model recommendation: choose $9/seat (B) — highest MRR after churn, more customers than C (better for learning and referrals), and C's advantage is within noise. Re-test annual plans and a 3-seat minimum later.

4 · GTM. Channels: content (retro templates), integrations marketplace listings, agile community partnerships, product-led free plan (1 team, 3 retros/month). Launch tier 1 with webinar and Product Hunt-style launch; support docs; onboarding emails.

5 · Activation & retention metrics. Activation = team completes first retro and at least one action item is marked done within 14 days. North Star = action items completed per active team per month. Guardrails: retro satisfaction score, churn reasons.

6 · Roadmap (Now/Next/Later). Now: MVP + pricing + onboarding. Next: follow-through report, Jira two-way sync. Later: AI theme summaries (with eval), enterprise features.

7 · Launch checklist (Templates library) and retrospective after 4 weeks.

Deliverables

Positioning statement · Lean Canvas · MVP scope (MoSCoW) · pricing analysis · GTM plan · launch checklist · metric tree and dashboard spec · 2-quarter roadmap.

Review criteria

Clear beachhead and positioning · MVP tied to riskiest assumptions · correct pricing maths with churn · GTM with owners and metrics · activation defined behaviourally · roadmap with outcomes.

Portfolio guidance

A 10-slide strategy deck: problem → segment → positioning → MVP → pricing evidence → GTM → metrics → roadmap → risks → asks. Label all data as synthetic and explain what you'd validate first with real customers.