Hello, it’s Aneta here 👋 This is issue #02 of UX Design Express and today we’re talking about

Context in your UX portfolio

When we write UX case studies, we tend to talk about storytelling but we never explain what this means in details. There is one overlooked layer of portfolio stories: context.

What’s the common problem with stories in UX portfolios?

Imagine you’re a hiring manager. You’ve received hundreds of applications from UX designers. You’re going through their portfolios and you start seeing a pattern. Every designer is showing:

• sticky notes

• site maps

• wireframes

• some hi fi screens

You start recognising a common list of deliverables. You think, cool, knowing some UX methods is a good starting point but

• what problem did you solve?

• did you have any constraints?

• who were your users?

There is no context here. It's like showing a painting with some missing spots, the art isn't complete and the story can easily get lost. At this point it’s our job as designers to make it easy for our readers, like hiring managers, to understand stories from our UX projects. So how can we do it?

In this newsletter, I’m diving into that exact problem that many of us designers have when presenting stories from our UX projects.

I’ll share with you my take on why context is the secret sauce for your UX portfolio. It's not just about what you did, it's about painting the whole picture – the problem you tackled, the journey you took and the people you helped out.

Let’s dive in 🐬

01. Your role in the project

When I review UX portfolios on my mentoring sessions, there is one key thing that makes it difficult for me to evaluate designer’s skills. It is figuring out what this designer actually did in the project.

Many designers explain this by mentioning what parts of the design process they were responsible for, e.g. user research or prototyping. While sharing this information is fundamental, there are a few more areas where there are hidden opportunities to highlight your contribution to the project.

1.1 - General information about your role

• UX Designer, Lead Designer etc.

1.2 - Highlighting what part of the process you were actively contributing to

• Responsible for

  • researching the problem space

  • identifying problems to solve

  • exploring various solutions

  • testing concepts / running experiments

1.3 - Using more “I did” than “We did”

• I iterated / conducted / initiated / designed etc.

1.4 - Giving credits to others

• The illustrations were done by talented John Smith

• I collaborated with another designer on creating an onboarding flow

• I partnered with Content Designer to write a copy for the onboarding flow

02. Project background

Working on a bootcamp or any other conceptual project gives you a different project environment than being a part of a project team in a fintech organisation. One of the biggest differences tend to be project constraints, team availability and business context. While real projects give you usually all of this, school assignments tend to miss this part. Starting your story with a clear context can help hiring managers understand what to expect from the case study.

2.1 - What was the project type?

• School assignment (bootcamp, university)

• Conceptual / passion project (including voluntary work)

• Real world project (including voluntary real case)

2.2 - What was the project scope?

• Totally new product

• New feature to an existing product

• Redesign of a selected feature

• Redesign of a whole product

2.3 - How did the project come to you?

• Received a brief

• Informed about a clear business need

• Initiated project together with a team member

• Initiated project myself

2.4 - What were the goals?

• Clear business objectives, e.g. KPIs, OKRs

• Success metric, e.g. increase engagement

• User goals, e.g. value users received

2.5 - What were the constraints?

• Technical, e.g. poor code, legacy product

  • Possible impact on work: Limited solution possibilities

• No clear product vision and strategy

  • Possible impact on work: Increased project ambiguity

• Low design culture in the organisation

  • Possible impact on work: Spent significant amount of time explaining design, setting up processes, templates, components etc.

• Limited time / budget

  • Possible impact on work: Scope decreased, quick fixes introduced

• Lack of constraints

  • Possible impact on work: very innovative, conceptual project for fun

2.6 - What was the team?

• Based on the expertise

  • growth team, merchant experience, checkout

• In-house / agency team

03. This one research artefact that you produced

Imagine that you did some product teardowns for your project. You prepared a deep analysis in FigJam, put there hundreds of screenshots and made lots of insightful comments. You put a lot of effort into the analysis and it also turned out to be a very useful artefact during the process.

Now you feel like this artefact is relevant to your case study story and you want to include it in your UX portfolio.

3.1 - Using framework describing: what you did, why you did it and what you learned

Part of 5Ws method

Product teardown artefact example:

• WHAT I DID → I analysed various flows within an existing merchant onboarding process, considering different starting points such as website access or ads links.

• WHY I DID IT → This helped me quickly understand the existing solution and form initial assumptions, at the same time helping with stakeholders‘ communication.

• WHAT I LEARNED → One key insight was that entry points seemed weak, failing to inform merchants about the value of our products.

3.2 - Not showing the artefact but creating insightful headers and contextual pictures

• Not writing “user research” but “for an ordinary person, anything related to cyber security seems abstract and cryptic”

3.3 - Highlighting visually problems on product screenshots or customer journeys

3.4 - Visualising research learnings

Understanding context in your UX project

In the first issue of this newsletter, I shared insights on understanding project context. But there's one more method I use when trying to get context of a UX project: investigation board.

Key parts of my typical investigation board

• 🔍 Collecting info

  • Like a detective, I gather all available information.

• 📝 Note taking

  • Every detail counts. I write down all key points.

• 🤔 Spotting assumptions

  • I identify assumptions which helps me understand potential challenges.

• 📸 Taking screenshots

  • Visuals help me quickly get the gist of the problem.

• 🔎 Focusing on facts

  • Evidence and real users’ feedback is what I look for.

Juicy resources 🧃

Context in UX portfolios

• Read about ROI of a good communication here. Context is important but don’t overdo it

• Read point 3 from this article to understand that there are different expectations from conceptual case studies vs real projects

• “Context is the glue that holds your portfolio together” - read more about it here

• Read this book to improve your communication

Context in UX projects

• Check here my projects examples where I used a product teardown method to quickly understand how the product works

• Watch this video to learn about different methods for understanding your users

• Learn about KPIs here to get the business perspective

That's it for today!

Enjoying the newsletter? Let me know here →

I’m back in two Fridays with another edition of UX Design Express where you’ll get insights on how to present problem statement in your UX portfolio 👋

Keep designing ✨
Aneta Kmiecik