PORTFOLIO POSITIONING
Quentin’s portfolio showed what he built but undersold what he led.
His case study focused on building a design system. Reading through the work, I saw a bigger story about how he helped change the way teams worked together.
Client: Senior Product Designer
Challenge: Portfolio positioning
Focus: Case study rewrite
Collaboration: Two revisions over one week
Quentin had more than 15 years of product design experience across SaaS, design systems, and complex products. He’d spent over a year looking for a role, sent hundreds of applications, and gone through dozens of interviews without an offer.
He’d also received a lot of portfolio feedback. The problem was that much of it conflicted, leaving him to figure out which advice was actually worth following.
Before rewriting the case study, I wanted to understand what someone would take away from it. Was it helping them see the experience Quentin actually had?
His concerns made sense, but there was more to work through.
Quentin was concerned about the amount of text, whether the visuals were doing enough, and how to order the sections. He also felt pressure to demonstrate AI experience in a project that wasn’t really about AI.
Those were understandable things to question but what stood out to me was how much the case study focused on the design system itself.
It explained the components and implementation. It gave less attention to how Quentin recognized a wider problem, got support for addressing it, and brought people across teams into the work.
That's important because those details tell you about the person behind the project.
Someone reading it could see that Quentin could build a design system. I wanted them to also understand the responsibility he took on to make it useful across the company.
We started with the problem he was trying to solve.
The original opened with the design system and what Quentin built.
I moved the organizational problem forward so the reader could understand why the work was needed, what Quentin was responsible for, and why it involved people across product, design, and engineering.
That gave the design system a clearer purpose in the story.
By the time someone reached the solution, they had the context to understand what Quentin was trying to change and why building components was only part of it.
Getting people behind the work deserved more attention.
Some of the most revealing parts of the project were spread throughout the case study.
Quentin had identified the problem, secured buy-in, and aligned people across product, design, and engineering. He’d also helped create shared ownership and supported adoption.
I brought those details together because they helped explain what it took to move the initiative forward.
A design system can look like a collection of components when that’s what the portfolio gives the most space to. But how do you get people to use it? How do you involve teams in the decisions? How does it become part of the way they work?
Quentin’s experience with those questions deserved to be visible. It showed the reader more of his judgment and the scope of what he had led.
The results needed that context too.
The numbers stayed the same. I changed what the reader understood before reaching them.
Once Quentin’s role and decisions were clearer, the outcomes were easier to interpret. They followed an explanation of what he had contributed and how the work fit into a broader effort.
I wanted the reader to understand that contribution accurately, including where other people and teams were involved.
The evidence was already useful. Giving it context helped explain why it belonged in his portfolio.
What Quentin realized
“I didn’t realize how much I did until I framed the problem and solutions correctly. I first thought I simply suggested a small change but in reality I initiated and led the transformation of a large company delivery system.”
This was important because it went beyond whether he liked the new writing.
Quentin had been describing the project as a relatively small change. Working through the problem and his role helped him recognize how much responsibility he had actually taken on.
I think that can be difficult to see when it’s your own work. You remember the individual tasks and decisions because you lived through them. Stepping back and explaining what they resulted to can take more effort.
Months later, he got back in touch.
Quentin later told me he had found a Design Ops role at Schneider.
“Positioning was the main issue.”
I can’t say the rewrite caused the offer. There are too many factors involved in hiring to make that claim.
What mattered to me was that his reflection came back to the same issue we would worked through. He had experience worth showing, but his portfolio hadn’t been helping someone recognize the full scope of it.
The Design Ops role was also interesting in that context. His project already included work around team alignment, adoption, and how the organization delivered. Those were the parts we would brought forward.
Your portfolio might be underselling the kind of work you do.
Quentin came in with concerns about his case study’s presentation. Working through it revealed a more important question of what did this project actually demonstrate about him?
The design system was part of the answer so was his ability to recognize an organizational problem and get people involved in changing how things worked.
That’s why I spend time figuring out what a portfolio should say before rewriting it. You can make the sentences clearer and still leave the most meaningful parts of someone’s experience in the background.
For Quentin, the story became more useful when it gave those parts the attention they deserved.
Explore another rewrite
See how I made Amandeep’s research easier to follow
See how I’d make Adam’s design decisions easier to see
Does your portfolio show the full scope of your work?
UX Portfolio Rewrite
If you know there’s more to your experience than your portfolio shows, I can help you figure out what deserves attention and how to explain it.