How to Breathe Life Into Personas

Written by: Barnabas Nagy

Personas are essential when you are working on a project and don’t know the target audience very well. For instance, not every designer has experience in fashion or banking. Creating a model of your target audience may help you and your stakeholders feel significantly more empathy for those people.

Personas can also help you get out of the mindset of thinking about users abstractly. “User” sounds like it does not refer to real people who have desires, concerns, past experiences. When real people use your app or website, they are there to reach their goals: to buy something, to research, to register for something they need, or to get information. How can we design something helpful for them without feeling empathy?

Thinking about users as “just users” is just plain harmful. Empathy for the real people who use the website or app, on the other hand, is essential. If we have empathy, we will not design something that would make these people feel trapped, cheated, or confused.

Humane personas

Using  personas enables us to feel more empathy by creating a life-like humans we want to make happy. The problem is, most personas are not designed to make the reader care about the person. Most of them look like dossiers: name, occupation, age, sex, some descriptive text, and a Google image search photo.  Why would anyone care about a persona that looks like a PowerPoint slide?

A usual, dossier-like persona.
A usual, dossier-like persona. Via Data Driven Personas

We should also always keep in mind that stakeholders are also “users.” We have to make our deliverables real easy for them to understand.

I wondered: What would make my personas more humane? The bullet-point personas really made me feel ashamed as a designer. I was sure that these deliverables would not reach their desired goal which is to put me and my stakeholders into the mind of the people who use their web site. So why do them that way?

Making life-like personas

I started to look for a solution. As a good UX designer should,  I did some Google searching, sketched, and then fleshed it out. I went through many versions until I found one I was happy with, and response from project teams seems to be positive. I think these deliverables can be developed further, though. I call the result the Humane Speech Bubble Persona.

Where a traditional persona would list attributes in bullet points, I had the persona tell his own story, in speech bubbles.

The author's proposed humanized speech bubble persona.
What would make my personas human? I made some concepts, researched, tested, and refined again.

The key bubble is the worldview. It represents  the central attribute that tells us who our person is, summarizing the person in a single bubble.

Worldview speech bubble
Worldview speech bubble

Then I added bubbles with attributes like “motivation,” “looking for…,” and “desired experience,“ which help us focus on the goals of the person. Adding the opposite of these, such as “demotivation,” “not looking for,” and “last experience,” is also beneficial. Finally, I added the persona’s questions. This helps us focus on the needs and concerns of the user.

The unsolicited insight that comes from an overheard conversation means you get useful information that wasn’t meant for you. The bubbles recreate that experience for the users of the persona.

Presenting text attributes in speech bubbles make the persona humane as well. Speech bubbles show the person speaking, in easy-to-follow sound bites. This makes the persona scannable and adds some fun to the deliverable.

Finally, to make the persona more scannable and relatable, I added pictures from the persona’s imaginary life to help us visualize the persona as a human being. The pictures represent both current as well as desired objects that the persona cares about. As well, when personas are hanging on a far-off wall, they provide an easy way to remember who this persona is, and what he really cares about. No reading necessary!

Conclusion

Making personas humane not only benefits you, the UX designer, but your stakeholders as well. Adding flavor to deliverables does not take a lot of effort, so why not do it? A humane persona will help us feel empathy for the real people who will use our designs and will help stakeholders accept concepts readily.  Try out the Humane Speech Bubble Persona, and let me know what you think!

For some more insight how I made this persona template, read my article on my website.

The General Stakeholder Interview

Written by: Kim Goodwin

This is an excerpt from from Kim Goodwin’s excellent Designing for the Digital Age. It is quite long, so we’ve broken it into several sections. Many thanks to Ms. Goodwin and Wiley for allowing us to share this with our readers.

Topics applicable to most stakeholders

Try to keep the interview conversational rather than reading from a list of questions, but consider writing a list of topics on the inside cover of your notebook where you can glance at them when you get stuck. These are some questions applicable to most stakeholders; topics specific to particular stakeholder roles follow. Note that it’s as important for in-house teams to ask most of these questions as it is for consultants; you may know one answer, but do you know this particular stakeholder’s answer?

