10

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?

Improve this question
4
  • 4
    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, 2011 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, 2011 at 16:30
  • Up my price until I can drown my sell out guilt in the smell of crisp green backs!
    – Ewan
    May 30, 2015 at 20:49
  • Put it on the backlog, priority = -1
    – ConditionRacer
    Jun 13, 2015 at 13:55

7 Answers 7

Reset to default
12

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.

Improve this answer
9

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.

Improve this answer
2
  • 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, 2011 at 9:25
  • 1
    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, 2011 at 14:20
6

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 either stick with or abandon. The choice of each approach should be carefully considered.

Improve this answer
2

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.

Improve this answer
1

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.

Improve this answer
1

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.

Improve this answer
1

For each of our products, we have a "list of ideas for future versions". So what we tell our users is "we will put your suggestion on that list" - and that is honest, we actually do that.

The list has no priorities, but we regularly pick things from it and use them to feed our backlog. We do not take them "in order", instead we try to identify which ideas give the "most bang for the buck" - the most benefit for as many of our users as possible, for a reasonable development effort.

Feature requests against the conceptual integrity of the product are likely to stay there forever. But occasionally, it happens that at least some of the ideas buried in those feature requests can be realized, maybe not exactly the way the person who suggested it was thinking of, but in a way which fits better into the product's architecture.

So my suggestion here is: do not just say "We will take that into consideration." and forget the idea as soon as you end up the phone call. Instead, have a tool where you store ideas and feature requests, maybe in an issue tracker, maybe in a Wiki, maybe in a spreadsheet, whatever suits your needs best.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.