Actors and Personas

1 Introduction

Here are some of the ideas that were shared in a conversation that I had with software development guru: Ivar Jacobson, (regrettably, I did not get a photo). The conversation that took place was intended to reconcile the concepts of "Actors" and "Personas". The intent of this article is to help clear up a common issue in software design and analysis: what are the differences between defining System Actors and Personas and why defining both is useful for the Analysis Phase of Software development--where System requirements are being defined.

The process of defining Actors drives the definition of product Features. The process of defining Personas drives Usability.

2 Organization

This document is organized following this structure:

1. The Purpose of Actors and Personas.
2. Actors Defined
3. Personas Defined
4. Actors and Personas in Practice

3 The Purpose of Actors and Personas

Commonly, in Waterfall and Agile methods of designing software, Actors are defined that illustrate "Who" is intended to be interacting with a system, be it Adminstrator, User, Content Manager, etc. However, Microsoft products take this process one step futher by addressing not only "Who does What" with the System, but "How" that individual wants to interact with the System. Refining "What" into "How" is the process of defining a Persona.

Examples of Personas: , what skillset does this person have? Are they an advanced User and want to access this using a command prompt? Or do they want to just access standard functionality and want a basic graphic interface? Is the User completely unacquainted with the particular functionality and want an automated tool that walks them through specific processes?

One of the obvious values in Microsoft software, (mainly seen in the XP and Vista generations) is their general approach to making functionality accessible by people with many different skill levels and backgrounds. On the otherhand, The usability of BSD and Linux are on the complete opposite side of the usability spectrum.

Because of the significance of the effort assuring quality and security, a very well defined and automated approach must be undertaken to validate the scenarios under which software will be utilized and how that software will be exposed. This process of definition begins with defining Actors and their associated Personas.

Reasonably, if software is going to be utilized, it must be utilized by someone or perhaps by something—such as an Administrator or even another System. Since it is impractical to identify each and every potential User of a product, potential Users must be first generalized into groups known as Roles or Actors, (Administrators, Content Managers, Application Users, Gamers, etc).

These generalizations categorize the different types of Users by what they “can” do and “how” they do it. Consider that “how” a User interacts with a System is a refinement of what interactions a User “can” perform; many people “can” speak, but “how” they speak may be completely different from one person to the next.

In order to test the quality of all of the functionality of a system including its security, it must be determined first what “can” be done with the System and “how” it is done. It follows then that by determining “who” is using the System—Actors—we can define what they “do”—Activities. Then, by determining that nature—the Personas—of those Actors, we can define “how” they are attempting to perform those Activities. Actors “can” perform Activities with the System. However, the individual Persona of each Actor helps us understand “how” individual Actors acts upon the System.

Once the Actors and Personas are defined within a System, automated tests can be created to simulate most of the different types of Users who will be interacting with the System. Then, with each of these different "hats", the simulations can "Act" out "How" each of those identities and more thouroughly test software functionality--and--its usability. For example, is it easier for a Home User using Windows XP to change their IP address or a Windows Vista user?

4 Actors

By generalizing the types of Users that will be interacting with a System, focused and automated testing can be performed from the View of a particular group of Users—represented as a single and generic Actor. For example, tests and security audits targeting the Activities of the “Application User Actor” may be associated with a higher prioritization than the "System Administrator Actor". In this case, all of the potential interactions that the “Application User Actor” can perform are tested. Alternatively, “System Administrator Actor” functionally could be distinguished and tested separately.

Again, Actors are defined by classifying and organizing what Activities a User “can” perform with a System. After grouping similar Activities, an Actor is generally associated with each group. An example of grouping similar activities could be: executing user applications and performing administrative tasks. In this case Users can be broken down into two Actor classifications: the Application User Actor, (who executes applications), and the Administrator Actor, (who performs administrative tasks).

4.1 Actor Definition

1. An “Actor” is a classification and generalization of a group of System Users and their Roles. These Users are represented as a single individual in System Analysis and documentation as an Actor. The term “Actor” can be generally considered synonymous to “Role”.
2. This classification of roles and responsibilities is typically represented as a single individual in system analysis. This single individual “Actor” represents a place holder for a group of similar Users performing similar functions within a System.
3. Each of the actual Users associated with a defined Actor Role usually performs similar Activities and Processes against a System.
4. Example Actors and User Generalizations: Administrator, User, Partner, Content Manager, Reporting System.
5. Example Sub Generalizations: Actor: Administrator <>

4.2 Actor Analysis Process

How can we know that all of the potential “Actors” have been defined in the process of Analysis? Since Actors are usually associated with a given Role or set of Responsibilities, there are a couple of System Artifacts, (documentation, source code, database schema, etc) that can be used as checklists.

