Eating Rotten Fishheads
This post originally appeared August 8, 2011 on BetterProjects.net
I do not believe Microsoft’s assertions that the ribbon is easy to learn. If you feed someone rotten fishheads for a while, then switch them over to a diet of fresh fishheads, they will be happier. You can then tout the statistical “fact” that “users prefer fresh fishheads,” even though the truth is that they HATE fishheads. That, I believe, is how Microsoft gets its rationale for UI changes.Cooper is discussing his recent switch from Office 03 for Windows to his new Mac. He hates Office’s ribbon interface, his point being that Microsoft’s claims of it being easier to use than the old interface is bogus. I agree.
His broader point though is that if you’re changing something from bad to merely less bad, you shouldn’t go around telling everyone about how great the new is. Its not. The cognitive friction you force on your users with a completely revamped interface is not worth it when your improvements are so minimal compared to the learning curve.
This came to mind as the meeting I sat in all day today spent a significant amount of time discussing the look and feel requirements for a new application we’re considering having a vendor create. Our current system uses a series of accordion menus down the left-hand side of the screen. Last summer, when that system received an upgrade, the new version allowed for pull down menu navigation across the top of the screen. Assuming that people were likely more familiar with that type of navigation, the default was switched to the pull down menus.
It was resoundingly hated.
See, the new navigation style really wasn’t any better (or worse) than the left-hand menus, it was just different that what people were used to using. Had the new navigation system been substantially better, maybe with large icons that can expand out into sub-folders, such as is seen with the iPad, then maybe the user outcry would have been much less.
When you’re looking to change something that is a known quantity for your users, always make sure that the change is really worth it to your users prior to making. But how do you know the change is worth it?
First, ask around to see if anyone is up in arms about it. Don’t ask subjective questions like, “Do you like navigation?” but ask more focused questions such as “Do you like left handed navigation or menu bars?” You’re more likely to reduce the ‘noise’ in answers and get to the real meat of the discussion. The flip side of this advice is to make sure you really do touch on areas that could be of real concern. If you miss asking about the real problem, you wasted everyone’s time and are no better off than before you started asking questions.
Next, place a value on the change. Does it save your stakeholders a lot of time? A lot of money? A lot of frustration? Define what 'a lot’ really is! If you have 10 users and your change will save them only a few seconds a month, it probably isn’t worth making the change UNLESS it removes something that is so incredibly annoying that you build a lot of good will. On the other hand, if you have 10,000,000 users and it saves each of them a few minutes a month, then the value of the change is very high.
Now, determine the cost of the change. There are lots of costs here. If its a system change, you’ve got to calculate the cost of the stakeholders to explain the desire, the analyst to figure out the best way to fit it into the existing process, the developer to code it, the testers to test it and the Ops team to deploy and support it. Your users will need to be trained on the new function, that will add to your cost. If the process change is significant due to a vastly changed process, will they be able to learn it and do so quickly? Don’t forget about the opportunity costs, either. While you’re making this change, what other changes are you forgoing that could be less costly?
Finally the hard part… determining if the change is really worth it. You take the value, subtract out the cost and see if you’ve got anything left. Even if you come out with a positive value here, remember that if the value is very small, then it may still not be worth it. The goal here is to provide your stakeholders with a significant positive value, one that is large enough to overcome their fear and reluctance to change.