Responding to user requests

Ever since I launched my little personal project a few weeks ago. I've gathered a small posse of real users. And real users, especially those that use the app every day, all have their own specific needs and wants.

Jeff Atwood recently wrote an interesting piece titled: Complaint-Driven Development. He describes how his team used complaints from the user to drive the design of their product. Basically it works like this:

• Get your software in front of as many real users as you can.
• Listen to all the things they complain about. It will be… a lot.
• Identify and fix the top 3 things people keep repeatedly complaining about.
• Do it again.

I think that this idea works well in theory. I think that the risks lay with the implementation of the idea.

Listen to the need, not the solution

When users formulate complaints, they will often do so in the form of a solution. For example, one of my users told me that they would like to be able to click on the start or end time of an activity and edit them directly with the keyboard.

That complaint is very valid. However, doing it the way it was expressed is a very risky proposition. It increases the complexity of the app and has the potential for making things difficult for my mobile users.

The need behind the complaint was that it was rather difficult to precisely control the position of the slider. It was a little too finicky. So, I formed a hypothesis that if I made the scale for the sliders more relevant to a normal workday, it would be less tricky to get it to stop on the right time. I released that and hopefully, users will be able to prove or disprove that hypothesis.

Always check against your product vision

User complaints can pull you in all kinds of directions. A guide that I am using to filter that out is to check against my original product vision. In particular, I wanted to make sure that I don't stray away from some of the company objectives like increasing the quality of the timesheet notes. Sometimes those don't perfectly align with solving your user's complaints.

And like everything else, I need to recognize that the original product vision is itself a hypothesis and it needs to be put back on the table if needed.

Be grateful for user complaints

The most exciting about this little project of mine is that I have actual real users. When I started it, I knew that I would use but that was it. I built a huge backlog of things that I wanted to add. 16 years of software experience told me to do that. My real users are making me realize that this long infinite todo list is filled with things that are not that important nor are they valuable.

With real users, that long infinite todo list seems a lot smaller.