Junior Designer Portfolio: Turn One Project Into a Case Study
Pearl Kim, 25, sat down at her laptop and opened her portfolio page.
She was lining up companies to apply to as a junior service designer. Her first move: put her capstone project on the front page.
She stared at the screen and stopped. Five carefully crafted final screens, and a single line of description.
"A matching app for incoming freshmen and student orgs."
She'd spent a full year on user interviews, wireframes, and usability testing — but only the final screens made it onto the portfolio.
The screens would earn her compliments on visual polish. But what she'd actually thought about for that year, and what decisions she'd made, weren't on the page at all.
Plenty of junior designers hit this same wall. The good news: the missing information is actually quite specific.
Let's walk through what to add and how to add it, alongside Pearl.
The trap of portfolios that only show results
The most common junior designer portfolio looks like this:
Project — Student Org Matching App
Role — UX/UI Design, User Research
Duration — 1 year (4-person capstone)
Tools — Figma, Notion
Screens — Home, Match, Org Detail, Application Flow (5 screenshots)
Now imagine a design lead or recruiter reading this. What goes through their head?
"Looks polished."
That's where it ends.
Nothing reveals what user insights came up, why this layout was chosen, or what was tried and discarded.
The look of the screen is there, but the thinking behind the screen isn't.
The real value of a designer's portfolio isn't "how does it look." It's "why this design?"
Screens alone only show "they can make things." But what hiring teams really want to see in a designer is: does this person decide based on users?
That's where the case study format comes in. A case study has three beats:
Problem — Process — Result
Fill in those three, and a person starts to emerge from the portfolio.
Let's walk through each beat using Pearl's student org matching app.
Problem: Whose pain were you trying to solve?
This is the part most often skipped — the "who was hurting, and why" question.
Pearl's first draft read:
[Before]
Designed a matching app so incoming freshmen could easily find student orgs that fit them.
What can a hiring team actually pull out of this? Two things: the target is freshmen, and it's a matching app.
Nothing about what user pain she actually found. It sounds like the project started from a generic premise — "finding clubs is hard."
So we asked Pearl: "Why a matching app? Were freshmen short on information about orgs?"
Her answer:
"That's what I thought at first. I started assuming it was an information problem. But after interviewing eight freshmen, I realized that wasn't the real pain at all.
The university's student org page already had everything. The number of orgs wasn't overwhelming either. What was actually stopping people was something else: they couldn't tell what each org was really like. Every description used the same kind of language — 'community and growth,' 'a welcoming space' — and you couldn't tell which ones were actually active or what the vibe felt like."
That interview insight needs to go straight into the portfolio.
[After]
The university already had a student org directory, and the amount of information wasn't the issue. But after interviewing 8 freshmen, the real reason for hesitation turned out not to be missing information — it was "I can't tell what the actual vibe is." Every org wrote in the same generic tone, leaving freshmen without any signal for whether it was a fit. Solving that pain became the core goal of my capstone.
The After version is longer, but the information density is much higher.
Whose pain, what the actual pain was, and why that's the real pain — all of it is there.
Three questions to cover in the problem section:
User — Who is this project for?
Pain — What's their actual pain? (Confirmed through research, not assumed.)
Existing limits — Why doesn't the current solution address it?
In designer case studies especially, the second one — the real pain you discovered through research — is decisive.
When your initial assumption about the pain differs from what research reveals, the gap itself becomes a signal of how you think.
Process: Why this design decision?
This is the heart of a case study.
It's the easiest section to skip and the most valuable one to include.
Most junior designer portfolios stop at "what I designed":
[Before]
Designed a matching system based on a recommendation algorithm. Users answer 10 questions and get personalized org recommendations.
This tells the reader, "OK, they designed a feature." But that's not what design leads actually want to know.
What they want is: "What user insight led to that decision?"
The biggest design decision in Pearl's matching app was: recommendation-first, or browse-first?
The initial concept was recommendation-first — a 10-question quiz that produced a personalized list of orgs.
But two insights came out of the user interviews:
"Another quiz?" — Freshmen were already fatigued by personality tests, BuzzFeed quizzes, and recommendation-driven feeds.
"Why is it only showing me these?" — They didn't trust the recommendation logic; if anything, a strong recommendation made them suspicious.
Pearl took those insights and shifted the concept.
[After]
The initial concept was a recommendation-first match: 10 questions in, a personalized list out. Two insights from user interviews changed that.
First, freshmen were already burned out on quizzes and recommendation feeds. "Another quiz?" came up in 5 of 8 interviews.
Second, they didn't trust the recommendation itself. "Why is it only showing me these?" — that kind of suspicion eroded the sense of autonomy. The stronger the recommendation, the lower the likelihood they'd actually join.
So I shifted the concept to a light filter (3 optional questions, skippable) + a browse-first list + a "current member quote" card on each org card. Freshmen still pick for themselves, but each org card surfaces the one thing they were actually missing — what the vibe is really like. Autonomy stays intact, and the genuine information gap gets filled.
Look at what's actually present in that paragraph:
Started from a hypothesis → This person works from hypotheses.
Validated the hypothesis with users → This person tests their thinking against real users.
Shifted direction based on what they found → This person acts on insights, not around them.
Acknowledged tradeoffs in the decision → This person designs in context.
The same "I designed a matching app" outcome lands completely differently depending on how it's written up.
Three things to cover in the process section:
Initial hypothesis — What did you start by believing?
Insight and pivot — What did you find in users, and how did you respond?
Tradeoffs — What did you gain, and what did you give up?
The "insight and pivot" piece is especially powerful for junior designer portfolios.
Juniors tend to hide the messy parts of their process to look like they "got it right from the start." But hiring teams actually look at that pivot point to see how a candidate thinks.
"I started with a recommendation-first concept, realized through interviews that the pain was different, and switched to a browse-first model" reads as far more three-dimensional than "I designed a browse-first model from the start."
Result: What changed, and how?
The final beat is result. Many candidates stop at "I finished it," but result has to go further.
[Before]
Completed the prototype and presented at the capstone showcase.
Almost no information. You only learn that they got to the finish line.
Good result writing has two layers:
Quantitative — what's measurable
N participants in usability testing
Number of clicks to selection (existing site N clicks → prototype N clicks)
Bounce rate, completion rate
Qualitative — what numbers can't capture
Quotes from testers ("I picked it because of the member quote")
Capstone showcase feedback or industry mentor reviews
Faculty commentary
Applied to Pearl's capstone:
[After]
In usability testing with 12 freshmen, the number of clicks to selecting one org dropped from an average of 11 (on the existing university site) to 4 in the prototype. 9 out of 12 testers indicated they'd actually want to join.
The most common phrase in post-test interviews was "I decided based on the member quote card." That felt like a direct signal that the pain we identified in early interviews — "I can't tell what the actual vibe is" — was being addressed.
At the capstone showcase, the most frequent question from faculty and industry mentors was about the pivot from recommendation-first to browse-first — and that pivot became the project's central differentiator.
Both layers are present.
And "user pain" runs as a consistent thread from start to finish. The result answers exactly the question the problem section opened with.
A tip for when your result feels thin:
Junior designer projects often have small testing pools or end within a single semester. When that's the case, be honest about it — but always pair it with "here's where I got to, and here's what I know would come next."
User testing stopped at 12 freshmen from our department. The next step would have been running the prototype during the actual student org recruitment period at the start of fall semester, and measuring real join-through rates.
That one sentence shifts the read from "their research was thin" to "they know where they are and where they're headed."
What design leads actually read in a case study
Let's flip the perspective one more time.
When a design lead or recruiter reads a junior designer's case study, the questions running through their mind sound like this:
Does this person decide based on users? → revealed in the problem section
Are their design decisions backed by reasoning? → revealed in the process section
How do they handle the messy middle? → revealed in the pivot
Can they verify outcomes? → revealed in qualitative + quantitative test results
Do they have an honest read on where they stand? → revealed in limits and next steps
When all five answers show up in a single case study, even a junior leaves the impression: this person knows how to work.
That impression doesn't require a brand name on the resume or full-time experience to back it up.
When the process of thinking is more visible than the polish of the screens, your portfolio finally becomes a place where how you worked is on display.
To close, here's what changed between Pearl's one-line draft and the case study version.
[Before]
Capstone: Student Org Matching App Role: UX/UI Design, User Research Duration: 1 year, 4-person team Tools: Figma, Notion
[After — case study structure]
Project: Student Org Matching App (4-person capstone, 1 year)
Problem — 8 freshman interviews showed that hesitation around joining wasn't an information gap; students simply couldn't tell what each org was actually like.
Process — Initial concept was a 10-question recommendation-first match. Interviews surfaced quiz fatigue and distrust of recommendation logic. Pivoted to a light filter (skippable) + a browse-first list + "current member quote" cards.
Result — 12-person usability test. Clicks to selection dropped from 11 to 4. 9/12 indicated intent to join. Dominant feedback: "I decided based on the member quote card."
Role — Lead Designer (research + main flow) Tools — Figma, Notion Links — Prototype · Full case study
Same project — but the four-line version and the full case study deliver completely different messages to a design lead.
The first version says "they know the tools." The second says "they decide based on users."
A case study sized for one portfolio page is usually about this length.
Too long, and the hiring team won't read it all. Too short, and the person disappears. When all three beats are present on one page, one project shows enough.
This article covered turning one project into one case study from a designer's perspective.
If you want the developer version, see Part 1 of this series. The PM version is coming soon in Part 3.
How to select multiple projects and arrange them on a single page will be the next topic in this series.