The term “user personas” often conjures up images of documents that describe the characteristics of an archetypical person. However, it’s more than just a description; it’s an illustration that allows designers and developers to create software that truly benefits someone’s life in a meaningful way.
While there are many variables, when we sit down with a prospective client, we ask these two things: “Who are your targeted users?” and “How would they use your product?” From these two questions, we begin to cultivate a mindset that we are not building the product for ourselves. We are creating the product for the end user — leaving a designer’s biases behind and egos in check.
How do we get from not creating a product for ourselves to creating a product for the user? It takes time and effort, and we will break that down for you.
User persona is much more than a document
User personas have a core, specific function. They illustrate the user in a colorful fashion, detailing aspects about their life. These details include not just how they might use a product, but how and why they using it in the first place. Examining ancillary items around a user’s habits and daily life influences design decisions and allows designers and developers to “get inside the head” of a person using their product.
These users are not market segments, actual users, or even roles. A persona is an outline, typically a one-page document, describing the attitudes, beliefs, needs and wants of an archetypal user.
Typically, there are multiple personas, complete with their own unique set of qualities, that go are used to inform the design process. Moreover, to keep these people in the minds of developers and designers, each persona is given a name.
“Each persona represents a significant portion of people in the real world and enables the designer to focus on a manageable and memorable cast of characters, instead of focusing on thousands of individuals,” said Sholmw Goltz of Smashing Magazine. “Personas aid designers to create different designs for different kinds of people and to design for a specific somebody, rather than a generic everybody.”
The goal is to humanize the end user and allow the designer to consider other factors surrounding that personified user’s interaction with the app. Factors that go into creating a persona include age, demographic, income, tech savviness, type of devices they use, car they drive, occupation and what they like to do in their free time.
When we performed user persona research on a travel rewards app, we created 4 different personas: John and Jennifer ‘the family first,’ Scott and Melissa ‘the points gurus,’ Lisa ‘the travel pro’ and Jeremy ‘the weekender.’ But despite their differences, they are all individuals that can benefit from using a travel rewards app.
The backstory of the persona
Alan Cooper, an American software designer and programmer, has been credited with coming up with the term and usage of user personas in the early 80s. During his lunchtime walks on a nearby golf course in Monterey California, he would play out a user interacting with the software he was creating in his mind.
“I found that this play-acting technique was remarkably effective for cutting through complex design questions of functionality and interaction, allowing me to see clearly what was necessary and unnecessary and, more importantly, to differentiate between what was frequently used and what was needed only infrequently,” said Cooper.
This playful acting and brainstorming put the future users of his software at the forefront in the design process. After Cooper moved into a consulting position in 1995, he discovered that doing thorough research on users would lead to better software, and the user persona was born.
How does a persona fit into the software creation process?
Cooper’s ideas evolved into goal-directed software methodology. This subset of user-centered design merges several disciplines (such as strategic planning, ethnography, and market research) to address a business needs, the bandwidth of a development team, and user goals.
At a high level, the practice of merging these thoughts places users through a journey of solving a problem and empower the user to solve a problem through software.
This story-driven thinking is a perfect way of creating a piece of user-centered software because the elements of a good story combine many elements of expressing emotion, underrating psychology, and connecting with a reader or viewer. More importantly, it allows anyone to experience and empathize with an event or narrative that is foreign.
As with any great story, there is a set of core components that drive a narrative and make a story worth reading. There are three components that we need to keep in mind:
As the protagonist of the story, this individual controls the software. Like we’ve talked about in this article, they have a specific attitudes, motivations, goals, and pain points.
These are objectives that the ‘persona’ needs to fulfill by using a piece of software. If you liken this device to the ‘journey,’ these goals are what the ‘hero’ is working towards, and the software enables them to accomplish the task at hand.
The scenarios act as the narrative in which the ‘persona’ operates. These devices are written and thought of in the first person, and address the when, where, and how of the story.’
As designers and software creators, we will all have different ideas of what makes a good product. Formed from our own experiences, thoughts and tastes, we have our own biases that will subconsciously creep into the design process–without us even noticing. Creating these personas helps us inform our decision making, and create products that users love to use and benefit their lives.
Taking the time to create user personas and understanding a user at a core level will allow designers and developers to step outside themselves and become user advocates. Check back soon to see how we create personas in part 2.