User Types

← Back to Method Diagram

“User Types are defined by the services and the use cases they require , not by personal traits or emotions that have no value, meaning or impact on solution behaviour.”

Purpose of User Types (Proto-personas) 

Properly defining the User Types allows us to gather a comprehensive list of the services they need (functional Epics if you’re an Agile person), so that we might extrapolate a comprehensive list of the Use Cases that make them up. 
In turn, the Use Cases reveal all the significant, valuable functional requirements and will ultimately allow us to create accurate User Journeys from each User Type and then the functional Prototypes that exemplify them in action.
User Types are the starting point for all these research deliverables and are initially revealed in the EPaRM Mapping exercise.

This also allows us to identify a representative set of users who represent each User Type, to interview, observe and usability test with later at the prototyping stage, ensuring we end up with a cogent efficacious solution for all target User Types.

The User Type document sheds valuable light on the important people and necessary needs/services. This can be shared amongst the project team and help on-board anyone who joins the team later. It ensures we miss no user requirement and even helps establish the scope of the project for everyone before beginning building a solution. In establishing the scope of the users that will affect and be effected by the project, we establish the scope of their required needs, hardware, software and processes.

NB: In the absence of a User Type document, project leaders very often invent personas based on numerous superficial and hierarchical differences in the people they see. Assumptions take over. This leads to a lot of unnecessary pseudo-data, duplication of needs, code and work.
A User Type entry is very concise and defined by its needs/services, not by the person’s title, role, hierarchy or some superficial identity differences. If two users have the same service needs and carry out the same Use Cases, then they are the same User Type.

Value of a User Type 

1. Project scope visibility: A comprehensive but efficient set of users and their required needs/services is revealed in this document. This gives insights that validate, modify or call in to question the scope of the project. It allows the client to confidently focus on where valuable changes live, so they can be prioritised and the project scope modified or validated to reflect only valuable functions.
2. Optimal behaviour modelling: In being able to identify both the User Type and their required needs/services (epics), we are able to plot only the necessary Use Cases to be researched, measured and designer/optimised in detail later. This helps ensure we deliver a solution that is truly fit for purpose, optimised for development and highly competitive.
3. Developer time and cost reduction: Developers and engineers can visualise a high level, preliminary model of services (epics) that the solution must facilitate. This helps them plan in advance of project commencement so that development time is optimised and estimated more accurately.
4. Expectation management: Visibility of the number of User Types and their capabilities (often not visible to management at all) allows us to reliably manage client expectations of the size, cost and effort involved in architecting and delivering the functionality required to deliver on the business goals effectively and in advance of any wasteful and expensive development.
5. We avoid duplication of work and behaviour. We do not waste time and money developing superficial or emotional personas that offer no insight or differentiation in solution requirements or non-unique functionality.

Anatomy of a User Type

Examples

NB. For security clearance and NDA reasons, some elements of the example files may be redacted, changed or removed.