1. Security Configuration: Since one Actor may have completely different responsibilities than another, they are often restricted from performing Activities that another Actor is responsible for. Therefore, there are generally User Groups and Roles defined within security Systems such as Access Control Lists, Active Directory, LDAP, etc. Typically, there can usually be an Actor identified for each of the Security Roles or groups defined.
2. Because most Systems are designed practically, (an objective is being pursued or some process is being performed), classifications of Activities supported by the System are generally defined. Each Process classification is often referred to as a Use Case, Scenario or Story. Since some Actors may perform one or more of these subsets of functionality, it may be that there can be an Actor defined for each main System Process. Example Processes could be: Browse Online Catalog, Manage My Account and Manage Catalog. Each of these processes may represent what a User “can do” with a System.

Actors that could be defined by analyzing common business processes:

1. Anonymous User: represents Users that can browse an online catalog
2. Customer: represents Users that can browse the catalog, who have a purchase history and can change their payment options
3. Administrator: represents Users who can manage the catalog and other Users

5 Personas

An Actor is to Feature as Persona is to Usability.

A way to explain a Persona is as “a refinement of the Actor”. Where an Actor is generally a classification of Users determined by "What" similar activities they perform. A Persona is generally a classification of Users determined by "How” they perform these activities.

A different practice is to use a Persona as an instance of an Actor. For example, some walk through a ficticious scenario with a Persona named "Samuel". In this document, this is not considered a Persona. Grammatically, it would be more correct to consider the Actor as the instance of a Character and to consider Personas as the different types of personalities or characteristics that could be associated with that Character. For example, the Character "Samuel" could take on the Character/Actor role of "Administrator" fulfilling the Persona type "Expert".

For example, two organizations may employ System Administrators. One organization may have dual tasked their Financial Manager to also be the System Administrator. Another organization may have several System Administrators on staff, each of whom have years of technological experience.

These two System Administrators are alike in several ways: they both have similar roles and responsibilities, and they both perform similar tasks. However, even if they are responsible for the execution of similar tasks and processes, they may perform these tasks in completely different ways based on their respective skill levels.

Therefore, what separates the definition of a Persona and Actor apart is the definition of “how” they do perform activities. Where Actors help Software Designers define features and determine what the System should be able to do, Personas help define all of the ways those features can be used.

5.1 Persona Definition

1. A Persona represents the personal context and qualities of an Actor. Although a particular Actor may be consistently perform the same Activities within a System, how they perform these Activities may change if they are accessing the System remotely, through hand held devices, at night, with a particular physical impairment, etc.
2. A Persona is a classification and grouping of distinctions of “how” an Actor/User executes activities within a System, such as basic or advanced methods by Student and Advanced Users.
3. A Persona reflects a general classification of System Usability. Based on the Persona, the System may guide the User through functionality in a very specific or limited way. For example, there may be User Personas defined such as: “Student Persona”, “Professional Persona”, “Casual Persona”, “Expert Persona”, etc. The “Student Persona” may be limited from performing activities that could result in a System failure. Alternatively, the “Expert Persona” may have no System limitations imposed and may execute Activities in the manner they seem appropriate.

5.2 Persona Analysis Process

In order to begin defining Personas for Actors, several generic Personas, (such as Context and Demographic Personas) can be referenced to see if they can be used for each Actor defined within the System. Then, domain specific analysis has to fill in any of the gaps remaining. How Actors use the System to perform an Activity may be impacted by associated personas.

Context Personas

1. Where can this Actor access this System? Personas: Mobile Phone User, Corporate Network User, Voice Recognition System User, etc.
2. From inside what System context can this Actor access the System? Personas: Windows User, Apple User, Linux User, Internet Explorer User, Mozilla User, Safari User, etc

.Demographic Personas

1. What is the skill set of the Actor using this System? Personas: Child, Student, Experienced, Advanced, Expert
2. How will the Actor be physically interacting with the System? Personas: Visually Impaired, Hearing Impaired, Tablet User, etc.

View Personas

1. What different ways can this functionality be viewed, accessed and executed? Personas: Graphic Interface User (i.e., Student Persona), Command Line User (Advanced/Experienced Persona)

6 Actors and Personas in Practice

Most software today has functionality implemented within to support varying Actors. Even support for the varying Personas attributed to Actors can be seen in many different products.

6.1 Product: Windows XP and Windows Vista

Activity: Manage Computer System
Actor: Administrator, Non-Priveleged User
Personas: Standard User, Advanced User, Enterprise Expert

Usability Distinctions: In order for Users to perform computer related management functions, Users access management related functionality through several different ways of interacting with the Control Panel based on their skill level and familiarity:

1. Control Panel Standard View: Standard User Persona
2. Control Panel Classic View: Advanced User Persona
3. Active Directory: Enterprise Expert Persona

6.2 Product: Visual Studio 2005

Activity: Create User Interface for Application
Actor: Windows Developer & Web Developer
Personas: Advanced and Basic Engineer, (Differentiating between those who are more comfortable with visual editing or those who need to be able to customize the interfaces at a very low level.

Usability Distinctions:In order for Users to create User Interfaces for applications, the System presents different views of very similar functionality.

1. Web Designer: Web Developer Persona: Basic
2. HTML Editor: Web Developer Persona: Advanced
3. Windows GUI Designer: Windows Developer Persona : Basic
4. Code Behind Editor: Windows Developer Persona: Advanced