Benefits Are Not Just What Civilians Call Features
We’ve defined the demographic and affinity segments in terms of what we have to sell, rather than how these affinity groups define themselves. And we’ve defined their needs in terms of the features and attributes we can offer, instead of much more broadly in the emotional terms that the customers define and recognize their needs themselves. This is a fatal error, but one which our intense customer focus almost drives us to commit.
— Dave Pollard; Why Is Innovation So Hard to Sell?It’s almost as if everyone else seems to be only capable of thinking in terms of raw features, rather than how those features are implemented. … It took Apple to see that the interface needs to be re invented for the touch screen rather than trying to meld two existing functionalities together. Electronics firms are not going to respond to the iPhone, because in their eyes, the iPhone couldn’t possibly be a success. Just like when the iPod was released, they will sit back absolutely convinced that device will to fail to capture the market.
— Reaction to the iPhone reveals how the electronics industry failed to beat the iPod.
Corresponding recently with a programmer who heads a development firm convinced me of something. This programmer speculated about how to categorize ease–of–use: as feature, benefit or something else. Perhaps, I wrote back, like the myth about Eskimos having fifty words for snow, we need a richer language to describe the environment all of us depend on.
The ads said that such a light touch was required to push the buttons that you could shift gears with [a] toothpick — something that apparently did not impress the millions who don’t keep toothpicks in their cars.
— The Edsel Turns 40 …sort of.Features are about the product, benefits are about the user
Ease of use has no existence outside of a user context. It is a user perception of several features, working together — a behavior. A feature simply exists or does not “…it is not a bug, it’s a feature” is the common refrain, while there are nuances and implementation variables to behaviors. For example, users want software to be smarter about interpreting their interaction with it. While smart lacks the technical precision to yield a feature, it can be a criterion of design and it can be a benefit. Ashlar’s application Vellum is the usual example given of smart anticipation of user input, but any application can emulate the design strategy behind it.
In order for the UNDO function to work, there has to be tracking of the last several actions the user performed. A common, programmable, feature. Benefit directed design would group the three functions the user performs on a selection as a single entry in a Command History list. Still a programmable structure, but different in the user perception of how smart a program behaves.
The Feature Directed Approach
A product crowded with features may be more attractive to consumers in the store, but too many features make a product overwhelming and hard to use, which leads to dissatisfaction with the product and perhaps even with the company. Even though people want more features, companies need to balance initial purchases against long–term satisfaction and repurchases.
—Feature Fatigue
It has been said the Edsel had a pushbutton transmission so sensitive you could change gears with a toothpick. This would seem to fit under the category ease of use — as long as users are kept out of the feedback loop. With users in the loop, you can see Edsel features in a different context. Users would call the Edsel a solution in search of problems.
Recurrent ideas lend themselves to feature driven development. One is business models gravitate toward a sales driven approach (pursuit of any sale, for any reason, at any cost). What impression there is of the user revolves around tasks. More precisely, those tasks which correspond well to discrete individual features. Customer input is translated into feature lists, with priority ranked by necessities of the production model.
From this perspective you can see how smartness or ease of use are cosmetic features to add after the serious work is done. Cosmetic features like, as the saying goes, polka dots on the Edsel.
Who ended up running the company? Sales guys. At the critical juncture in the late ’80s, when they should have gone for market share, they went for profits. They made obscene profits for several years. And their products became mediocre.
—Steve Jobs, OK, Mac, Make a Wish Apple’s ‘computer for the rest of us’ is, insanely, 20
Another attraction of the feature directed approach is the closeness with which the resulting product can follow the developer implementation model. Cognitive friction amongst project team members is minimal since few of the essential assumptions built into tools and technologies need to be questioned. The implementation model guides the product design, not designers. This cognitive friction isn’t really avoided, just shifted onto users, who now require extensive product education and training to adapt their mental models to the technology.
You won’t find users asking for design coherency, smartness or key differentiators which drive business to one brand and not another. Users know from experience asking for intangibles which are not communicated with enough technical detail are often simply refused.
The Benefit Approach: Saying “No”
Benefits exists beneath explicit product feedback, which fosters a marketing based model (resisting line extensions and loss of focus). If the larger objective is effectiveness, then fewer tasks is a beneficial plus, even when the feature list on product packaging suffers. Getting closer to the customer and user mental model is seen as a competitive advantage, making interaction design integral. Ease–of–use, smartness, and other intangibles are sought out and refined to technical function by benefit directed design.
A benefit directed development effort requires a methodology which gives more weight to software behavior and user results than feature requests. Desirability design provides just such a methodology.
Wait wait – put your hands down. Listen: I know you have a thousand ideas for all the cool features iTunes *could* have. So do we. But we don’t want a thousand features. That would be ugly. Innovation is not about saying yes to everything. It’s about saying NO to all but the most crucial features
—Steve Jobs, Say NO by default by Derek Sivers
One rule of thumb is features are user independent, and would exist if the product had no users or buyers. Benefits only exist as buyer perception, which causes some friction during development as technical structure must change to suit the target user. The downside is new versions can’t pile on features. Instead benefits to the design target direct how new and existing features act in concert each new version.
Features may sell, but coherent designs make for products a user desires to buy.
Resources
- Build As I Do, Not As I Say explains the drawbacks of feature directed design. Testing indicates both usability and marketing are off, the sweet spot for buying lies at the intersection of simplicity and capability.
- Feature Bloat: The Product Manager’s Dilemma “One way or another, managers must correct for the misleading information that many market–research techniques deliver.” The issue is Feature Fatigue, “When it comes to keeping a client over the long term, product satisfaction may be more important than just having an initial sale”.
- Reaction to the iPhone reveals how the electronics industry failed to beat the iPod explains feature directed design is a context “It’s almost as if everyone else seems to be only capable of thinking in terms of raw features, rather than how those features are implemented.” Hidden Dimensions – Apple is Outsmarting the iPhone’s Competition “Putting key pieces into place until the whole becomes more than the sum of the parts has been an Apple theme for quite some time. …The rest of the industry has nothing to compare to this.”
- Why Features Don’t Matter Anymore: The New Laws of Digital Technology explains how coherent design matters more than the component features and functions.
- Ashlar Vellum doesn’t resort to wizards. Instead the software accurately interprets what the user wants to accomplish. Without evaluating benefit desirability, designing wizards that make complex tasks easier for your users fails. The Dümster Anzunehmender User mindset results in Clippy; a form of Ronco Spray–on Usability. Progressive disclosure is another example, with feature and benefit based developers getting opposite (but predictable) results.
- ROKR will test the idea Apple design philosophy can be a added like any other feature; “The music–player module works like an iPod — though it lacks the clickwheel that makes its big brothers function so slickly.” Signal: When users identify modules from other product categories. Technology convergence without design coherence results in a chimera product which compares unfavorably to each category identified within it. Convergence only happens in the user’s mind, creating a new category where components disappear.
- Microsoft Office 2003 was feature directed, boasting over 1,300 functions. With Office 12, Microsoft takes a step toward benefits by introducing a results–oriented user interface. Related Design Crux article: The AntiAssumption Interface.
- The background noise in user testing is user habituation—users mistake familiarity with usability—feature directed development calls this “consistency”. UIE explains why Consistency in Design is the Wrong Approach “Why do we gravitate to consistency? Because it’s easier to think about. You don’t actually have to know anything about your users to talk about making things consistent. You only have to know about your design, which most designers are quite familiar with. Current knowledge, on the other hand, requires in–depth knowledge of the users. And that takes research time and investigative effort.” When a desirable alternative is presented, it wipes out competitors more focussed on what customers were habituated to than where they are going to be.
- (PDF ) Introducing User–Centered Design to eXtreme Programming, by Anders Toxboe bridges XP, which takes the first step toward benefit directed design, and UCD. The paper tackles several issues of context clash, for instance mapping personas to the user stories of eXtreme programming.
- “What’s happened here? We’ve defined the demographic and affinity segments in terms of what we have to sell, rather than how these affinity groups define themselves. And we’ve defined their needs in terms of the features and attributes we can offer, instead of much more broadly in the emotional terms that the customers define and recognize their needs themselves. This is a fatal error, but one which our intense customer focus almost drives us to commit. Once we get fixed in our mind what our demographic targets are and what needs we’re filling, we start to define our customer in the context of what we can sell to them, and we can’t shake that mindset.” Why Is Innovation So Hard to Sell? Dave Pollard
- The rise and rise of shuffle mode talks about the dynamic tension between simplicity and control in the iPod Shuffle.
- In the BusinessWeek article Getting to ‘Eureka!’ Joseph Morone cautions against following the customer, “If you worship at the throne of the voice of the customer, you will get only incremental advances, not brand–new ideas.” At its more common, “The product ends up filled with mismatched parts and random features, and becomes a dog’s breakfast.”
- Want to know which feature users prefer? Just slap up a web survey …what could go wrong? It could be people lie on surveys and focus groups, often unwittingly. So, for serious business decisions like interaction design the first rule has to be Listen to Your Users, but Ignore What They Say.
- Say NO by default Derek Sivers. Presents the idea of intelligent disobedience, something guide dogs are trained for but humans largely are not. This contrasts with the technique of throwing it against the wall (users) to see what sticks. Both benefit and feature directed projects say no, what differs is the model used to reach a decision. Scott Berkun distinguishes between the implementation model and use model as construction versus design.
- THE PALMPILOT’S CREATOR REFLECTS ON GOOD DESIGN “An abundance of preferences and options makes great feature lists on packages, but these ‘features’ are confusing to users and rarely used.”
- Bad designs are copied from design leaders, losing design integrity as mismatched features are forced into one box. Good designs are stolen from many, the component parts improved upon to fit a coherent design vision.
- The Edesel’s teletouch transmission. “The ads said that such a light touch was required to push the buttons that you could shift gears with toothpick — something that apparently did not impress the millions who don’t keep toothpicks in their cars.” Interesting to note the Edsel was full of such technical features. As one analysis of the Edsel project points out the Rambler, introduced at the same time, did quite well.
- The Content–Free Buzzword–Compliant Vocabulary List seems paradoxical. Buzzwords are content in one sense — filling a container — they just aren’t informative. The article’s premise is nothing you haven’t heard before, features don't sell benefits do. It is said so often, in so many ways; yet many sites simply mislabel features and buzzwords as benefits. Information on the difference between features and benefits is crucial.
- “Another problem is that buzzwords will sometimes take on a life of their own, with people repeating the phrase because it makes them sound like insiders, even if they aren’t quite sure what the term means.” Tech buzzwords may sound neat, but what do they mean? A basic interaction design principle is setting up users to look stupid is not endearing. And no better way to make the user feel smart than explaining buzzwords can make for bad keywords.