As product designers and developers, we solve problems that our users encounter. Our work, hopefully, provides solutions to tasks that either take users too long to complete, confuse them or didn’t exist in the first place. But how do we determine what solutions or features are needed?
Beyond data and interviewing users, we need a reason to build a feature. More specifically, we need guidelines. These guidelines should help us determine the best flow for a new solution. At Unrelated, these guidelines come in the form of user personas.
At the start of each project, we work with our clients and their teams to figure out the different types of individuals who might use their product or application. This list may be short if it’s a niche product. Or it could feel endless if the product is not geared toward a specific user group. And while we don’t spend days creating personas for each individual on our list, we do, however, create a list large enough to cover the bulk of our heavy users.
But what is a user persona and what do we need to consider when creating one for a product?
A user persona is a representation of a subset of users of a product. It is meant to provide a brief understanding of what problems this group faces. What influences them to make certain decisions. And how the product can best fit into this groups day-to-day life.
Where do we start and how do we build usable personas?
Group Common Users
Our first task is to study our current data. At this point, we should be able to come up with a few different types of users based on prior interviews and analytics. We can divide users in to subsets who share similar characteristics. For example, we might have a set of users who primarily use our product on their mobile phones, they fall within the same age range and expressed issues with a similar feature set.
It’s important to note that not all users in a group will be exactly the same. And that’s OK. The goal of a user persona is to group similar users. Find individuals who face similar problems, but also have a similar job title or perform similar duties on a day-to-day basis. This way when we consider whether feature A or feature B is best, we can rely on our users to provide the correct answer.
Again, depending on the size of our application, the number of user groups may vary. We have had as few as five and as many as 100. Just remember, you can always add new users as you discover them.
Develop A Back Story
Next, we need to determine what makes this user perform certain actions or what might be the cause of their frustration. We want to understand who this user is as a person and stop looking at them as just another data point.
Start by answering these questions:
- What is this user’s name?
- How old are they?
- What do they do during their daily routine?
- What challenges, outside of the product, do they face?
- Do they use technology often or not so much?
- Would they consider themselves early adopters of products?
These are all important questions to ask when developing a user’s back story. If a user primarily uses your application while commuting on a train to work each day, it’s important that you consider this outside factor before building a feature that takes a while to load, or causes them to incur extra data charges.
Additionally, as designers we want to know how comfortable they are with technology and or web products. Knowing details such as these, help us to determine what steps we need to take to guarantee the software is foolproof.
Determine Key Challenges
Once we know what influences our user to make certain decisions, we can start to create a list of challenges they face in regards to the application.
Our goal in building this list is to determine possible solutions later on. To narrow our design focus and solve problems that exist rather than introduce new ones. It’s easy to lose track of what a user needs during the design phase. But if we continue to refer back to our guidelines, we can limit the number of extra or unnecessary features.
Additionally, this set of challenges will help us to determine the best implementation strategy. Does a user need more hand holding or do they need us to get out of their way?
Both require a different design strategy and both solve for two different problems. We might find that we need both strategies. One set of users wants more help understanding the ins and outs of the application, while the other learns best by trial and error.
Determine Possible Solutions
Lastly, we can start to form a set of possible solutions to our user’s problems. This set of solutions doesn’t have to come in the form of user stories or features just yet. It can be a simple set of ideas or suggestions. Just concepts we can continue to refer back to during the design and development of the product.
While these solutions don’t need to be fleshed out features, they should be build-able. After all, we don’t want to propose ideas we can never execute.
In short, when determining what a user needs, we need to focus on that user. We as designers and developers need to understand who they are, what influences their daily life and how we can best solve for their specific challenges.
User personas provide us with guidelines when building new features or fixing aspects of our product that might be broken. Any time you are considering building a new feature, make sure to check your user personas. If it doesn’t solve a user’s problem, it’s not worth building.