This other day I was just minding my own business, you know, coding and stuff, when I suddenly felt the full wrath of a dissatisfied user. As it turned out, my last year’s project completely missed the mark for this user and he just casually dropped by to give me a piece of his mind. I’m guessing it’s a matter of time before he’s back again.
I’m not exactly troubled by the fact that there are dissatisfied users. It’s hard to build something that pleases everyone and I don’t think it’s realistic to work under such constraints. What really gets to me though is the fact that I completely failed to realize that there were such users while I was running the project. In fact, had I realized that, I would have definitely done something to make up for it – if nothing else, at least a pre-emptive PR campaign.
No, it’s not that I was slacking off. Even though I’m a developer, I typically also run a part-time product management shop out of my cubicle to verify and rectify the original requirements (trust me, I discover a lot of problems that way). In addition, by keeping people involved throughout the project, I can usually claim some pretty satisfied users.
But it still bugs the crap out of me that I didn’t detect these other users who expected something else.
Playing this back in my head, a few things come to mind. The satisfied users were:
- Easy to communicate with, which led to in-depth conversations that helped me understand what they want
- Proactive with feedback and eager to try out new features right out of the oven
- Equally obsessive about getting this done right
As for the dissatisfied users:
- Communication problems. For example, I had distributed beta builds in the hopes of getting some good criticism but didn’t get any. Case in point, the same person who came by to yell at me was given a copy of the said beta build. However, he somehow decided to hold his silence until it was too late. This turned out to be a widespread issue among dissatisfied users.
- Lack of mental connection. For example, I’ve had people express scepticism about Subversions’s ability to automatically merge concurrent changes. Since Subversion has been doing that really well for years (and before that we had CVS and others), I had to disregard such comments and take the person with a big grain of salt. Not to say that these people actually offered any constructive feedback on the beta build – the discussion never gained any depth. There were a number of such incidents and my course of action each time was to stick with the information from people I found reliable.
How to do better next time? First, you could say the dissatisfied users had their chance and blew it, so they fully deserved this. Well, yes, but I still can’t stand the idea of having dissatisfied users period so I’ll need something better than that.
Looking back at it, it’s a puzzle. I’m building something. I have to figure out what it is, sometimes while I’m building it. There are hidden clues everywhere, reliable and unreliable informants, some of whom withhold crucial information for irrational reasons (too shy, embarrassed, high…). The plot thickens with every conversation, every demo, every new realization. Put it together correctly and you’ll have a project that’s deliverable within specified constraints, and will have a reasonable number of satisfied users. Get it wrong and you might wind up doing it all over again in a couple of years.
When dealing with inarticulate users, remember to ask very specific questions. For example, asking “do you need a vehicle with off-road capabilities?” might give you some of the same blank stares and perhaps amusing answers like “I don’t think it’s possible for cars to operate off the asphalt”. However, ask “do you want acceleration right and brake left?” and you’ll be more successful at jogging the underpowered neurons on the other side, and maybe even have a decent conversation.
I think I’m gonna try that next time…
Val's Blog 