Feature-zilla! Will Featureful Kill Usable on the Web?

Share this article

Feature-zilla! Will Featureful Kill Usable on the Web?

Photo credit: Ѕolo
Photo credit: Ѕolo

When did you last use the references feature in Microsoft Word?

Or truly needed any more than about a quarter of the filters in Photoshop?

When talking about feature bloat in applications, our minds often slip to thinking about Microsoft or Adobe software and the statistic that most users only utilise about 20% of their feature sets.

Whilst many vendors are doing a far better job than they used to, the same is true about many software solutions.

On the flip side, when was the last time you found yourself swearing at the screen attempting to accomplish a seemingly simple task that surely should just work (formatting lists in Word anyone)?

We’ve all used over-bloated software, hoarding a plethora of features that we feel we might someday need.

‘Damned if I won’t find a place to use that diffuse, bi-polar, boolean mosaic filter before I die!’
you think to yourself.

The aim of most software vendors is, of course, to shift units and build customer bases. It’s hard to excite consumers to buy with statistics such as ‘now 50% more usable!’ as opposed to ‘100 new features’.

In fact, it’s hard to imagine what, say, your dad or your dentist would even make of that the first quote?

So, what does this mean to mobile and web developers and designers?

These worlds have, by necessity, been stripped-back and feature-light. But as bandwidth increases, server costs decrease and user expectations increase, we are tempted to add more and more into our web apps, while becoming lazier with our execution.

We’re now experiencing the same ‘rust’ in our sector that application developers have already been through, and are emerging from again.

it..creeps!

Now, I work primarily with off-the-shelf, open source Content Management Systems (CMS) and Client Relationship Management (CRM) tools. Both have celebrated reputations for steep learning curves and mind-numbing complexities.

These systems fit very well into the cliche in our opening paragraph. They attempt to be all things to all users, which can often lead to frustration or compromise on the part of developers and for end-users.

They also present the temptation to provide features that were never requested or needed. Off-the-shelf systems offer fantastic, time saving devices for your projects, but can also distract you and your users from what is really important.

Remember, it is as easy to turn things off as it is to turn them on.

This article is something of an initial discussion around prioritising better usability over features in our work, but if there were one point I would like to hammer home the most, it would be to make our creation tools (CMSs, Frameworks, Languages) more usable and approachable.

This is now increasingly relevant with recent efforts encouraging everyone to learn to code.

So, why is feature creep overwhelming usability?

Developers are a scarce resource

In the open source world, we often see issues and bug queues languishing for years with major areas of functionality left unfixed because a developer has moved on (physically, mentally or time-wise).

At the same time, we see huge efforts poured into new features, additions, and branches of projects over disagreements or doubling and replication up of similar tools.

One area that is perennially lacking is thorough documentation. Sadly, this is exactly the area that beginners encounter the most, and is always pushed as needing contributors. But let’s face it: writing docs is never going to be as glamorous as coding some sexy new feature.

Developers often prefer big ideas over finishing touches

In the open source world, we have to bear in mind that most projects are run on volunteer time. Project leads and developers are always most likely to be drawn to work on the bits that interest them the most. Unfortunately, small, iterative usability improvements aren’t always that high on their fix-it list.

In fact, often the natural mentality of developers is to want to make something technically amazing, and this invariably focuses on the structural or code level — not necessarily a level that will make sense to most end users.

The silent majority is.. well .. silent

The communities that form up around products are usually full of vocal minorities, all lobbying for their killer feature to be added. While the majority of users are probably not interested in that feature, few would actively protest against adding it.

I mean, no-one wants to be a killjoy, right?

Suffice it to say, actively seek out the opinions of the silent majority, and diplomatically remind yourself that those shouting the loudest may not always be right (even if you don’t tell them that directly).

So, what to do?

Most small development agencies quote their projects based around features. Indeed, the client often has a checklist of things they want from their site and quoting follows these lines.

In an ideal world, we would all follow user-centered and agile principles, but often the concept of not issuing a fixed price quote is still a little too ‘out there’ and scary — for both development house and client.

However it’s certainly possible to break your quote out into different collections of features, or phases based around client priority.

You can then help guide a client through the process of deciding which of these should be done in order of priority, and slowly introduce them to thinking of their clients as the end user and how these features will (or won’t) solve their problems.

Resist the temptation to design, code or quote for features that appeal to you. We all love a challenge, and it’s very tempting to get all misty-eyed at the thought of heroically fixing a design problem that has been plaguing your creative community for decades.

Back in my university days, we covered a topic that I have always sought out to highlight in products that manage it successfully: the concept of ‘abstraction’, or making something complex appear stunningly simple.

When designing and developing front ends, keep this in mind and strip out the extraneous that a user just doesn’t need to know about or access to achieve a successful outcome.

The sad fact is that people are mostly lazy (or perhaps attention-thrift), and don’t really care about your efforts to make some fantastic series of events happen. All they really care about is clicking a button that makes everything they want (even if they don’t know what it is yet) happen.

No matter how innovative and game-changing things may be under the hood, if it’s too hard to understand how to use it, people will gravitate elsewhere. The road to awesomeness is littered with far shinier turn-offs (and everyone is talking about them).

Remember that restrictions and limitations can often lead to far superior creative output. This applies equally to the tools you use, but also to the features you provide to your end users.

Attempting to create a wondrous, flexible, system is hard work and will create more problems than you may be trying to solve in the first place.

Locking down your users to a carefully selected and well-executed core set of features is far simpler and will probably win you more supporters in the long run.

It is certainly possible to ‘sell’ a reduced feature set — focus on the time you are saving people, the more pleasant and productive experience.

Be harsh and judgemental with your interfaces, experiences and feature sets, and always bear in mind that classic of adages, “If in doubt, leave it out”.

“If in doubt, leave it out”.

Unfortunately, it’s too easy to add features to software. They don’t require the physical parts, logistics and costly processes required for adding features to bricks-n-mortar products. It won’t make the box any bigger to ship, right?

The increasing trend for rolling software releases has become even easier to accomplish. Just pop it in next weeks update.

Would you pay for an upgrade that reduced features?

This has been an approach attempted by Apple with their most recent OS X upgrades. While they have added some new features, they’ve also stripped their base application offerings of anything deemed extraneous or unused.

One would assume that these decisions were based upon statistics and research. While there was some noisy backlash against these decisions, I wonder if it wasn’t more a case of people wanting the option of having a StairMaster, rather than ever wanting to actually use one.

I suspect there are a lot of StairMasters in garages.

It’s not all bad. Some companies in our sector are doing a great job of keeping it simple. Dropbox is a great example. They’ve got one great idea and have bravely resisted the temptation to add multi-tiered social integration, video chat, and a fun gamification element. Yay them.

Funnily enough, Steve Jobs reputably once told them them they didn’t have a product, they had a ‘feature’.

This week Steve’s ‘feature’ was valued at $10 billion.

Maybe we need more features after all…

  • So, what do you think?
  • How do you evolve a product without strangling it?
  • Would you advise a client against adding a feature, even if it cost you income?
Chris WardChris Ward
View Author

Developer Relations, Technical Writing and Editing, (Board) Game Design, Education, Explanation and always more to come. English/Australian living in Berlin, Herzlich Willkommen!

Share this article
Read Next
Get the freshest news and resources for developers, designers and digital creators in your inbox each week