What’s your role with respect to this product?

If you’re a consultant, the reason for this question is obvious, but even if you’re an insider, you or one of your teammates may not understand someone’s role as well as you think you do. It’s also an easy, non-threatening way to get the conversation started.

What did you do before this?

Answers to this question will tell you whether this person has some unexpected expertise to share and will give you some clues about how this person might view the world; a product manager who has a background in the domain but not in product management won’t have the same concerns as an experienced product manager who doesn’t know the industry.

What is this product or service supposed to be?

It’s interesting to see what aspects of the product or service each person emphasizes. One of the key things to look for in the response is any hint of functionality no one has mentioned before, since this is important not only in helping the product team achieve consensus, but also in keeping the project timeline within bounds. Some stakeholders will answer you with an impenetrable wall of buzzwords: “It’s a distributed, service-model three-tier architecture that will leverage existing technology,” and so forth. In such cases, ask them to break down what that means by asking how they would explain what it does for the average user.

You’ll also want to ask the reverse of this question: What is the product not meant to be? Some stakeholders have difficulty being realistic about what they can accomplish, so it’s important to build consensus about boundaries as well as goals.

Expect a wide range of answers. With respect to software, this diversity is usually due to what people think will be in the first (or next) version versus what will be in later versions. You may be able to clear things up by asking each interviewee to compare the immediate release to what the product will eventually become.

Who is this product for?

Although the marketing or product management people have the most informative answers to this question, the range of answers from other stakeholders can highlight issues your research will need to address. It’s also important to know what assumptions there are about users so you can test them and see if they’re true.

There may be variation due to a poor understanding of who the users are. On a recent project, for example, one stakeholder told us the product was going to be so indispensable that executive users would want to log in remotely from the airport, while another told us executives would only consume monthly reports generated by subordinates. Both agreed that executives were the targets for the information, but they had differing opinions about whether executives would see the information as so mission-critical that it had to be accessible at all times. This sort of variation doesn’t mean the organization is dysfunctional; it just means people need better user data to clarify things.

When is the version we’re designing going to be released?

It’s normal to hear optimism from the marketing and sales people and pessimism from the engineers, but if the answers to this question differ by more than a month or so, mention it to your project owner. Also, don’t forget to ask why the timeline is what it is. Sometimes there’s a serious mismatch between goals and timeline—stakeholders may say this project is going to be the basis for all of their products in the next ten years, but they want to launch it in just a couple of months. Don’t just let this slide; it will bite you later. Instead, point out the apparent contradiction and ask about it. “You’ve said the product has to be all things to all people. You’ve also said it has to ship by the end of this year. Those two things are potentially conflicting. Which is more important and why?” A reasonable executive stakeholder will clarify what the priorities are.

What worries you about this project? What’s the worst thing that could happen?

This is a good topic for the later part of the interview, after the stakeholder has relaxed a bit. Sometimes the anxieties will be things you can help with, such as worries that the product won’t have the right functionality. In other cases, the worries may point out organizational weaknesses you need to be aware of. While engineers always worry that there won’t be enough time to build the product the way they’d like to (and they’re always right), listen for truly unrealistic expectations. You may hear concerns beyond the usual level of grumbling that one part of the company is not up to doing what it needs to. If you hear that the marketing team is largely inexperienced in the product development world, you may be able to help by educating as you go. If it appears the engineering team is less capable than most, you’ll either need to suggest some additional engineering resources if you’re in a position to do so, or you’ll need to be fairly conservative in your design.

What should this project accomplish for the business?

In a highly functional company, most stakeholders can answer this question to some extent, but it’s amazing how often a senior executive is the only one who can do so. When this happens, you can help the organization by disseminating the business goals during the design process.

If stakeholders struggle with articulating this, try asking more specific questions: How will this product generate revenue? How will this product save money? How should this product affect the company’s brand and position in the marketplace? What should the company be able to accomplish with the product that it hasn’t before?

