As programmers, it's vitally important for us to understand what our code should be doing. This knowledge starts with knowing the people using our product. While we're deep in the code, our mind tends to focus on technical details. But to truly understand the purpose of our work, we need to know how it's relevant to our users. We need ways to keep our users as integral parts of our development process.
User portraits, or personas, are tools that direct our attention to people. These portraits are profiles of the users of our system. Beyond casual discussions, they let us record our impressions and understanding of the people using our product. User portraits let us talk about a specific person, rather than an abstract concept of a user.
If you prefer video, I cover this material in my class How to Write a Great User Story.
This article introduces a way to track the user and covers what types of things we should consider. As a programmer, it's crucial for you to be part of this process, and have access to this information. You'll be making decisions every day that impact the people using your software. This is true whether you're writing the UI, or working on the back-end server. Each choice you make impacts the user in some way. Thus you should understand what the user wants from the product.
Finding out who our user is
A user portrait is a profile of a single target user. There's nothing fancy here. It's like writing a profile page on a blog. It includes a lot of details about who the user is, and what they do. You can pick virtually any tool to write them, like a shared document, or Wiki article, something that allows for collaboration. User portraits are a way of communicating between teams.
You can start your portrait by selecting a photograph of a person. Try a stock photo site, such as pixabay. It's not essential, but it can help visualize who we're talking about. It serves as the basis of the user portrait. The focus on a single person prevents our ideas from running wild -- we're not trying to describe our entire user-base.
This idea of a user portrait is called personas in marketing. I'm shying a bit away from that term though, as it has a lot more depth and research than what might go into a shorter user portrait. They often accumulate classes of users into a single person as well, rather than focusing on representative individuals. Certainly though, if your company already produces personas, don't duplicate that effort.
Along with a picture, a user portrait should include a name, age, and other basic demographics. You want to capture all the relevant details that might influence the use of your product. For example, an application about meeting people would vary depending on whether people live in cities or rural areas. Or the person's job is relevant if your product is targeting a specific job niche. This need only be a short bio, with some key points that define who the person is.
Working from that bio, write a description of what they are currently doing -- in the context of your app. For example, if you want to help writers, you should determine how your user writes presently. What tools are they using, and what processes do they follow.
Contrasting the current state, we add a description of the desired state. That is, what would the user prefer to do differently, or what can your product offer to improve their workflow.
This comparison between the current state and the desired state is the key to addressing the user's needs. It's how we find ways to improve their situation, and address all levels of the UX design Pyramid. It's what gives focus to our development.
Add more portraits to capture more users
Software has a variety of features, and users will be selective of the ones they use. One user portrait will describe only one experience with the system. As you cater to other users, you will create several user portraits.
A collection of user portraits lets you further analyze your system. As a programmer, this lets you design better code. By keeping the high-level desires in mind, you can determine which parts of the system need to be adaptable, and which parts are key features. You can adjust the accessibility of the product based on the abilities, or constraints, of the user.
The prioritization of issues is aided by these user portraits. Quite often we get caught up chasing a stream of issues we mistakingly believe to be vital. It's easy to get trapped in a corner of the system when you spend a lot of time there. By having high-level user portraits to look at, you can always bring yourself back to the primary goals of the project. You can look at each issue form the high level to determine how much impact it would have.
The value of knowing the user
Often we talk informally about users and even carry their image in our heads while programming. I'll admit, this is generally the way I've worked on projects -- there have been few times when I worked with a clearly profiled user. It's unfortunate, since even a tiny amount of effort, writing down those thoughts, gives a big boost.
There are four significant ways that user portraits benefit our development.
Communication: They provide a way for different teams to talk about the users and gain a common understanding of what the product should be doing. The language should be kept at a widely accessible level. Programmers, artists, marketing, and everybody in a development company should understand the user. Success requires strong communication and a shared mindset.
Psychology: By having specific people in the portrait, it shifts our thinking from designing for a fuzzy concept to designing for a real person. This allows us to empathize and place ourselves in the role of the user. It activates all of those neurons we use to deal with relationships and emotions.
Transformation: We often make assumptions about our users. Having several profiles lets us challenge those assumptions. We can use our real-world knowledge, to decide whether our beliefs are valid, or whether we're creating an inconsistent image.
Focus: Keeping the focus of development on the user is perhaps the most substantial benefit. There are so many ways we can get distracted. User portraits are a concrete artifact that we can continually look at. Any time we have doubts, we can look back at our users. These representations direct our effort to a common goal.
An example
This is a basic example I use in my class. I've kept it short to demonstrate that you don't need a lot of detail to start. Getting this basic idea is enough to focus on the user. More information can be added over time.
Martin is 32. He lives in a small apartment in a big city. He's an account manager for an advertising company
What do they do? Martin likes to take his grill and guitar outside on the weekends, near a lake or a river. He loves inviting friends and playing music for them.
What do they want to do? Martin is looking to find fellow musicians who would like to play some music on the weekends casually.
The contrast between their current situation and the new situation is the desire to find fellow musicians. Instead of going out with people he already knows, Martin wants to meet new people. This is the part of his story that is significantly different. He may not be motivated to use an app that only plans his outings unless it also helps him get new people.
Indicating he is an account manager establishes that he has enough technical competence to use a new solution. He'll also be familiar with communicating with new people and organizing events.
Living in a small apartment gives him the impetus to get out on the weekend. It's an important consideration if your product suggests meeting locations. Martin would not be interested in office space to hold his gatherings. He'll need a map that can place locations outside the city. It can influence your choice for how you implement a search feature. There's little value in searching for business names, or possibly even streets, but a visual map selector with nearby roads marked could be useful.
With this minimal biography, we can deduce a lot about how our system should work. It's enough to keep our focus on the user.
Moving on to user stories
User portraits are a relatively high level of detail. Even when short, they provide a focal point for development. Having them around is often enough to keep you thinking about the user while you code. They should become the roots of your user experience design.
These are not static artifacts. As you develop, you will extend and modify them. As you encounter questions in the code, you might need to get answers at the user level. Other teams may point out inconsistencies that need to be fixed. User portraits are living documents.
To go further, you'll want to derive user stories from the portraits. These provide more details on specific user activities. You can check out the Engineering guide to writing correct User Stories. I'll also followup with my own take on these a bit later. For now, the key is to think in the user's perspective. Have empathy with the people in your portraits, and consider requirements from their viewpoint.
Check out my class on How to Write a Great User Story. Learn how to create a user portrait and write a user story. Understanding the user is essential to creating a good product.
Top comments (0)