User Personas
Podcast: Play in new window | Download (55.0MB) | Embed
Subscribe: Apple Podcasts | Spotify | Email | RSS | More
According to Wikipedia, a User Persona is a fictional character created to represent a user type that might use a site, brand, or product in a similar way. These user types may roughly represent market segments to your marketing department and might represent system roles to your developers, designers, and IT personnel. In short, a user persona is a collection of the goals, limitations, perspectives, and desires of a segment of a product’s userbase. While you are probably already informally thinking of your users in this way, there are many benefits to formally defining your user personas.
Over time, regardless of the development team, certain processes are almost constant. Members are added to the team, team members go away (including into other departments and into management), testing and documentation has to take place, and everyone involved has to have meaningful discussions about user expectations while keeping miscommunication and misunderstanding to a minimum.
User personas are very useful for organizations that are developing software. Not only do they give clarity to how an organization interacts with its users, but they can often drive design decisions by shedding light on user expectations, capabilities, and preferences. You may find that your organization has to support a number of user personas with a wide range of life experiences and expectations. Software is easier to develop, document, market, and support if you know this up front.
Episode Breakdown
Problems User Personas are supposed to solve.
Mismatched vocabulary between departments
A “customer” for accounting is not the same as a “customer” for support. The expectations of these different categories of users need to be discussed as part of a larger company vision.
Improper use of technical terms for the audience
Your development team should not be deciding how the organization refers to things, unless your customers are developers. In addition to weird terms that aren’t universal (using “service” to describe a long running process), development terms may clash with marketing in a bad way. Additionally, you may need to “dumb down” the terms you use when describing technical terms or avoid getting into details entirely for certain types of users.
Creation of features that the market is not interested in
Your development team should generally not be the ones coming up with new feature ideas. Most developers are terrible at this, particularly for non-developer markets. Instead, experts in the market who have an understanding of a particular user persona should be the ones coming up with features for that persona. Personas are also useful for determining whether a paid version of a feature is even viable. For instance, if a feature can be done with excel and your version costs money, you’ll have a hard time selling it to an audience of accountants, but you might well be able to sell to elementary education teachers.
Improper prioritization of bug fixes and features
User personas are useful for having a good understanding of what problems a bug actually causes for a user. For example, if your users are software developers, something that causes display resolution issues might not be a big deal, simply because the developers can work around it easily. On the other hand, if your users are wait staff in a busy restaurant, then such a bug is huge problem.
Bad support scripts
Your support team probably has a set of approaches for responding to bugs. Some of those responses may be inappropriate for your users. For instance, if your users are IT professionals, asking whether they’ve “turned the machine off and back on again” will come across as insulting.
Problems User Personas can help solve.
Recurring support problems.
You may notice that certain segments of your user base have problems with certain features. This may point to problems in training or onboarding. It might also mean that you simply need to hide that feature from that kind of user.
User onboarding difficulties
When training new users to use the system, a lot of problems with inaccurate (or non-existent) user personas will show up during onboarding. You may need to change the way you do training to handle this.
Developer gold-plating
Developers love over-architecting systems. With a clear set of user personas in hand, you may have a better case for keeping them from doing so. For instance, your users may not want something with a ton of options, even if the developer thinks it’s a good idea. Users can be turned off by too many options.
Bad marketing copy
Your marketing copy has to be appropriate for the audience you are trying to reach. User personas will help you figure that out. This also helps when marketing is trying to understand the likely objections that a potential buyer might have.
Security issues
The sophistication of your users can also determine how you mitigate security threats. Understanding the environment in which your software runs will also help you to think about security issues. A home PC running at someone’s kitchen table has a very different set of security threats than a laptop running in a secure environment at a bank.
What a persona should include
Demographics
This doesn’t necessarily mean that demographics necessarily matter, but these are especially handy to have for marketing and support purposes. This can also tell you when internationalizing your application is worth doing from a business perspective.
Education level
You need to know how sophisticated your users are and tailor your software for that. This is not necessarily an insult to people – your goal as a developer should be to make people more efficient regardless of their educational level. However, to do so, you have to take it into account.
Industry experience
You also need to know how much experience an average user has in the industry. Every industry has its own terminology for various things. A user persona can help you include the right information for a user, without confusing them.
Technical capability
You definitely should know how comfortable your users are with a computer. This makes the entire process easier. One of the reasons a lot of non-expert people shy away from linux is the frequency with which linux tutorials rely on the command-line. You also don’t want to insult your users or give them directions for things that they can’t complete on their machine.
Goals
You need to know WHY your software is being used by this particular cohort. You need to know WHAT they expect to get out of it. This helps because you can design your software to get them to the desired end state as quickly as possible.
Frustrations
You should have some idea of the things that most frustrate certain types of users. Not only will this make it easier for you to avoid such frustration in your own software, but it also helps your marketing team when wording ad copy to go after your competitor’s customer base.
Motivation
Users have a wide variety of things that motivate them. For instance, gamification can often help in certain contexts, with certain users, but can make your application seem like a toy to others. You need to figure out what drives users to use your application and do more of that.
Attitude
Your users (or their industry) may have certain attitudes that can impact software design and support. For instance, it can be difficult to pursuade software developers to pay for software, simply because of expectations from open source, or because they can build it themselves. You also need to know if your audience is particularly computer-averse. If they are, you need to take extra care not to alienate them with your user interface.
Book Club
Power Talk: Using Language to Build Authority and Influence
In this book Dr. McGinty looks at language and how we use it to influence the world around us. She talks about two types or modes of communication. The first is Language from the Center. This is authoritative and commanding. The other is Language from the Edge which is collaborative and responsive. Both forms of communication have their place and purpose but we have to know when and where to use the right one. Over the next month I’ll be going through this book and bringing highlights of her insights to you.
Tricks of the Trade
Will didn’t write anything.
Sounds a lot like a Grady Booch’s UML Actor… How would you differentiate a User Persona vs an Actor in UML?
Tricks of the Trade:
The major reason for using personas is to avoid miscommunication. When miscommunication occurs, you can utilize the personas to troubleshoot and fix the issue.