UX research for indie devs
Indie devs, being your own user isn't the only way to do UX research
How does one go about creating products? How do you find the pain points of your customers? Do you do research/ask/read about them? What's the process for that?
The indie dev's typical research approach for products
As an indie dev, I only have 2 criteria when it comes to selecting products to make - something that solves my own painpoint that I love to make (or a painpoint I’m super familiar with), and the product is monetizable. I do UX research in my day job as a consultant so there’s a whole process for it, but when making my own stuff, I usually don’t go there as it’s too early stage, and I prefer to launch MVPs and get feedback from there. But I try to tap on the intuition and skills of UX research in the background to make decisions.
A great way to do user research is to develop empathy for the users’ painpoints. Scratching your own itch and being a user of your own product - “dogfooding” they call it - happens to be a fast-track way towards that empathetic understanding of the users’ painpoints. Because you use it yourself, there’s a substantial amount of empathy that you can translate over from your own specific, individual experience to that of your collective users (how much depends on context and product). That’s a popular indie maker approach, because it needs next to no UX research capabilities or training. A maker just wants to be a maker and make stuff, not go for class in UX research because they’re not interested in being a UX designer.
Scratching your own itch isn't always possible
But dogfooding and scratching your own itch not the only way, because sometimes there’s no way you can be a user - imagine how designers can design a product for cancer patients when they don’t have cancer themselves. Do they go inflict cancer on themselves then? Not realistic to do so. So how do they do that?
What matters most is that the maker/designer is super familiar with the problem space and have deep empathy for the painpoints that the users face, even if they don’t use the product themselves.
UX research methods for indie devs
Some ways to get to that deep understanding is doing good design/UX research. Some basic, 101 type of methods/techniques:
- Shadowing - shadowing the user for a day means following them for a day as they use your product/service, immersing in the everyday experience of the user, walking in their shoes, which helps you get a lot more nuance and empathy that might be beyond the screen into the real life context and constraints when they are using your product.
- Contextual inquiry/ethnographic interviews - sometimes you need to probe deeper into their motivations, aspirations and personal stories in order to truly understand the larger picture. A survey or a remote video testing session won’t cut it for such purposes. So having in-depth conversations with your user for 60-90 minutes allow you to really dive deep.
- Field observation - sometimes when engaging the user face-to-face, they might unknowingly ‘perform’ for you and you might get inaccurate data. So the best way is to observe people using your product without them noticing. This technique is great for services, where you can just sit quietly at the corner and observe people coming in and out of your service counter. But it can work for digital products too.
- Bodystorming - even if you’re not the user, you can role-play as one. When designing an app for folks who are blind, designers can blindfold themselves and go through the same experience to develop empathy for the users’ painpoints.
- Prototyping & testing - one of the best ways to truly see if your product works is to create a prototype and put it in the hands of the users, observe how they interact with it in their own environment, and get feedback on it.
What you can do
These methods doesn’t have to take too much time actually. You don’t have to go to research saturation of engaging 30-50 users! As an indie maker, just find 1 or a few users, and use one or a selection of the approaches, and that would already be super helpful.
Follow my daily writings on Lifelog, where I write about learning to code, goals, productivity, indie hacking and tech for good.