I think this is where customer testing comes in. Watch 10 or 100 customers try to use you product, and observe the features they "reach for" but are not there - and the ones that are there, but they never use.
Dangling by a Trivial Feature
31–40 of 63 posts
Re: Dangling by a Trivial Feature
#32Earlier quoted context omitted.
And they're often closed source, so there's limited chance to add the features. You might be able to ask users on some forum. And maybe there's something on the website about feedback or feature request. Having said all that how do you control the flood of "Why doesn't X do Y?" (when Y is in the menu, on the tool bar, on the splash tips of the day, in the tool tip, etc)
Theoretically it should be solved by making everything scriptable, but in practice this solution tends to only work for a small subset of users (who could benefit from customization). We still have this road ahead.
Or more services like Bountify?
Re: Dangling by a Trivial Feature
#33As someone who sells software online, the most horrifying thing about this scenario is that the user is very unlikely to ever tell me why they moved on, and so I'm terrifyingly unlikely to ever know that this trivial feature is missing. This literally keeps me awake at night. Statistic: it takes roughly 200 non-converting free trial downloads of my software to get one data point of feedback telling me why they decide…
This is why metrics and analytics have become superstars lately. Why hope for your users to tell you, when the software can do it by itself?
Following the article's use case, the software could transmit the last dozen or so commands or actions performed by the user. In a simplistic scenario, how would you interpret it if 40% of your user's last commands are "Save"? Success, surely! How about "Undo"?
The art and magic, of course, are in figuring out valuable yet inexpensive metrics for your app, capturing that data when you have thousands or millions of users, and interpreting the meaning.
Re: Dangling by a Trivial Feature
#34Any implementation must accept that you will lose users this way. You can't implement every 'trivial' feature possible in order to avoid shedding users; implementing one way precludes a different way that also sheds users. Overall, you try to maximize the number of users that you don't shed, but that's it. And in fact, you're frequently better off shedding users willy-nilly, iteratively finding what the core features…
I think part of the reason why developers that "dogfood" their own product is so important to some people. If you use your own product, you tend to find these sorts of important minor issues faster. I think, as developers, we've all been guilty about missing obvious and simple areas for improvement because we don't use the product, like users do, every day.
Re: Dangling by a Trivial Feature
#35It's very simple. In any environment, the person who asks, "Why would a user want to do that?" is the one who should be fired first.
Yet this environment created the iPad and propelled Apple to near-unprecedented success. It's not as simple as that—cutting features is often as important as adding features.
Re: Dangling by a Trivial Feature
#36Any implementation must accept that you will lose users this way. You can't implement every 'trivial' feature possible in order to avoid shedding users; implementing one way precludes a different way that also sheds users. Overall, you try to maximize the number of users that you don't shed, but that's it. And in fact, you're frequently better off shedding users willy-nilly, iteratively finding what the core features…
I think part of the reason why developers that "dogfood" their own product is so important to some people. If you use your own product, you tend to find these sorts of important minor issues faster. I think, as developers, we've all been guilty about missing obvious and simple areas for improvement because we don't use the product, like users do, every day.
Or we have worked places where our bug reports are taken at low priority compared to real customers'. Real customers often don't bother reporting simple bugs, either assuming they will be fixed anyway or judging their value (to one user) as too small. So fit and finish suffer, because developers who do care are systematically ignored.
Re: Dangling by a Trivial Feature
#37Earlier quoted context omitted.
Settings are for microwaves. Computer-based tools should be reprogrammable. Still, the tool should be easy to configure for the 80% case.
Settings on a microwave are, I think, a terrible example. Most microwaves I've used are horribly over-encumbered. I expect two dials on any microwave I use: Time, Power. Maybe a control to set the time, if it has a clock. I don't disagree with your general point about tools being able to be reprogrammed, though. One of the reasons I loved Autocad as a tool is the Lisp interpreter that allows you to script and extend…
Do you have any current examples of consumer level microwaves with that simple interface? I've been looking for exactly that sort of simple microwave, but I haven't been able to find any in my brief searches on the internet or in the large mart style stores.
Re: Dangling by a Trivial Feature
#38That's why you need settings in your tools. The tool should work efficiently without you ever looking at the settings, but if you need it you should be able to change anything you like. Not sure it applies to consumer interfaces. Ideally it shouldn't. But for tools that you use to do day-to-day work, absolutely.
I have never found making something a configurable setting to solve any problems. All it does is push the decision forward to what the default should be, given that 99% don't change it.
Design is about making decisions. Trying to duck that leads nowhere.
Re: Dangling by a Trivial Feature
#39I think something gets lost when we call this kind of shortcoming a missing feature... A missing feature is too easy to dismiss since we can mention all these scary words like "paralytic featur-itis." The fix here involves no new dialogs, no additional learning curve, nothing fancy whatsoever. It's just a case of absent-minded application design, and the point stands that it makes a tremendous difference in the end p…
Another possibility is that the developers implemented it and the UI designers/tech writers insisted that it be eliminated because it would "confuse the users".
Re: Dangling by a Trivial Feature
#40Earlier quoted context omitted.
Settings on a microwave are, I think, a terrible example. Most microwaves I've used are horribly over-encumbered. I expect two dials on any microwave I use: Time, Power. Maybe a control to set the time, if it has a clock. I don't disagree with your general point about tools being able to be reprogrammed, though. One of the reasons I loved Autocad as a tool is the Lisp interpreter that allows you to script and extend…
Do you have any current examples of consumer level microwaves with that simple interface? I've been looking for exactly that sort of simple microwave, but I haven't been able to find any in my brief searches on the internet or in the large mart style stores.
This Samsung model is the most popular one in Sweden currently:
http://www.samsung.com/se/consumer/appliances-kitchen/microw...
But when you look at the Samsung US range of microwaves:
http://www.samsung.com/us/appliances/microwaves/all-products
...it becomes clear that (Samsung US belives) simplicity doesn't sell as well there...