A Portfolio Isn't a Warehouse. It's an Evidence Chain.

I used to treat a portfolio like a warehouse. Project background, one page. User personas, one page. Journey map, one page. Three pages of wireframes, five pages of final designs, and at the very end, one big number that said "improved efficiency." Everything was there. It took me a while to realize what was actually happening: a recruiter flipping through a portfolio gives you something like thirty seconds. Most of those pages I'd stuffed in were mostly there to move me.

The real victim is the reader. He has to do the hardest part of the job for me — guess, from a stack of pretty screens, what I actually changed, and on what grounds it was me who changed it. The moment he can't tell, he's already on the next file.

So I set myself a fairly brutal rule, built specifically for cutting pages: if I remove this page, does the recruiter's read on my ability actually change? If it doesn't, no matter how nice it looks, it hasn't earned a place in the main story.

Those first thirty seconds, the recruiter is looking for a map

When a reader clicks into the Signals case, the first thing he has to figure out is not how refined your brand gradient is. It's five things: this is an R&D workflow; I'm the only product designer on this flow; the team also has one PM and ten engineers; the project ran about five months; the goal was to bring down the cost of tracing an experiment back to a material.

Once those five sentences are on the table, the complex interface screenshots that follow finally have a ruler to measure against. If roles and constraints aren't shown first, a dense system shot leaves the reader unable to tell — did the designer lead the build of this information architecture, or did he trace it, line by line, off a requirements doc? The one thing a portfolio should never make the reader do is guess.

A wall covered in sticky notes doesn't prove you can think

"Research — define — diverge — deliver" is the name of a process, not proof of ability. Throw up a photo of a wall plastered in sticky notes and the most it proves is that stickies were in the room that day. What the reader actually wants to dig out is this kind of thing: which finding overturned the original plan? Which constraint made the team grit its teeth and walk away from the flashier direction?

So a process page is best written in three beats: finding, decision, cost. For example: we found that what scientists lacked wasn't another filter — they couldn't even tell which experiment a recommended material had come from; so we promoted lineage from a side helper into a proper module on the object detail view; the cost was that detail-page density jumped all at once, and the hierarchy had to be rebuilt. Written this way, the process travels — it carries cleanly into the next project.

The bigger the number, the more you owe an explanation of what it measures

In the Signals task test, the time on a single tracing task dropped from about two hours to forty minutes — roughly 66% off. A number like that, sitting in a portfolio, genuinely stops people. It's also the easiest one to overuse.

I would never write it as "design improved R&D efficiency by 66%." What we measured was that one specific tracing task, not a scientist's whole workday; it came out of a usability test, not a long-term live business metric; and the product shipping at all owed as much to the PM's calls, engineering's execution, and the data team's pipeline. Laying those caveats out honestly doesn't cheapen the project. It shows exactly one thing: I know how far my evidence can actually walk.

A component family portrait — anyone can snap one

The UnifyUX case is way too easy to tell as a pile of colors, fonts, and buttons. The trouble is, any halfway-mature design system can put those on a table. What my case has to prove is this: why did the team actually need a shared language? Which misalignments were quietly manufacturing cost? And how did this set of rules genuinely work its way, step by step, into the collaboration between design and engineering?

If a case stops at "I built a design system," the reader sees only an artifact. If it can lay out the chain — from auditing several scattered products, through tokens, components, documentation, all the way to engineering adoption — this time the reader sees a systemic capability.

The ugliest image, put in, actually scores the most

In Finfold, the prettiest frame is the content workbench. But the one that proves product judgment is, oddly, the ugliest image — the failure state: one platform's generation has crashed, the rest are sitting there fine; the user can see exactly what broke, and can retry just that one. Putting that image in is the same as saying outright: I didn't treat AI as some all-powerful magic. I genuinely thought through what happens when it blows up.

The same logic runs across every product: if you build payments, you'd better show a decline and a refund; if you build permissions, show "here's the thing we won't let you do, and why"; if you build complex B2B, show empty states, conflicts, and undo. A portfolio that's nothing but sunny days leaves the recruiter with one quiet suspicion — this one's probably never weathered the bad weather that comes after a product ships.

That said, this isn't a license to turn the case into a collection of hell-joke error screenshots. Pick one example — the one that cracks the system's rules open the widest — and that's enough. Let the reader see with his own eyes: when the normal flow gets interrupted, was the data preserved, is accountability clear, and does the user still have a next step to take.

"Owned end-to-end, zero to one" — the loudest line, and the emptiest

"Owned the full 0-to-1 process" looks impressive written out, but it's usually the vaguest line of all. A project of any real scale can't have been you alone, grinding start to finish. A version that holds up under scrutiny goes like this: I was the sole product designer on this flow, working alongside one PM and ten engineers; I led task flows, information architecture, interaction, and usability validation; the technical approach, the data pipeline, the business calls — those were carried by the relevant partners.

What makes a senior designer valuable was never collapsing the whole team into a single "I." It shows up in whether you can define the problem cleanly, build a reliable basis for decisions, and get a roomful of different roles aligned behind one direction, into a consensus that can actually be executed. Stand those up, and the recruiter does the math on what you're worth himself.

When I actually start cutting, this is the order I go in

I cut the research ceremony first, then the duplicate finals, then the numbers I can't even explain to myself. After those rounds, I go back and check whether each project proves a different ability: Signals proves handling complex relationships and task efficiency, UnifyUX proves cross-product systems thinking, Finfold proves AI uncertainty and workflow. If all three get told as the same "found a pain point, made a new screen" template, no amount of volume moves you off the spot.

And there are things this little case-study board simply can't hold — those I hand off to the writing to unfold: one tradeoff, one failure, one method. Keep the case tight, let the writing spread out, and link the two. Read this way, what the reader runs into is no longer a static warehouse full of finished goods. It's how this person grew his judgment, step by step.