Taking the theater out of the UX
It happens to all of us. We keep talking on behalf of the user, while at the same time crazy deadlines and resource constraints within the organization makes reaching out to users really hard. That’s the concept behind “UX theater”; UX professionals using UX methods and tools without talking to users. In this article I cover how I learned to mitigate this problem. As I said, it happens to all of us.
Whether you are a solo UX’er in your company, or you are part of a team, I’m sure you usually spend a lot of time communicating ideas, discussing findings and sharing insights with your team. Sometimes, for the sake of alignment with other teams, we even need to introduce what it is we do to the company. From C-Level people to junior developers and everything in between. Everyone seems to have their own understanding of what “User Experience” means, so agreeing on a common definition from the start is always a good idea.
I have worked with companies where, due to time/financial constraints, engaging with users was not a priority, so if I wanted to reach out to users or validate something, I would have to recruit candidates on my own. On the other hand, I worked with a company where 70% of the staff was in some way a “persona” and we had so much influence in our industry, that engaging users wasn’t a problem.
A couple of days ago I saw this tweet, and it got me thinking. The concept of “UX theatre” came along and I think is quite accurate. Basically, it means claiming to do UX while don’t engaging with users at all. And as I said earlier, I have been in companies where we did just that. And I’m not proud of that fact.
We are living in an era where technology is taken for granted. Everyone is creating their own apps, and there are apps for everything. No one expects apps to “just to do the work”. Users expect an experience, they expect digital products that makes their lives better for real, and that’s why user-centered design became all the rage.
But user-centered design is hard and it takes time. Finding time to talk to users (not your time, THEIR time), visiting them, creating prototypes, running workshops, observing them, organizing and documenting findings, sharing findings with your team, mining metrics, you name it. Regardless of the process and the tools, it is always hard. Because users are humans, and humans, unlike servers and programming code, are unpredictable.
But user centered design is hard and it takes time, finding time to talk to users (not your time, THEIR time)…
After reading the responses from the original tweet, I decided to put together some of the lessons I learned. Hopefully I can inspire someone to avoid doing “UX theatre” without losing rhythm.
Here they are:
— Ask Why: This seems really simple, but one of the common misunderstandings around the UX discipline, is that we are supposed to implement solutions created by stakeholders and “make them” user-centered. In my experience, most of the time projects are built around the wrong assumptions or the problem space is not clear. If you don’t ask why and define what is the expected user outcome, the rest of the process will be really complicated and confusing. And you might end up solving the wrong problem.
— Speak Up: As UX practitioners we need to be good at selling what we do, unfortunately, most of the companies are not mature enough to understand the importance of UX on their products and operations. Even though this has improved a lot lately, we still have a long way to go. Talk to stakeholders, explain to them what it is that you do, what your motivations are and why you do what you do. Most of the stakeholders are really interested in two of the things we do: solve problems and generate value, so it shouldn’t be a problem to engage them.
Talk to stakeholders, explain to them what it is that you do, what your motivations are and why you do what you do. Most of the stakeholders are really interested in two of the things we do: solve problems and generate value, so it shouldn’t be a problem to engage them.
— Share your findings: Data is king, especially when it is well presented and it aligns with the business goals. Every time you do user testing, contextual inquiries or workshops, make the habit of writing everything down and share it with the team. The connection between what the team does and user outcomes is really powerful. Try to bring up findings and anecdotes all the time, during stand-ups, meetings, retros, etc. The bottom line is: bring the user to the office as much as you can.
— Tools are tools: We waste so much time discussing which design software is better, which prototyping platform is better, if doing moderated usability testing is worth the time, if analytics tools are too expensive and so on. We need to keep in mind that we use tools to prove our hypothesis, to test task effectiveness and to understand our users. All of the conversations should be around which tool is better for the specific case, and if we can get the insights we are looking for.
— Measure: Right after defining the problem space, define what success looks like, you don’t have to define complex KPI’s. Common indicators such as: task completion time, task success rate, user error rate, user satisfaction, can make a good KPI. Defining KPI’s is not only important to ensure if you are achieving the expected outcome, but also to keep iterating and improving.
— Design is never finished: This one may seem obvious, but digital products are never finished. As UX practitioners we should be very good at compromising what is important and how we can keep improving and delivering the vision without suffering scope creep. Don’t forget to keep everyone informed of why you are compromising. Explaining why production code doesn’t look like the pixel-perfect mockups from the UX team. It should be a conversation around strategy, not a finger-pointing session.
— Be aware of the politics and be empathetic: Most of the software companies are political entities, and as such, there are different interests for different roles; a Product Owner will be focused on the delivery, the Product Manager will be in charge of getting the requirements covered, the CFO will be worried about reducing costs, Salespeople are looking to add new features so they can close more deals, and so on. I have found that it’s really helpful to understand each team member’s motivation and consider it when communicating with them. This is also really helpful also for dealing with developers. Have you tried to get a pixel-perfect screen out of a developer who hates CSS? It’s not fun.
In terms of reducing “UX Theatre”, this is what is working for me so far. If you want to discuss something, please drop me a line. If you are in Auckland, let’s go for coffee. Flat white for me. No sugar.
