Using personas
Designing enterprise apps using Personas and Roles
Personas appear to be a relatively simple concept, but its semantic representation opens the flood of many different interpretations. It is becoming a source of confusion not only across the design community but also transferring this misalignment to whole product teams. How do you actually use Personas with real-world constraints in an enterprise environment?
Cooper’s About Face provides a clear definition of a structured goal-directed interaction design process. I am sharing my own thoughts on pragmatic use of Personas in the context of complex service management product design process.
Tasks
In an enterprise environment, chances are that you are not inventing a brand new task type. By using your product, people will not change their daily routine, job description or salary band. People are required to perform a certain task as formalized in job role description and organizational chart. This does not necessarily say that the task is aligned with individual people aspirations or that the task is making any sense ¯\_(ツ)_/¯.
Synthesizing the task workflows is an essential part of the user research, but might be not discovered during direct user interviews and does not necessarily overlap with patterns discovered when synthesizing Personas. People might be not able to describe a complete end-to-end task or define all the possible conditions and variables as they are focused on optimizing their individual performance and not necessarily responsible for the outcome of the whole department.
Interviewing management and leadership stakeholders would provide the team with important information about the organization’s outcome expectations for a particular role. In my pragmatic approach, I also recommend capturing the existing legacy system interaction regardless of how horrible user experience it might currently provide. You cannot improve something that you cannot visualize.
Roles
I am currently focusing on complex enterprise Service Design challenges and the trend is to employ a single service management platform to host all the apps. This opens great new opportunities for personalized experiences using various channels and user interfaces and comes with a challenge of designing for individual system roles — who can do/see/use what product features when using a single system.
These system roles are not always aligned with the organizational model because they are an abstract software construct. A human can use the system from a perspective of multiple roles. One day, a user is assuming a workflow leader role responsible for dispatching the work for teammates, while the other day, the same user is using the same system from a position of a regular team member.
System roles are often a way how leadership and stakeholder envision behavioral change and advocate for a “correct behavior”. When the system does not fit the user’s mental model, people would simply bypass the workflow and hack their way around. This is a risk when designing consumer products, but there are many cases where introducing these constraints using role permissions is a valid design approach in an enterprise environment.
Because of legal constraints (e.g. Chinese walls), we have to design a system where data access is separated by role permissions. Department leadership and stakeholders can also have valid insights into the previous individual performance overview and purposefully introduce system roles e.g. team or group manager, that is not related to a formal job role or title and would not come from ethnographic field research describing individual goals and motivations.
Using Personas, Roles, and Tasks
Synthesizing user research into personas or capturing the job role tasks does not provide the value on itself. Just by presenting Persona attributes to stakeholders often leads to “So-what” moments, because from the artifact itself it is not immediately obvious why you did it and how this is supposed to be used. Chances are, that some of the opportunities identified by the research are already known for years and Persona appears to be an abstract construct.
Personas without scenarios are like characters with no plot. — Kim Goodwin
I use three storytelling techniques to capture the future or existing human-computer interaction:
- Individual people’s goals and motivations captured with Personas → Scenarios
- Organizational expectations captured with Tasks → Interaction Diagrams
- System permissions requirements captured with Roles → Service Blueprints
Scenarios
Personas are great when defining the overall product narrative. I use Scenarios in initial project phases and use them less in later project stages.
Interaction diagrams
Interaction and Activity diagrams are an important design tool capturing the interaction including various conditions and constraints.
Service Blueprints
During the early discovery phases, it is useful to use Personas to drive a collective understanding of an ideal use of the service. The ideal forum to build a mutual agreement is Design Sprint workshop.
In the next project phases, I re-design the Service Blueprint outcome using system roles. This artifact is perceived as less abstract and can be used either as a functional specification or as a handy service documentation deliverable.
Conclusions
It is possible to design a product without using Personas at all. Personas as a design artifact do not provide any specific value on its own, and they are a useful tool when defining Scenarios or Service Blueprints.
I have limited experience with using Personas in later project stages. They were useful to generate the initial stakeholder’s buy-in when demonstrating user research synthesis process. Once the project starts to run in incremental Scrum iterations, I never managed to establish a common vocabulary using Persona names and characteristics. It might almost appear, that they fade away and are not used at all 6–12 months after the initial discovery.
This is not entirely true, because we used Personas to define a global end-to-end product narrative using Scenarios. We also have usability testing data available, either from validating prototypes or real product increments.
I found Interaction diagrams and Service Blueprints defined from the perspective of system roles to be more effective techniques in the iterative design process. The roles are based on field research and aligned with stakeholder’s expectations. Diagrams and role-based Service Blueprints are useful as functional specifications and also help to build common vocabulary with many different technical functions involved in a service management software product lifecycle.
