There are two ways of constructing a software design; one way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.— Charles Antony Richard Hoare

Feature-creep or featuritis is a tendency to constantly add features which inevitably leads to complex products that are confusing and hard to use. To make matters worse, by adding features we move the product away from solving primary issues – the reason for making the product in the first place. Some products are even conceived with featuritis.

Adding features is the easiest to do in the world of software. There is no need for physical changes plus they are quick and easy to accomplish. Thus, most software products suffer from this disease.

What causes feature creep?

Most software suffering from feature creep are technologically rich solutions which arise from user and business people requests, as well as from marketing research. Engineers add features because they want to create a technologically better product. Because they are the ones controling the development process, we get a technologically advanced software which fullfils the business requirements, but is very difficult to use. On the other hand, business people want a product filled with features believing that would make it more competitive and wanted on the market. However, it must meet client requirements as well. Everything is about quantity with them: requirements, time and resources.

By asking the wrong questions like “Wouldn’t it be cool to add this feature?”, development teams add functionalities which are unnecessary for basic software purpose, the one that supports users’ primary activities. As we know, intermediate users use only a part of software functionality, so a large part of the added features is not going to be used at all. Even when the team agrees to focus on core functionalities only, no one is quite sure what these are. There are only assumptions and guesses which easily lead to feature creep.

Users and their goals

Features are important – they present a picture of software capabilities and value. However, there is something more important which is usually left out – people. People who use the software. Without users in mind, without knowing why they do something, you only ask what are we building and how. The why is left out. Nobody is wandering if there is a need to build something. The users have goals and needs different from those whose create or sell software.

When user goals are not recognized, the only thing that we can focus on is individual activities and tasks. Tasks and activities, however, are only steps a user takes in order to achieve their goals. A task is uploading a CV, an activity would be applying for a job, but the goal is to get a good job. Since goals are what motivates people their tasks and activities will serve in achieving their goals; and as tasks and activities map onto features, it is clear they too are serving this purpose. If we don’t know what the goals are, there is no limit to adding new functionality. This is where the true nature of featuritis lies.

Missing design process

A successful product requires not only good technology platform and satisfaction of business needs but also an adequate design process, which is usually missing. Instead of non-designers asking questions about cool features and making decisions based on that professional designers should, as an integral part of the team, seek answers to who the users are, how do they act, which activities they wish to perform and how the software should behave in order to meet their requirements.

Answers to these questions are available through various research methods, which should come before the development process begins. Research results should be modeled into Personas – presenting the central point for design process. Personas will always remind us of who we are designing (and developing) the software for and keep features under control.

Furthermore, various ideas will be researched and validated, iteratively, through people testing thus allowing us to create software accommodated to users rather than forcing them to accommodate to a software product filled with fancy features. So, an iterative, user-centric design keeps the users in focus throughout the design process and enables us to meet users’ needs and goals. Thus keeping non-important features out of scope.

Good and bad (and very ugly) example

Take Dropbox for example – Dropbox does one thing and it’s doing it well – it synchronizes your offline data with their online copy. No fancy features here. Dropbox is focused on what the users need. By answering the question “Why is Dropbox popular and not something similar, like Windows Live Sync, which is free?”, Michael Wolfe explains in a short and effective way what’s standing behind Dropbox success.

To much regret, it is far easier and cheaper to build a feature-rich software than to satisfy the needs and goals of users. We know this due to a large number of bad examples. I once came across an article (can’t remember which or where, if anyone knows, please share) explaining how the problem of featuritis was solved by adding a feature which let’s you choose a mode: beginner or expert. Another feature to cure featuritis! Unfortunately, this is how many software products look like today – difficult to maintain metastasized mutants, which scare the users.

Looks like something you saw recently?