Prevent feature-creep by focusing on users’ goals
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 controlling the development process, we get a technologically advanced software which fulfills 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. 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 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 lets 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.
* * *
Remember RSS? You can subscribe to my blog here.
19 Comments
Very interesting read, thanx for sharing! Even though I’m getting a tad freaked out by your last remark on basic / default / advanced user modes as I’m currently working on a project in which I deliberately included such ‘workspaces’…
Well, at least your article got us discussing the purpose of such a ‘feature’ ;)
Cheers,
This is a wonderful read. The problem with this process is that most of us do start out with a focus in mind, but magically drop it halfway in. Especially in the case of startups, when things have to happen so quickly and you barely have time to blink, let alone design multiple phases of usability testing. Now it would be wonderful to hold clients at bay and take the time to really drill this out, but a lot of times, that isn’t the case. What end up happening is that we get a feature dump, and all we’re expected to do is make it appear as un-obnoxious as possible. And this is where the beginner/advanced conundrum usually rolls in.
Nice to see another blog. I believe it’s along the same lines as the blog ‘Empathy adn web design’ which talks abt taking the user into perspective.
Its quite an interesting point you make here about how features often mask the real purpose of the software.
I like the way that the difference between business requirement and client requirement has been pointed out. Maybe we are unable to see this difference or tend to ignore it (following business requirements is easier).
This blog makes me wonder about my own approach to aligning my tasks and goals with the goals of the user. A point to think upon as I give form to the business requirements.
Cheers and keep these blogs coming.
"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."
Totally agree with this.
A friend of mine recently talked about this with regards to how businesses continue to provide a wide choice to the consumer, to the extent that consumers have no longer have a real excuse about purchasing something wrong these days … they either didn’t need it, or they don’t know what they really need.
Regarding a successful product however, you can’t blame businesses for taking advantage of people, when those people have no real understanding that they are in fact being taken advantage of … especially by their own choosing (albeit unknowingly).
New features and more features … people find this synonymous with value for money. We recently began analysing clients that factored in ‘removing features’ from a website, especially when wanting to add something. There has yet been a single case where a client was willing to remove something they already paid for.
True. Dropping the process halfway in and doing things ad-hoc happens (too) often. It’s certainly leads to scrappy products that are technically poor and aren’t focused on users.
Thank you Manish
[quote]A well designed and humane interface does not need to be split into beginner and expert subsystems[/quote] – Jef Raskin
Easier said then done, but something that we should be aiming for.
I think it would be better for businesses that, instead of taking advantage of people, hire designer(s) that would help people find out what they really need and what would really support their activities.
It is true that people find features synonymous with value. When we want to buy some product we thoroughly check every little feature and compare it with similar products. Features inevitably impact purchasing decision.
Great article, but I would contend that the problem is more severe with physical products. How many cup holders does one car need? The additional features drive up the cost of these physical products when the users could really care less. At least with digital products you can leave in or out the features (and the costs) that users really require. Much harder to do in a "real" product, which is why these designers should read your post as required reading.
Love this post, and agree with everything, enthusiastically… right up to the point where you mention someone else who suggested the user-level modes as one possibility for fixing featuritis. That may have been me, in one of my Featuritis posts or talks. I understand Raskin’s point, and yours, on this but my perspective is within a very specific context–passionate users. And when I say "passionate", I am referring to the kind of passion one has for a serious hobby or profession. In other words, a utility-that-does-one-thing-well-then-disappears is an entirely different answer to the "user goal" question.
I want my users to be able to do exactly what they want, in the most natural way possible. But by definition, a passion-inspiring activity will have ever-increasing goals. Today I want to just upload my video, next week I want to do simple edits, and finally I want to add special effects, sound tracks, and sophisticated timing. A goal that exists around passion is about growth and development, users kicking ass, learning and doing more than they were before. My first choice is always to have separate graduated products, like Apple’s transition from iMovie to FinalCutExpress to Final Cut, or GarageBand to Logic Express to Logic (though the jumps between stage one and two is enormous). But a well-designed presentation of user-modes based entirely on the user’s goal (driven at least partly by their current level) can also solve this problem.
I agree with you that Featuritis is awful, but simply lopping off a set of potentially advanced and complex goals is a killer of growth and passion for the user. I have mo problem with a product design that says, we are for beginners, period. As long as they recognize that when they have done their job well, users will outgrow them.
Well… It is more subtle than that, I reckon. I have advised companies that have rightfully chosen to be awesome at entry-level products that they can do one of three things if they want to keep the passion going…
1. Build a second (and perhaps later a third) product for more advanced users
2. Build "level modes", if appropriate, so that advanced users have access to more complex capabilities without overwhelming the beginners (recognizing that beginners can simply be those who just never need the advanced capabilities)
3) keep the entry level product/goals as-is, but help users grow and develop their skills in other ways, within the constraints of the system. Simple example could be an entry level graphics editing tool that gives tutorials and support for the "craft" and art. In other words, rather than giving the users ever more elaborate effects tools, focus on users who can see the tool constraints as a creative driver, and help them learn to get better at the artistic, rather than power-user side.
Hope that makes sense. What a wonderful topic. Thanks!
Wish I had seen this before I posted a somewhat similar post! Casey @freshbooks and I were just commenting on the "elastic user" a term coined by Alan Cooper. I think what we’re all feeling is the pain that comes from either a lack of or not enough consideration to user experience. If it were taken more seriouslyduring the development process we’d see much better products.
Kathy, I’m predicting a paradigm shift in software as we transition to cloud based apps. They will be more super niched (and seemingly entry level) products that connect to each other. I think your suggestion around levels would still be valid in the super niched web apps concept, but instead of just levels, I would add that sometimes it’s about building a totally separate block to connect to the original. Figure out if those other features are truly an "advanced" mode or if it can be a stand alone product by itself that connect to the original one. So now you have "lines" of products along with "levels" of products.
Janko/Kathy, really would love your feedback on my post on Greatest Web Apps. (It’s linked to my name).
Imho today it is difficult for many to decide what is actual feature for them. One contributor to this is agressive marketing, renaming, (silly)numbering, and we could go on forever.
I dont personally prefer to pick a beginner or expert view, its kind of distracting anyway. maybe I have tools I want to use in the expert view even though I just started using the product, that is slightly confusing. On the designer side it is purely impossible to label something beginner or advanced for every user. We all have very different strengths and weaknesses.
I like the point on missing design process. It is (usually) missing because good designs are well thought out, the more attention it gets from designers the more likely it will succeed in the given scenario. Probably many devs consider this whole design stuff a waste of time at most companies. They dont think it is challenging or whatever the reason is.
Norbert, excellent point. I would suggest, though, that in your example… If you are a beginner to the product but want an "expert" view, then something has already gone wrong with the use cases and design of the product itself. In other words, do not condemn user modes based on poor implementations of them.
A design based on use-cases rather than features, by considering only what the user truly needs and wants to achieve, may be better able to manage complexity (manage, not reduce) for the user in a way that feels completely natural. If my user is unnaturally forced into selecting "beginner" or "advanced", I have already failed. When I suggest user modes, I do not necessarily mean that the user is seeing these labels. It means that complexity is managed and presented more or less just-in-time for the user in the most natural way.
The alternatives (I am greatly over-simplifying) are more like:
* eliminate complexity completely (dowmside: user cannot grow and develop within THIS product, not necessarily a bad thing if other products /paths exist)
Or
* present everything to the user at all times (featuritis)
So… I prefer just-in-time over just-in-case, and in the right circumstances, use-case driven design CAN offer a richer feature set without cognitive overload for users, and without forcing them into unnatural choices of "expert" vs. "beginner" etc. Do not condemn the approach of user modes based on poor implementations… though I agree there are often much better ways. A building-block, pluggable framework for adding capabilities is quite compelling… I am interested in Pashmina’s comment about the impact of the cloud.
But you have helped me recognize the need to use more precise language. When I refer to "user modes" or even "level modes", I really mean "user capabilities", which is based not so much on levels as on user goals/results. All that really matters is what happens when the clicking/swiping/dragging/pinching stops… Did the user accomplish what he wanted? More importantly, for those of us who want to enable passion… Did he produce a result that makes him feel as though he kicked ass? :)
To clarify, my thoughts around cloud based and building block type apps does not rely on a concrete or unifying framework. That’s part of the shift in how we approach our tools and services. There is no need for a framework necessarily.
When one company attempts to create both a framework, and all the building blocks, what emerges is frankenstein bloatware (http://www.greatestwebapps.com/why-software-apps-suck/ ). I’d rather pick several super niched apps for my needs than one mediocre software that does it all.
The SaaS that are doing it right have robust and friendly APIs, and the data can be shared, aggregated and presented in different contexts. Mailchimp is a clear case that this business model works, and they’ve also stuck to that philosophy. They aren’t trying to be anything but the best email marketing. They’ve grown exponentially since 2001 and with no VC or crazy capital raising funding. A couple years ago, Ben even wrote about how investing in API (http://www.mailchimp.com/blog/milestone-19000-mailchimp-api-users/ ) made all the difference to their sales, and how.
And I truly believe that it’s these types of super niched apps that enable our users to kick ass. The traditional softwares that try to unify the modes/tasks may be functional, and help the user accomplish his needs, but rarely create passionate users.
I agree in the principle — super-niche trumps one-size-fits-all. My goal is not necessarily to provide *more* (features, capabilities, etc.), but to provide *deeper*, and again, my interest is mostly in domains where real passion can exist. One can certainly have very loyal and enthusiastic users around a niche utility targeted at those who have no interest in taking it further. That’s an excellent goal for a successful product, just not the one I am interested in. If there is no path toward growth within the context of the product… nothing that could be considered "expertise" or advanced skills, then it does not fit the criteria.
And to clarify, the expertise and skill do not and SHOULD not be *on* the product, but rather *through* and *because of* the product. For example, a camera user wants to be an expert in *photography* (or, at least, be better at taking and posting more interesting and comment-generating photos) as opposed to becoming an expert *on cameras*. Just another example of "Don’t make me think" which really means "don’t make me think… about the wrong thing". The tool should get the hell out of the way so i can get on with the interesting challenges around what I am am trying to craft, not how to tell this f’n complicated feature-bloated Frankenstein-app how to do it.
I continue to love this thread! What an awesome way to jump-start my day, thanks.
Practicality with the inclusion of common sense works here. No use "overworking" on the things.
People are now fed-up with over crowded things.
I fully agree with you.
A perfect example of an application suffering from featuritis is Nero, and so much so that the pirates have released a cut down version for what the software was originally designed. Now that is crazy, it seems the pirates are more in touch with the Nero customer base than Nero themselves.
Those pesky end users eh! Causing all the bother. Actually scope creep is one of the biggest reasons I try to stick to a Prince2 methodology from the outset… all those product breakdowns and product descriptions and PID’s seem irritating but it just re-iterates the scope time and time again! I would always get a firm specification approved by all parties and set up a formal path for deviations from the scope. Inevitably there is always a bit of creep!
I agree in the principle — super-niche trumps one-size-fits-all. My goal is not necessarily to provide *more* (features, capabilities, etc.), but to provide *deeper*, and again, my interest is mostly in domains where real passion can exist. One can certainly have very loyal and enthusiastic users around a niche utility targeted at those who have no interest in taking it further. That’s an excellent goal for a successful product, just not the one I am interested in. If there is no path toward growth within the context of the product… nothing that could be considered "expertise" or advanced skills, then it does not fit the criteria.