Actors

Actor is a term used primarily in use case modeling. A use case models the interaction between multiple parties – or actors. An actor can refer to a person, a system, a part of a system, an organization – anything you’d like to model the behavior of using a . For our use we’ll talk about human types of actors.

Typical examples might be

• Cashier
• Customer
• Manager
• Accounts Payable Clerk

An actor typically references a common name for a type of user. Often they take the form of a job title. In most cases the name is common with respect to the organization paying for the software to be built. For instance actor names like "customer" and "manager" are relationships individuals might have with an organization. When you use an actor name within that organization, the people you’re talking with typically know who you’re referring to and will infer characteristics of that type of person from that actor name.

Pair named actors with goals

To make an actor or list of actors more useful, we might pair the actor name with a goal or list of goals with respect to a process or piece of software we’re considering.

For example, let’s say we were building a point of sale system. Given an actor like cashier we might list a few goals like:

• ring up sales for customers quickly
• do customer returns
• look up prices for customers
• keep the cash drawer balanced

When creating an actor or list of actors, pair them with the goals that motivate their use of the system you’re designing.

User Roles

The term "role" is used in a variety of contexts. It refers to the goal relationship someone has with tool or process. Think of a role as a hat a person puts on. Throughout the day, or even moment to moment, a person can change their role as they might change a hat. Their role might change as their goal with respect to the tool or process changes.

Typical roles might be

• Casual browser
• Impatient buyer
• Order taker
• Time tracker
• AP voucher enterer

In these example roles names I’ve used a "thing-doer" form. The role names all refer to some type of work or activity a person is engaging in with tool or process. Someone wearing the hat of a particular role has the objective of completing that work or activity. Reading a role name tells me what the person is engaged in doing – although not necessarily why.

For "extra credit" I’ve used the decorated form of "adjectived-thing-doer" such as "Impatient buyer." The adjective tells me a bit about the state of mind of a person engaged in this activity. I can assume an impatient buyer in a store would like to find what they need quickly and leave.

The form of role I’ll gravitate to here is from Constantine & Lockwood’s Software for Use.

A good role name reflects the goal a user has with respect to the software

For example if I were building a kiosk in a large book store to help people find books I could define roles for the various people who’d use that kiosk. Suppose I have a type of customer who shows up at my book store in a hurry looking to find what they need and get out quickly. I might be tempted to call this kind of person an "impatient buyer." However, the software I’m building doesn’t allow it’s users to buy – only to find the location of books in my large bookstore. A better name for this role might be "impatient location searcher." Such a role name more accurately reflects the goal with respect to the system.

A person may take on many roles

A user may change roles as they change goals. For example upon finding something interesting in an on-line website a "casual browser" might change to an "impulsive buyer" or a "skeptical comparison shopper."

A variety of actors my fulfill the same role

Within an organization we might find an Accounts Payable Clerk. The clerk may report to an Accounts Payable Manager. Within that organization, those job titles may be significant. If we’re writing software to support the Accounts Payable department, that software may support the routine activity of AP voucher entry. That routine activity might be engaged in by both the AP clerk, and the AP manager. A role name like "AP voucher enterer", although it sounds a bit forced, let’s us focus on person engaged in this activity – not a job title which may have little baring on that activity.

User Profiles

An actor or role may be profiled by adding relevant information about the types of people occupying that actor or role.

Given an actor and goal or a user role we know a little about the user of our system, but likely not enough to run through a subset of design choices and make some decisions. It may help to add some details to our user such as age range, computer expertise, experience with the software they’re using or process they’re engaged in, the place they’re likely using the software… and the list of information relevant to your design could be endless.

When we start to identify characteristics of our user, we begin to build a profile that helps us better understand that user.

Consider profile characteristics relevance to your design

There are a huge number of details we might consider about any type of user. Some of those details are more relevant than others to the design of your software. For example when designing software to support a business process, a characteristic like gender is likely not relevant. I suppose there’s always an exception, but whether our user is male or female may not have much baring on their goals when using the software or how they might use it. However, if we’re designing a consumer product that caters to specific market segments, how we design the product for stay-at-home-moms might be different than how we define it for sports-fanatic-men.

Most characteristics may have some baring on design, but some have more than others. For example frequency of use is a characteristic that is very relevant to an information kiosk in a museum that’s likely used very infrequently by its target users.

For each characteristic you profile, consider it’s relevance to the design choices you need to make.

For characteristics that have big impact, make sure the information you have regarding that characteristic is comprehensive and reliable.

Consider a variety of characteristics

There’s a variety of characteristics you might consider. Here’s a list, not comprehensive, but useful as a starting point.

Profile characteristics come from research

If you’ve read this incomplete list of user characteristics you may be wondering how you’re going to get all this information. There are a number of ways.

The most sound way is through research.

We might learn more about our users by conducting a series of user interviews and consolidating information across interviews.

Information can also be obtained by observing user during usability tests, conducting focus group discussions, or by learning in context in an apprenticeship style interview with your users.

We can also get information by conducting studies or leveraging studies conducted by others. You might get usage details by examining logs from existing software. You might also conduct surveys of your target users directly asking them questions.

All of these approaches, and many I likely haven’t thought of, yield valuable information that can be consolidated, distilled, and placed into relevant profile characteristics.

Profile characteristics come from assumption

Making choices based on assumption is often considered a bad idea. But we do it all the time. In fact our assumptions are often based on our past experience and observation. It’s just that we may not recall the specifics of the observation well enough to label it "sound research." If your company is in the business of writing software for a specific business area or market, there’s likely people in your company that know quite a bit about it. You may be even one of them. Interview these subject matter experts, or talk to yourself if you’re the expert, and collect assumptions about your users to populate your user profiles.

