Designcase
Back to blog

Case studies

How to Turn a Bootcamp Project Into a Strong UX Case Study

Learn how to turn a bootcamp UX project into a stronger case study by adding context, constraints, decisions, and realistic trade-offs.

4 min read
Ömer Arı avatar

Ömer Arı

4 min read

Cover image for bootcamp-project-into-strong-ux-case-study

A bootcamp project often starts with a clean brief. The target user is defined, the process is known, and the expected deliverable is clear. That helps you learn the method, but it can make the portfolio version feel too tidy. When I review a junior portfolio, I am rarely trying to judge whether the person followed a course framework correctly. I am trying to understand how they handled ambiguity once the framework became less clean.

What a hiring manager sees in a bootcamp project

A bootcamp project signals effort, but it also raises a question. How much of the work came from the designer, and how much came from the course structure? That does not make the project weak. It only means the case study needs to make your own thinking more visible. The safest approach is to be clear about the context. Say that it was a course project. Then explain what decisions were yours, what constraints you worked with, and where you had to choose one direction over another.

Add the missing layer: constraints

Most course projects look similar because they have similar process steps. The difference comes from constraints. Time, access to users, feedback quality, research limitations, scope changes, and technical assumptions all help the reader understand how you made decisions. A useful constraint might be: you had one week for research, you could interview only three users, or the prototype had to focus on onboarding rather than the full product. These details make the work feel situated.

Turn activities into decision moments

A junior case study becomes more convincing when each activity leads to a decision. Do not stop at “I created personas.” Explain what the persona changed. Did it narrow the onboarding flow? Did it change the information architecture? Did it make you remove a feature? The same applies to affinity maps, wireframes, usability tests, and UI iterations. The artifact matters because of the decision it helped you make.

Use plausible context without pretending it was a real client

You can add context without inventing a fake company story. For example: “Because this was a bootcamp project, I treated the brief as a simulated product challenge. To avoid making the case study too abstract, I defined three working constraints: mobile-first scope, limited research access, and a one-week prototype deadline.” This is honest and more useful than pretending the project had stakeholder pressure it never had.

What to leave out

Remove process screenshots that do not change the reader’s understanding. A wall of sticky notes, a persona template, and ten similar wireframes can slow the case study down. Keep the artifacts that explain a decision. If an artifact only proves that you completed an exercise, it probably belongs in your working file rather than the final case study.

A simple rewrite example

Weak version: “I conducted user interviews and created a user persona.” Stronger version: “The interviews showed that new users did not understand which plan fit them. I used that finding to simplify the first step of the onboarding flow and delay plan comparison until the user had seen the core value.” The second version tells the reader what changed because of your work.

Frequently Asked Questions

Should I say it was a bootcamp project? Yes. Hiding it usually creates more risk than clarity. Be honest about the context and specific about your own decisions.

Can a bootcamp project get me an interview? It can help if it shows reasoning, role clarity, and good judgment. The project does not need to look like a real client project to be useful.

How many bootcamp projects should I include? One strong project is usually better than three similar course exercises. Choose the one where you can explain decisions clearly.

Should I redesign the project after the course ends? Only if the rewrite improves the case study. A polished UI alone will not fix unclear reasoning.

Can I use AI to write the case study? You can use it to ask better questions and find gaps. The final reasoning should still sound like you.

Related reading