# Case Study: [Project name]

> Portfolio case study template for designers, product managers,
> researchers and engineers. Based on common UX and product portfolio
> practice: context, your role, the problem, constraints, process,
> solution, measurable outcomes and learnings, told as a story a hiring
> manager can follow in five minutes. Replace every `[bracketed]` value
> and every line marked *Example*.

<!--
Guidance: How to use this template
- Reviewers spend two to five minutes per case study. Lead with a
  one-screen summary (section 1) so they get the point even if they stop
  there.
- Make your own contribution unmistakable. Use "I" for what you did and
  "we" for team work, and say which is which.
- Show decisions and trade-offs, not only final screens. The process is
  what hiring managers evaluate.
- Respect confidentiality: anonymise the client, blur sensitive data and
  get permission before publishing work done for an employer.
-->

| Field | Value |
|---|---|
| Project | [Project name] |
| Client / company | [Company or "Fintech start-up (anonymised)"] |
| My role | [Lead product designer] |
| Timeline | [Mon YYYY to Mon YYYY, N weeks] |
| Platform | [iOS, Android, web] |
| Status | [Shipped / Pilot / Concept] |
| Reading time | [5 minutes] |

## 1. Project overview

<!-- Guidance: The "TL;DR" in four parts: context, problem, what you did, result. Add one hero image. If the reader stops here, they should still remember the outcome. -->

[Two or three sentences: who the product serves, what was wrong, what
you changed and what improved.]

*Example:* Ledgerly is a bookkeeping app for 40,000 freelancers. New
users abandoned onboarding because connecting a bank took 11 steps. I
led the redesign of the bank-connection flow, which raised onboarding
completion from 38% to 61% in eight weeks.

![Hero image: final design of [screen or flow] on [device]](images/[project]-hero.png)

## 2. Role and team

<!-- Guidance: Your title, responsibilities and the people you worked with. Be precise about ownership: what you led, what you contributed to, what others did. -->

| Item | Details |
|---|---|
| My role | [Title and what I owned] |
| Team | [1 PM, 4 engineers, 1 researcher, 1 data analyst] |
| Stakeholders | [Head of Growth, Compliance, Customer Support] |
| My responsibilities | [Research plan, journey mapping, interaction design, prototype testing, design QA] |
| Tools | [Figma, Maze, Amplitude, Jira] |

## 3. The problem

<!-- Guidance: State the user problem and the business problem with evidence (data, quotes, support tickets). Write a single problem statement or "How might we" question that the rest of the case study answers. -->

**User problem:** [What users struggled with, with evidence.]

**Business problem:** [Why the company cared, with a metric.]

**Problem statement:** How might we [help whom] [do what] so that
[outcome]?

*Example:* Funnel data showed 62% of sign-ups never connected a bank.
In 14 support tickets per week users said they "did not trust" the
screen asking for their banking password. How might we help freelancers
connect their bank quickly and confidently, so they reach their first
categorised transaction on day one?

## 4. Constraints

<!-- Guidance: Constraints make your decisions understandable. Time, budget, technology, regulation, legacy systems, brand, accessibility. -->

| Constraint | Impact on the work |
|---|---|
| [Constraint] | [How it shaped decisions] |
| *Example:* Bank aggregator SDK screens could not be restyled | Focused design on the steps before and after the SDK |
| *Example:* PSD2 strong customer authentication | Could not remove the bank's own login step |
| *Example:* Eight-week deadline before the tax season | Prioritised changes engineers could ship in two sprints |
| *Example:* WCAG 2.2 AA requirement | Contrast, focus order and screen-reader labels checked in every iteration |

## 5. Process

<!-- Guidance: Show how you got from problem to solution in three stages. For each, say what you did, what you learned, and what decision it led to. Include artefacts (journey maps, sketches, prototypes) with captions. Skip what did not matter; a process diagram for its own sake adds nothing. -->

The work followed three overlapping stages:

