Do You Need Personas in a UX Portfolio?

Many junior UX portfolios include a persona section that feels familiar: a name, an age, a job title, a few goals, a few frustrations, and often a card that looks polished but has a weak connection to the rest of the case study.

The issue is rarely the visual design of the card. The issue is that the persona does not do much work inside the story.

Because personas are common in UX courses, many designers assume that every UX portfolio project needs one. It can start to feel like a case study is incomplete without a persona. That is not how strong portfolio storytelling works.

A strong UX case study does not need to show every method you have heard about. It needs to make your design thinking understandable.

So the better question is not:

Should I add a persona to this project?

The better question is:

Does this persona help the reader understand the user problem, the design priority, or the decision I made?

If the answer is yes, a persona can help. If the answer is no, it becomes a decorative UX artifact that takes space without adding clarity.

What is a persona?

A persona is a summarized profile that represents a user type. In a good UX process, it should come from research, behavioral patterns, needs, constraints, and repeated observations.

In a portfolio, the value of a persona is not the card itself. The value is the user pattern it helps explain.

A weak persona often looks like this:

• Sarah, 29
• Busy professional
• Wants to complete tasks quickly
• Gets frustrated by complicated interfaces
• Comfortable with technology

None of these details are automatically wrong. The problem is that they are too generic to explain a design decision. Most people want tasks to be quick. Most people dislike confusing interfaces.

A stronger persona carries a more specific behavioral pattern:

• This user does not perform the task often, so they need reassurance at each step.
• This user understands the product category, but hesitates before committing because the outcome feels risky.
• This user starts on mobile, then delays the final decision until they have more context.
• This user needs to know whether mistakes can be reversed before moving forward.

These details are more useful than a name, an age, or a stock-photo-style profile. They can be connected to design decisions.

When does a persona help in a portfolio?

A persona helps when it explains something the reader would not understand as clearly without it.

There are three common situations where it can work well.

1. Different user types require different design decisions

In some projects, one user group is not enough to explain the product experience. For example, in a payment or finance product, a first-time user and a frequent user may need different things. The first-time user may need clarity and reassurance. The frequent user may value speed and shortcuts.

In that case, a persona or user segment can show why the design needed to support different priorities.

A stronger portfolio explanation could sound like this:

Research showed two behavior patterns. First-time users needed explanation and reassurance before moving forward. Returning users already understood the task and expected a shorter path. This led us to design a more guided first-use flow while keeping a faster route for repeat use.

Here, the persona is not just a profile card. It explains the design direction.

2. The persona explains a design priority

Sometimes a persona helps because it explains why you gave more weight to one design decision over another.

For example:

• If the user is applying for credit for the first time, trust and clarity become more important.
• If the user is completing an urgent task, speed and error recovery matter more.
• If the user is comparing a complex product, information structure becomes critical.
• If the user is unsure about the outcome, confirmation and next-step messaging become part of the experience.

In this case, the persona does not only answer “who did we design for?” It answers “why did these priorities matter?”

That is what makes it useful in a case study.

3. The persona is based on evidence

The weakest persona is the one built from assumptions without any clear evidence. That usually leads to vague goals and predictable frustrations.

A stronger approach connects the persona to research.

For example:

In interviews, first-time applicants did not mainly struggle with the number of steps. They struggled to understand what the outcome would mean for them. I defined the persona around uncertainty during the decision moment rather than demographic traits.

This tells the reader a few important things:

• The persona was not invented randomly.
• It came from a research pattern.
• It shaped the design priorities.
• It has a role inside the case study.

When does a persona weaken a case study?

Personas are not required in every UX project. In some case studies, adding one can make the story less focused.

1. The persona does not affect a design decision

If you show a persona card and never refer to it again, it becomes a loose artifact.

This pattern is common:

1. A persona appears.
2. Wireframes appear.
3. Final screens appear.
4. The connection between the persona and the design choices is never explained.

The reader is left to guess why the persona was included.

A better solution is to remove the persona or replace it with a sharper user need.

For example:

Users wanted to know where they were in the process because uncertainty about the remaining steps made them more likely to abandon the flow.

That sentence can be more valuable than a generic persona card.

2. The persona is mostly demographic

Age, job title, city, and income can matter in some projects. In healthcare, education, banking, public services, or regulated products, demographic factors may shape access, literacy, trust, or risk.

