"Feature frenzy"- 10 tips to getting feature creep under control

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!). Microsoft, has relied on features to market products for years, but with XP shifted to more task-centered marketing strategies (Windows XP stood for x-perience at one time; for the first time menu features took on "task language" in XP). Windows Vista promises better task focus, but the jury is out on whether the new "task grouping" UI in Office 2007 is good or bad.

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. Now when you use Microsoft Word (or other program), do you use 90% of the features that are available? Did you even know half of them were there?

5. Validate features with user tasks. Features need to be tamed by validating them with real world user input. 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 you have your features 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 scenarios first, use cases next. Use cases are good and fine, but they are a deliverable of best practices in programming (UML). 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"?

Footnote: They're not the same thing, but few people realize this- I'll cover this in an upcoming post.

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 that 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? 

Conclusion

Task-oriented designs containing task-oriented features make users feel more successful. Take the simple example of playing video on the web...

Case study:

Why is YouTube so popular? For one, they make playing the actual video easy (by using Flash as a platform). Both Microsoft and Apple continue to degrade the user experience with the politics of media player choice: Windows Media Files are annoying to play in Windows Media Player; likewise Apple Quick Time files are annoying to play on a PC (note: I am both a Windows and Mac user). YouTube fills the vacuum in media player politics by playing with Flash (and making the play button a huge arrow over the start of the video file). File format compatibility and interoperability is a huge win for the user experience.

Note: If you are offering video on your site, look to YouTube for emerging standards in user interface design and display. If you are not using Flash for video, you need to provide options- don't assume QuickTime files will play smoothly on a PC- as MarketingSherpa recently did-they don't always. (Link to conference video promo page with video in QuickTime only format!)

Remember how you deploy features in an application must be guided by real world understanding of users and their tasks. Without task validation and prioritization, you can easily fall into "feature frenzy".

Feature creep as a business and development model has outlived it's usefulness with numerous examples in the graveyard of software history. Thankfully, new Web 2.0 designs are inherently trying to be be mindful of the Importance of User Experience (poster).

Best Wishes,
Frank Spillers, MS

Comments

[Frank]

"YouTube let people see the video right away," Mayer, vice president of search products and user experience (Google), said during a short talk. "That's why it did so well."

http://news.com.com/Google+says+speed+is+king/2100-1032_3-6134247.html

The Human Factor in Gadget Design (Feb 12th new article)
http://news.com.com/The+human+factor+in+gadget%2C+Web+design/2100-1008_3-6158224.html?tag=st.txt.caro