Portfolio & Case Studies (UI/UX Design Tutorial)

By the end of this lesson you will be able to choose projects for a portfolio, write a clear case study that shows how you think, and present your work honestly in an interview.

A design portfolio is not a gallery of pretty screens. Reviewers want to know how you solve problems: how you learned about users, what you tried, what failed, what you changed and why. A case study tells that story. Two or three strong case studies usually do more for you than twenty unexplained screenshots.

What reviewers look for

When someone reviews a junior designer's portfolio, they usually ask:

Can this person understand a problem and the people who have it?
Can they explore options and explain their decisions?
Can they produce clear, usable, accessible interfaces?
Do they test their work and learn from it?
Can they communicate clearly in writing?

Think of a maths exam where the teacher awards marks for working, not only the final answer. A case study is your working. A beautiful final screen with no working gets few marks.

Choosing projects

Two to four case studies is a good range for a first portfolio.
Mix types if you can: one app, one website, maybe one redesign of a real service.
Concept projects are fine when you are starting out. Label them clearly as "Concept project" or "Self-initiated", and never imply a company hired you.
Redesigns of real apps should be respectful: say that it is an unofficial concept, and do not claim insider knowledge.
Client or job work may be under an NDA (non-disclosure agreement). Ask permission, hide confidential details, or describe the process without showing protected screens.

Case study structure

A clear, repeatable structure helps readers who skim. Run this example to see a simple case study page skeleton.

