Collaboration Case

What it is. A collaboration case is the fourth project in your five project portfolio lineup. It is the one hiring managers read to decide if they want you in their Slack channels and critique sessions for the next few years. After you show what you can do alone with the flagship, how you can switch styles with the range setter, and how deep your expertise runs with the depth piece, the collaboration case proves you can actually work with a team. You pick a project where you had to negotiate with engineers who had technical constraints, product managers with aggressive timelines, or other designers with different opinions. Then you write the case study with radical honesty about what you wanted to ship, what you actually shipped, and why the compromises made the final product better or at least viable. Include the workshop you ran in FigJam to align stakeholders. Show the decision matrix you created when opinions diverged. Quote the feedback that made you scrap your favorite solution. This is the project that signals you understand design is a team sport not a solo performance. Most designers hate writing these because they require admitting you did not have all the answers. That discomfort is exactly why they work so well with hiring managers who have been burned by brilliant but difficult designers before.

What it is not. A collaboration case is not a polished gallery of final screens with a throwaway line about how you partnered with the team. It is not the project where you claim every decision was reached through perfect consensus and no feelings were hurt. Those stories do not exist in the real world and they read as fake. It is also not a complaint session about bad stakeholders or how your brilliant ideas were ruined by committee. The tone has to stay solution focused while still being real. Never throw former teammates under the bus even if they deserved it. The goal is not to look like the smartest person in the room. The goal is to look like someone who elevates the room. If your draft makes you look like a victim of bad collaboration then scrap it and choose a different project. Vague phrases like worked closely with cross functional partners are red flags. Name the partners. Name the conflict. Name the resolution or lack of one.

Concrete example. In 2022 at Notion the designer responsible for the database views overhaul wrote a killer collaboration case. The project involved three other designers, five engineers, two PMs, and the customer success team who brought real user complaints about how confusing the advanced filters had become. The designer wanted to introduce a new unified query builder that would replace the fragmented interfaces. Engineering said it would take twice the estimated time because of how deeply the views were tied to the core block system. The PMs wanted to ship incremental improvements instead of a big bang redesign to protect the quarterly OKRs. The customer success team pushed for more export options that complicated the UI. The case study walks through the initial research board with 62 user interviews, the three rejected directions including the designer's ideal but unscoped version, the compromise architecture that used modular components the engineers could deliver in sprints, the A B test results that showed a 52 percent reduction in support tickets for database issues, and a reflection that admitted the team should have included a frontend engineer in the first two weeks of discovery instead of week six. The designer included a screenshot of the shared Coda doc where all feedback was centralized and a quote from the lead engineer about how the designer translated between design and code constraints better than anyone they had worked with. That level of specificity and honesty is what gets you the interview at companies that value real collaboration over solo heroics.

When to use it and when not to. Use a collaboration case when you are targeting senior or staff design roles at product companies with more than 20 people on the team. The job descriptions that repeat words like cross functional, stakeholder alignment, or team player are basically begging for this project. Slot it fourth in your homepage after the first three projects have already shown your individual abilities. Update it after every major launch that involved real compromise. Keep the version with the clearest lessons and strongest metrics. Do not use it if the project ended in failure with no measurable positive outcome or if you cannot write it without sounding resentful. In those cases replace it with a second depth piece or expand your personal project to include collaboration like running a design critique club or contributing to an open source design tool. Never open your portfolio with the collaboration case. It works best once the hiring manager already respects your craft and is now trying to figure out if they can stand working with you. Avoid it for freelance heavy portfolios where every project was done solo. In that situation the personal project can sometimes double as a collaboration case if it involved heavy user testing with real people giving feedback.

The collaboration case does not prove everyone liked you. It proves you shipped anyway.