Framing UX concepts for your team: CUJs, use cases, personas

tl;dr — jargon is less important than aligning on what you need to know to solve user needs.

Today’s goal is to document how I’ve framed UX concepts to be more digestible for xfn teams.

I want to create products that make lives better. I’m listening to Save The World by Swedish House Mafia today.

Do UX terms/concepts need disambiguation?

Let’s test this. Can you explain the differences between these terms:

• CUJ
• use case
• user goal
• user flow
• user journey
• user story
• user persona
• user archetype
• information architecture
• information hierarchy
• interaction pattern
• design pattern
• affordance

Some of you can, some of you can’t. Now try explaining this to your product/eng team — see how many of them can keep these straight. And then try writing concrete examples for each of these terms from your own product. If you arrive at something sensical, congrats, you’re in the 1%. If not, it’s not just you — it gets confusing fast.

from xkcd

Why do these UX concepts matter?

Not all of them do. The parts that DO matter are important because they help the team align on priorities and understand how the entire scope of work fits together to solve end-to-end user needs for a use case.

Here are some common problems and symptoms to watch out for, and how alignment can mitigate it:

• We keep bouncing around building random cool features, but can’t get a set of users to stick with/pay for the product?
  Likely, the team isn’t aligned on focusing on solving an end to end use case first before expanding to others. Users need to see enough value in solving their particular need before sticking with a product.
• Leadership keeps asking for clarity on the “CUJ”, and you feel like you’ve explained it several times but they seem to be asking for more.
  Likely, you’re not aligned on what the term means. Just find some time or shoot an email and clarify it with concrete examples. Some people think a CUJ means a step-by-step flow; others think the CUJ is an overall user goal. Get on the same page.
• Eng wants to cut scope and doesn’t understand why we need to spend time on “small things” like fixing copy, colors, help content?
  Likely, the team is not aligned on what the user needs to be able to accomplish their e2e use case. This one is tricky since it’s easy to slip over into unnecessary scope creep. Take the example of a shopping checkout feature: maybe showing a clear disabled state and explanation for why the “Pay” button is disabled until you’ve filled out a payment method is necessary to avoid user frustration and drop-off.
• The team and leadership seem divided on which features to focus on?
  Likely, the team/stakeholders are not aligned on which user archetypes to focus on. A user archetype often correlates to a user segment, and by focusing on solving the needs for one archetype, you can in theory unlock adoption for the entire segment. If you can focus on which users to target, then you can focus on which features to build.

from Dilbert

So what’s a good way to frame these UX concepts?

Here’s what I’ve tried that’s worked. It might not work for everyone, and might not even be the “right” way to do it, but it’s what I found to make the most sense. I anchor on just a few terms and suggest we all use the same terms if possible, to avoid confusion.

First, let’s break these into two categories: USER-related UX concepts, and DESIGN-related UX concepts.

The user-related category is about understanding and aligning on the user and their needs.

The design-related category is about the actual UI/UX design that attempts to solve the user needs. Note: I’ll cover this in another post.

Key user-related UX concepts:

1. The use case (aka “job”, “goal”)
   This is the high-level “task” they’re trying to do. Imagine a friend fiddling with a product on their computer, and you asked them “hey what are you up to?” — what they’d respond with is likely the “use case.” The use case takes the form of statements like “trying to find a bday gift for mom”, or “trying out this ChatGPT thing”, or “figuring out whether we should move over to a new HR system”, or “making a project plan”, or “working on this new shopping cart feature”, etc. They’re often high-level, usually tool/solution-agnostic, and easy to understand without a ton of expertise. Most importantly, the use case helps you understand what their goal/objective is, and the hope is that this use case will be a good fit for using your product to accomplish that goal. I prefer writing use cases with the type of user in mind, for example: a student needs to write an essay for homework.
2. The user [arche]type (aka “segment”, “category”, “persona”)
   A generalized “category” of users based on common behaviors, traits, and needs. For example: students, parents, knowledge workers, programmers, first-time users, small business owners, etc. Purists will point out that user archetypes and personas are not the same, which is true. Developing a persona is essentially like creating a profile of a person who represents your target users, but for simplicity, I think it can be merged into one concept and many leaders mis-use the term anyway. Having a clear idea of what type(s) of users you’re building for allows your team to focus the design, reduce scope by addressing common requirements, and prioritize features respectively.
