Topic 10 — Portfolio and landing the job

Goal: Build a portfolio and present yourself to land an entry-level design role.

Lesson 10.1 — The thing they actually look at

Tessa is rebuilding her LinkedIn after eight years of styling retail floors, and she spends a whole Sunday agonizing over the wording of her old job titles. The next morning she shows it to Marcus, her mentor at Wanderwell, expecting feedback on the bullet points. He reads it for four seconds, then asks: "Where's the link to your work?"

That question is the entire chapter.

In design hiring, the portfolio matters more than your resume or your degree. A resume tells someone where you've been. A portfolio shows them how you think and what you can make, which is the only thing a team is actually buying. Marcus has reviewed hundreds of applications; he can tell you he's never once hired someone because of their school, and never once not hired someone strong because they lacked one.

Here's the part that should change how you sit in your chair: a portfolio can be built entirely from self-directed projects, using the exact skills this course gave you. No prior design job required — only the work itself, done well and explained clearly.

A degree says you sat in a room. A portfolio says you can do the job. Hiring managers only pay for the second one.

So Tessa stops fussing over her job titles and opens a blank Figma file. The resume can wait. The work can't.

Lesson 10.2 — A case study is a story, not a screenshot

A portfolio is a small set — two to four projects — and each one is a case study. When Tessa first heard that word, she pictured a glossy gallery of final screens, the prettiest version of each app she'd designed. So her first draft was exactly that: six clean mockups, no words, lots of white space. She was proud of it.

Marcus scrolled through it in silence, then said the line she'd remember for the rest of her career.

"These are beautiful. But I have no idea how you got here, and that's the only part I'm hiring for."

A case study is the story of your thinking, not the highlight reel of your output. Anyone can drop a screenshot into Dribbble and make it shimmer. What a reviewer can't get anywhere else is the reasoning: why you chose this layout over the three you rejected, what a user struggled with, what you'd fix next time. Reviewers want process because process is what they're hiring. The final screen is just the receipt.

This is why two to four projects is plenty. One project, explained well with the decisions visible, beats ten shiny screens that show no reasoning. Depth signals a designer; volume signals a stock-photo site.

Tessa goes back into her file and starts writing next to each screen. Not captions. The story.

Lesson 10.3 — The five beats of a case study

So what does the story actually contain? Hannah, Wanderwell's researcher, frames it as five beats, in order, and Tessa pins them above her desk:

1. The problem — what were you solving, and for whom? Name the user and the pain in one or two sentences. "Travelers planning a group trip lose track of who agreed to what." That's a problem. "I redesigned a travel app" is not.
2. Research and insights — what you learned before you designed anything. Even a few user interviews or a competitor teardown counts. The insight is the gold: the surprising thing you didn't expect.
3. Your process — flows, wireframes, and the options you explored. Show the messy middle. Three sketched directions, the one you killed and why, the wireframe before the visual polish. This beat is where reviewers lean in, because this is where your judgment lives.
4. The solution — the polished final design. This is the part you were tempted to lead with. It lands far harder after the reasoning, because now the reviewer understands every choice.
5. Testing and outcome — what you tested, what you learned, and what you'd improve. "I tested the booking flow with five people; three missed the date picker, so I'd make it larger." Honesty about a flaw reads as maturity, not weakness.

When Dev, the frontend engineer, reviews her draft, he stops at beat three. "This is the part I'd want to talk to you about in an interview," he says. "The final screen tells me nothing. The two layouts you rejected tell me you can think." The messy middle is the asset most beginners delete. Keep it.

Lesson 10.4 — Pick projects that prove you think

Tessa's stuck on what to actually make. She has no client, no real app, no team handing her a brief. Two paths solve that, and both produce genuine, reviewable work.

