and I’ll tell you how I can help.
Don’t worry about what you think your needs are, I’ll do that for you. I am a user experience designer. The hero you need when the situation is dire. Like batman stopping a mugging in a dark alley, I will drop in to stop the bleeding and return the income to your wallet.
At least that is how I envision myself. Other UX designers, don’t lie. You feel this way too. That’s ok though. We need to feel self-important. How can we help and provide a valuable service if we don’t believe in ourselves. Even the newest among our ranks (me!) can be of immense help in adding to the bottom line.
We all have standard training that we employ in our problem solving and discovery processes. As long as the goal is the same, even two separate solutions can have similar benefits. What matters is an examination of the issues and finding solutions. Up to the point of actually working with users in a testing scenario there are so many ways to get there. It is best to consider how will you uncover the issues. What are the methods that help you learn. Are there some methods that don’t work for you? Instead of just going through a standard trope of methods, you should be looking for the methods best suited to your style of research.
As a personal example, lately I’ve been really into using journey maps as one step towards discovery and learning about user pain points. I didn’t always do this, but now that I do, I wonder whether I should have been doing this in my previous projects; “Was I overlooking something, should I have looked for alternate ways to view this problem?” Would I have come to the same conclusions if I had used separate discovery methods? I think not because the problem will still be the same. Only the users can determine what those are, not the researcher trying to improve the experience. We are only reacting to those involved in using the product. We can’t change their perception of it.
As an outside observer, and not inside the user’s brain, we have no way of influencing how they interact with the product. We merely use our tools and methods to uncover the problems and make improvements that the user is essentially requesting through their complaints and failures to execute. So the question to address is: How best to get inside the head of the user? What methods are in your toolbox that you can use? We were all trained in multiple discovery methods. You have your favorites. Maybe you prefer quicker discovery solutions or diving into the minute details of competitive research. Is it working for you? Why does it work for you? Is there another method that might give you more insights? Does any of that matter even? I’m not sure it would. Like I previously stated the problem is still the same. All the methods of discovery you employ will eventually lead you to the same conclusion.
The caveat here is that you are not introducing bias into your research and user testing. You may have been thinking this: It is the one wild card that could affect the outcome of your research. Bias is sneaky, but more prevalent during user testing since we have direct contact with the users. Our own bias and presumptions can have an impact on how we view things too. Being aware of your thoughts and emotions can help lead you along in your research. It can give you a direction to follow, but it can also give you a false confidence in your research. Just be aware of how you approaching the project. The methods are free of bias so if you are strictly documenting what you see, the bias will probably be minimized or avoided. I usually don’t worry about bias until user testing, but it is something to be aware of at all stages of the discovery and research phases.
Your story, tell it to me again and I’ll tell you how best I can help and what your needs are. My methods are honed and ready to deploy. I know what I am doing because i’ve done it many times before. When we get to the testing phase, then I will listen. Before that the directional control is all mine. So sit back, relax and let me solve your problem.
