Elastic Users & Role of Personas
What are elastic users and how personas can come handy in making critical design decisions while defining the user experience of a digital product.
Have you ever encountered with these kind of questions while presenting your design to the customer or the development team — “What will happen if the user wouldn’t like to do this… and instead the other one, which might be missing in the design…” If you have come across similar questions similar that get you in a fix, then please read on to find how to avoid the root cause of these situations.
These questions, most probably happen to be the edge-cases — in technology terms. These are the situations that might possibly happen, but usually won’t for the target set of users.
Goal-driven designs follow a process, in which user-archetypes are defined quite before plunging into designing. User archetypes are useful to understand the needs, goals and tasks of the real users. These user-archetypes are defined using the data insights found from the different sets of research activities accomplished on the real users. The user-archetypes, typically include all the behavioural attributes of most of the users and in fact represent a large section of users. The personification of the user-archetypes is done and given all the physical attributes of a real user such as name, age, profession et al. This user-archetype is called persona.
It’s always quite imperative to refer to a persona by its name, so as to be in the closest proximity to the users’ needs and goals naturally — being in that mindset. Now, the designer starts thinking in the shoes of that persona. So, there are the situations that might possibly happen, but usually won’t for the target persona.
The product teams, sometimes unaware of these background activities behind the scene, think around the complete set of users and may come-up with cornered or edge cases. In those product discussions, they tend to use the term ‘user’, which is too broad to cover all possible scenarios. We cannot prioritise user’s goals just based on our assumptions or perceptions. Mostly people talk about the needs of the ‘user’ from their perspective.
The astonishing fact about this discussion is, while that the team-members are talking about the ‘user’, which is a replica of the users’ perception in multiple scenarios in their minds. These are not the real users who, represent a large set of users in that particular context. In this way we can conjure up as many different kinds of users as many participants are there or even more than that. With so many user representatives existing in the minds of team members, we can not build a consensus on user needs and it will lead to a stalemate.
Thus, stretching the term ‘user’ to refer to a wide variety of users brings the elasticity in the term ‘user’, and so the participants stretch it and mould it as per their perspectives. This ‘user’ term is referred as Elastic User. The communication language for all the participants use the term ‘user’ to refer to the current user of the product/system, which we refer to as elastic user. Designing for the elastic user gives a product development team freedom to build what it pleases, while still apparently serving “the user.”
To get rid of such situations around elastic users or too many edge cases, we take the help of the insights from the user-research, and create a user-archetype that can serve the purpose of non-elastic and realistic user referred as persona.
A meticulous examination and analysis of the research findings is carried out and the behavioural attributes of the real users are identified. Along with that, the different other attributes of the users pertaining to the use of the product can be determined. The users are mapped to those attributes with a logical precision. Here logical precision tells that, the user need not to be quantitatively mapped exactly to the attributes, rather a comparative mapping can be done.
In order to map these users on a technology-friendly parameter, say “gadget-loving”, we can have a scale with two ends — technophile and technophobic. John can be mapped to extreme end of technophile and Fredrick can be mapped little close to John but more towards the centre. While, Michelle can be mapped little close towards technophobic end. So, this kind of attribute mapping is always relative in nature rather than precisely quantitative. This is what logical precision means. Similarly, all the users under the study and the research are mapped to create a pattern. This evolving pattern that comes out of the mapping represents different user profiles. The patterns, which cover around 8 users can be identified to be grouped under a persona. In this way, we create personas, that represent a large group of users in terms of their needs, behaviours and goals.
The importance of personas can be illustrated in the office wall for public display or it can be explained in a quick discussion before a decision-meet. The small but significant notable point here is, to refer the user by the name of the persona while explaining a persona-based scenario is equally important. It’s always important to note while practicing a UX-process that we should avoid two common mistakes –
- Conflating different situations in different contexts
- Referring to the large set of users with the term ‘user’
Practices to follow for a directive discussion without unnecessary digression are -Talk about persona before a design decision meet
- Call users with a named Persona in a context as per the scenario
- Drive the discussion only on the lines of scenario.
- Emphasise on thinking in the shoes of the personas rather than having a preconceived notions about users and get your biases away.
- Do not confine the persona with excess situational constraints so as to welcome too many perspectives and ideas.
- Edge cases must be designed and programmed for, but they should never be the design focus.
In short, Real users’ needs and behaviour can be better understood using personas, that are defined based on exhaustive research insights and ‘these personas in a scenario’ should be used to drive product discussions so as to build a truly usable and useful product.
As this is my first story published on medium, I’d love to know your thoughts in comments. Do not forget to clap 👏 if you like this stuff! (That’d help me share more such stories!)
