Making Personas Work for Your Web Site: An Interview with Steve Mulder
Steve Mulder is Principal Consultant in the User Experience group at Molecular, an Internet consulting firm in Boston, and author of the book, The User Is Always Right: A Practical Guide to Creating and Using Personas for the Web. UIE’s Jared M. Spool recently had the chance to talk with Steve after his UIE Virtual Seminar, The User is Always Right: Making Personas Work for Your Web Site, to answer some additional questions about personas.
UIE: Is there specific training design team members need to create personas?
Steve: It’s important for the people responsible for creating the personas to have active listening skills, empathy, and clear communication skills. Ultimately, what design teams need to do is aggregate all of the qualitative or quantitative data into a clearly communicated story. This means that writing and communication skills are also critical. From the point of view of a more tactical skillset, the design team will get better results if they have experience conducting interviews and writing surveys.
If you want to incorporate more quantitative data into creating personas, it’s helpful to find a statistical analyst to assist in cluster analysis for segmentation. But at the very basic level, it’s the softer skills that are most important, such as listening to people and thinking outside existing assumptions.
UIE: How do you determine how a persona will interact with a web site or design when the personality type of a persona is drastically different from the people designing the product?
Steve: The most powerful way of determining how a persona will interact with a design is actually talking to users and not just imagining how a user would interact with the product.
When design teams talk to people that fall into the persona group, they understand the needs of the people represented by the persona, how they use the site, and what they expect from interacting with the design. Then, based on the responses from the user interviews, design teams can determine what this persona would do in certain situations.
The main thing a persona allows designs teams to do is to think outside themselves and really get an understanding of who it is they are designing for. When design teams build a persona, they write a story about a character that represents a whole type of user that is fundamentally different from themselves. They put themselves in the shoes of their users and think about how the persona would interact with a web site or design.
The hardest thing for designers to keep in mind is that they are not designing for themselves. They are designing for the needs of the people who will actually be using the product. Personas are one of the most powerful tools for helping designers keep users in mind.
UIE: When design teams don’t have the time or budget to perform user research, do you recommend teams create personas based on who they believe the users of their web site or design really are?
Steve: I think personas not based on actual user research are absolutely better than no personas at all. A lot of customer and user knowledge already exists in many organizations, and by looking at the sales, marketing, product, customer support, and tech support perspectives, you can bring all these existing bits of knowledge together into personas without talking to any actual end user. If you design teams can’t easily talk with ends users, this is the most effective way to try out personas for the first time.
UIE: The persona artifact, which is the document you end up creating to render the persona live, often acts as a discussion piece to get team members discussing whether or not they think the persona represents the target users correctly or adequately. Are there any other benefits to discussing the persona artifact?
Steve: Personas often act as a consensus-building tool. A while back, I was working on a web search engine, and my team initially thought, “How can we create personas for a whole search engine? Search engines are so general and broad.” Because of this, we actually didn’t use personas. We moved on in the project.
When we got into the phase where we were talking about features like advanced search and customization, we realized we were all thinking very differently about whom we were creating the search engine for. Because we didn’t do personas up-front, we wasted a whole lot of time later on the project because we didn’t come to a consensus early on.
When we realized no one on the team was on the same page, we actually stopped and backed up. We created a fast version of personas just to build consensus internally, and then we resumed where we had left off in terms of basic content features and Information Architecture.We found that as a team, we operated much more efficiently after we backed up and went through the consensus-building exercise.
UIE: Is the persona creation process different if you’re creating a persona for an existing web site or design than if you’re creating a persona for something that is brand new?
Steve: From my experience, the basic process is the same. But the advantage with an existing web site or design is that teams have an existing customer base to talk to. It makes the whole creation process flow a lot better because teams can speak to existing users and tap into their current experience with the site. I’ve found design teams get a bit more data with an existing site than with a brand new product.
However, the basic process of building the personas, such as the research teams perform, the user segments teams create, and the various approaches to dividing those users into personas is really the same for existing or new sites.
UIE: People often play various roles when interacting with a web site or design based on their certain context or purpose. This changes the way teams interpret how a persona will act when teams look at product-related activities. Are personas typically based on job roles and tasks?
Steve: Personas are not usually based on job roles and tasks. I often think about personas as a hat people wear; it’s not necessarily a permanent part of them. For example, if I go to a genealogy site, I may be in researcher mode with plenty of time to delve deep into the web site and perform research. However, if I go to a gardening site, I’m going to be a completely different persona. I’m going to be someone who’s looking for very quick advice, such as a beginner. My persona, and the way I interact with the website, changes completely depending on what domain I’m going into.
Another good example of this is a career site with two very different audiences, the job seeker and the employer. I typically do not recommend only two personas for this situation, with one for the job seeker and one for the employer. This is because not all job seekers are alike, and not all employers are alike. I recommend that you create a set of job seeker personas, and a set of employer personas. It makes sense to tease them apart because the needs of job seekers and employers are so different in various contexts.
UIE: Do you have any tips for successfully convincing organizations to adopt personas into their design process?
Steve: A lot of the success in convincing organizations to adopt personas involves knowing your audience and understanding the organization’s culture.
A few times my team and I didn’t understand how best to introduce personas to our audience and we went with a more “touchy-feely” approach. We used full-sized cardboard cutouts of personas, and role-played how the personas would introduce themselves to the company, what the personas would say, and how the personas would feel. This approach failed when our client wanted to see actual evidence and survey data, not cardbard cutouts.
The experience of socializing personas must be tailored to the organization and its culture. If you work in a very numeric, data-driven culture, the team needs to dive into more of the survey data that underlies the personas they created. If you work in an organization that’s much more driven by the marketing side of the equation, you’ll need to know that stories, pictures, scenarios, drawings, and photo diaries will be much more well received.
How to Win Stakeholders & Influence Decisions program
Gain the power skills you need to grow your influence on critical product decisions.
Get mentored and coached by Jared Spool in a 16-week program.
Learn more about our How to Win Stakeholders & Influence Decisions program today!