For a long time, my portfolio looked like many UX portfolios.

Each case study included user research, personas, user journeys, benchmarking, wireframes, design explorations and detailed documentation explaining every step of the process.

I believed that showing everything would demonstrate the depth of my work.

In reality, I eventually realised that most people never reached the end of those pages.

The problem with traditional case studies
‍
Many UX case studies are written for other designers.

They explain methodologies, workshops and frameworks in great detail, often turning what could be a concise story into a long document.

While this information can be valuable, it isn't always what recruiters, hiring managers or clients are looking for.

Most people reviewing portfolios have limited time.

They want to understand three things as quickly as possible:
- What was the problem?
- How was it solved?
- What was the outcome?

If those answers are buried beneath several sections of research documentation, there's a good chance they'll never be seen.

Showing everything doesn't always communicate more
‍
One of the biggest lessons I've learned is that more content doesn't necessarily create more clarity.

A twenty-minute case study isn't automatically better than a five-minute one.

In many cases, it can make the most important parts harder to find.

The challenge isn't deciding what to include.

It's deciding what not to include.

From process-heavy to outcome-focused
‍
As projects became more complex, I found myself becoming increasingly interested in user behaviour, information architecture and usability.

I wanted to understand not only how things looked, but why people interacted with them the way they did.

This curiosity naturally led me into UX design, research and product thinking.The focus shifted from designing interfaces to solving problems.
‍
Product design brought everything together
‍
When redesigning my portfolio, I started questioning every section.

Did recruiters really need to see every wireframe?

Did clients care about affinity mapping exercises?

Would a founder benefit more from understanding the business challenge than reading through a complete research report?

In most cases, the answer was clear.

The story became stronger when unnecessary complexity was removed.

The structure I use today
‍
Today, most of my case studies follow a much simpler structure:

Overview
A short introduction explaining the product and its purpose.

Project Overview
The context behind the project and the challenge being addressed.

Challenge
The problem that needed solving.

Solution
How the product was designed to address that problem.

Key Features
The most important parts of the experience.

Design Highlights
Selected design decisions and considerations.

Outcome
The value created by the final solution.

This structure allows visitors to understand a project within a few minutes while still providing enough depth to demonstrate my thinking.

Process still matters
‍
Simplifying case studies doesn't mean ignoring the process.

Research, workshops, testing and iteration remain essential parts of how I work.

The difference is that they now support the story instead of becoming the story.

When someone wants to explore the process in greater detail, I can always provide additional documentation or discuss it during interviews.

Process still mattersToday, most of my case studies follow a much simpler structure:
‍
Looking forward
‍
As designers, we often feel pressure to prove how much work happened behind the scenes.

But portfolios aren't archives.

They're communication tools.

For me, simplifying my case studies wasn't about showing less work.

It was about making the most important work easier to understand.