top of page

User Personas

Connecting developers to our players.

THE STARTING POINT

THE SETUP

So after communicating the benefits of such a survey with top management, I reached out to Kara Pernice and discussed the purchase and setup for the survey. Our company would answer to the survey, but the NN/g would analyze the results, so it was a thrilling collaboration on our side.

First, I needed to figure out, who our participants should be, from whom I would get appropriate feedback that would be representative to determine nominal-actual comparison of our current status quo in terms of UX.

In the end, I decided to aim for designers, user researchers, creative directors, top management and producers, as I expected those groups to be either directly involved into UX processes or being in the position to enable UX improvement within the company.

THE STARTING POINT

As designers, we know exactly who we are creating our product for, right?

 

No, wrong.

Just because we are human beings that enjoy specific products and our users are human beings who might enjoy the same product does not entitle us, as developers, to assume, we are the users. This is lazy and harmful, for both - the company's revenue and towards our users, for whom we want to provide great services and experiences.

 

I once joined a project, where users were not a topic among developers. When talking to them, they told me about the cliché of male, teenage gamers, who'd play their games, as the main target group. Thus, the surprise could have not be bigger, when I had the chance to meet up with the core-gamers that *actually* turned out to be the unintended main target group. Mainly male, yes. But none of them was below 30, with the oldest one around 64, when I met him. Turned out, he spent 1-2k € on the product every other month. I felt grateful and ashamed at the same time, when learning that. There was somebody like that, who was so dedicated to our product, yet we, as designers, did not address his needs and expectations properly. And unfortunately he was not an exception.

MISSION STATEMENT

This happened many years ago, but it was the very moment, I decided that I would never blindly consult a project, without making sure first that the developers were fully aware of who their core users are.

So I started to brainstorm, which pieces of information would be relevant for a user persona for game developers, since games a very complex products that have multiple stakeholders with different needs. Apart from the development team, there were producers that needed other information to plan iterative processes, community managers that were in touch with the players and last but not least the marketing department that also needed specific information on how to build up effective marketing strategies that would appeal to the right audience.

p5.jpg

FIRST STEPS

After lots of iterations, I finally came up with a concept that would work as a general template for most of our game projects - with some specific adjustments within the overall sections - depending on the project. Since so many aspects had to be covered, a simple persona-sheet with a nice picture and few slogans would not do.

persona_info_2.jpg

After I identified the basic areas that I wanted to include into the persona-template, the next step was to add details and shape the first draft that could be filled with information in the following iterations.

persona_info_draft.jpg

LET'S GET THE DATA!

A user persona is a fictive, specific representation of a target group, based on qualitative and quantitative data. If done well, it helps to assess various problem-statements during production and brings the user closer to the developers.

Every piece of information, such a persona consists of, is based on data - either qualitative or quantitative.

There is no such thing as 'free-styling'

and making up facts.

So in order to get all the necessary data to shape a representative persona, I teamed up with our user research lab and the marketing department. We defined our strategies, on how to get the appropriate data for each section.

Quantitative Methodologies

Survey: We created a survey that covered most of the demographic information and investigated genre- and playing preferences. Usually, such a survey would be sent to around 200-500 participants.

Customer / Market Business Reports: For genre and segmentation, as well as general player habits and preferences, we extracted information from various customer/market research reports, that were done by our company on a regular basis. They targeted the international marked, so the range of insights was very high here.

Qualitative Methodologies

Semi-Structured Interviews: For more sensible data, we scheduled one-on-one semi-structured interviews, usually with around 10-20 participants. Here, we focused on assessing more individual information that helped us to add the 'personal touch' to our persona.

Focus Groups: For specific gameplay-relevant features, we organized focus group with our expert users (who we determined as representative users for our persona) to get their opinion about features and general expectations about the product.

Card Sorting: This step was optional, but helped us to determine categories, terminologies, etc. for specific features or help us to shape a better order or hierarchy within functionalities.

A few documents and data we assessed, such as focus groups evaluation sheets, technology usage overview, user behaviour research report,...

data.png

Apart from that, we also coordinated with Community Management and organized meetups with a group of our target players and developers. Such events were a great way to close the personal gap between designers and players and were perceived as a valuable experience on both sides.

MEET JESSICA

After months of user research, validating surveys, adjusting data and interviewing people, our first persona, 'Jessica', was ready to be introduced to the development team. I did it carefully, presenting each section backed up with the according data to avoid the assumption that any part of the persona might be made up. 

The reception by the team was very positive, they were excited to integrate Jessica into their daily workflow. Since the development team was partially involved into her creation, the acceptance was very high from the very beginning. Jessica immediately became a part of the team and already days later, I could observe team members vividly discuss Jessica's preferences, when debating design features.

Personas_pic.jpg

Apart from Jessica, who was our primary persona, we created a secondary persona and an anti-persona.

CHALLENGES & NEXT STEPS

While the development team embraced Jessica to its fullest, unexpected complications appeared within other departments, especially within marketing. Even though we have been collaborating on the creation of this persona, more parties got involved after her finalization and suddenly marketing and brand expectations clashed with development/user expectations. After many discussions and reviews of the data used for this persona, we agreed that this persona would be mainly serve the developers and marketing would get to cherry-pick specific data, especially relevant for them and follow up on those information in order to create a slimmed down version for their marketing-persona.

So my main learning and take-away here, was that even something as universal as a persona for one specific project is not universal enough for all involved stakeholders.

But at least, the acceptance and positive effects that Jessica brought to the development team were enough to make a point and demonstrate the advantages that come along with personas. This ultimately kick-started a persona-creation for all the other projects, I got involved with later and after some years, it became common practice among the teams, I worked with, which I regard as a very successful development in user-centered design.

bottom of page