HTMLTry it yourself

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="utf-8">
  <title>Case study skeleton</title>
  <style>
    body { font-family: system-ui, sans-serif; margin: 0; color: #1a1a2e; line-height: 1.55; }
    article { max-width: 680px; margin: auto; padding: 24px 16px; }
    .tag { display: inline-block; font-size: 13px; background: #fef3c7; color: #78350f; padding: 2px 8px; border-radius: 999px; }
    h1 { font-size: 30px; line-height: 1.2; margin: 8px 0; }
    .summary { font-size: 18px; color: #374151; }
    dl { display: grid; grid-template-columns: repeat(auto-fit, minmax(140px, 1fr)); gap: 12px; background: #f4f4f7; padding: 16px; border-radius: 8px; }
    dt { font-size: 13px; color: #4b5563; }
    dd { margin: 0; font-weight: 600; }
    h2 { margin-top: 32px; font-size: 22px; }
  </style>
</head>
<body>
  <article>
    <span class="tag">Concept project</span>
    <h1>Making clinic booking less stressful for older patients</h1>
    <p class="summary">A mobile booking flow that cut booking steps from 9 to 5 in my prototype and helped all 5 test participants book without help in round 2.</p>
    <dl>
      <div><dt>Role</dt><dd>Solo UX/UI designer</dd></div>
      <div><dt>Timeline</dt><dd>4 weeks</dd></div>
      <div><dt>Tools</dt><dd>Figma, paper, Google Forms</dd></div>
      <div><dt>Methods</dt><dd>Interviews, usability tests</dd></div>
    </dl>
    <h2>1. The problem</h2>
    <h2>2. Research and insights</h2>
    <h2>3. Ideas and decisions</h2>
    <h2>4. Design</h2>
    <h2>5. Testing and changes</h2>
    <h2>6. Outcome and what I learned</h2>
  </article>
</body>
</html>

You should see a page with a yellow "Concept project" tag, a big title, a one-sentence summary, a grey box with role, timeline, tools and methods, and six numbered section headings. A busy reader can understand the whole project from the top 20 percent of the page.

What goes in each section

The problem: who struggles, with what, and why it matters. One short paragraph and your problem statement.
Research and insights: what you did (for example, six interviews and one observation), and the three or four insights that shaped the design. Quotes help.
Ideas and decisions: sketches, flows and the options you rejected, with reasons. This is where you show thinking.
Design: key screens, components and design system choices. Explain why, not only what.
Testing and changes: what you tested, what failed, and what you changed. Before-and-after comparisons are powerful.
Outcome and learning: honest results, and what you would do differently.

Be honest about results

Junior case studies often invent impressive numbers like "increased conversions by 300%". Experienced reviewers spot this quickly, and it damages trust.

Over-claiming	Honest and still strong
Increased bookings by 300%	In round 2, all 5 participants booked without help (3 of 5 in round 1)
Users loved it	4 of 5 participants said the time slots were easier to understand
Industry-leading design	Passed WCAG AA contrast checks on all text
Validated by AI	Tested with 10 people across two rounds

Small, real numbers from your own tests are far more convincing than big invented ones. If a project never launched, say so.

Writing the case study

Write in the first person ("I interviewed...", "We decided..."), and be clear about your own role in team projects.
Keep paragraphs short, with headings readers can scan.
Put captions under images that explain what the image shows and why it matters.
Aim for a case study someone can skim in two minutes or read in ten.
Proofread. Spelling mistakes in a design portfolio suggest carelessness with detail.

Before-and-after pairs with captions are one of the clearest ways to show a design decision. This example builds one with <figure> and <figcaption>, using simple drawn screens instead of images.

HTMLTry it yourself

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="utf-8">
  <title>Before and after figure</title>
  <style>
    body { font-family: system-ui, sans-serif; padding: 16px; color: #1a1a2e; }
    .pair { display: grid; grid-template-columns: repeat(auto-fit, minmax(220px, 1fr)); gap: 16px; max-width: 640px; }
    figure { margin: 0; }
    .screen { border: 2px solid #1a1a2e; border-radius: 16px; padding: 16px; height: 180px; display: grid; align-content: start; gap: 6px; }
    .code { border: 1px solid #6b7280; padding: 6px; font-size: 12px; color: #4b5563; }
    .chip { display: inline-block; border: 1px solid #5b21b6; border-radius: 999px; padding: 6px 10px; margin: 2px; color: #3b0d8c; }
    figcaption { font-size: 14px; color: #374151; margin-top: 8px; }
    figcaption strong { color: #1a1a2e; }
  </style>
</head>
<body>
  <div class="pair">
    <figure>
      <div class="screen"><span>Enter slot code</span><span class="code">e.g. S-0915</span></div>
      <figcaption><strong>Before:</strong> patients typed a code from a reception list. 3 of 5 failed.</figcaption>
    </figure>
    <figure>
      <div class="screen"><span>Choose a time</span><div><span class="chip">9:00 am</span><span class="chip">9:15 am</span><span class="chip">9:30 am</span></div></div>
      <figcaption><strong>After:</strong> tappable time chips. All 5 chose a slot without help.</figcaption>
    </figure>
  </div>
</body>
</html>

You should see two small drawn screens side by side, each with a caption that states the change and the evidence. On a narrow screen they stack.

Where to host it

Common options include your own simple website, a portfolio platform such as Behance, or a well-designed PDF for email applications. Whatever you choose:

Make it load fast on a phone, with compressed images.
Make it accessible: real text (not text inside images), alt text, good contrast.
Put your best case study first.
Add a short "About" with what you are looking for and how to contact you.

Presenting in an interview

Interviewers often ask you to walk through one case study in about 15 to 20 minutes. Practise a short version:

One minute: the problem and your role.
Five minutes: research, insights and key decisions.
Five minutes: the design and why it works.
Three minutes: testing, changes and results.
One minute: what you learned and would do next.

Expect questions like "What would you do with more time?" and "What was the hardest trade-off?" Honest, thoughtful answers matter more than a perfect design.

Common mistakes

Only final screens, with no process.
Invented metrics or vague claims.
Too many projects, each explained badly.
Unlabelled concept work that looks like real client work.
Huge images that make the portfolio slow on a phone.

Key points

A portfolio shows how you think, not just what you made.
Two to four strong case studies beat many weak ones; label concept projects clearly.
Use a clear structure: problem, research, decisions, design, testing, outcome.
Report honest results from your own tests; never invent numbers.
Make your portfolio fast, accessible and easy to skim, and practise presenting it.

Exercise

Write the top section of a case study for a project from this course (for example, the canteen pre-order app): a title, a one-sentence summary with an honest result, and the role, timeline, tools and methods box. Change the skeleton example to show it.

Show solution

HTML

<span class="tag">Concept project</span>
<h1>Helping students order canteen lunch between lectures</h1>
<p class="summary">A pre-order flow that let 4 of 5 test participants place an order in under a minute in my second prototype.</p>
<dl>
  <div><dt>Role</dt><dd>Solo designer</dd></div>
  <div><dt>Timeline</dt><dd>3 weeks</dd></div>
  <div><dt>Tools</dt><dd>Figma, FigJam</dd></div>
  <div><dt>Methods</dt><dd>Observation, interviews, 2 test rounds</dd></div>
</dl>

The summary names the user, the outcome and a real, modest result from your own test, and the tag makes clear it was self-initiated.

Quick Quiz

1. What makes a case study convincing to reviewers?

2. How should a self-initiated redesign of a real app be shown?

3. Which result statement is best?

What reviewers look for

Choosing projects

Case study structure

What goes in each section

Be honest about results

Writing the case study

Where to host it

Presenting in an interview

Common mistakes

Key points

Exercise

Quick Quiz

Learn UI/UX Design with a mentor