Personas misconceptions
Personas are a powerful design technique and a great way to design products. They are even becoming to be standard in user experience design. Personas can help in building and reinforcing design culture and foster collaboration around real user goals and needs.
However the concept of personas is so broad, that by misinterpreting it, enterprises can easily turn in a wrong direction. Instead of building evidence and data based design culture, they start to rely on intuition and interpretations.
In my current mission, I am trying to advocate Goal-Directed Design methodology. There are resources available directly from Cooper dealing with personas misconceptions (by Teresa Brazen). I decided to add my POV and summarise few personas misconception symptoms that I was able to observe.
Frozen Personas
A lot of the times, a design-driven project starts with an input of external design agency. There are a lot of benefits in this. External consultants can provide a new perspective and deep vertical design skill-set. However, external consultants have very little control over the full lifecycle of a product design and design deliverables. For large enterprises, product design takes months and years, even when they ship results in fast and agile iterations.
After ethnographic research phase, personas are constructed and used to define scenarios and design framework. From this moment, these become to be the only design artefacts used to communicate design.
At large enterprises, everyone is busy. Busy people look for shortcuts. Stock photo with persona name, headline, nice summary — everyone gets it. It's done.
Even when personas are served with some research background, very few stakeholders dive deeper into research objectives and research synthesis. They see that {n} number of real users were interviewed, so this means that these personas are valid.
In reality, every research has gaps. Not all the necessary people can be interviewed because of deadlines and budget restrictions. People's goals and motivations evolve over time. For a professional product, it is very hard to observe and interview non-users, e.g. users of a competitive product. IT professionals are working in complex eco-systems that as whole evolves rapidly (DevOps, SaaS, Mobile). Goals and responsibilities of the same group of professionals just cannot be the same as they were 2 years ago.
When this dynamic change is not taken into account, personas become to be locked. They represent a frozen snapshot of time with fixed constraints and never validated research gaps.
Ethnographic research is not one time only activity. Personas are not frozen final deliverables, but living design artefacts that should evolve over time. Research gaps are important part of the research. It is not possible to assume that any sophisticated research at any scale will answer all the questions in just one iteration.
Interpretation
General assumption with "everyone is a designer" approach is, that design should be not a responsibility of a small group of experts. It is rather a responsibility of the whole organisation, which means that everyone should participate in design execution.
While the general idea is good, the flip side of the coin is undervaluing complexity of design domain. It is safe to assume that anyone can provide valuable design feedback and critique. But clearly not anyone has the appropriate knowledge to execute the design.
The most visible symptom is persona interpretation or sometimes called elastic personas. Different roles in product development process tend to project their POV through the persona artefact. If you apply enough abstraction and good rhetorics, to define any software requirement you just need any persona stock photo with a headline.
I can recognise this symptom every time I see a powerpoint with persona name, that contains different content (goals and motivation) than original persona artefact synthesised from research.
Clearly not everyone is designer. To fully understand and apply complex methodologies such as goal directed design and personas, it is not enough to quickly scan through final persona deliverable in powerpoint.
Professional designer sharpening his hard skills in all design areas from gestalt psychology to interaction design would more likely spot typical cognitive biases such as anchoring or bandwagon effect (by Wouter de Bres).
There is very little gut feeling and intuition in a good design. Even that personas came from extensive research, their interpretation is an assumption that always needs validation with real users.
Marketing messaging
Persona deliverables tend to be appealing. They provide a human touch to abstract technical problems. People quickly fall in love with personas, and tend to re-use the same deliverable across the organisation — from marketing through sales and technical support.
The drawback is, that the information stream is then reversed. Instead of observing users and synthesising important discoveries into persona artefacts, users are presented with personas as something they should fit into.
When marketing presentation contains persona description, it looks like a triumphal statement of "Look this is you, we figured it out. We know you better than you do".
While I am embracing transparency of my own design process, personas are too intimate and personal to be shared outside of the organisation. They are subject of change and people would have hard times to relate to a changing artefact. After all, it is personal data that are synthesised into persona goals and we promised not to share it.
There are many complementary techniques whose final deliverables might look very similar to personas — such as market segments. Together with design personas, market segments can form a coherent system to drive the customer experience design. But as each was created using different techniques and intended for different purposes, they are not interchangeable.
User profiles
Imagine a situation, where field consultant is giving feedback to a development team about the customer visit. To the team, it feels confusing and full of contradictory statements. One of the team members is asking "What persona is this particular user representing?"
The answer is "When he logs in, he is like Alexi. But then he used {Feature A} like we designed it for James. But when having a conversation with him I would say that his goals match Tim, even that his skill-set and job responsibilities were different."
The team then assumes that with this explanation, bad feelings around contradictory statements were cleared out.
Humans are not X-men transferring their bodies into different humans. But to the engineering team having agile background this feels natural. Engineers often see personas as user profiles or roles, as a hat to wear when interacting with the technology.
When formulating use cases, engineers expect that the same person can "log in" and interact with the technology "as Administrator" as "User", or as "Alexi" or as "James".
Personas came from research with clearly defined objectives. When research was not focused on a specific area, these personas cannot be retrofitted to design different product area.
When research was focused on goals, motivations around security and authentication, then the outcome of this research (personas) cannot be used to design holiday planning system by only replacing "As a User" with persona name.
In sample feedback above, it is clear that the team has just spotted research gap that need to be addressed. Contradictory statements has to be taken as assumptions that needs to be validated before jumping into conclusions and designing any product or user interface.
Conclusions
Frozen Personas, Interpretations, Marketing messaging and User profiles were the most visible personas misconceptions that I was able to observe over the time.
Fire is a good servant but a bad master.
Personas are a powerful technique and great way to design products. But they are just top of the iceberg of a deeper concept of ethnographic research and other assumption validation techniques.
I am trying to embrace design as evidence and data-based problem-solving discipline. I would like to provide enough visibility to my own design process so that all the stakeholders and users can see behind the curtains of what it takes to design a good product.
I welcome broad stakeholder discussion and feedback. I believe that to a certain degree, everyone in an organisation should be interested in user experience design. But this does not necessary mean that anyone can grab final persona deliverable and re-interpret it in any other area.
Correctly defined user profiles might help to define personalisation requirements. Properly researched market segments can help to broadcast product benefits and USP to customers and decision makers that are not the same as end users. And together with design personas that include internal users, they can form one coherent customer experience design system.
