User Role Modeling

User Role Modeling In Sitecore

In a previous blog, we talked about user roles, what they were and how they were used. In this blog, we will focus on the methods to determine what user roles to use for your Sitecore project.

What Is User Role Modeling?

As previously discussed, a user is anyone who receives benefit from a product. User modeling is a technique used to establish a commonly agreed upon list of user roles for a product. These user roles and their descriptions provide helpful context for user stories and other backlog items.

Think of user modeling as one aspect of stakeholder analysis that is focused on the people interacting with the product and receiving value from it.

User Role Modeling And Personas

• What roles do users adopt when using our system?
• What types of users do we have?
• What do they care about (with respect to our system)?

Role Modeling Steps

1. Brainstorm An Initial Set Of Roles
2. Organize The Initial Set
3. Consolidate Roles
4. Refine Roles

1. Brainstorm An Initial Set Of Roles

Generally getting the business stakeholder, project team including developers together to start identifying user roles. Some use sticky notes or cards to identify each user role. Everyone starts writing role names on the cards or notes and adding them to the board, wall or table.

This can be done electronically as well, but ideally the first draft should be in some sort of visual format for all to view. Continue with everyone adding roles/cards/notes until progress stalls and participants are having a hard time thinking of new roles. Allotting 15 minutes for this activity should be plenty of time to come up with most of the roles.

2. Organize The Initial Set

Organize the roles/cards/notes into groups that represent the relationship between the roles. Overlapping roles are placed so that their cards overlap. Sometimes roles will only overlap slightly, sometimes they will entirely overlap. Remove roles that are duplicates of others.

As much as you can, you want to stick with user roles that define people and not systems. Initially, defining system roles can aid in the brainstorming process to determine the user roles. But ideally, you want to identify users that are absolutely and positively benefiting from the product.

You do not need user roles for every conceivable user of the product, but you do want roles for the ones that will satisfy the success of the product. You want to include users who expect an outcome from the product.

3. Consolidate Roles

Now it’s time to start condensing and consolidating the roles. Start with those roles that were completely overlapping. Each participant that came up with these roles should describe what they meant by the role names. The group then briefly discusses to decide if the roles are the same and can be consolidated into a single role and to determine the role name.

Also, roles that do not contribute to the product's success can be eliminated. The goal is to have user roles that are highly distinctive in their context, characteristics and criteria. Rename roles to more clearly align with their function. Add any roles that may have been missed. Organize the roles into super roles and sub-roles if applicable and where appropriate.

4. Refine Roles

Now the roles have been consolidated and all participants have a basic understanding of each function and how the roles relate to each other. The next step is to define attributes for each role.

A role attribute is a fact or bit of useful information about the user who fulfills the role. Ideally, you want to find information about each role that distinguishes one role from another.

Here are some attributes to consider:

• The frequency with which the role will use the product
• The user’s level of expertise with the product
• The user’s general level of proficiency with technology
• The user’s general level of proficiency with the product
• The user’s goal for using the product

When Should You Use Role Modeling?

User modeling is especially helpful when working on products with a significant amount of user interaction and where there are different types of users who can perform different activities or access different functionality.

Ideally, this is done early on in the project as it helps to establish the range of users and can provide needed context. It can also provide helpful information when establishing scope.

Why Should You Use Role Modeling?

Having defined and consistent use of user roles in user stories reduces confusion and helps ensure all cases are covered. The output of user modeling can also help with gap analysis.

If there are any user stories that have a user role that was not identified during user modeling then it could mean it was previously missed, you have the wrong user role in the story or that user story is not really part of the effort, i.e. scope creep.

If there are user roles without an associated user story, that raises other possibilities. You could be missing user stories or you have identified an unnecessary user role.

When creating user roles, consider what permissions they need in the product. The user base may have different titles but essentially do the same thing. User roles should not identify specific people but groups of people.

How Many User Roles Should There Be?

There is no correct answer to this question. It is truly dependent upon the product being developed, those that will obtain value from it. Sometimes, once the user roles modeling workshop determines a set of agreed-upon user roles, but when thinking about writing the user stories for each role, you realize you’ve missed a role or two, or that some would have the same user story and thus need to be further combined.

Another Technique - Personas

Only use this technique if you can ascertain direct, tangible benefit to the product. For some of the more important roles, it may be worth going a step further and creating a persona for the role.

A persona is an imaginary representation of a user role. A persona describes the role in sufficient detail so that everyone feels like they know the persona. Personas contain market and demographic research information in order to truly represent the product’s target audience. A persona is not required for every user role. However, you may want to consider writing a persona definition for one or two of the primary user roles.

User stories are much more expressive when put in terms of a user role or persona. This will hopefully remind the team about whom they are developing the product and provide benefit in thinking about a specific user role or persona when discussing or coding the story.

What are the user roles in your Sitecore implementation project?