```mermaid
flowchart LR
  R["Research"] --> I["Ideation"] --> T["Iterations and testing"] --> S["Ship and measure"]
  T -->|"Findings"| I
```

### 5.1 Research

[Methods, number of participants, key insights.]

*Example:* I ran 8 remote interviews with freelancers who abandoned
onboarding and analysed 3 months of funnel data with our analyst.
Three insights stood out: users did not know why we needed bank access
(5 of 8), the bank list search failed for regional banks (4 of 8), and
users who skipped the step never came back (91% churn in 30 days).

![Journey map of the original onboarding flow](images/[project]-journey.png)

### 5.2 Ideation

[Options explored, how you chose between them.]

*Example:* We generated 14 ideas in a cross-functional workshop and
scored them on impact and effort. Three directions went forward: an
explainer screen before the SDK, a smarter bank search, and a
"connect later" path with a manual import.

### 5.3 Iterations and testing

[Prototype rounds, what changed each round and why.]

| Round | What we tested | Participants | Finding | Change made |
|---|---|---|---|---|
| [1] | [Prototype] | [N] | [Finding] | [Change] |
| *Example:* 1 | Low-fidelity explainer screen | 6 | Users skimmed long copy | Cut copy to 3 bullets with icons |
| *Example:* 2 | Bank search with aliases | 10 (unmoderated) | 9 of 10 found their bank in < 10 s | Kept; added logos |
| *Example:* 3 | "Connect later" with CSV import | 8 | Users chose it only when bank was missing | Moved to secondary link |

## 6. Solution

<!-- Guidance: Present the final design with annotated visuals. For each key screen or feature, explain the decision and the reason. Link to a prototype or live product if allowed. -->

[Describe the final solution and the two to four decisions that made
the difference.]

1. *Example:* **Trust screen before connection.** Three short reasons,
   the security standard used, and "We never see your password".
2. **[Decision]**: [What and why.]
3. **[Decision]**: [What and why.]

![Before and after comparison of the bank connection flow](images/[project]-before-after.png)

Prototype or live link: [URL]

## 7. Outcomes

<!-- Guidance: Measured results, with baseline, result, time window and how they were measured. Credit the team. If the project did not ship or has no data yet, say so and use qualitative evidence (usability scores, stakeholder decisions). -->

| Metric | Before | After | Window | Source |
|---|---|---|---|---|
| [Metric] | [Value] | [Value] | [Period] | [Analytics tool / study] |
| *Example:* Onboarding completion | 38% | 61% | 8 weeks after launch | Amplitude funnel |
| *Example:* Steps to connect a bank | 11 | 6 | At launch | Flow audit |
| *Example:* Support tickets about bank trust | 14 per week | 3 per week | Month after launch | Zendesk tags |
| *Example:* Task success (usability test) | 55% | 90% | Round 3 | Moderated test, n = 8 |

[One sentence on business impact, for example revenue or retention.]

## 8. Learnings

<!-- Guidance: Honest reflection is a strong signal. What worked, what you would do differently, and what you learned about the users, the team or yourself. -->

- **What worked:** [Insight.]
- **What I would do differently:** [Insight.]
- **What I learned:** [Insight.]
- *Example:* I would involve compliance in the first workshop; their
  late review cost us a sprint.

## 9. Visuals checklist

<!-- Guidance: Use this list to prepare images before publishing, then delete it. -->

Prepare these visuals, each with a caption that says what the reader
should notice:

- [ ] Hero image of the final design (section 1).
- [ ] Research artefact: journey map, affinity diagram or data chart.
- [ ] Sketches or low-fidelity wireframes showing exploration.
- [ ] Iteration comparison: before and after a test finding.
- [ ] Final annotated screens or a short video of the flow.
- [ ] Outcome chart with the baseline marked.
- [ ] Alt text written for every image.
- [ ] Sensitive data blurred and permission to publish confirmed.

## Standard and licence note

Based on common UX, product design and product management portfolio
practice. Original text written for this collection; example product,
names and metrics are fictional. Template licence: MIT.