When using assumptions to populate user profiles, make notes about those assumptions and the profile characteristics you’ve used them. For each characteristic, consider how relevant that characteristic is to the design. From here you can make a determination of how risky it is to use an assumption. For an important characteristic, one that might have big impact on your design decisions, you might want to replace assumptions with research.

Leveraging assumptions to create profiles is a quick way to get started. Replacing assumptions with research later helps you reduce the risk of bad design decisions without sacrificing pace too much.

Personas

Actors and roles seem a bit abstract. It’s harder to put a face on them, to understand details about them that may have bearing on the design of a product. Profiling an actor or role begins to add this additional detail. But, an profile can still be somewhat abstract. For instance, a profile may refer to 18-27 year, men or women, with varying computer experience, and varying economic backgrounds. That variance may make it tougher to make design decisions.

Creating a person remedies this by selecting specific details from a profile and using those details to create a archetype of a specific fictitious person that "personifies" the group of users within a user constituency. A profile composed of 18-27 year old mend and women with varying computer experience and economic backgrounds might be personified by:

Selecting specific details focuses design

It’s difficult to design for a large group. Trying to satisfy everyone is the road to disaster. Using a persona to target your design allows you to focus on satisfying a single individual. The goal is a strong coherent design that subsequently satisfied most people in its primary user constituency. This rather than a design that looks like it’s trying to make allowances for too many types of people.

Select representative details

For a group of users within a category of information, there will be some variance. But, it’s common to see clusters or areas where a higher density of people within in a similar range exist.

Let me be more concrete.

Let’s say we’re designing an application used by largish organizations to process accounts payable. The typical accounts payable clerk’s computer experience may vary wildly from absolute novice to expert. But, if we were to arrange this group on a curve, we might find there are a large number with moderate computers skills, a reasonable number of novices, and very few experts. A curve might look something like this.

When personifying this group, it makes sense to describe a person with moderate computer skills – someone who’s pretty comfortable using a computer, but not the person you’d call on when you can’t get your laptop to connect to the Starbuck’s WiFi.

Choosing a specific data point from this group of users will focus your design so it doesn’t cater to absolute novices, or proficient experts, and is most likely to work well for the great majority of AP clerks in your target user constituency.

Create personas by making relevant representative information concrete

Create a persona by leveraging profile information and choosing a representative subset of information from each profile characteristic. Connect this representative information together using concise prose. Describe your person in a way that makes them seem concrete.

As you describe your representative person, keep in mind the information needs to be relevant to the design of this product. Including information about the car they drive might be relevant to the design of a handheld product often used in a car, but irrelevant to an accounts payable processing system.

Keep the profile short and easily consumable by its reader.

Make the persona sticky with a name, pictures, quotes, and stories

Give your persona a name. This allows you to refer to him or her in first person. Not only does this help consumers of the persona better identify, but it’ll shorten lots of conversations you’ll be having about this user constituency. Instead of saying business people who travel often, you can say "Duncan." Choose a memorable name – but not too out of the ordinary.

Add a photograph into the persona to give this persona a face. Let your reader look into the personas eyes.

You can select an image from a variety of sources. When I’m building something for internal use, I’ll fall back on a Google image search. But, if I suspect the image might get out of my company, and I’m concerned with potential licensing issues for the photo, I’ll rely on a source for clip-art images. Currently I use iPhoto.

Select a photo that shows more than your persona’s face. Show your persona in context where they’re likely to spend time using the product you’re designing. A photo of a traveling businessman using a laptop in an airport is a more powerful image than a close-up of a man that looks like he could be a businessman.

Attach quotes to your persona delivered in first person by him or her. Select a quote where the persona says something about their goals, pain points, or needs. You might also select a quote that helps illustrate a detail relevant to design.

If we were building time tracking software for Duncan, he might say:

"The half hour wait for the plan Friday afternoon is when I like to get my time and expenses taken care of so I can enjoy the weekend with my family."

If I were building time tracking software for Duncan, I now know he uses it on a laptop, likely in a busy airport, may or may not have internet access, and wants it to be quick enough to use that he can complete it in a few minutes. I may know someone like Duncan. Even if I don’t, I can look into his eyes, hear his voice, and begin to imagine the sort of software that could satisfy him.

I find that if I’ve gathered information by talking to a few Duncans that I’ll have lots of quotes in my notes that I can use. Stitch a couple quotes together that clearly identify user needs in their voice.

Adding in an anecdotal story further makes the persona more tangible and memorable. Use a story told to you by a potential user of your product. As with quotes, you may blend together a couple stories you’ve heard. Choose a story that helps illustrate the need the user has for this product.

When selecting representative profile details, look for details that compel multiple personas

When looking at profile details you may find a wide variance in a certain interesting area. This may be an opportunity to split a profile into multiple personas.

For example, assume we’re building a new service in our college campus website. We’ve profiled students and we see a wide variance in computer experience and skills. Computer skills seem pretty relevant to downstream design choices. I may choose to create two personas. The first may have strong computer skills. The second may be downright computer phobic. We’re then left with the decision of which of these users we consider more critical to the design of this software. You can see also that the value of the persona we create might extend far past the software to give us guidance on how we might publicize or market this new service.

While looking at profile data, look for relevant variances in characteristics as well as interesting correlations. If you’ve helped conduct interviews or gather other research data, you’ll begin to see patterns, or distinctions that make a difference in your design that compel you to create multiple personas for the same type of actor or role.