Consider the User (& Other Essays)
There’s an old saying — “assuming makes an ass out of you and me” — and I’ve never been more convinced that those of us who deal in user-centric research, development, or design ought to wear a crest with that emblazoned on it.
I was fortunate enough to attend the inaugural UXRTO conference in March; as a person whose love of data and research sensibility underlie nearly every decision they make, spending a day having frank conversations about why we need to prioritize user-focused research as we move forward in product development was a breath of fresh air.
It’s easy to forget about why — or more importantly — who, you’re doing something for.
It got me thinking about my methodology as someone who consults, asks questions, and sources contractors to execute building products and writing content that aims to solve a problem or answer a question. Whether it’s a content strategy with multiple persona needs, re-jigging site architecture for navigability, or improving a user flow to tie those things together, there is only one starting point: consider the user.
Numbers, like hips, don’t lie.
It’s natural to be precious about something that you’ve poured your heart and soul (and so! much! time!) into. Becoming personally attached to something can be as equally fulfilling and motivating as it is a tunnel you can’t see through. When you think you’ve come up with a solution that is elegant and right, it’s nearly impossible to consider that it might not be. The bravest thing we can do is figure out why something isn’t right, and try to correct the course.
Much like working through our biases, being honest to the strengths, weaknesses and blindspots of your team, product and/or company is tough. Confronting these things means divorcing your emotions from your assumptions, and getting some data to back up what you’ve assumed to be true.
Opening ourselves up to data and feedback that challenges our assumptions will only make things better; it helps us better serve the people we’re solving for in the first place. Qualitative and quantitative data are what help us paint a picture that marries functionality with anecdotal user evidence, and as painful as it can be to see that you were wrong, the numbers don’t lie.
We each come with our own set of biases, but when we’re too close and precious about something, we run the risk of being blind to roadblocks.
It’s okay to be wrong.
When you’re developing a product — whether it’s a website or a video or a web application — centre yourself in the mind of your user(s). Brainstorm how the product might cause risk or harm. Think of how it might conflict with culture, or socio-economic status. Talk to your stakeholders. Conduct a risk assessment. It’s painful to admit the potential of being wrong, but if we think of it as a pay now or pay later principle, I’d always rather pay now.
But how can we mitigate risks and minimize the likelihood of being wrong?
Consider the user: think of how features are different for other people, or how your experience will differ from theirs. You are not the user; if they aren’t interacting with the product how you expected them to, it’s time to understand the root cause before you create a solution. Luckily, the answers are in front of us.
Your users are already telling you what they want, and what they need. When you’re ready to listen to them, they’re talking about features and functionality — do some keyword research, scope your competitors, read review sites, and dig through Reddit. Finding out the good and the bad is key to making your next iteration that much better.
If you start making a list of loose threads, you can start to see where assumptions begin to unravel. And underneath that tangle of string, we can see the issues and the potential pain-points, and get right to mending them.
Go ahead and jump.
I have a hard time admitting that I don’t know everything, but I’m working on it. If we want to be better product managers, UX designers, developers, content strategists, etc., the best thing we can do is be transparent about what we do and don’t know.
Not sure who your user personas are? Learn them.
Not sure what the product platform is? Learn it.
Not sure what all the features are? Learn them.
Becoming an expert on your product and how it interacts with the rest of the ecosystem is invaluable. Whenever I take over a new project, I go through the entire process as if I am a brand new user. I read every piece of content available to me. I follow the steps exactly as we’ve laid them out. I try and do what the product wants me to do. I take that and figure out where the disconnects between my own expectations and assumptions of my behaviour are. If there’s a disconnect between the documentation, onboarding, or how the product’s being advertised, that’s a problem we can easily solve for just by seeing it with fresh eyes.
Other than your users, the best people you can talk to are people who are closest to them. Sales people, customer service reps, community managers — they know the shit because they see it in real time. They’re the best sources for anecdotal evidence, and developing a system where they can log that information for you to analyze will be something you’ll thank yourself for later. These people are also the best for helping you determine if something is an edge case, or a real problem, not to mention that you’re all committed to making something better, and it’s nice to feel supported in that endeavour, especially when the data feels overwhelming.
So jump the heck in. Don’t be afraid of the people you’re trying to serve — they just want a better product too.