3. The user journey (aka “CUJ”, “path”, “flow”)
   A detailed step-by-step “flow” that a user goes through in your product. Understanding the detailed flow is crucial to understanding areas of friction and confusion. I loved this analogy I learned over the years, which compares a product to a city: imagine the different pages and components in your app are like buildings and parks in the city, and there are various roads that let users navigate between these areas. Your users will travel all across the city in different paths, but perhaps the vast majority mostly travel between building A and building B. This is what you’d consider a “critical/common user journey”, and it’s where you’d want to focus your time on ensuring the roads are smooth and signs are intuitive. Rather than prioritize fixing all the biggest potholes in your city, try to fix all the ones that are on the most important journeys.

These are the top three user-related concepts I’d get the team to align on. Concepts like “user stories” are often bundled in with more detailed user requirements and agile methodology, and how you define those can be a post for another day. :)

by Gary Varvel | Copyright 2018 Creators Syndicate

Something to watch out for is what level people write their use cases. Some people will write them at such a detailed level that they start looking more like functional requirements, rather than actual use cases. Other times, people write overly detailed use cases that seem too niche to be the main use for the product (unless you’re targeting that narrow of a use case).

NOT a use case: user needs to check out and pay for the items in their cart.
Unlikely any user would answer the question “why are you using this product” with “I want to check out and pay for items in my cart.”

Use case (but niche?): homeowner wants to buy new lights for their home.
Maybe appropriate if your product/service is focused on lighting for homes or most of your customers/revenue actually comes from this segment/use case.

Use case: a small business owner wants to sell their goods online.
This could be a good use case to focus around for products like Shopify, Etsy, and even certain services like Stripe, although Stripe would probably focus more on developers and tech startups.

Figuring out what level of detail to define these concepts is more an art than a science. The reality is, they can sort of infinitely nest, like when a kid keeps asking “why?” too many times. Sometimes in big tech, you’re working on one small feature rather than a whole product, and it’s easy for the “user goals/use cases” to be narrowly focused on a specific need.

Try not fall into that trap. When this happens, try to bring the team back to anchoring on use cases that are solution/tool-agnostic. This will help you think outside the box for solving user needs.

You know that saying — “the customer doesn’t need a 1/2 inch drill, they need a 1/2 inch hole” — it’s still missing the point. What the customer really wants is to put up some of her paintings.

from xkcd

Here’s a concrete example from a product I once worked on: we were designing a feature to allow customer IT administrators to turn off access to certain apps for employees in their domain. Pretty technical, pretty specific. At the time, our “use cases” looked like this:

• As an IT administrator, I want to identify 3P apps our employees are using.
• As an IT administrator, I want to turn off access to a specific app… etc.

In hindsight, these were probably too detailed, and almost like user stories or user requirements, than use cases. Also, they leaned a bit too much on how we envisioned implementing the solution. If I were to rewrite the UX concepts as we’ve described them above for this scenario —

1. Use case (aka job): an IT administrator needs to manage employee access to unvetted software.
2. User archetype (aka segment): IT administrators at large enterprise companies who are responsible for ensuring software employees use are configured properly to avoid leaking proprietary information.
3. User journey today: if you asked an IT administrator to try to turn off access to ChatGPT, they would most likely go through this flow —
   a) open the Google admin console
   b) click on the Apps navigation item, look around
   c) get confused about what would let them block this app
   d) search in the search bar in the admin panel, but no identifiable result
   e) search on Google, find the help center article
   f) click on link in the article, jump into admin panel, finally turn it off
   [note: this is probably improved by now]
4. User stories for our new feature:
   - IT admin can identify 3P apps our employees are using
   - IT admin can turn off access to a specific 3P app
   - IT admin can find the audit of 3P apps from the search bar
   - etc.

By thinking about the overall use case & goal, you can think of alternative solutions that may have made more sense. In fact, for a large enterprise company, it’s almost preferable that 3P apps be “blocked by default” and instead allowlist apps one by one — this would’ve probably been a more effective solution for our customers.

That’s what’s worked best for me, but of course, what will work for you will depend on your team culture and norms. Regardless of what terms you use, just remember that the important part is aligning on what you need to know about your users to solve for their needs.