When you have an idea for a new feature or product, all you want to do is “go go go!” It is that drive that turns great concepts into company success. But time and again, there is one wrinkle that keeps us from effectively executing on those ideas: the egocentric intuition fallacy.
The egocentric intuition fallacy is the compelling illusion that one knows the determinate of one’s own behavior and satisfaction…
– Helander, Landauer and Prabhu
I have seen the Egocentric Intuition Fallacy bring down great teams throughout my career. For example, a company hears from a single client group – or, more(likely, one user at that client group – and the company, in response, creates a workflow that mirrors how that one user, claims they would like to solve a problem. Problematically, it is almost never the case that the way any one user wants to solve a problem is they way most users want to solve it.
Even when a system is obviously hard, intuition may not reveal the true reasons…
– Helander, Landauer and Prabhu
We have all heard a customer, or even a member of the product team, who attempts to identify the goal of a software task by proposing an egocentric flow:
- PROCESS MIRRORING:
Use this process that already exists – exactly as is. Just make the tool allow me to do A then B and then perform task C which goes into D then E then F - SIMPLE MODIFICATION:
Leaving things as they are, I just need a big red button right here
I call these “can’t you just” or “I just want/need” requests – as the request often starts with “can’t you just do/add/change this?” That prefix is often a red flag that the request will be subject to the Egocentric Intuition Fallacy.
The problem with all of these suggestions is that they are proposals for solutions but do not involve the deeper question is WHY. Why must a user go through those steps? Or why do you need the button? Individual users can only see the tree right in front of them and this makes sense as it is not their job or responsibility (it’s ours as the product creators) to see the broader forest. Think of the often-used quote attributed to Henry Ford:
If I had asked people what they wanted, they would have said faster horses.
Individual users’ feedback provides a unique window into individual experiences. As product creators, we must remember that their intuition is most likely to optimize a local min/max rather than respond to a larger problem.
While this is a challenge to overcome, the Egocentric Intuition Fallacy has a second component:
We all tend to greatly overestimate the degree to which what is true for us will be true for others; we greatly underestimate variability in performance and preference… We put too much faith in a special sample of one, ourselves…
– Helander, Landauer and Prabhu
This second part impacts how we, as software creators, assess our own experiences and perspectives. How often have you witnessed or been a PLM or Engineer, that used their own experience as representative of a larger group of users and designed a feature around this?. When I was running my design studio, I heard so many clients claim that they did not fall into the Egocentric Intuition Fallacy because “I have been in field X for such a long time,” or “I used to do job Y.” However this thinking is exactly what the fallacy warns us about! With this perspective, a software creator will inevitably design a solution from and for their own perspective. But just as science requires more than one data point to draw a conclusion from (objectively collected) data, software creators must strive for the same objective: an unbiased approach to designing workflows.
Now that we know about the problems, the question is: how do we combat this? How do we avoid designing software for ourselves and thereby missing the perspectives of potential customers? UX designers have some techniques that everyone from CEOs, to PLMs, to engineers can follow.
Persona Example from “UX Aspects of Threat Information Sharing Platforms: An Examination & Lessons Learned Using Personas”
Personas – create a fictionalized representation of a group of users. This representation includes demographic information, their workflow (as it pertains to their position in a company), their personal goals, their professional goals, and their personal technology use. Now every design decision should be grounded by referencing this persona, rather than an individual’s (or lone customer’s) feedback.
Study the underlying task – rather than jumping to a workflow first, do the research (E.g. ethnography, interviews, etc) on the underlying task or on goals that users are trying to achieve. Use the current process as a guide, not necessarily in building the exact steps of a flow, but to understand the content and conclusions the end user must reach by using said product. Ensure that this information is reflected in your persona, and then design a feature for your software that gets that one persona to their goal as quickly as possible (not necessarily re-creating their entire process).
Understand the Errors -Determine how to validate a task, how its quality can be assessed, and how to find out when humans are most likely to face errors. Integrate this in your persona’s frustrations (assuming users are aware of the errors) or potentially in their professional goals. Then embed features in your design to directly call attention to these user errors (e.g. speed to complete a task, or detail quality for the task assigned). Thus the product not only solves the problem, but captures the trouble spot to reduce errors, speed up the process and help the end-user achieve their professional goal (making them covet your product).
Map onto Familiar Patterns – Find a comparable,existing software that users are familiar with and leverage that familiarity to create your tool/workflow. For example, if your tool has “objects” that get edited, saved, shared and collaborated,look to document management services (e.g. Office365, Google Docs, Box/Dropbox). If users interact with tasks to which they get assigned and then must complete and coordinate on, perhaps leverage other communication platforms (e.g. email, slack/messaging) or ticketing systems. By identifying platforms and products a persona is already comfortable with, you can leveragge the patterns most intuitive to them.Perhaps the most appropriate pattern is even from an unrelated discipline like gaming, music, or sports.
Run larger experiments – study many users andmap your findings from multiple data points onto ONE persona so that you capture common goals and challenges. This is preferable to over-fitting to one individual data point.
We know that taking the time initially to study and create personas feels like “not moving a product forward,” but consider that building the wrong feature or workflow often costs months or years. Doing the upfront studies and research should only take a few days or weeks and help avoid potential future re-dos (saving months) or the need for patchwork solutions (which no one ends up liking).
Cover Image by Kelly Sikkema on Unsplash
