We use actor hierarchies to organize the different users of a system. Different people play different roles, and thus do different jobs. We use different actors to identify and organize those people. When deploying a system globally, we usually discover people that do the same jobs, but do them differently. Incorporating the notion of personas lets us deal with this.
Why Actor Hierarchies?
User-centered, or user-centric design is an approach to developing software that focuses, as the name implies, on the users of the system. When designing the solution – and more importantly, when defining the requirements for the system, special attention is placed on the users of the system. More specifically, center stage is devoted to developing software that helps the users accomplish their goals.
From a requirements perspective, the key is to acknowledge that there are different types of users, doing different types of work with the software. It is reasonable to conclude that they will have different needs. An actor hierarchy provides a way to organize the different needs of the people doing different jobs. [Note: These are the same actors that are identified in use cases.]
A Simple Actor Hierarchy
Let’s start by creating a simple actor hierarchy. We’ll build on this incrementally as we add more complexity to our user base. We’ll look at a hierarchy for sales representatives (reps) for a company that manufactures goods for sale to other businesses. Each business to which the company sells products is known as an account.
The hierarchy represents an approach to classification of sales reps. Each successive level of the hierarchy is more specific than the previous level. All employees who sell products are considered to be sales reps (the top level in the hierarchy). When the company sells products to its accounts, it is not always obvious which products should be sold. In those cases, an engineer is brought in to help determine the exact need, and suggest the right products to sell. This engineer is known as a technical sales rep and the technical sales rep works with an account rep to determine the right products and terms to close the deal. The account rep is responsible for making the individual sale, and occasionally gets help from the technical sales rep to do it.
The hierarchy shows that all sales reps are either technical reps or account reps. If an employee is a sales rep, then he must be one of the two choices.
Account reps are further divided into two groups – representatives who work with large accounts, and reps who work with small accounts. The company currently considers accounts that make more than $500,000 in purchases per year to be large accounts, and the rest are small accounts. The main difference in behavior is that a large account rep works with only one customer – and in fact, for really large accounts, there may be multiple representatives for a single account. Small account reps, however, each work with more than one account, maybe even dozens of accounts.
You could argue, in the abstract, that large and small account reps should not be treated as different types of actors – because they all manage relationships with customers and sell products. However, there is enough of a difference (in our hypothetical example) between the jobs of the two types of reps that it is worth treating them as separate actors.
In our example, the large account reps are focused on account retention, and maintaining relationships with a single customer. These reps are focused on account retention and are usually managing the upgrade cycle for their customers. The upgrade cycle is when a customer replaces their existing, worn out or obsolete equipment with new equipment. Small account reps might be working with really large potential customers who currently buy from the competition. These small account reps are focused on acquisition and growth. They are also trying to manage and create relationships in an attempt to grow the customers until they become large accounts. Small account reps are also managing multiple customers, and have additional activities associated with managing that complexity.
Global User Base
The situation above describes how the company (or if you have a product management hat on – the companies in the target market segment) organizes their sales force in one region. What do you do when the the company has operations around the world? If all global operations are the same, then you don’t do anything. It is a rare company that works this way. Most global companies have grown their regional businesses (where a region might be Europe or Asia, or it might be China or India) independently. This could be do to growth by acquisition, or the parallel growth of separate regions managed separately.
In different regions, companies often have different business models. They also usually deal with customers in different ways. These differences may manifest from varied local business practices, different characteristics of the customers, or different levels of maturity in the market for the products being sold. There are also differences in regional regulations, policies, and laws – although you should generally manage those as variations in business rules, not business practices. We’ll side-step that layer of complexity for the purposes of this article. Pretend that the same laws, policies, and regulations are in effect in all of the regions.
The same general actor hierarchy can serve to represent the sales reps in multiple regions, with some modifications to account for the differences. Consider for our example, that the company sells products both in North America and in Latin America. The actor hierarchy above describes how the sales team in North America. The company’s operations are a little bit different in Latin America (for our example).
Latin American operations are relatively new to the company. Where the company has a well established market in North America, it has relatively low market share but very rapid growth in Latin America. As a result of the way the company’s business has evolved in the two different regions, there are two distinct differences between the two regions in the way that sales reps are organized.
- Technical Sales Reps. In North America, technical sales reps (TSRs) are salaried employees, who participate in a profit sharing program. In Latin America, the technical sales reps have a base salary, but sales-commissions make up a large portion of their compensation. The North American TSRs are therefore incented to propose solutions that are highly profitable (thus increasing their profit sharing bonuses). The Latin American TSRs are incented to propose solutions that may sacrifice profitability in exchange for increased revenue (thus increasing their commissions) .
- Small Account Reps. In North America, small account reps, like all account reps, are employees of the company, and work on commission. In Latin America, small account reps are not employees of the company. Small account reps are third-party sales people. The model is very similar to independent insurance agents. The small account reps, when trying to bid on a job, can propose solutions from the company or from one of the competitors. The third party small account rep also gets to set the price that his customer will pay for the products, and negotiate the price that the company will accept – pocketing the difference.
In both situations, the user populations are different, and will behave differently. The TSRs in both regions do fundamentally the same work – but with different motivations. The Small account reps in Latin America, are markedly different from the ones in North America – in motivation, relationship with the company, and the work that they do.
Using Personas To Express Regional Differences
Personas provide an effective way to describe archetypes of classes of users. Persona development is a key component of the interaction design process, but it can be leveraged very effectively in a traditional requirements process as well. Each persona represents a homogeneous population of users. In other words, the collection of users that are in a role represented by a single actor, and who have similar personal goals. By defining personas, we can manage requirements in the context of those personal goals. One actor in the actor hierarchy may have multiple personas associated with it. This makes sense when there are groups of individuals with different personal goals.
The most common example, and one that is almost always present, is built around the notion of user experience. You can classify users of a product as novice, competent, or expert users. Novice users usually become competent users but rarely become expert users. Those people who become expert users are usually a different breed. Professional drivers become experts, where casual drivers rarely exceed competence.
These two user groups are made up of people with different goals, who use cars differently (even though they both drive, they drive differently, and with differing expectations and needs). It is critical to separate user groups that are different, and treat them differently, to avoid the elastic user problem.
The two different technical sales rep (TSR) populations – in Latin America and North America – would be best represented as two different personas. The TSRs in both regions do fundamentally the same work – provide technical support to an account rep, to help in closing a sale. The North American TSR is profit motivated, where the Latin American TSR is motivated by increasing revenue. These different goals make it very unlikely that the same persona would accurately describe the TSR population in both regions. There are other factors that drive the identification of multiple personas for the same role (in the actor hierarchy), but to simplify, we are focusing just on the regional dynamic.
Since the TSRs in both North and Latin America are performing the same job, it does not make sense to treat them as having different roles in the actor hierarchy.
Using Additional Roles in the Hierarchy to Express Regional Differences
In situations like with the Small Account Reps in North and Latin America, it is better to create distinct roles in the actor hierarchy to represent them.
The North American Small Account Rep works on commission and is an employee of the company. This rep is focused on closing the deal, but only with products from the company. This rep also may work with other reps to help them close deals – sharing intelligence about market pricing, helping with product selection, etc. There are elements of teamwork and collaboration present because all of the reps are “on the same team.”
In Latin America, the Small Account Rep is also focused on closing the deal. But this rep does not care who’s products are used to close the deal. The rep will work to get the lowest possible price from the company, in order to maximize the difference between the company’s price (to the rep) and the rep’s price (to the customer). 100% of this difference goes to the rep, so even if the rep is handsomely rewarded or commissioned based on transaction margin, the rep will always make more money by negotiating a lower price from the company. The rep also has additional activities associated with getting quotes from the competition and managing relationships with the company’s competitors.
Not only are the jobs different, but the company will treat these two reps very differently. For example, the company would be likely to share cost or margin information with the North American rep. That information will help the rep know how low he can price products for the customer without jeopardizing the company’s profitability. The company knows that the rep wants to close the deal at the highest possible price, to increase margins and therefore increase the rep’s compensation.
The company will not want to share cost information with the Latin American rep. The company is still motivated to get the most profitable deals, but the company realizes that the rep is trying to get the lowest possible price – not the highest possible price. This means that the company needs to provide low enough pricing for the rep to close the deal, and low enough pricing that the rep will resell the company’s products instead of products from the competition.
Summary
Actor hierarchies provide a way to differentiate groups of people who have different roles. Personas provide a way to describe groups of people within a role who share motivation and characteristics. The combination of the two allows for clear, yet flexible expression of requirements – both from a business perspective, and from a user perspective.
When dealing with user populations in different regions of the world, it makes sense to extend the actor hierarchy when the jobs, and business requirements of the user populations vary. When the users are doing the same job, but with different motivations, using personas to describe the differences makes more sense.
Very interesting viewpoint. It addresses some of the problems I’ve had working with personas and I believe it’s a good starting point for people starting to work with personas.
Thanks, Anna, and welcome to Tyner Blain! I’ve been very happy with this way of defining the hierarchy so far. What are some of the other problems you’ve been having that this does not address?