What is “Feature-itis”?
‘Feature-itis’ – a condition where the whole org is focused on delivering features endlessly while usability is low.
How an organization can contract it
Imagine a scenario where a software product adds on features year after year while not taking the time to check if they are actually adding value to the User (and are actually being used). Then consider the complexity it creates for the designer to fit in (or hide) the UI, and for the development team to maintain the code.
All of this leads to extra costs for the business and affects the bottom line just to have it available in the market. All the while it is making it difficult for the User to adapt and will not get used. There’s an infamous company product of this scenario where it had 621 features in its 10+ years of existence. When a proper study was done it showed that less than 5% of the features were used with regular frequency. The remaining features were perhaps gets used once in a while or for extreme edge cases. This begs to question to the whole org then, “why are you making life so difficult for your Users and yourselves?!”
Why it’s a trap
Feature-itis is harmful to UX & for business, here’s why:
- Asking Users to perform too many mental tasks when they shouldn’t – too many things to remember when it’s not at all required for the tasks of the User. They’d be right when they think “why are there so many features & complex UI which I don’t need or want to use?”. The high number of features means a high number of interaction cases for designers to consider and UI components to display or hide
- The cost of maintaining the code & design – can account for tens or hundreds of thousands of dollars, if at an enterprise level, in millions. A bloated product which has high maintenance costs while not adding much value to Users is a real business problem as well as a UX problem.
Getting immunity to Feauture-itis
Using evidence-driven User research/usability testing would be the way to navigate around this serious condition. Depending on the UX maturity of your org, the level of pushback from your colleagues on doing Rapid Learning before investing in new features would be greatly reduced if you have the below:
- Have your facts ready on the needs of Users from either ethnographic studies or field research (User interviews). A collection of behavioural data of target Users from at least 30 participants
- User persona boards based on facts & evidence, ideally proto-persona boards which are updated regularly with new findings
- Separate the assumptions from facts, with paths to validating those assumptions with research
Apply the remedy to Feature-itis
Catch the symptoms of poor feature ideas early, and root out the ones which are adding little/no value to Users before heavy investment in production. Run ‘Rapid Learning’ via prototypes which are quick to produce (the likes of InVision or paper prototypes). Med-Fi or medium fidelity WireFrames as Rapid Prototypes would suffice as long as they communicate the journey & interaction with test participants. Since you can leverage from User research done of 30+ people already, here testing with 5 participants would be acceptable for most cases.
To save valuable time, best to articulate in a few sentences of what is the doubt/hypothesis you’d like to validate. Having a target goal of what is exactly you wish to have answers for, and the mentality of “what is the most effective & quickest way to get this answer?”.
Embrace failures as part of the process to success
If the answers come back with sobering results you can share these valuable insights on why it failed before investing excessive time & resources on a wrongful path. Did your prototype fail due to the idea or poor execution in usability? Would Users adopt it at all? What in fact is adding true value to Users? Failing fast & cheap at the start is the key.
Contrarily, if it is indeed a success from the Rapid learning tests, it’s validation for UX & business that it is worth future investment in pursuit. Risk mitigation is built-in into this way of working; weeding out features which are potentially useless from the ones to create.
Do you like this topic? Read more in our part 2.
