Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

What do you do when a user asks for a complex feature that you could implement, but you aren't going to do it because 1) it adds unnecessary complexity to other users 2) you are not going to do it as an option either because you don't want your settings panel to be complicated.

I wrote an iOS app and there are a few users that asked me for some complex features that I can't do because of the reasons above. Most of the time I just answered them that "We will take that into consideration." Explaining them that they are in the minority that wants this feature is not going to help either. So, what do you do in the case like this?

share|improve this question
3  
Not an answer to your question, exactly, but in your example: you can easily have a very simple interface and have lots of features by hiding the advanced options away under something like "advanced options". Way too many apps only do one or the other, completely unnecessarily. –  MGOwen Feb 9 '11 at 4:45
    
You can't get away with feature intoxicated users. They have seen something somewhere and now they want that in their app. I have experienced this too often. The best option is to bring up two words "Schedule" and "Cost". –  abhi Dec 30 '11 at 16:30

6 Answers 6

I usually do three things when I'm in such a situation:

  1. I think twice if the user's idea might be a good idea after all. I learned not to trust my first instinct. Sometimes the user is right, and I'm wrong.
  2. Explain to the user why you can't include that feature.
  3. Explain the user how she can acchieve what she needs with the software she has

I think the last point is most important. Most users don't want exactly their suggestion implemented. They just need a solution to a problem and they suggest the simplest possible solution they can think of. Maybe you can find a better solution that you can implement.

share|improve this answer

I think that you should be honest with your users. Don't tell them, "We will take that into consideration", if you have already decided that you will not. That will lead the users to believe that the feature will come someday, and become disappointed because it never comes.

In the long run, that will benefit you the most, I believe.

share|improve this answer

I would just thank them for the suggestion but say its not on your road map right now. People will mostly understand that you have limited resources.

share|improve this answer

If you read Seth Godins blog (http://sethgodin.typepad.com/) you will see the same message coming through over and over:

  1. Ship something (and listen to the feedback)
  2. Don't try and please all the people all the time.

I've had a similar issue to you with a product I sell. I've had all sorts of requests for all sorts of features. The application has grown to be more complex than I really wanted. Every option adds complexity, something I wanted to avoid. And now I have more complexity than I would like.

Doing this pleases more users. And drives away users who find it to be too hard to set up.

Having simple/advanced setup is a way out of the bind. Up to a point. It makes your development more complex, though.

In all cases where I get a request, I always reply politely. Sometimes I will outright refuse, though this is rare. And where I do this I explain why, usually it would be in response to a request that would require the entire UI to be revamped, an undertaking so massive I just won't go there. In that case I explain my reasons, but thank the user for the request.

In ALL cases, including those I reject immediately, I log them in the features & defects database for consideration for the next release. This allows a bit more time to think about it all, and perhaps come up later with an alternative thats not exactly what was requested but might add some value.

If a feature request has been considered, annotated, and a decision is finally (at development time) made to kill it, then I close it. Otherwise they get left open for reconsideration later.

This is not a perfect approach, but in the end as the software author you have certain design principles that you need to wither stick with or abandon. The choice of each approach should be carefully considered.

share|improve this answer

You need to come to a compromise. Your user (the reason the app exists) is saying it doesn't meet one of his/her needs.

There is a difference between addressing the user's needs and allowing the end-user to design your application. Have a meeting with the user and ask a lot of "Why?" questions until you get to the core of the task the person is trying to perform and can't, or that is just too cumbersome to perform in the current UI. Take those notes and mock up some alternative approaches that you CAN live with and present them back to the user.

Above all: Remember that the app doesn't exist to make your life easier as a programmer. The app is there to serve the user.

share|improve this answer
2  
Makes sense if you're dealing with an application that's used by a handful of users (ie. an enterprise application), but it's overkill if you're trying to appease a single user of an iOS app that has tens of thousands of other users. If you spend all of your time trying to appease 0.01% of your users you'll go crazy and broke. –  Ant Feb 9 '11 at 9:25
    
You are making a lot of assumptions there. Principally that the pain of this one user isn't shared among others. Another good way to go broke is to ignore your customers wants/needs. –  JohnFx Feb 9 '11 at 14:20

I think you're doing the right thing. You can't please everybody, and you shouldn't! Be polite and professional, but you don't have to do everything you're asked.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.