UX myths to forget in 2020
In August, 1971, a Stanford psychology professor designed a simulated jail environment in the basement of Jordan Hall, where 18 college students would role-play prisoners and guards during 2 weeks.
The hypothesis: witness how people would abuse power when given the proper circumstances.
It was called the Stanford Prison Experiment.
The experiment became widely accepted by the psychology community. It has been cited in hundreds of papers. Films and documentaries used it as inspiration. No one ever questioned the validity of the experiment. No one but Ben Blum.
It was recently discovered that the Stanford Prison Experiment was a deceit. Philip Zimbardo, the psychologist professor behind it, paid both guards and prisoners to act in order to exacerbate the premise of the experiment.
All of a sudden, a lot of decisions by psychologists were made based on a false assumption.
5 years ago, when I was embarking on the journey of becoming a UX practitioner, I was impressed by the willingness of the community to share knowledge, as well as the endless sea of available resources to consult: case studies describing full-blown UX processes, templates and freebies to experiment with, and lessons learned by talented designers while practicing design.
But all these available resources also came with a high price: information overload.
UX Frameworks aiming to solve any project no matter the constraints. Inbound marketing campaigns disguised as “free” content. Blog posts and stories more interested in claps than learnings to share.
The unfathomable stream of information made more difficult to distinguish the signal from the noise. As James Gleick once said:
When information is cheap, attention becomes expensive.
In the spirit of embracing a new year with more truths, following are (only) five myths and bad practices that are taken for granted in our discipline time and time again, which can alienate us from reach maturity as UX practitioners.
Myth #1. Design is about problem solving
Defining designers as problem solvers semantically implies that we are the only ones who get to solve them. This is a complete fallacy, as we are neither special nor the center of our organizations.
Problem solving is a team’ sport. As such, we should involve multidisciplinary roles when making and executing decisions.
One of the definitions of design that I am most fond of is the one Jared Spool advocates for, who defines it as “The rendering of intent”, because of its simplicity yet eloquence to describe our profession.
However, I came across a different one by author Dan Brown who describes design as facilitation. Both definitions can dance together and give us a clearer visualization of our roles. Let me explain.
We are not problem solvers in the sense that we cannot afford solving a problem that users don’t have, neither organizations can benefit from. Before solving anything, we need to define what the real problem is by doing discovery efforts, and bringing shared understanding to our teams over the best-educated guess of the problem we are going after. Once the team is aligned, we then work with a multidisciplinary team to facilitate the solution of the problem.
During this facilitation, we build specific artifacts to have the conversations we need to have in order to get us one step closer to the solution. Those artifacts might be wireframes, prototypes, or even a single whiteboard session. A lot of designers put too much emphasis on the output rather than the outcome, but we’ll cover that later.
Designers do not solve problems alone. They first identify the root cause of the problem and then work with cross-functional teams to facilitate its solution.
Further information
Donald Norman on why he never solves the problem he is asked to solve.
Myth #2. You only need 5 users to spot 80% of the issues
In 1992, Robert Virzi released a paper stating that 80% of usability issues of a system would be detected by testing with 5 subjects. Ever since, we have told our stakeholders that 5 users are enough to check the validation box on a project.
5 users are going to get us to the other side.
I am totally fine with (starting with) 5 tests, the problem is assuming that it will reveal 80% of the issues. We are not in 1992 anymore. Products today are way more complex and intricate as they are used by more people (hence leading to more likely scenarios), and we are doing the organization a great disservice by selling this “magic pill” of only 5 usability tests because it is easier to pitch, because we don’t need to deal with rejection that much, so we can go back to wear our headphones and do design.
If we inherited something bad from classic design is the idea of finite design. Design is never done.
Start with 5 users, and then another 5, and so and so until you are able to predict user’s behavior, what Jared Spool defines as point of least astonishment.
Further information
Myth #3 Focusing too much on the methods
With so many frameworks, books, card decks, and methods being published every day, it is easy for designers fo feel “Fear Of Missing Out” and be more comfortable adopting an out-of-the-box way of approaching a project (e.g. Design Sprints) than taking a step back and analyzing the situation before defining the process to solve it.
Methods, frameworks, and playbooks give us certainty. We don’t need to allocate cognitive effort to come up with a new way to make things. A decision less to make. Why reinvent the wheel every time?
The drawback is that there are no two equal design problems.
Take deliverables, or its 2019 version: artifacts, as an example.
Creating artifacts has never been the goal. The end goal is the conversation. If you can get your point across with a single session with your developer on a whiteboard, then you don’t need a wireframe. But not having your symbols and Zeplin up-to-date is scary, right? So we spend our whole life drawing rectangles, pushing pixels, and then handing off the artifacts because we’re too afraid that developers might do something wrong, and we never have the conversations that really matter. The ones that will help the team ship something faster to our customers, have real feedback, and then go back to the whiteboard and make new decisions, based on the discoveries the team made.
As Jon Kolko states:
No method can be the solution for solving the world’s hardest problems. Only hard work, perseverance, and a lifetime of experience can drive the real problem solving, form giving, and changemaking we strive for as designers.
Myth #4. Generalists vs specialists
IDEO co-founder Tom Kelley once said: “there are some problems that might be better solved by going deeper, and there are others that might be solved by going broader”.
I don’t claim to have expertise on anything, nor that I want to. I do however have a lot of areas of curiosity. If you’ve read Designing your Life, you know that it does not matter whether you know where you are going to be in the next 20 years, you only need to figure out what your next step is.
The piece of advice: explore all areas of UX: User Research, Interaction Design, Content Strategy, Information Architecture, Visual Design. Even Front-End, and if you feel energized by doing one of them, give it a second chance, but don’t precipitate too early on trying to find “your passion”. By exploring the whole threshold, when you encounter with a really complex problem, you will know to what extent you‘re capable to address it; what’s more, you will know which areas and disciplines might have a better chance to solve it, because you went through them already.
Myth #5. UX is only about the user
It strikes me that the worst enemy of User Experience is its name itself. Not because of what it describes, but because of all that it leaves aside.
It does not consider understanding the technological constraints that designers need to figure out at the beginning and during a project.
It does not account for the fact that designers not only work at the service of users, but also organizations that need to stay on top of their game by driving innovation.
No user (no matter how early adopter) is going to knock at your door, ask you to remove your headphones while you were merging your branch on Abstract, and give you X amount of money so you can solve their problems. Companies might be in that position. But you need to do some tradeoffs. This does not mean that you will stop being customer-centric; that is still the ultimate competitive advantage, but you need a trojan horse that will help you bring customer centricity to the doors of your organization. That trojan horse is empathy with stakeholders, and a baseline of business language.
You first need to show real interest in the organization’s goals. Conducting stakeholder interviews with key players to figure out how do they measure success. Mapping out in which archetype do their decision-making culture fits. A great resource to develop a discovery strategy is Dan Brown’s book Practical Design Discovery.
Once you are able to discern the definition of value for the organization, you can start doing discovery efforts to figure out the user’s needs, and coming to an agreement with the team involved towards which user behaviors do you want to encourage/discourage, that will likely end up in delightful experiences for your users and drive business value.
At the end of the day, we are not trying to make organizations richer for the sake of capitalism, or blindly advocate for user’s needs because that’s what our job title says. Our real mission is finding the middle ground between what users and organizations perceive as value, and doing a fair exchange of it.
There is an old joke about how Edmund Wilson, an extraordinaire writer and critic, would read books “as though the authors were in trial for their lives”.
With such scrutiny should designers embrace the information we receive every day. With such scrutiny should you have read this story, and with such scrutiny should you approach your everyday work and the decisions you make, as the combination of all of them is what will define the success of your work.