How will you, personally, define success for this project?

Many stakeholders will simply reiterate the business goal, or they’ll say the thing they’re most worried about won’t happen. Some will give you insight into other things that worry them or what will get them excited about the design. You might hear things like, “If we just avoid this problem we’ve had before, I’ll be happy,” or “Other people in the company will finally see the value my team can offer.” Understanding these issues is essential in building support for the design.

Is there anyone you think we need to speak with who isn’t on our list? Who are those people?

Ask this one toward the end of the interview. Check in with the project owner later to see if discussion with any of the people mentioned is really a good idea.

How would you like to be involved in the rest of the project, and what’s the best way to reach you?

This is a good one to save for last. It’s an especially good opportunity to make sure the senior people stay involved at key decision points. If you have a middle manager who’s reluctant to involve senior management, this gives you room to say “The CEO specifically said she wanted to be involved in that meeting.”

See also

Excerpted with permission from the publisher, Wiley, from Designing for the Digital Age: How to Create Human-Centered Products and Services by Kim Goodwin. Copyright (c) 2009.

The Marketing Stakeholder Interview

Written by: Kim Goodwin

This is an excerpt from from Kim Goodwin’s excellent Designing for the Digital Age. It is quite long, so we’ve broken it into several sections. Many thanks to Ms. Goodwin and Wiley for allowing us to share this with our readers.

Marketing stakeholders

Marketing stakeholders (such as marketing executives and most product managers) are usually responsible for promoting the company’s brand, identifying new market opportunities and products that could address them, or both. Most marketing people will immediately view designers as allies who will promote a customer-centric point of view. Some view designers as threatening rather than helpful, though; when you talk about doing research and driving some of the requirements, you may be treading on territory they view as theirs. If they’ve just spent hundreds of thousands of dollars on market research that doesn’t provide the answers you need, you also have the potential to make them look bad. Talk about how the design team’s work is in addition to theirs, not instead of it, and describe how you can help communicate their vision to the engineering team (which is often a point of frustration).

There are a number of questions the marketing people are best equipped to answer; some examples follow. The more brand-focused questions are things a visual or industrial designer will particularly want to know, though the answers can prove useful to the whole team. These questions are in no particular order; they generally fall somewhere in the middle of the questions for all stakeholders listed above.

Who are your customers and users today, and how do you want that to be different in five years?

It’s essential to see where the marketing team wants to take the product or the brand, especially if it involves a change in direction. This will affect how you plan your user and customer interviews, since you won’t want to limit your research to existing customers if the idea is to break into a new industry vertical. (Note that if you’re a consultant planning the research before the project kickoff, the project lead should have asked this question at that time.)

Sometimes the vision is so ambitious that it sounds impossible. For example, the interviewee might paint a very broad picture about handling all types of business communication. This could turn into a monstrous product that attempts to replace phones, email, instant messaging, online conferencing, and more. Try asking what business they definitely don’t want to be in.

Ask for clear timelines. Sometimes, the engineers think the marketers are unrealistic because they talk in very grandiose terms, but don’t always clarify when they want the vision to be fully realized. Often, the marketing folks are talking about a five-year vision and don’t expect the whole thing to be accomplished in the first release a year from now. This is one of many opportunities to help improve communication between groups.

How does this product fit into the overall product strategy?

If the product is part of a bigger suite of related offerings, you need to know what role it plays in that greater plan. For example, if you’re designing the entry-level product in a set and the marketing team envisions getting people to upgrade as their needs change, you know you’ll need to focus on giving that product limited but excellent capabilities and a design that can scale up. If they’re envisioning the product as some sort of platform for future growth, you’ll need some idea what those possible directions are if you’re going to have any chance of anticipating them in the design.

Who are the biggest competitors and what worries you about them? How do you expect to differentiate this product?

While it’s seldom helpful to spend a lot of time on competitive research unless you want to build a “me too” product, you at least need to know what else is out there. Ideally, you will get to interview and observe people using these competitive systems, too. Some people see the competition as the other companies trying to sell similar products, but be sure to discuss the hidden competition, which might even be some combination of paper, telephones, and face-to-face communication.

