User role modeling
User role describes the relationship to the system.
I read this from somewhere, but could not find its origin any more. In Mike Cohn's classic book "User Story Applied", there is a chapter dedicated on this topic called "user role modeling". It referred to Larry Constantine's work and his book "Software for Use", chances are it is from there. Do let me know if you happen to know.
Anyway, from my recent experience in helping team charter a new project, we encountered an example that illustrated this nicely.
It is a data application for internal use. Some common uses are as below.
- Sales looks at product information and price information while creating quotation for customers.
- Sales updates price information.
- Marketing looks at product information and price information while building marketing campaign.
- Marketing uploads product photo.
- Product engineer adds new product information.
- Product engineer restricts the access to certain product information.
- Pricing group uploads price information.
- Pricing group validates price information.
- ...
It is tempting to define the following user roles.
- Sales
- Marketing
- Product engineer
- Pricing group
- ...
Those roles come directly from work, thus, easy to access. However, those do not describe the relationship to the particular system - the data application. Why does it matter? Same roles have different intents onto the system, while different roles have similar intents onto the system. This makes it difficult to understand the system from those user roles. It makes it a lot easier to understand the system when you define user roles in terms of their relationships to the system.
For this data application, in terms of relationship, we define initial user roles as Producer and Consumer.
Considering two major data types in this application - product data and price data, we may refine the initial roles further like this:
Producer
- of product data
- of price data
Consumer
- of product data
- of price data
Product data contains text data and photo.
Considering different ways of producing and consuming data, we may refine the initial roles further like this:
Producer
- creator
- updater
- controller
Consumer
- viewer
- validator
When we consolidate the user roles with those mixed, we end up with the following list.
Producer
- Product text data producer (by product engineering)
- Product photo producer (by marketing)
- Pricing creator (by pricing group)
- Pricing updater (by sales)
- Pricing controller (by pricing group)
Consumer
- Viewer (of both product and price data, by marketing and sales)
- Product validator (by product engineer)
- Pricing validator (by pricing group)
Mike Cohn in his book defines user role as "a collection of defining attributes that characterize a population of users and their intended interactions with the system." To me, this is the verbose version of "relationship to the system".
