Feature bloat is a an issue for any company that sells software, as you probably sell it on the features, and in most cases to stay competitive, you add new features.
Too many features in any piece of software can create an ever expanding navigation menu which can increase the users decision time, thus increasing their cognitive load, worst still you could leave the user disorientated and confused.
Hick’s law, or the Hick–Hyman law, named after British and American psychologists William Edmund Hick and Ray Hyman, describes the time it takes for a person to make a decision as a result of the possible choices he or she has: increasing the number of choices will increase the decision time.
Here’s a handful of symptoms you can check to see if your system has feature bloat:
- Not taking features out
- Users asking “wheres that feature?”
- Feels “too big to re-design”
- No ongoing Improvement stage
- Help Documentation out of date
If you have one or all of these symptoms in your system, chances are you have Feature Bloat and it’s having a negative effect on your systems product quality, creating a poor user experience.
All is not lost, there are treatments for these symptoms:
1.Not taking features out
When’s the last time you took a feature out?
It’s not easy to do.
You could create a minimum bar of usage/value and make your decisions to remove a feature from the data.
2.Users asking “where’s that feature?”
Chances are, squeezing more features into a system that’s navigation was designed when your first launched the product and not changed since, will leave users feeling lost and unable to find information.
The original primary navigation; secondary navigation, and utility tools are now doing a job they was not intended for and may struggle to bear the weight. The main structure of the product may not be optimal.
The problem is probably that with each new feature added the global information architecture is not getting updated or re-addressed.
You may be getting support tickets from users asking “where’s that feature”.
You could audit your users tasks, navigation systems and make a phased plan of integration, taking into account the product roadmap. Basing these decisions on actual data from your Analytics package will make the decisions less risky.
3.Feels “too big to re-design”
You’ve added so many features over the years that the system feels too big to re-design, the general consensus is that a re-design would take too long and be too expensive and in a few years we will probably just create a new system.
You could be right, you could get to a point where it’s more cost effective to take everything you have learnt and create a new system, but if you just repeat the same feature bloat behaviors, the new system will inevitably create the same feature bloat issues and end up with the same problem; too big to re-design.
One solution could be; don’t re-design, re-align. Further segmentation of user groups, better grouping of tasks and even culling low usage areas of the software could help re-align the system.
Maybe you have some user tasks that would be better utilized as a wizard, it could be an action, not a main section. Maybe you have some users whom only undertake a handful of particular tasks that would be better suited to a micro-app on a iPad.
An audit of the current user tasks could help re-define the main sections helping re-align the system to how it’s actually being used.
As I know from fad diets, they never work, a long term mindset change is what’s needed, not a quick diet.
4.No Ongoing Improvement stage
If you don’t have a phase of ongoing and iterative improvement, but only have new features and customer request making up your backlog of tasks then you will continue to have feature bloat and the problems it brings.
Along with the new feature requests you should ideally have a steady review and optimize phase of work with the aim of improving quality. Better still, measuring usability and product quality, and long term goals to improve the score.
5.Help documentation out of date
If your help documentation is out of date, chances are your users tasks may be out of date, and chances are it’s due in part to a focus on shipping features hastily, without the correct help and support documentation. As UX Designers our holy grail it to create patterns of use that do not require documentation, but it’s good practice, in fact it’s one of Nielsen’s 10 Heuristics to actually provide help and documentation.
With every new feature or new section you could make part of the acceptance criteria of that task to create supporting help documentation.
If your new feature will help you sell the software, chances are it’s the same content that marketing would want to help sales so it can be re-used.
Help that helps ease the pain a little, I will endeavor to add symptoms and treatments to this list.