Consistency vs. Innovation
One of the most vexing user experience questions is: When must applications be consistent with each other? When is it OK to invent news ways of doing things that require users to relearn established methods? There is rarely an easy answer, but a Product Manager can play an important role in making these decisions.
Most of us assume that it's a good thing when a mouse click performs the same action in different applications. Few of us miss the bad old days when every word processor had its own conventions, and there were no Windows interface guidelines and web interaction conventions. De facto standards have been created by successful products and suites, such as Microsoft Office and the Adobe suites. If you've learned one application, you've learned most of what you need to know to use another.
But product designers are constantly confronted with opportunities to do things in a better, but different way. Is consistency an inviolable "must", or, as the saying goes, "the hobgoblin of small minds"?
There are enough "standards" in the software world that you can often pick from several. The aforementioned Office and Adobe suites, for example, have very different ways of managing menus, drawing graphics and applying styles. Likewise, web applications often base their user interfaces on toolkit-provided controls and predesigned widgets, which are often inconsistent. Look at the many ways videos are controlled in web-based players, for instance.
When building a new application, there's always the temptation to do things in new ways. It's a natural, competitive feeling: "we can do it better than the competition." Most real innovations start this way, with an invention that improves the user experience. But useless and confusing variations also happen for a similar reason: "we need to be different."
This is where the Product Manager plays a key role. Like so many other product decisions, this one should be based on customer needs and problems. The PM defines the target customers - primary, secondary, tertiary - and every design decision needs to be made in the context of those customers' requirements. If, for example, the target customers have never used a similar product before, there is more leeway for user experience invention. On the other hand, if they have been using a similar product, then it's a good idea to look carefully at where they have problems with the old product, and innovate in these areas. Changing things that are familiar and working satisfactorily is more risky.
Sometimes the customer is acclimated to one way of doing things, but it's creating problems and limitations that the customer may not be aware of. The case of the Office Ribbon is instructive.
(Be sure to watch The Story of the Ribbon, if you haven't seen it: http://blogs.msdn.com/jensenh/archive/2008/03/12/the-story-of-the-ribbon.aspx)
When Microsoft looked carefully at how its customers used Office 2000, it turned out that 1) people knew how to do a small range of tasks effectively, but 2) they were unable to take advantage of many features that they needed, due to problems discovering and/or using the features. The Office team was faced with a choice between continuing to build on top of Office's rickety menu/dialog user interface, or make a radical break. Product designers were able to show huge productivity increases when users could pick from highly visual representations of functions, if these functions were organized in a logical manner. The proposed new design was a new, nonstandard interface, the Office Ribbon.
The dilemma was that the gains in productivity (and satisfaction, too) were most evident among new users and experienced users who made the effort to learn the new interface. There were problems when experienced users (and there are millions of them) tried to just start using the new interface. They were often frustrated and angry. Not good.
Microsoft made a very bold decision to create a new standard. (When you're Microsoft, you can do things like this.) The obvious option of providing "classic" menus was rejected - it would radically slow the transition to the new UI, and add a huge development burden. The result is a mixed bag - some Office customers refuse to upgrade to Office 2007, but most of those who made the move eventually express satisfaction with the Ribbon, and studies in fact show increased productivity and wider use of Office's features.
Product Managers and designers have to make decisions like these every day, usually on a smaller scale. Stay with the familiar? Invent a better way? The tough decisions really come down to assessing the costs and benefits to customers. Here are some of the key questions to ask:
- What is the user problem that a new design is addressing?
- How serious is the problem? Is the user complaining? Is there reason to believe that users are not able to work with the product effectively, even if they aren't aware of it?
- How significant is the improvement offered by an innovation, from the user's point of view? Is it really better? Can you quantify this, ideally through testing?
- Does the improvement require a significant amount of relearning or other dislocation on the part of the users? Will they consider it sufficiently worthwhile to make the effort? Are they likely to feel that it was worthwhile after they have made the effort?
There are two other factors to consider.
First, is there a competitive advantage to be gained, in addition to that provided by increased satisfaction? For example, providing a standardized, integrated installation routine across multiple product may facilitate the creation of a product suite or bundle that supports a business strategy. (Think Adobe's suite strategy.)
Second, innovation is expensive. Even if a new user interface can be developed quickly, there is a cost in testing it on customers (you are testing before deploying, right?) and modifying QA plans. Good ideas are worth paying for; unnecessary innovations generally cost more than they're worth.
Change for the sake of change is rarely a good idea. Innovations that solve real customer problems are usually worthwhile. Distinguishing between the two can be the difference between driving customers crazy (and maybe driving them away) and making them fall in love.
Personally, I prefer it when customers love my products.
Most of us assume that it's a good thing when a mouse click performs the same action in different applications. Few of us miss the bad old days when every word processor had its own conventions, and there were no Windows interface guidelines and web interaction conventions. De facto standards have been created by successful products and suites, such as Microsoft Office and the Adobe suites. If you've learned one application, you've learned most of what you need to know to use another.
But product designers are constantly confronted with opportunities to do things in a better, but different way. Is consistency an inviolable "must", or, as the saying goes, "the hobgoblin of small minds"?
There are enough "standards" in the software world that you can often pick from several. The aforementioned Office and Adobe suites, for example, have very different ways of managing menus, drawing graphics and applying styles. Likewise, web applications often base their user interfaces on toolkit-provided controls and predesigned widgets, which are often inconsistent. Look at the many ways videos are controlled in web-based players, for instance.
When building a new application, there's always the temptation to do things in new ways. It's a natural, competitive feeling: "we can do it better than the competition." Most real innovations start this way, with an invention that improves the user experience. But useless and confusing variations also happen for a similar reason: "we need to be different."
This is where the Product Manager plays a key role. Like so many other product decisions, this one should be based on customer needs and problems. The PM defines the target customers - primary, secondary, tertiary - and every design decision needs to be made in the context of those customers' requirements. If, for example, the target customers have never used a similar product before, there is more leeway for user experience invention. On the other hand, if they have been using a similar product, then it's a good idea to look carefully at where they have problems with the old product, and innovate in these areas. Changing things that are familiar and working satisfactorily is more risky.
Sometimes the customer is acclimated to one way of doing things, but it's creating problems and limitations that the customer may not be aware of. The case of the Office Ribbon is instructive.
(Be sure to watch The Story of the Ribbon, if you haven't seen it: http://blogs.msdn.com/jensenh/archive/2008/03/12/the-story-of-the-ribbon.aspx)
When Microsoft looked carefully at how its customers used Office 2000, it turned out that 1) people knew how to do a small range of tasks effectively, but 2) they were unable to take advantage of many features that they needed, due to problems discovering and/or using the features. The Office team was faced with a choice between continuing to build on top of Office's rickety menu/dialog user interface, or make a radical break. Product designers were able to show huge productivity increases when users could pick from highly visual representations of functions, if these functions were organized in a logical manner. The proposed new design was a new, nonstandard interface, the Office Ribbon.
The dilemma was that the gains in productivity (and satisfaction, too) were most evident among new users and experienced users who made the effort to learn the new interface. There were problems when experienced users (and there are millions of them) tried to just start using the new interface. They were often frustrated and angry. Not good.
Microsoft made a very bold decision to create a new standard. (When you're Microsoft, you can do things like this.) The obvious option of providing "classic" menus was rejected - it would radically slow the transition to the new UI, and add a huge development burden. The result is a mixed bag - some Office customers refuse to upgrade to Office 2007, but most of those who made the move eventually express satisfaction with the Ribbon, and studies in fact show increased productivity and wider use of Office's features.
Product Managers and designers have to make decisions like these every day, usually on a smaller scale. Stay with the familiar? Invent a better way? The tough decisions really come down to assessing the costs and benefits to customers. Here are some of the key questions to ask:
- What is the user problem that a new design is addressing?
- How serious is the problem? Is the user complaining? Is there reason to believe that users are not able to work with the product effectively, even if they aren't aware of it?
- How significant is the improvement offered by an innovation, from the user's point of view? Is it really better? Can you quantify this, ideally through testing?
- Does the improvement require a significant amount of relearning or other dislocation on the part of the users? Will they consider it sufficiently worthwhile to make the effort? Are they likely to feel that it was worthwhile after they have made the effort?
There are two other factors to consider.
First, is there a competitive advantage to be gained, in addition to that provided by increased satisfaction? For example, providing a standardized, integrated installation routine across multiple product may facilitate the creation of a product suite or bundle that supports a business strategy. (Think Adobe's suite strategy.)
Second, innovation is expensive. Even if a new user interface can be developed quickly, there is a cost in testing it on customers (you are testing before deploying, right?) and modifying QA plans. Good ideas are worth paying for; unnecessary innovations generally cost more than they're worth.
Change for the sake of change is rarely a good idea. Innovations that solve real customer problems are usually worthwhile. Distinguishing between the two can be the difference between driving customers crazy (and maybe driving them away) and making them fall in love.
Personally, I prefer it when customers love my products.