Just like any phrase, “less is more” is one of those things that inevitably falls prey to misuse. During the last few years I’ve seen numerous instances of “less is more” misinterpreted as “removing features leads to better design”. Um, nope, design ain’t that simple, there just isn’t a silver bullet.
Although I don’t blog a lot, I’m trying to start a series of posts with examples of this as I encounter them.
Today’s example – Amazon Fire TV Data Monitoring
Recently my parents showed interest in watching online streams, specifically ones on Prime Video. They happily installed a Fire TV at their place.
Now, they use a data plan that isn’t very abundant, but enough for most of their needs. The plan offers a daily data transfer limit, essentially you get fresh data quota at midnight. Now, Fire TV has a nifty Data Monitoring feature that lets you set a maximum limit on consumption. I was quite happy to learn this, but not for long.
Do you see the problem? Yes, there is no way to set a daily quota because someone at Amazon decided that its “too much” to let the user define the unit and assume that “Most people have monthly billing cycles”.
This is just sad, because technically its near-zero effort to provide an option to configure this to daily (or hourly, or yearly) but this small mistake prevents such a powerful feature from being useful.
What’s the fix?
Well, quite “simple”, add another field to select the unit (hour/day/month/year) which defaults to monthly. Users with monthly plans will never need to change it but your software will still be usable to the rest who happen to be on a daily limit.
Make it easier for users to use your software, without compromising on its usefulness – its not easy – but that is what makes Great UX.
Shantanu Tushar 
One thought on “Less isn’t always more”