Do UX managers need a portfolio?

"Your UX portfolio Is not a museum of your work, it is an argument for why someone should trust you to lead."

I spent a fair amount of time working on my portfolio. More than I expected, if I'm being honest.

Buckle up! This is going to be a long read.

I thought the difficult part would be choosing the projects. I had spent years working on products, leading people, solving problems and making decisions. Surely, all I had to do was put the best bits together.

It wasn't that simple.

I had case studies. I had screenshots. I had outcomes. I had a CV that talked about strategy, leadership and business impact.

But when I started looking at everything together, I realised something was missing.

Me.

Not my name, photograph or professional history. Those were easy enough to put on a website.

It was missing the person who made the decisions. The manager who had to navigate competing priorities, bring people along, make difficult calls and occasionally admit that something hadn't worked.

The portfolio showed the work. It didn't always show the thinking behind it.

And that matters when you're applying for a leadership role.

A hiring manager isn't simply looking for someone who can produce good UX. They want to know whether you can help other people produce good UX, make sound decisions, influence the organisation and build the conditions in which good work happens.

Your portfolio needs to make that case.

The trouble with showing your best work

Most UX portfolios begin with a familiar question: 'Which projects should I showcase?'

I started there too.

Over the course of my career, I'd worked on enough projects to fill a fairly substantial website. The temptation was to include everything that looked impressive.

A complex product. A successful redesign. A research-heavy project. Something involving AI. A few attractive screens.

The problem is that a collection of impressive projects doesn't automatically make an impressive leadership portfolio.

Imagine interviewing two candidates.

The first shows you a beautiful interface and explains how the team arrived at the final design.

The second shows you a complicated product challenge. They explain how they helped the team understand the problem, worked through competing priorities, aligned stakeholders and made decisions with incomplete information.

Both may be good UX professionals.

But if you're hiring a UX manager, the second candidate is answering a different question.

They're showing you how they think and lead.

That's the shift I had to make when putting my portfolio together.

I stopped asking, "Is this a good project?" I started asking, "What does this project prove about me as a leader?"

It's a small change in wording. It makes a considerable difference to what ends up on the page.

Choosing projects is a leadership exercise

I eventually settled on a portfolio that included projects such as Northstar, Acme Analytics, Bell the Bull and RideTogether, alongside work from healthcare and other product experiences.

They weren't all there to demonstrate the same skill.

Northstar gave me an opportunity to talk about UX strategy and multidisciplinary collaboration.

Acme Analytics explored a complex enterprise security problem.

Bell the Bull let me demonstrate how I approached an AI-enabled concept that needed technical validation and legal consideration.

RideTogether brought research and product strategy into the picture.

The projects had different strengths. That was the point.

I wanted the collection to tell a broader story about how I approach problems, work with people and make decisions.

This is where I think managers need to be more ruthless than individual contributors when selecting portfolio pieces.

You don't need to demonstrate every skill you possess in every case study. You need the collection to demonstrate the range of problems you can lead.

One project might show how you developed a strategy. Another might show how you helped a team work through ambiguity.

A third might demonstrate how you influenced a decision or introduced a better way of working.

Think of your portfolio as a team of players. You don't need seven strikers. You need people who bring different strengths to the game.

Your case studies should work the same way.

Three or four well-chosen projects that demonstrate different leadership capabilities can tell a stronger story than ten projects that all say, "I can design a good product."

The uncomfortable question

'What did I actually do?'

This was one of the more useful questions I had to ask myself.

When you've spent years working with designers, researchers, writers, product managers and engineers, the outcomes are rarely yours alone.

That's a good thing. It's how product development should work.

But it creates a challenge when you're writing a case study.

The team redesigned a journey. The product improved. Stakeholders agreed on a direction. A difficult problem was solved.

Where do you fit into that story? It's tempting to describe everything using the word I.

I led the strategy. I drove the redesign. I aligned stakeholders. I delivered the outcome.

After a while, every case study starts to sound like a one-person army - That's not leadership. It's a suspiciously small team.

The opposite mistake is to talk about the team so much that your own contribution disappears.

A hiring manager shouldn't have to guess what you did.

So I started looking more carefully at the decisions I had made, the problems I had helped clarify, the people I had brought together and the systems I had helped establish.

There is a meaningful difference between saying: "We redesigned the product experience."

And saying: "I helped establish the problem we needed to solve, aligned the team around the priorities, and guided the UX strategy while designers, engineers and product partners developed the solution together."

The second version gives the reader a better understanding of your role without pretending you did everything yourself.

It also makes room for the things that are often missing from leadership portfolios: judgement, influence and the ability to help other people do their best work.

Not every good story ends with a victory

There is another temptation when building a portfolio.

You want everything to look successful.

The metrics should go up. The project should launch. The team should be happy. The stakeholders should applaud.

Real life doesn't always cooperate.

Some initiatives change direction. Some ideas don't make it into production. Sometimes the result is useful, but not in the way you expected. Sometimes you learn more from a decision that didn't work than from one that did.

Bell the Bull, for example, was an AI-enabled concept that won senior leadership approval at a hackathon. Engineering validated its feasibility, and legal review was conditional. Those distinctions matter. It would be easy to dress that up as a fully deployed AI product with proven business outcomes.

It would also be misleading.

The actual story is interesting enough: identifying a problem, shaping a concept, building organisational support and working through feasibility and legal considerations.

That's meaningful evidence of leadership, even without claiming a production outcome that hasn't been established.

The same principle applies to metrics. If a result was measured, say so. If it was a projected outcome, label it as a projection. If the project was an experiment, explain what it tested.

A portfolio is not a sales pitch in which the truth gets rounded up.

