A portfolio is not a gallery of your prettiest screens. It is evidence that you can solve problems. The person looking at it usually has little time and one question: “can I trust this designer with a real task?”. A good case study answers that question quickly and convincingly. Here is how to build one.
How many projects you need and which to pick
At the start, two or three strong case studies are enough. One detailed case with an honest account of the process outweighs ten images without context. When choosing projects, use three criteria:
- You made the decisions. Work where you only recreated someone else's layout doesn't show your thinking.
- There is a clear problem. A case without a problem is just a showcase.
- Variety. For example, one mobile app, one web service, and one piece from a design game or challenge with a deadline.
Study and competition projects are perfectly legitimate material as long as you label the context honestly: “study project”, “concept”, “entry for a community design game”. Invented clients or results that never happened destroy trust faster than any weak piece of work.
Case study structure: six blocks
It helps to keep the same structure across all your case studies, so the reader can find their way around easily. Here is a basic outline:
- Short summary. Two or three sentences at the very top: what the product is, what the task was, what you did. Someone who reads only this should already get the point.
- Problem. Who had trouble and why. Be specific: not “improve the UX” but “people couldn't find where to change their delivery address and wrote to support instead”.
- Your role and constraints. What you personally did, who you worked with, how much time you had, what technical or business constraints applied.
- Process. How you investigated the problem, which options you considered, what you tested. Don't retell the whole process; show the key moments.
- Solution. Final screens with an explanation of why they look the way they do. This is the heart of the case.
- Outcome and lessons. What changed, what you validated, what you would do differently.
If you don't have outcome numbers, don't make them up. Describe honestly what you tested: “five out of five test participants found the action without hints”, or “the solution hasn't been tested with real people yet; my next step would be usability testing”. Honesty looks more professional than impressive but dubious percentages.
How to write so people keep reading
Most case studies go unfinished not because of weak design but because of the text. A few rules that help:
- Use headings that state findings. Not “Research” but “People looked for discounts, not categories”. Even someone skimming will follow the logic.
- One idea per paragraph. Long walls of text get skipped.
- Caption every image. The caption says what exactly is worth noticing.
- Show before and after. A comparison makes the value of the change obvious.
- Say “I” when you did it yourself and “we” when it was a team. It is honest and clarifies your role.
- Cut the jargon. Your case may be read by HR or product people, not only designers.
Example: rewriting a weak passage
Weak: “I did research, created personas, a CJM and wireframes, then built a UI kit and the final design.” This is a list of artefacts that doesn't say what you learned or why it mattered.
Stronger: “Conversations with six people showed that most of them abandoned checkout because of an unexpected delivery cost on the last step. So I moved the delivery estimate to the product page and tested two ways of presenting it in a clickable prototype.” Here there is a finding, a decision and a test.
Common mistakes
- Dozens of identical phone mockups with no explanation.
- A process described generically, as if from a textbook, without a single decision of your own.
- No stated role: it's unclear what you did and what the team did.
- Other people's work or recreations without a clear label.
- Confidential material shared without permission. If a project is under NDA, remove names and data or describe the process without the final screens.
- Broken links and prototypes that require access requests.
- Old work placed first. Your strongest case should lead.
Where to host your portfolio
The format matters less than the content. A personal site, a PDF or a profile on a design platform all work. What matters is that the portfolio opens quickly on a phone, has a clear first page with your name, focus and contact, and doesn't require sign-up to view. If you send a PDF, keep the file size reasonable and check that every link is clickable.
It helps to have two versions: a full one for people who want to dig in, and a short one of a few pages for a first introduction.
Reorder your cases for each role
The same portfolio doesn't have to look identical for everyone. If the team builds a mobile app, put your mobile case first. If the job description mentions research, make sure your first case shows the research process in detail, not in a single line. It takes fifteen minutes, but the person reviewing your portfolio sees relevant experience straight away instead of having to look for it.
Get feedback before you send it
Before sending your portfolio out, show it to two or three people: a fellow designer, someone outside design, and, if possible, someone with hiring experience. Ask each of them to retell, after two minutes, what you did in your first case. If their summary doesn't match what you wanted to convey, the case needs rewriting. You can share your work and ask for feedback in Spaceberry Community.
If you lack material for case studies, design games with a clear brief and a deadline are a good source. Read about the formats the community runs in Activities.
Pre-publishing checklist
- My strongest case comes first.
- Every case opens with a two- or three-sentence summary.
- The problem is stated specifically: who had trouble and why.
- It's clear what my role was and who I worked with.
- At least one decision is shown with a “why” explanation.
- The outcome is described honestly, with no invented numbers.
- Every image has a caption, and there is a before/after comparison.
- Study and competition projects are labelled as such.
- No confidential data appears without permission.
- All links and prototypes open without an access request.
- The portfolio is easy to view on a phone.
- There is a contact that makes it easy to reach me.
A portfolio is never final. Come back to it every few months: replace weaker pieces with new ones and rewrite the text when you start seeing your old decisions more critically. That's a good sign: it means you're growing.