Why the (feature) frenzy?
Historically, marketing says “software sells with more features” (or perceived features). There is a psychology (especially true in the United States) that the more you get when you buy something, the better the purchase decision.
Unfortunately, added ‘bells and whistles’ might feel like a better deal, but can turn into a nightmare when you (or your user) sit down with the software and use it.
A few words about features
Features. We love them, and we hate them. Features you need enhance your ability to complete tasks and are easy to love. Features that get in your way or add extra effort, interpretation, or exploration, can be a pain.
The field of Usability Engineering has proven that features if integrated tightly into a user’s task flow can be powerful. Features born out of marketing or engineering ideas, not validated with user behavior, can end up being adoption blockers.
Oh, sure you need features to market and sell your product. That’s where all this feature frenzy stuff started. Software marketers perfected the art of feature-worship back in the 1980’s (starting with Apple’s Guy Kawasaki, the guy who decided to ship the Apple IIx without a key feature–a floppy disk drive!).
10 tips to getting feature-creep under control
The best way to tame feature frenzy (before it turns into the dreaded disease “featuritis”) is to identify and understand your user’s task flow. Here are ten steps that I use regularly to bring some discipline to feature creep when identifying user experience strategy and defining user interfaces.
1. Get task-focused.
Conduct field studies, or Task Analysis, where you can get a bird’s eye view of what your users are doing. What problems are they trying to solve and what is the context of the task environment (conditions and constraints in which tasks are performed)?
2. Map business requirements to user tasks.
Business requirements are only as good as the relevancy features end up having for users. Focus groups and informal requirements gathering is not sufficient for an optimal user experience. Business Analysts need to take the lead from real world user data. If the business wants the user to do XYZ, how does that match to the reality of the tasks currently performed by the user?
3. Talk about user tasks, not features.
A common mistake teams make is to get caught up in proposed features and functionality. Keep your language in your meetings task-oriented. When feature discussions are dominating the conversation, can you find a way to turn the conversation toward user tasks?
4. Design for probability, not possibility.
Engineering requires the mind to think of infinite possibilities in search for “what could go wrong?” or “what is missing?”. The reality for the average user is that what they will probably end up using is a fraction of what you are offering. When you use Microsoft Word (or another program), do you use 90% of the available features? Did you even know half of them were there?
5. Validate features with user tasks.
Real-world user input must validate features; this will tame them. When you create personas, don’t create them in a vacuum- make sure the fake characters are from the real world. Persona research will help identify tasks. How many features are you currently managing in your web application that haven’t been validated against user tasks?
6. Map features to tasks.
Introducing balance (equal representation of user needs) is the end goal of usability efforts. Once your features are defined, you will want to do your due diligence and map them to user tasks. When prioritizing your features, do features come first, or tasks?
7. Create a feature-task matrix.
Sorting out the features from the tasks can be helpful with a matrix. The more you can transform your features into tasks, the closer your design will reflect true ease of use. What percentage of your features match the tasks users will most likely perform?
8. Think of scenarios first and use cases next.
Use cases are good and fine, but they are a deliverable of best practices in Agile programming. Use cases describe system-driven scenarios. Task scenarios describe probabilities of user behavior as validated through user observation. Have you ever made the mistake of referring to user tasks as “use cases”?
9. Use tasks to test features and features to test tasks.
Having identified your user’s tasks, you can use these tasks in your usability tests. Usability testing is essentially a feature audit with the primary question: Is it working the way the user expects it to?
10. Use diary studies to evaluate feature adoption over time.
Giving users diaries where they can record their thoughts and experiences can help you capture data easily missed in shorter visits. These diaries or “cultural probes” can be extremely valuable for reporting problems with features or “wish list” items- features users want that are not quite there or not presented in a way that makes sense to them. If you’ve given your users a survey, what’s stopping you from sending them home with a diary that can give you an eye into how your features get actually used over time?
Let Us Help
Learn more, request a Usability Test
Additionally, you can request a Field Study
