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.
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 should be created after conducting user interviews and reviewing notes.
The following elements should be included in a persona card:
- Title: Persona's "name" and role in the organization
- Key Attributes (include those that are related):
- Frequency of use
- Purpose: This can decide at what timeframe the information should be aggregated. For example, if a user monitors performance every week, then a weekly trend might make more sense than a monthly trend.
- Values: Daily, Weekly, Monthly, Quarterly, Yearly, Multiple times a day, Multiple times a week, Multiple times a month, Bi-weekly
- Duration of use
- Purpose: This can help define the application posture, which characterizes the application as either “sovereign,” a power tool that monopolizes a user’s attention for a long period of time, or “transient,” an application that is only called when needed to perform a specific job. Knowing this can guide the choices of visualizations and the density of information. For example, sovereign applications might allow for more pages with a high density of information or more complex visualizations, since users would be willing to take more time to read it. We can capture current time of use and ideal time of use as two data points, and use ideal time of use as a testing metric.
- Values: Very Short (<1 min), Short (1-15 min), Medium (15-30 min), Long (30-60 min), Very Long (>60 min)
- Analytics Experience
- Purpose: This attribute is the measure of the persona’s ability to conduct complex analyses, such as those involving a large amount of information, a complex visualization, or a long flow of sequential steps. This attribute can help us gauge the user’s comfort zone, group concepts, and decide which concepts will likely be adopted. It can also help us design instructions or training materials.
- Values: Low, Medium, High
- Dataset Familiarity
- Purpose: It’s important for users to understand key definitions used in the design, including measures, dimensions, and business rules. Knowing a persona's familiarity with the dataset will help us decide whether we should have a centralized location to explain all key definitions, or provide descriptions on demand.
- Values: Low, Medium, High
- Project Impact
- Purpose: Knowing the relative impact of the project to the persona can help in prioritizing personas and their requests.
- Values: Low, Medium, High
- Business Mindset
- Values: Operational, strategic, tactical
- Type of Analysis
- Values: Descriptive, diagnostic, prescriptive, predictive, exploratory
- Frequency of use
- Goal: The sccess criteria of a persona (what makes this persona succeed at work). A good business goal should summarize the high level tasks the persona performs, be measurable, and be specific to the person while also aligned with the company strategy. The goal doesn’t have to describe how it will be measured.
- Tasks (to achieve the Goal): In order to achieve the business goals, a persona needs to perform a series of key business tasks. These tasks can have a hierarchical structure, and in a persona card, only the highest level in the hierarchy needs to be documented. The highest level of tasks should be specific to the persona -- in another word, they should match the Single-role Business Process. Lower level tasks, and other details should be documented in Task Analysis.
- Pain Points: A pain point is a problem, a challenge, or a frustration, real or perceived. This section documents pain points in the persona’s current workflow. Aside from documenting the pain points, some considerations should also be documented, such as:
- Is it data centric or business centric?
- Can we solve this with a BI application?If data centric, do we have the data to support a solution?
- Is it in scope or out of scope?
- If in scope, is it a nice to have, need to have, or must have?
- If out of scope, should it be documented in a roadmap?
- Notes: In this section, document notes that are worth mentioning but not necessarily a pain point. For example, you might document what the user thinks or feels about something, what has the user heard or seen before, etc.
