How to Show Your Contribution in a Team Project

The real problem

Team projects are common, but they often create unclear case studies. If everything is written as “we,” hiring teams may not understand what you personally shaped. The goal is not to take credit for everything. The goal is to make your contribution legible.

Team language makes this harder. When a case study uses “we” throughout, the reader has no way to know which decisions were yours. The portfolio looks like a project record rather than a demonstration of your judgment. The work may be excellent. As a solo portfolio piece, it is invisible as yours specifically.

What to focus on instead

The goal is not to pretend you did everything. The goal is to make what you did specifically clear to someone who was not in the room. That usually means naming two or three decisions or artifacts that you shaped, and explaining what you specifically contributed to each one.

Key principles:

• Separate team context from your personal responsibility.
• Name the decisions or artifacts you directly shaped.
• Mention collaboration without hiding behind it.
• Explain where you influenced the direction.
• Use “I led,” “I contributed,” or “I supported” accurately.

A practical structure

Use this simple flow:

1. Context: What was the team structure, and what was your place in it?
2. Problem: What needed to change, and was that framing yours or the team’s?
3. Role: What were you personally responsible for, not the team?
4. Decision: Which decisions can you trace directly to your input?
5. Reasoning: What was the evidence or constraint that shaped your specific choices?
6. Outcome: What changed because of your contribution specifically?

For team projects, the Role and Decision rows carry the most weight. They are where you distinguish your contribution from the team’s output. If those two rows are vague, the reader will default to assuming you had a supporting role.

Example framing

Weak framing:

I redesigned the flow and improved the user experience.

Stronger framing:

I focused on the onboarding step where users were unsure what to do next. Instead of adding more explanation, I simplified the sequence and made the next action more visible. This helped the team align around a clearer first-use experience.

The stronger version makes the contribution traceable. The reader can tell which part of the work was yours, what judgment you applied, and what your role produced. That traceability is what makes a team project work as a solo portfolio piece.

What to avoid

• Do not turn the case study into a gallery of screens.
• Do not hide your role behind vague “we” language.
• Do not overclaim impact if you do not have evidence.
• Do not describe every step equally; highlight the decisions that mattered.
• Do not copy another designer’s case study structure without adapting it to your own project.

Final thought

A team project case study works when the reader finishes it knowing what you specifically shaped. Not the team, not the product. You. If that answer is clear, the contribution is visible.

More case study guides

• what hiring managers look for in UX case studies
• writing a UX case study without metrics
• preparing your UX case study for a design interview