Skip to content
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
26 changes: 18 additions & 8 deletions 2-Define/Methods/personas.md
Original file line number Diff line number Diff line change
@@ -1,10 +1,19 @@
## Personas

#### What is it?
A persona is typically defined by the user's role in the organization but this isn't always the case. It represents a group of users with same business goals.
A persona represents a group of users who share the same business goals, perform the same tasks, and are expected to interact with the solution in the same ways.

It's typically defined by a few characteristics shared by the represented users, such as:
* Who - Who are they? What are their roles in the organization?
* What - What do they do? What are their responsibilities?
* Why - Why do they need this solution? What are they trying to achieve?
Users who have these in common usually need to interact with the solution in the same way. In some cases, other characteristics can affect how the users might use the solution therefore differentiate personas as well. For example:
* Where - Where do they perform their business tasks?
* How many/much - What's the magnitude of their business tasks?
* How - How do they fulfill their responsibilities and achieve their goals?

#### Why do you use it?
During user interviews you might find that multiple users of the same role can have different priorities, motivations and pain points. By creating a persona for a group of users, you define what the common goals and needs of the group are. Personas define who you are designing for.
Personas are essential to our user-centered design process. Instead of throwing all users in the same pool of information, personas can help us surface the most efficient and effective paths for them to get to their destinations.

#### When to do it?
Personas should be created after conducting user interviews and reviewing notes.
Expand All @@ -13,19 +22,20 @@ Personas should be created after conducting user interviews and reviewing notes.
The following elements should be included in a persona card:

* Title - Persona's role in the organization
* Business Goals - The persona's highest level success criteria
* Business Functions
* Business Goals - The persona's business success criteria. They should be measurable and specific to the persona and the business domain in scope.
* Key Attributes:
* Frequency of use: Once a year <---> Multiple times a day
* Time of use: Seconds <---> Hours
* Technical Ability: Limited <---> Proficient
* Technical Exposure: Limited <---> Proficient
* Data Savviness: Basic <---> Stats guru
* Data Set Familiarity: Nonexistant <---> Comprehensive
* Perspective: Strategic <---> Operational
* Perception of the Project: Couldn't care less <---> Life changing
* Key Activities > Key Tasks
* Key Questions to answer
* Notes & Quotes
how does each attribute shape the design?
* Routine Activities - A routine activity is a contexualizer of business tasks. It defines when (how often), where, with whom the persona perform certain tasks. For example, the sales manager persona has a weekly sales planning meeting on monday morning with sales reps.
* Business Tasks / Key Questions - What are the high level steps/components needed to achieve the persona's business goals. The tasks or questions in a persona card should remain on a relatively high level. Detailed tasks or questions should be documented in Task Analysis.
* Notes
* Quotes

#### Example

Expand Down