Persona definition: A persona is a fictional but realistic description of a
typical or target user of the product. A persona is an archetype instead of an actual living human, but
personas should be described as real people.
A key to BrainGu's product designs is that we design products around people rather than teach
people how to use our products. To do so, we understand our customers - their behaviors, attitudes, needs,
and goals. We get to know the end-users/operators to create a design that will satisfy their needs.
Personas allow us to understand our primary users and create a product that works for them.
Scenario-based Design: A scenario describes a specific target user trying to
achieve a particular goal or perform a specific task in one particular context.
Simply put: Scenario = user + task + context
Two pitfalls designers typically fall into are taking a feature-based or task-based approach
to design. In short, the feature-based design's problem is that users don't understand features singularly
or think of them like the team building them. The user is trying to accomplish a task, reach a goal, and a
feature without context in the whole flow doesn't make sense most of the time. Features aren't in isolation;
they almost always have an entry and exit point.
The task-based design recognizes the problem with feature-based design since the user is
trying to complete a task. However, the task-based design does not always take into account users, their
goals, or context.
Take the example of changing a light. That's a simple task, and assumptions about the user and
task can be made. It is almost guaranteed that you thought of screwing a lightbulb into a socket as you read
that task. That's the assumption. Let's step back a minute and look at the context and why the user wants to
change the light. In this context, the task said light, not a lightbulb. In this example, the user is
remodeling their kitchen and wants to change the light fixture. It is essential to understand the context of
the task and the actual goal (the why) of the user. If we had gone ahead with our assumptions and designed
and developed a feature that changed a lightbulb, that would be entirely useless for our users and waste
resources.
The light example above illustrates a few crucial areas of UX design.
- You are not the user. (more on this later)
- Users don't say what they want. (In the example, the user just said "light" but in context meant light
fixture)
- Don't go with your initial thought and instead dive down into the why. Keep trying to understand the why
the user is not saying.
In a scenario-based design process with personas, all of these issues would have been caught
and avoided. We know the user, their goals/their why, who they are, and what they are doing. We see the
context of what they are trying to do. We know the task they are trying to complete. Together, we create a
scenario flow or interaction model that strings all the necessary pieces together to create an experience
that delights the user.
You are not the user.
Understanding that you are not the user is the key to giving and getting feedback to create an
impactful user experience. When you assume to be the user, you will unconsciously insert your assumptions
and biases into the solutions you create. The biggest one being you know the product like the back of your
hand. You helped build it. A user won't have an understanding even close to what you possess. Something
seemingly trivial and effortless to you could trip up a user and cause a lost sale/user/mission. Always try
to look at things with "fresh eyes" and from a new user's perspective.
Best Practices
While making assumptions regarding specific users and their needs can lead you down the wrong
path. Assumptions based on best practices and industry standards are often the correct thing to rely on as
they are tried and true.
The key is to combine industry-standard best practices with a scenario-based approach.
Combining tried and tested methods with a use-case-specific context is the key to a superior user
experience.