Does users really prefer quicker apps or does features trump all?

Question

How much of an impact does a faster application count considering the competition, or does features trump everything? Where is the balance point, and for what type of apps?

Answer 1

It depends - if it's a feature they need, then that feature will decide it. Application speed is a feature, after all.

Answer 2

I can't think of a case where you'd want a slow unresponsive application. I also can't think of a situation where you'd tell a client you can't have feature X. As a developer I have always been able to find a way to implement the features the client wanted and still have responsive application.

Answer 3

Users buy based on how many features an application has, and will bitch bitterly and endlessly about any features your application lacks that $OTHER_APP has. But if you add so much as a single new button, they will immediately complain about how bloated the app is getting and how much better the old versions were.

This is why you should ignore anything your users ask for. Make a program that you enjoy using. Assuming you're not insane, that will result in an application other people like as well.

Answer 4

I think most users use what they're told to use. Acrobat Reader, Word, Internet Explorer, Outlook Express. These experiences are so bad that many users have no confidence in software at all, and they're not likely to try alternative products.

But other users, who are not too jaded to try something else, discover that the grass really is greener. These users will look for a program that not only does what they want, but does it better than another program. And these are the users who download third-party applications like yours.

In other words, yes, the users who are going to bother with your program are going to care about its performance!

I totally don't know this, by the way. This is based on the users I know, myself included.

Answer 5

Users complain more about full-featured applications being slow than they do about fast applications being limited. That's because not many people use applications that don't do what they want, no matter how quick they are - you don't complain about software you don't use.

Answer 6

IMO, the type of apps will affect the balance you are talikng about. If you are developing software for customer, then you might want to consider the kind of feature your product would have as customer ussually looks for the feature of the product to make a buying decision.

But if you are developing software for your own company e.g internal use then is better to judge how each feature affect the performance during the requirement gathering phase. Highlight to your manager or your audience if they want a certain feature that will affect performance. It will be better for them to bear the consequences rather you take the responsibility when the apps are slow after implementation.

Just my 2 cents.

Answer 7

I worked on a deathmarch, re-architecting a web application that novice Java "programmers" had mangled which hardly worked at all. About 80% of their code was thrown out, and the 20% or so that did work was kept, because we had a (at least twice!) extended deadline to meet. So, while that 20% code did function properly, it was (and still is) crap and causes the application to run very slowly (for instance, when it pulls from a database, it PULLS from the database...if it says it found 10,000 records, it PULLED (in some cases records may have been created in Java to fill in the blanks) 10,000 records!

I realize this little diatribe may seem off the point of the question at first, but I'm getting to that.

Certain code was shared between three sections of the application. For codenames, we'll call them L, P and E. L encompassed E as E is just a subsection of L, and P used similar data but was not exactly the same. The searching functionality for L, P and E all use the crappy search behavior described above: pulling essentially all those records from the database each time a search is executed.

The requirements stated that a user should have a 30-day window in which to search for L, P and E data. Because L and P were the most important (and you could get to the E data by searching for L), and because of some weird requirement changes/unchanges, the E section was the least priority section of the three.

When all was said and done, the E section functioned somewhat properly...except that the end date was not verified by the validator, meaning that anyone searching for E data could put in a valid begin date, and search the database from that point forward.

The users of E discovered this quickly, and LOVE IT. Despite the fact that it takes tons of time, the users love the additional functionality of being able to search for such a long amount of time, so much so that the application support lead, when being told of the bug, knew that the users liked it so much that they would be very upset if we took this ability away from them.

So, features do tend to overcome speed issues, if they are useful features, which a essentially unlimited database date range lookup is.

Answer 8

Unless you're working on an app for programmers, you're asking the wrong people ;)

Seriously, though, my point is that the best way to find out whether your users value features or speed is by doing user research and usability studies. Usability is often a balance between learnability, efficiency, prevention of errors, etc. Figure out likely use cases and let them guide you, but follow up by watching actual people try to use your app.

Answer 9

For the majority of users, neither! Flashy boxes and hype are what sells, most people don't reasearch before they buy.

Answer 10

Depends on the application.

Sometimes a good UI with a few well organised steps can feel faster then using an application that has faster response but more complicated UI.

It is all about trade offs and the type of users.