What three or four qualities do you want people to attribute to your company and your product?

In an established company, good marketing people have a clear answer to this sort of question, and that answer guides everything they do. This answer is essential when your mandate includes developing a unique design language for hardware or software. It can be useful for interaction design, as well; when you are presenting a particular bit of functionality or behavior, describing how it supports the brand values can be a powerful argument. Mind you, this argument works best with very brand-driven organizations, such as consumer product and service companies—in a company that thinks the brand is just the logo, you won’t have much luck with this approach.

In organizations that are less sophisticated about brand, people may struggle with this question. This is where analogies can come in handy. Some people try to get at this information by asking “If your company were a car, what kind of car would it be?” It can sound less silly and be more productive to frame the question in human terms, such as “If your product were a person, how would you describe its qualities?” You might also ask for examples of other brands or products they think embody each attribute, and why.

Note that most larger companies separate product marketing and corporate marketing; the product marketing people may be focused more on understanding their particular segments, leaving the brand issues to the corporate people. If that’s the case, ask this question of the corporate team.

What is the current state of the identity, and could we have a copy of the style guide (if there is one) and examples of it applied to materials?

This question is essential for consultants, but in-house teams probably have this information already. Like the previous question, this is more geared toward corporate marketing than product marketing. In a company that’s sophisticated about marketing, you’ll see consistent visual themes across print and online collateral as well as the visual and industrial design of products; you can look at any Apple product or marketing piece from ten feet away and immediately see that it’s from Apple, for example.

In less sophisticated companies, you may see one style applied to print, another to the Web site, and still another applied to the products (or even worse, no consistent style across any of them). You might also find that the company has a style guide geared almost entirely toward print rather than pixels or hardware. If you’re lucky, the style guide will at least take into account the visual design differences between print and Web design. It’s a rare company, though, that has much of a style guide suited to digital product design, so visual and industrial designers must often interpret the spirit of those guidelines across platforms.

When the style guide doesn’t seem appropriate to what you’re designing, it’s critical to get access to a senior brand stakeholder; a less-senior marketing person dedicated to a product or group often enforces the guidelines without seeing where they should be bent. For example, when my team was designing a phone for one company, the relatively junior marketing person assigned to the product told us it absolutely had to be a certain color and had to contain certain style elements common to the company’s other phones, even though our mandate was total reinvention of the product family. When we were eventually able to get a senior marketing executive involved, he immediately understood why the parameters needed to be varied, so long as the design still conveyed the brand attributes in other ways. This is certainly a tricky situation when you’re an in-house designer; your best option might be to let it go for now, but later try a style treatment that follows the guidelines and one that captures the spirit of the brand even if it breaks the guidelines.

 

See also

Excerpted with permission from the publisher, Wiley, from Designing for the Digital Age: How to Create Human-Centered Products and Services by Kim Goodwin. Copyright (c) 2009.

The Engineering Stakeholder Interview

Written by: Kim Goodwin

This is an excerpt from from Kim Goodwin’s excellent Designing for the Digital Age. It is quite long, so we’ve broken it into several sections. Many thanks to Ms. Goodwin and Wiley for allowing us to share this with our readers.

Engineering stakeholders

Try to speak with engineering management as well as the design engineer(s), if such a role exists; it’s seldom a good idea to involve the entire engineering team at this point. If there are no design engineers, a system architect and GUI lead may be the best option for software expertise. When hardware is required, be sure to involve the electrical and mechanical engineering leads, as well as anyone responsible for manufacturing.

Programmers and engineers may initially be wary of designers. They may have worked with people who called themselves designers, but who proposed horrendously difficult solutions that seemed “cool.” Programmers may feel that designers are stepping on their toes, since some currently design screens themselves. You might also encounter mechanical engineers who view industrial designers as stylists rather than problem-solvers. However, any technical group’s reluctance to give up control over design is usually due to the fact that so far, they’ve been the most competent to do it. It sometimes takes a while, but once they see that good designers can actually do a better job than they can, most engineers are delighted to let go of the design.

