Set 02 · Portfolio · UI/UX
UI/UX portfolio, process shown.
Hiring managers screening product designers read for one thing: whether you made decisions or made screens. A grid of polished mockups cannot tell them apart, which is why beautiful portfolios get rejected every day. Three complete case studies written slide by slide — a checkout redesign, a design system, and a feature that shipped and failed.
SamplesThree, complete
FormatCase study — slide by slide
ReadingFree, no signup
LengthSeven sections per case
Sample OneSeven sections · Measured outcome
The classic product case study. Note that the screens appear sixth, after five sections of reasoning — that ordering is the entire point.
Zain Abbas
Product designer · Lahore
1 — The frameFour facts
Checkout redesign · Daraz-scale marketplace, 2025
My role: sole designer, with one PM and three engineers
Duration: 11 weeks, design to release
Outcome: mobile checkout completion 61% → 74%
Role, team size, duration and result in four lines. A reviewer decides whether to keep reading here, and "sole designer" versus "one of six" changes how they read everything after it.
2 — The problemWith a number
Thirty-nine percent of mobile users who reached checkout did not complete. Analytics showed the largest single drop at the address step, not at payment, which was where everyone assumed the problem was.
The business goal was revenue. The user problem turned out to be a form that asked for a province before it asked for a city, on a keyboard that covered the field.
A business number and a user problem in the same block, and a correction of a shared assumption. That correction is the strongest sentence available in a product case study.
3 — What I did to find outMethod and sample
Session recordings — 60 abandoned mobile checkouts watched end to end
Five moderated tests with real customers on their own phones
Support ticket review — 400 tickets tagged checkout over three months
The recordings were the useful one. Users repeatedly tapped the province dropdown, saw the keyboard cover the field, and scrolled away.
Name the methods and the sample sizes, then say which one actually produced the insight. Listing four methods and implying all were decisive is a tell.
4 — The decisionAnd what was rejected
Three routes considered:
One — reorder and simplify the address form, guest checkout by default. Chosen.
Two — one-page checkout. Rejected: payment provider required a redirect we could not remove in this quarter.
Three — saved-address account push. Rejected: it fixes the returning user, and the drop was concentrated in first-time buyers.
The rejected options with their reasons. This is the section that separates designers who make decisions from designers who receive them.
5 — The constraint I designed around
The payment redirect could not be removed. It added a full page load and a visual break in the middle of the flow.
Rather than hide it, the step before it was rewritten to say what was about to happen and why, with the order total repeated after the return. Ticket volume mentioning "did it go through" fell noticeably afterwards.
Every real project has a constraint that could not be designed away. Showing what you did inside it is more useful than any greenfield concept.
6 — The screensFour, captioned
Before and after, side by side — the address step
The reordered form with the city field first and the keyboard state shown
The pre-redirect explanation screen
The confirmation with the total repeated
Each caption states the decision, not the feature: "city before province, because the keyboard covers the second field".
Four screens. Not thirty. Each one exists to prove a decision described earlier.
7 — What happened, and what I got wrong
Mobile checkout completion 61% → 74% over six weeks post-release, held at 72% at twelve weeks.
Support tickets tagged checkout down roughly a third.
What I got wrong: guest checkout by default reduced account creation by 19%, which the growth team had not been consulted about. We added a post-purchase account prompt in the following release, which recovered most of it. I should have found that stakeholder in week one.
A real number that held at twelve weeks, and a real cost. Reporting the six-week spike and stopping is what everyone does; reporting the twelve-week figure is what makes it believable.
Why this one works
- The screens come sixth. Five sections of reasoning first. A reviewer skimming for decision-making finds it immediately.
- It corrects a shared assumption. Everyone thought payment; it was the address form. That is the moment the case study becomes worth reading.
- Rejected options are shown with reasons. Two routes, two constraints. This is the clearest available evidence of judgement.
- The outcome is held at twelve weeks. Anyone can produce a six-week spike. Reporting the settled number is the honest version.
- It names a cost he caused. Account creation down 19%, and the stakeholder he missed. Nothing else in a portfolio reads as senior the way this does.
Sample TwoSeven sections · No user-facing metric
Systems work is the hardest thing to put in a portfolio because there is no screen to show and no conversion number to quote. The outcomes are internal, and they are still measurable.
Zain Abbas
Product designer · Lahore
1 — The frame
Design system for a B2B logistics platform, 2024
My role: design lead, with one other designer and two engineers part-time
Duration: two quarters, ongoing after
Outcome: new screen design time down from ~3 days to ~4 hours
The outcome is a team-efficiency number. For systems work that is the correct metric, and it is one a hiring manager immediately understands.
2 — The problemCounted, not asserted
I audited the product before proposing anything: 14 button variants, 9 shades of grey, 4 date pickers behaving differently, and 3 competing table components.
Two designers were producing screens that did not match, engineers were rebuilding components that already existed, and QA was filing visual bugs faster than they were being closed.
The audit numbers are the whole opening. "The UI was inconsistent" is an opinion; fourteen button variants is a finding, and it is what got the work approved.
3 — What I did first
Screenshotted every screen in the product — 71 of them — and printed them on a wall.
Grouped by component rather than by page. The wall is what convinced leadership; the spreadsheet version of the same information had been ignored twice.
How you got buy-in is part of the case study. Systems work fails politically far more often than it fails technically.
4 — The decisionAnd the deliberate limits
Built the twelve most-used components first, not a complete library. Buttons, inputs, select, date picker, table, modal, toast, tabs, card, nav, empty state, form layout.
Deliberately not built: charts, the map view, anything used on fewer than three screens.
One set of tokens for colour, spacing and type, named by purpose (surface, danger, muted) rather than by value (grey-200).
What you chose not to do, and why. A designer who scopes a system down to twelve components has shipped one before.
5 — AdoptionThe part that usually fails
A library nobody uses is a failed project, so adoption was designed as part of the work.
Migrated three high-traffic screens myself so the first examples existed.
Paired with each engineer once, for an hour, rather than writing documentation nobody reads.
Added a component checklist to the design review template.
Held a fortnightly 30-minute clinic for six months.
This section is what distinguishes someone who built a Figma library from someone who changed how a team works.
6 — The artefactsThree, captioned
The audit wall — 71 screens, grouped by component
The token sheet — colour, spacing, type, named by purpose
One component page — the table, with all states and the usage rules
Not the whole library. Three artefacts that show how it was thought about.
One well-documented component page proves more than forty component thumbnails.
7 — What happened, and what I would change
New screen design time down from about three days to about four hours.
Visual bug tickets down 60% over two quarters.
Component library used in 90% of new screens twelve months on, measured by the engineering lead.
What I would change: I built the date picker three times because I did not talk to the two teams using it differently until the second rebuild. Component work should start with a conversation about every existing use, not with the design.
Three internal metrics, one named source, one specific process failure. A complete case with no user-facing number in it.
Why this one works
- The audit is counted. Fourteen buttons, nine greys, seventy-one screens. Numbers turn an opinion into a business case.
- Adoption is treated as design work. Migrating three screens himself, pairing instead of documenting. This is the section most systems case studies are missing entirely.
- The scope has explicit limits. Twelve components, and a list of what was deliberately excluded. Restraint reads as experience.
- The metrics are internal and sourced. Design time, bug volume, adoption measured by the engineering lead. Correct for the work, and verifiable.
- How buy-in was won is in the deck. The printed wall after the spreadsheet failed twice. Hiring managers for senior roles are reading for exactly this.
Sample ThreeSeven sections · Negative outcome
The case study that gets people hired, and the one almost nobody includes. A designer who can dissect their own failed feature is demonstrating the single most valuable habit in product work.
Zain Abbas
Product designer · Lahore
1 — The frame
In-app savings goals feature · Fintech app, 2023
My role: sole designer, with a PM and four engineers
Duration: 9 weeks
Outcome: 4% adoption at 60 days. Feature removed in 2024.
The failure is on the first slide. Putting it there is what makes the reader trust everything else in the deck.
2 — What we believedThe bet, written down
Users told us in research that they wanted to save but found it hard to start. We believed a goal-setting feature — name a goal, set an amount, set a date, auto-transfer weekly — would convert that stated intent into behaviour.
We expected 20% of monthly actives to create a goal within 60 days.
The hypothesis and the target, stated as they were before launch. Without the pre-registered number, any post-hoc explanation sounds like excuse-making.
3 — What we builtTwo screens
A four-step goal creation flow and a progress card on the home screen.
Shipped to 100% of users after a two-week 10% rollout that showed no problems, mostly because the sample was too small to show anything.
Short. In a failure case study the build is the least interesting section and should be treated that way.
4 — What actually happenedThe numbers
4.1% of monthly actives created a goal in 60 days, against a 20% expectation.
62% of those who started the flow abandoned it at step two — the amount field.
Of goals created, 71% had no transfer after the first one.
The feature was removed in a cleanup release eleven months later.
Full numbers, including the removal. Half-reporting a failure is worse than not including it.
5 — Why, as far as we could tellThree findings
Follow-up interviews with 12 users, 8 of whom had abandoned at step two.
The amount field required a number people had not decided. "Save for a wedding" was real; "save PKR 8,000 per week" required a calculation they could not do standing in a queue.
The weekly auto-transfer needed a commitment users would not make to an app they had used for four months.
And stated intent was not intent. They wanted to have saved. That is not the same as wanting to save.
Three findings, in increasing order of how uncomfortable they are. The last one invalidates the original research method, and saying so is the point of the case.
6 — What I would do differentlyMethod, not feeling
Test the commitment, not the interface. A fake-door test — a goals button that led to a waitlist — would have shown 4% interest in three days rather than nine weeks.
Never size a feature on stated intent alone. Ask what they did last month, not what they intend to do next month.
Roll out at 10% until the metric is readable, not until the bug reports stop.
Three transferable rules. This is the section a hiring manager reads twice, because it is what he would bring to their team on day one.
7 — What came out of it
The round-up feature that replaced it — spare change from card transactions swept to savings, no goal, no commitment, no amount to decide — reached 23% adoption in its first quarter.
It exists because the first attempt failed clearly enough to explain why.
The failure produced the success. Ending here turns the whole case study from a confession into a demonstration of how product work actually progresses.
Why this one works
- The failure is on slide one. Four percent adoption, feature removed. Hiding it until the end would read as a reveal; stating it first reads as confidence.
- The pre-launch target is quoted. Twenty percent expected, four percent achieved. Without the expectation, the result has no meaning.
- The hardest finding is included. Stated intent was not intent — which invalidates the research that justified the project, including his own.
- The lessons are methods. Fake-door test, ask about last month, roll out until the metric is readable. Rules a team inherits by hiring him.
- It ends with what the failure produced. A 23% feature that only exists because this one failed legibly.
Why process, not screens
A hiring manager reviewing product design portfolios is answering one question: did this person make the decisions, or execute someone else's? Screens cannot answer it. A junior designer handed a spec and a senior designer who reframed the problem produce visually identical artefacts, and only one of them is being hired.
Everything that distinguishes them lives in the words — what the problem turned out to be, what was tried and rejected, what constraint could not be moved, what the number did afterwards. That is why these case studies front-load reasoning and put the screens sixth.
The practical test: cover every image in your portfolio and read what is left. If the remaining text still shows a person making judgement calls, the portfolio works. If it reads as a caption list, it does not, and no amount of visual polish will fix that.
NDAs, team work and credit
Two problems come up in almost every product portfolio, and both have standard, honest answers.
The first is confidentiality. Most product work is under NDA and most of it can still be discussed if you generalise properly.
- Anonymise the company, not the problem. "A logistics platform, roughly 2,000 business customers" tells a reader everything they need.
- Convert absolute numbers to relative ones. "Completion up 13 points" instead of the raw revenue figure.
- Redraw or blur the screens rather than omitting them, keeping the structure and losing the branding and real data.
- Never show anything unreleased, and say so in the deck — "current work is under NDA and can be discussed in interview" is a completely normal line.
The second is credit. Product design is a team sport and overstating your role is the most common way a strong portfolio collapses in the interview, because the reviewer asks one level deeper and the answer is not there.
State your role in the first section of every case: sole designer, design lead, one of three. Then use "I" for what you did and "we" for what the team did, consistently. A case study that says "I designed and the team built" where the truth is "I contributed to a shared design" is a problem you will meet in the room, not on paper.
Three cases. Not eight. Reviewers spend a few minutes on a portfolio in a first screen, and three well-written cases are read while eight are skimmed.
- Pick for range, not for beauty. One measured product outcome, one systems or craft case, one difficult or failed project. That combination covers everything a hiring manager is checking for.
- Web or PDF, both work. If the portfolio is a site, make sure it can be read without an account and does not require a password to be typed by a reviewer on a phone. If it is a PDF, keep it under 15 MB.
- Password-protected case studies are a real cost. Every barrier loses some readers. If you must protect one, leave two open.
- Write a one-paragraph summary at the top of each case containing role, duration and outcome, so a reader in a hurry gets the whole thing in twenty seconds.
- Include the process artefacts as they were. The messy whiteboard, the printed wall, the annotated recording notes. Re-drawing them neatly afterwards removes the evidence that they were real.
And keep one case study permanently up to date. Portfolios rot quietly — the last update is usually two jobs ago, and the gap is the first thing a reviewer notices when the dates do not reach the present.
Cover the screens and read what is left.
All three case studies are free to read and copy. Want them as an editable deck, or your own projects written into this structure? Both take a minute.
Build mine with Hexa →
Download all three · Free
The people above are illustrative examples written for teaching purposes.
Names, employers, registration numbers and figures are invented and should not be copied
into a real application — use them as a shape to pour your own verified numbers into.