Still, in many digital product case studies, behavior is more useful than demographics.

A portfolio reader usually needs to understand:

• What is the user trying to do?
• Where do they struggle?
• What information do they distrust?
• Where do they hesitate?
• When do they abandon the task?
• Which design decision responds to that behavior?

These points are more useful than a generic profile.

3. The persona repeats information already explained elsewhere

Sometimes a persona repeats what the problem statement, research findings, or journey map already explain.

In that case, it does not need a separate section. The user type can be described inside the research or problem framing section.

For example:

Research showed two main behavior patterns: experienced users wanted to complete the task quickly, while new users wanted more explanation before making a decision. The design needed to balance speed and reassurance.

This is shorter and often more useful than adding multiple persona cards.

How to write a persona section better

If you use a persona in your portfolio, treat it as part of your reasoning, not as a template to fill.

A practical structure can help.

1. Explain where the persona came from

The reader should know whether the persona came from interviews, survey data, analytics, support tickets, stakeholder input, or a workshop.

For example:

This persona was based on six user interviews and repeated issues found in support tickets.

If you did not have research, be honest about that too:

This project had limited research access, so I used a hypothesis-based user scenario and identified the assumptions that would need validation later.

That is stronger than presenting an assumption as research.

2. Define the persona by behavior

Instead of starting with demographics, start with the behavior that shaped the design.

Weak version:

Emily is a 31-year-old busy professional.

Stronger version:

Emily represents users who do this task rarely and need reassurance before moving to the next step.

The second version gives the reader a clearer path to the design decision.

3. Connect the persona to a decision

After the persona section, make the connection explicit.

Useful phrases include:

• This led us to…
• Because of this behavior…
• For this user type…
• This priority shaped the design because…

For example:

This user type did not want to continue without understanding the result of the action. Because of that, the confirmation screen did more than say “success.” It explained the outcome, the next step, and how to recover if something looked wrong.

Now the persona is connected to UX writing, flow design, and trust.

4. If you show multiple personas, clarify the difference

Three personas that all say similar things do not help much.

If you include more than one persona, the differences should be meaningful. They might differ by:

• Goal
• Experience level
• Frequency of use
• Risk perception
• Decision behavior
• Information need
• Success criteria

For example:

New users needed reassurance and explanation. Returning users wanted to complete the same task with fewer interruptions. This difference created two design priorities: a guided first-use experience and a faster repeat-use path.

This explains why more than one user type matters.

What can you use instead of a persona?

A persona is not the only way to explain the user.

Sometimes another format is clearer.

User segment

If you have different user groups but do not need a full persona, a simple segment may be enough.

Examples:

• First-time users
• Returning users
• High-risk users
• Comparison shoppers
• Users with low confidence

User scenario

If context matters more than user identity, a scenario can work better.

Example:

The user starts the application on mobile, then pauses because they want to understand the cost and repayment plan before continuing.

Jobs to be Done

If motivation is the key point, a job statement may be more precise.

Example:

When comparing options, the user wants to understand whether the choice is safe, manageable, and worth committing to.

Problem statement

If your goal is to clarify the problem, a strong problem statement may be enough.

Example:

Users abandoned the application before the final step because they could not tell which information was binding and which could still be changed.

A quick checklist before adding a persona

Before adding a persona to your portfolio, ask:

• Is this persona based on evidence?
• Does it explain at least one design decision?
• Does it focus more on behavior than demographics?
• Do I refer back to it later in the case study?
• Would the case study be clearer without it?
• Could a user segment or scenario do the same job with less space?

If most answers are no, the persona probably does not need its own section.

A stronger persona section example

Here is a simple structure you can adapt:

Research showed two behavior patterns. First-time users needed explanation and reassurance before continuing. Returning users already understood the task and expected a shorter path.

Instead of defining personas by age or job title, I defined them by confidence level and frequency of use. This shaped two design priorities: a more guided first-use flow and a faster path for repeat users.

There is no decoration here. The section connects user understanding to design direction.

Next step

Before improving the visual design of your persona card, write one sentence:

This user type changed my design decision by…

If you cannot complete that sentence clearly, do not make the persona bigger. Strengthen the user need, behavior pattern, or problem statement instead.