The focus and length of engineering interviews differs quite a bit between a new product and a revision of an existing one; in the first case, there is more room for the design to drive the technology, while in the second, the capabilities of the existing technology, when combined with the project budget and timeline, may introduce significant design limitations.

However, don’t ask what you “can” and “can’t” do because in a healthy organization, that will be a business decision and not a technical one—although physics really does limit what you can do with hardware, there’s very little you can’t do with software given sufficient time and budget. Instead, ask what kinds of things would be hard to do and why.

Engineers also tend to relax more when you say you’re not trying to get them to commit to anything at this point, but simply to get a sense of what they already expect may be challenging. The following questions are helpful on most projects, though most projects call for additional, unique questions, too:

What technology decisions have already been made, and what’s driving them?

In the case of a new product, the technology decisions would ideally happen once the design started to take shape, but this is not always the case. When an existing product is being reworked, the technology train may have left the station a long time ago; the software development platform or perhaps several of the electrical components have already been identified. Even decisions that have already been made are sometimes unmade later, though, if the reasons are compelling enough.

For example, one client told us they had already sunk millions of dollars into a particular system as the basis of their development. However, our later research showed that users had needs this system simply couldn’t address. The company’s executives weren’t excited to see those millions go down the drain, but they were glad they’d learned about the issues before throwing away the additional millions they’d planned to spend.

How large is the engineering team assigned to the project, and what are their skills?

This is ideally determined by what the design requires, but in practice there may be a fixed number of people and days allotted to the work. As with technology decisions, though, designers often better serve the business by questioning such parameters than by accepting them. The most important thing to look for is a mismatch between the expectations for the product and the number and skills of the engineers. If you’re designing a big enterprise product and there are only two developers assigned, you’re going to run into trouble.

Likewise, if the software or hardware team has very limited skills, you may need to scale back your design ambitions, though it’s better to find a tactful way to encourage stakeholders to bring in the appropriate expertise if you can. Lack of skilled programmers was an enormous problem at the height of the dot-com boom, when companies hired anyone who’d taken an HTML class and called them software developers; this seems to be less of a problem during “bust” cycles but is likely to crop up any time there is a shortage of talent. I’ve seen similar issues in organizations where mechanical engineers are only accustomed to doing plastic casings and not designing moving parts.

You may wonder how a designer can assess the skills of an engineer. In truth, most designers can’t. However, if you have enough experience working with skilled people and less-skilled people, you’ll learn that certain attitudes and behaviors tend to indicate skill level. If you hear engineers saying that something is impossibly hard when half of your last ten project teams were able to build it, you might start to wonder.

It’s also a bad sign when programmers are anxious about designs they can’t assemble from off-the-shelf libraries; it could mean the timelines are ridiculously short or they’ve seen truly absurd solutions proposed, but sometimes it means they simply don’t know how to build it. The most skilled programmers and engineers get excited about technical challenges, as long as the challenge is there for a good reason and the timeline is reasonably sane.

Could you draw a diagram and tell me in lay terms how the existing system works?

Sometimes this is important information; sometimes it isn’t. You probably won’t know until later whether you need it. Certain system limitations, such as client-side data that’s not always synchronized or response times that are very slow, can make interaction design more challenging. The same is true of hardware systems; if it won’t be possible to change certain kinds of boards or other components, you may not have much room to change the form factor. Just be sure to take this information as food for thought, rather than as something carved in stone.

Note that there’s a reason to ask for an explanation in both visual and lay terms, as shown in Figure 5.2, even if you think you’re well versed in techno-speak—it encourages clarity, and can be another indication of an engineer’s skill level.

Figure 5.2 Example of an engineer’s system diagram.
Figure 5.2 Example of an engineer’s system diagram.

See also:

Excerpted with permission from the publisher, Wiley, from Designing for the Digital Age: How to Create Human-Centered Products and Services by Kim Goodwin. Copyright (c) 2009.