A collaboration belongs in your portfolio when the reader can understand your exact contribution before they reach the second paragraph.
That standard is simple. Name who built the product, name what you owned, and separate your work from everything that already existed. If the reader has to infer the boundary, the case study is not clear enough.
I learned this while rewriting my own IronLife entry. Milan built the Webflow site. I wrote, edited and published the fitness and SEO articles through its CMS. The project belongs in my portfolio because the content work was mine. The Webflow build was not.
Put the role boundary above the fold
Most misleading portfolio pages do not contain a direct lie. They create the wrong impression through placement.
A title such as “IronLife fitness platform” appears first. Screenshots show a polished website. Several paragraphs later, a small credit says that someone else designed and built it. The credit is technically present, but it arrived after the reader had already assigned authorship.
Use a role line directly below the title instead:
My role: article research, AI-assisted drafting, editing and CMS publishing. Site design and Webflow development: Milan.
The AIGA Standards of Professional Practice make the same principle explicit: collaborative portfolio work should identify the precise areas of authorship. The useful part is not the formal rule. It is the placement. A skimming reader should see the boundary as quickly as the project description.
Use the skim test
Open the project and look only at three things:
- The title
- The role line or tagline
- The first image and its caption
Can a stranger explain what you personally produced? If the answer is no, rewrite those three elements before touching the rest of the case study.
On my IronLife case study, the category says “Content / CMS collab.” The introduction names Milan as the Webflow developer and says directly that I did not ship the build. That boundary is visible before the longer explanation begins.
Replace broad claims with owned deliverables
The easiest repair is to replace a vague team claim with a deliverable attached to a person.
| Avoid | Why it misleads | Write instead |
|---|---|---|
| “We built a fitness content platform.” | The reader cannot see who designed, coded or wrote it. | “Milan built the Webflow site; I wrote and published the article set.” |
| “Led content strategy and SEO.” | “Led” hides the work and the team. | “Researched, drafted, edited and published the fitness articles.” |
| “Redesigned the checkout.” | It implies ownership of the complete flow. | “Redesigned the payment step inside an existing checkout.” |
| “Increased traffic by 40%.” | It claims attribution without showing how it was measured. | “Traffic grew during the publishing period; I cannot isolate the content’s effect.” |
Specific language can make a role sound narrower. That is useful. A narrow contribution explained with real decisions is more credible than a large contribution described with foggy verbs.
Caption the contribution, not the screen
Screenshots create authorship assumptions faster than paragraphs can correct them. A caption such as “IronLife homepage” only describes the image. It says nothing about why the image is in your portfolio.
Use the caption to state the boundary:
Article template populated and maintained through the Webflow CMS. Interface and Webflow build by Milan.
The same rule applies to video. If a screen recording mostly shows another person’s design and development, add a short title card that states your role before the movement begins.
Treat metrics as separate claims
A project may have performed well without proving that your contribution caused the result.
Use a metric only when at least one of these is true:
- you measured it yourself and can explain the method
- a named source measured it and you attribute the result
- the data isolates the part of the project you owned
Otherwise, describe the work rather than borrowing the project’s outcome. “Published twelve articles through the CMS” is defensible. “Drove the site’s growth” requires attribution evidence.
This also makes interviews easier. You can discuss decisions, constraints and the work you shipped without defending a number you never had access to.
Keep collaborative work in the portfolio
Deleting every collaboration produces another false picture: that you always work alone.
Collaboration can prove that you can enter an existing system, respect ownership, coordinate with a specialist and deliver one part without taking credit for the rest. Those are valuable skills for agencies, product teams and clients with work already in progress.
The honest version needs four facts:
- Who built what
- What you personally owned
- What existed before you joined
- Which results you cannot attribute to your work
If confidentiality prevents you from naming someone, name the role instead: “site built by the client’s internal team” or “design by a partner agency.” The boundary matters more than the public name.
A 10-minute portfolio audit
Choose one collaborative project and make these changes:
- Write a role line under fifteen words.
- Move it directly below the title or into the project card.
- Attach every deliverable to the person who produced it.
- Rewrite image captions around your contribution.
- Remove metrics you cannot measure or attribute.
- Read only the title, role line and first caption as a stranger.
If those three elements describe your contribution correctly, the rest of the case study can add depth instead of repairing a misleading first impression.
That is the goal: keep the collaboration, show the work you truly did, and make the credit impossible to miss.