The first: redesign an app you find frustrating. Tessa books a lot of trains, and the regional rail app makes her want to throw her phone. That frustration is a real problem with real users. The trap here is the word "prettier" — a redesign that's only a nicer color palette proves nothing. Hers has to explain why the new version is better, grounded in the principles she learned: this screen cuts the steps to buy a ticket from seven to three; this layout fixes a contrast level that failed accessibility. Better, with a reason behind it, beats newer paint.

The second: design a small app for a real need. Priya, the PM Tessa partners with, points out that the best beginner projects are narrow. Not "a social network." A tool to split a group vacation's costs. Small scope, fully thought through, beats grand scope half-built.

Either way, the principle Marcus keeps repeating holds: one thoughtful, well-explained project beats ten shiny screens with no reasoning. Tessa picks the rail-app redesign and one small group-budget tool. Two case studies, both with the five beats. That's a portfolio.

Lesson 10.5 — The resume, the interview, and the edge nobody else has

The resume still matters, and it carries a hidden test. A designer's resume is itself a design sample. Misaligned columns, three clashing fonts, a wall of gray text: that alone gets Tessa cut, because if she can't lay out her own one page, why trust her with a product? So she keeps it clean, lists her real skills — Figma, prototyping, user research, visual design — and, above all, links to the portfolio at the top. The portfolio is the destination; the resume is the road sign.

Then come the interviews. For designers, they almost always include three things:

• A portfolio walkthrough. You present one case study and explain your decisions out loud: problem → process → solution → what you learned. This is the single most important interview, and the one beginners under-prepare. Tessa rehearses hers until she can tell the rail-app story in five minutes without notes, the way she once walked buyers through a styled room.
• A design exercise or whiteboard challenge. "Design an app for booking dog-walkers." They are watching your process, not waiting for a flawless result. So you clarify the problem ("who's the user — the owner or the walker?"), consider users, sketch a few options, name the trade-offs, and think out loud. Silence reads as a blank mind. A narrated rough sketch reads as a designer.
• Behavioral questions about teamwork and critique. Design is a team sport, and the deal-breaker is someone who can't take feedback. When they ask about a time your work got torn apart, the right answer shows you listened, iterated, and improved.

And here is Tessa's edge — the one a fresh design grad can't fake. Eight years reading what made a shopper linger or leave is empathy, the core skill of UX. A teacher, a nurse, a customer-service rep — every people-facing past is a source of user understanding. Frame your old career as exactly that; don't hide it.

Then treat the hunt itself like a design project: ship the portfolio, get feedback, iterate, apply again. The field is competitive, and entry-level US salaries typically run roughly $56k–$82k (higher in metros like New York). A process-driven portfolio plus stubborn persistence is what breaks people in.

Worked example — Tessa's rail-app case study, start to offer

Tessa picks the regional rail app she hates. Watch the five beats become a case study, and the case study become a job.

Problem: "Commuters buying a one-off ticket have to tap through seven screens, and the fare options are buried." One sentence, a named user, a real pain.

Research: She interviews four friends who use the app. Three screenshot the same moment of confusion — the fare-zone screen. That becomes her north star.

Process: She sketches three flows. The first hides fares behind a menu; she kills it and says why. The other two she wireframes. She keeps all of it, including the killed direction, because that rejected sketch is proof of judgment.

Solution: The polished redesign cuts the purchase to three screens and surfaces fares up front. It lands hard because the reviewer just watched her reasoning.

Testing and outcome: She tests with five people; four buy a ticket with no hesitation, one fumbles the date picker. She writes that down honestly and notes the fix.

Now the interview. Wanderwell brings her in. She walks Marcus through the rail-app story in five minutes — problem, killed flow, redesign, the date-picker she'd still improve. In the whiteboard round they ask her to design a trip-packing checklist; she clarifies the user first, sketches two options aloud, names the trade-off, and never goes silent. Asked about critique in the behavioral round, she tells how Marcus once called her first portfolio a beautiful mystery, and how she rebuilt it.

She gets the offer: an entry-level product designer at $74,000. No design degree. Two self-directed case studies and a story she could tell. That is the whole job of this topic.