Define system user roles
When workshopping, outline and define system users. System users are the people who maintain the product and also interact with it. Think about system roles as all the entities that the new product will have an impact on. Consider how this new product affects these users and their projected interactions with the product.
For example, when rebuilding the application that helps a bank automatically approve loans, the roles could be
- system administrators;
- underwriters creating risk models;
- loan processors performing manual exception checks;
- account representatives working with the customer;
- customer getting notifications about their loan;
- department leads reporting on the loan approval metrics; or
- compliance and security departments capturing event logs.
A seemingly simple application with a single primary user type can influence a lot of different system roles—directly through the workflow or indirectly through the speed and quality of service.
After extracting all user roles from the prospective client team’s SMEs, identify the following for each role:
- The goals of the user: Listing the outcomes for the user (e.g., process two times the applications while making 30 percent fewer mistakes)
- The challenges/frustrations the user faces: Note the obstacles or pain points the product seeks to remedy (e.g., the need to rekey information, having data distributed across multiple screens)
- The typical day for the user: A high-level description without going into actual functional user journeys
- The current resources: A list of applications, tools, and sources being used to perform day to day responsibilities related to the domain
Discuss with the stakeholders how the roles should be ranked in terms of importance from a productivity perspective. For example, improving the workflows of the underwriter and the loan processor should create 80 percent of the business value for this product—and then continue to user journeys as the next step.
