When Is a User not a User?

Thinking in Terms of Roles rather than Individuals

How many times has this happened to you? You’re buying a gift for someone important in your life. You get them something that may not be your thing, but you know they’re into it. Next thing you know, you see ads for that item on every website you visit and the store frequently recommends products that YOU don’t want. This happens because the design of the system assumes that the buyer is the same person as the consumer of the product. This mismatch frequently leads to a sub-optimal user experience and missed opportunities. Let’s examine how we might design a system to take full advantage of other possible transactions AND leads to a better user experience.

What Is a Role?

A role describes actions an individual may take in a specific situation. They may take these actions directly in the system (buys a product) or outside of the system in a way that impacts other functions within the system (consumes a product). Understanding what happens outside of the system allows us to consider the entire user experience. We may see opportunities to enhance our design to make it easier for the user to conduct those outside activities, for example, allowing the user to indicate that this purchase is a gift.

When talking about these roles, focus on the action that is taken rather than any one individual taking it. This is not to say that we’re ignoring the individuals taking these actions, but rather we need to make sure we understand what actions are taken in the system in addition to the people taking those actions. This dichotomy allows us to remember that a single individual may fill multiple roles in the system or just one. Of course, multiple individuals can and will fill the same role (hopefully you have lots of people buying your products).

Continuing with the e-commerce example I started, here’s a brain dump of potential roles:

1. Decider: Triggers this whole process by deciding that something must be purchased.
2. Buyer: Finds and purchases one or more products on the website.
3. Payer: Forks over the money for the product.
4. Consumer: Enjoys whatever the buyer bought.
5. Receiver: Receives the package containing the product.
6. Returner: If the product doesn’t meet expectations for any number of reason, the person filling this role packages up and returns the product.

Why Are Roles Useful?

Thinking in terms of roles provides these benefits:

1. Common terminology: Communication among the team and the stakeholders will be consistent with fewer misunderstandings.
2. Prioritization: It will be easier to declare which roles must be fully instantiated in the system and which ones can be put off until later releases.
3. Permissions model: As you map out the potential roles within your system, you’ll begin to understand the permissions that your system will need.

What Is the Proper Granularity?

In theory, you could have just one role that accounts for all of the actions in your system, but, as I noted in the opening of this piece, that not only limits the flexibility of your design but also blinds you to potential opportunities. You could go to the other extreme and have a role for every function a person could execute in your system. That maximizes your flexibility but complicates how you think about the system if you have TOO many roles to consider. Ultimately, you need to decide what is the right level of detail for your team and the system you’re building. Consider splitting a role into 2 or more if the people you expect to be taking those actions differ greatly, either because of their own goals or their experience with the system. Likewise, you may wish to merge multiple roles into one if they are closely related activities AND the people you expect to execute those functions are similar. You know you’re in the right place when you’ve balanced flexibility with clarity.

Continuing with our example, here’s how we might refine our list of roles:

• We might need to split the Buyer into Searcher (tracks down the desired product) and Purchaser (executes the transaction on the website) since those are two distinct activities.
• Do we need a Decider role? They won’t be interacting directly with the system. I would talk to marketing, though. If we choose to keep the Decider role:
  • Could there be multiple Deciders?
  • Do we need greater clarity on the typical decision-making process?
  • Would we need a role for the person who determines that a product should be returned?
• We may decide to merge the Buyer and the Payer if we find that they are always the same person. Would we expect a lot of children to act as the Buyer and need to get the credit card from a parent?

How Do the Roles Interact?

Just having your roles defined is useful as it gets your mind in the right place to think about your system. NOW you can dig in to see what opportunities shake out from interactions you haven’t yet considered. The vehicle for this is a matrix where each role is listed on both axes. The Y-axis represents the role that initiates an action, while the X-axis is the target of the action. The cell at the intersection of the two is where you list the actions. In use cases where there may be multiple individuals fulfilling a specific role, you may need to call out actions within that role. It’s OK to leave a cell blank if you cannot think of an interaction between the two, but remember to revisit this on a regular basis.

	Decider	Buyer	Receiver	Consumer
Decider		Tells what to buy and where to send it Answers questions	Asks if they can receive a package	Knows preferences of
Buyer	Ask questions Tells transaction status	Coordinates to ensure no duplicate purchases	Tells estimated arrival time of package	Wants to keep transaction secret from so it’s a surprise
Receiver	Confirms that they can receive a package	Signals receipt of package		QUESTION: do we need to worry about how the package gets from the Receiver to the Consumer?
Consumer	Tells preferences Indicates receipt of product	Thanks	Thanks	Shares product with

Let’s consider the following situations:

1. One person fills all roles: I buy myself a book that I’m interested in. My interactions are only within the system, though the trigger that led me to believe I’m interested in that book may be external. And, yes, this purchase should inform your suggestions of what I may like.
2. One person is the consumer, another fills all other roles: It’s my partner’s birthday, I need to buy a present. The interactions during the transaction are all within the system since I know the Consumer’s preferences and I do not need to coordinate with anyone. In addition to what we noted before, that this purchase should not be taken to indicate MY preferences, the system also needs to make sure it doesn’t spoil the surprise for the consumer.
3. Each role is a separate individual: I remind my adult child that mother’s day is coming. She coordinates with my other kid to make sure the package gets to mom. There’s the communication of preferences, questions to make sure we’re buying the right product, coordination to make sure we don’t wind up with duplicate gifts, and then making sure the arriving package is taken care of. This is a lot more complicated than the first two cases. We need to account for this if we believe this will be a significant portion of our customers.

Iterate, Iterate, Iterate

Filling out this matrix will likely lead you to revisit the list of roles, merging and splitting as you deem necessary. That’s OK. In fact, it’s encouraged. This is an iterative approach that allows you to refine your understanding of the universe in which your system will operate.

Some potential opportunities:

• Since the Buyer and the Consumer may not be the same individual, we can allow the buyer to indicate that this is for someone else and keep this out of the algorithm for suggesting new products to this individual.
• Maybe we can identify the Consumer and associate it with an existing account.
• We need a gift-buying registry of some sort to keep multiple Buyers from stepping on each other’s toes.
• Do we want a feature to allow the Consumer to thank the Buyer?

As you see, breaking down the user interactions into roles gives us greater flexibility in the design of the system. This flexibility will lead to a more tailored user experience and surface new opportunities targeted at subsets of your customers. That’s a win-win.

To learn more about how to identify the roles that interact with your system, contact us for a free consultation at info@tenmilesquare.com. We’ll walk you through our domain model approach that brings clarity to the universe in which your system operates.