It's an invitation to trust your judgement.

And trust is difficult to establish when every project is presented as an unqualified success.

Screenshots aren't evidence of leadership

Visuals matter.

But.

A portfolio that consists of walls of text is hard to read, and product work often benefits from showing the actual experience. But screenshots can become a comfortable hiding place. It was easy to fill a page with wireframes, research artefacts, flows and polished interfaces. They make the page look busy. They also give the impression that something substantial has been said.

Sometimes, very little has.

A hiring manager looking at your portfolio should be able to understand why the work mattered without examining every screen.

Then I remembered some questions my design mentor would ask me:

• What was the problem?

• Why was it difficult?

• What did you decide?

• Who needed to be involved?

• What changed because of your contribution?

• What evidence tells you the approach worked?

If a visual helps answer one of those questions, keep it. If it merely proves that you know how to use a design tool, consider whether it deserves the space.

I found it useful to think of visuals as supporting evidence rather than decoration. A simple diagram showing the decision-making process can be more revealing than six screenshots of the finished interface.

The point isn't to make the portfolio look less designed. It's to make the design work harder.

What's your Leadership story?

I could write that I'm an empathetic manager. I could say I believe in collaboration, coaching and giving people room to grow.

Most managers could write the same thing. The words aren't the difficult part. The evidence is.

If you say you empower people, show a decision you helped someone make independently.

If you say you value collaboration, explain how you worked through a disagreement between functions.

If you say you're strategic, demonstrate how you connected a product problem to a wider organisational goal.

If you say you coach people, show how you helped someone think through a challenge rather than simply handing them the answer.

This is where your leadership portfolio starts to become more personal.

Not because you've added a photograph or written a paragraph about your values, but because the reader can see those values in the way you work.

Your leadership philosophy shouldn't sit on a page by itself, waiting to be admired. It should appear throughout your case studies.

The same principle applies to your About page. A short introduction can tell people who you are and what you believe. Your work should then demonstrate that those beliefs aren't just well-chosen sentences.

Write for the job you want, not only the job you've had

This was another important consideration while I was building my portfolio.

A portfolio naturally looks backwards. It tells people what you've done. A job search also asks a forward-looking question.

What could you do here?

If you're aiming for a Head of UX role, your portfolio needs to make a case for your ability to influence product strategy, establish direction, develop people and improve how UX operates across an organisation.

If you're applying for a Senior UX Manager role, the emphasis might include team leadership, cross-functional collaboration, execution and the ability to turn strategy into outcomes.

The evidence needs to come from your actual experience. You shouldn't invent a larger team, a bigger remit or responsibilities you haven't held. But you can make the relevance of your experience clearer.

A project that initially looks like a product redesign may also demonstrate how you aligned stakeholders around a shared problem. A process improvement may reveal your ability to establish systems that help a team work more effectively. A research initiative may show how you helped an organisation make a better decision.

The work doesn't change.

The story you tell about its significance becomes more precise. That's not spin. It's context.

And it helps a hiring manager see the connection between the leader you've been and the leader they need.

Make the website easy to use

There is a slightly embarrassing irony in building a UX portfolio. You can spend so much time explaining how to make products easier to use that you forget to make your own website easy to use.

I wanted my portfolio to be minimalist, uncluttered and easy to navigate. The case studies needed enough visual presence to invite exploration, but the overall experience couldn't get in the way of the content.

That meant making decisions about hierarchy, navigation, page structure and how much information to reveal at once.

The same principles we apply to products apply here:

• Don't make visitors work to understand who you are.

• Don't bury the work you're most proud of.

• Don't force people through a complicated journey to find your CV or contact details.

• And don't confuse visual cleverness with usability.

A recruiter may spend only a few minutes looking at your portfolio before deciding whether to explore further. You don't control how much time they have. You can control how much effort it takes to understand your value.

Make those minutes count.

A portfolio is never really finished

I still think of a portfolio as a living piece of work. My portfolio isn't perfect, but it is an evidence of some of the most prominent work I've done so far and ones I'll do in the future.

New projects give you new evidence. Old projects become more meaningful as you gain perspective. Your career direction changes, and the story needs to change with it.

You may discover that a case study you once considered essential no longer supports the roles you're pursuing. Another project, previously overlooked, may reveal something important about how you lead.

That's fine.

You don't have to preserve every project like a family photograph.

A portfolio should reflect the professional you are becoming, not simply archive the professional you used to be.

If you want a practical starting point, use these questions for every case study:

• The problem: What needed to change, and why did it matter?

• My role: What was I accountable for, and what did I contribute?

• The decisions: What did I influence, prioritise or challenge?

• The people: How did I work with the team and other stakeholders?

• The evidence: What changed, and how do I know?

• The learning: What would I carry into the next challenge?

You don't need to answer every question with equal detail. You do need to give the reader enough to understand your contribution.

And be honest about what you don't know. That's part of leadership too.

The takeaway

Building my portfolio forced me to do something I hadn't fully appreciated before.

I had to look at my career not as a sequence of projects, but as a pattern of decisions. The problems I'd chosen to work on. The people I'd helped. The systems I'd built. The times I'd changed my mind. The outcomes I'd influenced, and the lessons I'd carried forward.

That pattern tells a more useful story than a collection of attractive screens ever could.

If you're moving up as a UX manager, don't ask only whether your portfolio shows good work.

Ask whether it shows why someone should trust you with a bigger problem, a broader team and a more consequential decision.

That's the portfolio worth building. And if you'd like to see how I've approached it, you can explore my UX Manager Portfolio.

Not as a template to copy, but as an example of one leader trying to make the evidence speak for itself.

God Speed.