I am about to get my Android app in beta and am weighing two different strategies

  1. Show users the full set of app capabilities even though I suspect that some of them are redundant and then ask them which ones they can well do without
  2. Show them a basic set of app capabilities - the bare minimum expected set for an app of that genre if you like - and then augment them during the course of the beta by exposing hidden capabilities as and when requested

Until I started thinking about this seriously my inclination was to go down Route 1. However, I am now wondering if Route 2 is not perhaps better in terms of beta user UX - why open up the road to confusion through too much choice and too many options when in fact I suspect that many of them are not going to be appreciated anyway?

Any views from the UX community here would be much appreciated

3 Answers 3


For your app to succeed it needs to work perfectly, otherwise it will just attract bad reviews. Think about what the big guys do: new features are listed as pending in a future release, and only added when they work.


Route 2 is by far the best choice. A GUI should never be more complex than what is required to accomplish the task at hand. Bells and whistles are nice, but often difficult for new users to differentiate between true-grit and pure fluff. Hide the fluff.


If you're following the lean UX "minimum viable product approach", the version 1 should only have the basic set of app capabilities. "Basic" being the capabilities that solve the user problem/address the user need -- only that and nothing more. Concentrate on those basics for launch. Ideally, you should be finding out what the redundant features are before even building the MVP. This should be figured out during prototype usability testing.

Your Answer

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

Not the answer you're looking for? Browse other questions tagged or ask your own question.