Listen to Your Users, but Don’t Surrender Your Own Vision.

This post was inspired by one of my apps – Time Clock Helper. As I mentioned in a previous post, Time Clock Helper was written because I needed to calculate the hours I worked on a standard punch card. The app has been in the app store for a while and used by a lot of people. So, that being the case means that I get requests for features regularly. Some of these features are good ideas such as being able to track more than a single day, or emailing the hours worked to someone else. They weren’t aspects that I had originally planned on, but they have proven useful to many users. I didn’t have to give up the core reason for the app to implement them, or make it more complicated to use.

Well, sometimes the requested features don’t make as much sense. One example of this was making a way to track multiple employees using a central server. While, it would be possible to make that happen and I know it could be useful it would take away from the actual purpose of the app. There are many apps out there that do just that and probably do it better than I would have. That wasn’t as much the issue, though.

I wanted an app that would make it easy for a user to calculate the hours worked on a single time card using the standard four punches. Anything that makes that more difficult would take away from the actual purpose of the app. So, while I like giving people what they want, I make sure that it makes sense for the overall app and won’t hurt the original purpose for the app.

As you develop your own apps, it is important that you know what you want to accomplish, and who would most likely use it. Then, try to only implement features that will be needed to serve those users. It is really easy for features to creep into an app that make it more difficult to use, or hurt it in other ways such as clutter, or slowing it down.