give them what they need, not what they want
May 02, 2008
It is a dicey thing saying no to customers, especially when they pay big bucks for not only the software license, but a bus load of consultants that integrate and customize the software for their deployment. However, I believe that the same truths hold as when you hear from 50 customer in 500,000 and you really cannot give each person what they want. You need to listen them, then give them what they need, not necessarily what they are asking for. But they best way to say no is to actually convince someone of a different perspective, that they gain something by the omission of something else.
When old tricks don’t work…
People create their own myths about how a feature works. Humans naturally develop a mental model of what’s going on, of cause and effect. When an interface is well-crafted and the designers made the correct assumptions, most people will develop a mental model that is close to reality. Sometimes the best of intentions go wrong. For example, many webmail interfaces have a “Block Sender” button on the screen where people read their emails. When someone gets an offensive, unsolicited email, they think “ugh. I don’t want to get this junk from some creep,” so naturally they click the “Block Sender” button. The problem is that the spammers aren’t using their real email address — they fake something up and rarely do you receive an email twice from the same sender. Nowadays preventing spam needs to be more sophisticated, most webmail systems often offer the option to “Report as Spam” which is much more effective since there is a back-end service that develops heuristics on what is spam and what isn’t, so even if the sender doesn’t match, the new spam might be recognized and blocked. Not only that, but if people block the sender of every spam message they receive, they quickly develop gigantic blocked senders lists, which many back-end mail systems aren’t optimized to handle. So when a customer licensing email says, I want a “Blocked Sender” button on the main screen of the app for a new deployment, I tell them the back story as I understand it and explain that people really want to just prevent junk mail and we should make the options that will help with that first and foremost. So far it has worked out, the insightful product managers agree.
When something better comes along…
Knowing the what people really need is especially tricky when transitioning from an old interface to a new one. Whether upgrading a version or switching vendors, individuals always have a hard time at first adjusting. I keep running into this with the “Nickname” field in email. It’s really hard to say no to any feature that exists in Outlook. For better or worse, it is the most popular desktop email program and webmail apps have historically emulated as many features as they could. So, most webmail apps have a nickname field. Now this feature was important in the days before auto-suggest, in the early 90s when we all had 100MHz processors running Windows 3.1 and before Web pages had Javascript. Instead of looking up a contact or typing a long email, you could choose a short nickname for someone.
Ok, maybe it isn’t needed any more, but what harm is it? Aw… come on, it’s just one more field. One of the huge usability advantages of web applications over desktop applications is that they tend to be simple. This design often emerges from necessity based on technology limitations. As the technology improves to offer a more desktop-like experience, designers and product managers have an opportunity in this new space of moving beyond the cluttered desktop experience to offer a simplified interface that is no less powerful. By offering a nickname field, you are telling people they need to manage their address book, they need to go through and pick their favorite people or people they communicate with frequently and set them up. In this new age of vast information stores, software is becoming more adept and figuring out what you need and giving it to you without requiring a setup process. Auto-suggest is an innovation along these lines. You can just start typing the first few letters of someone’s name and their full name and email address pops up. By taking away a feature for some people, we make sure that they know and new people know they don’t have to rely on the old way of doing things, and we streamline how they use the application and allow the software to work for them and for them to do less work.
The art of design is making choices. We develop models of how people would be most effective in accomplishing their tasks. We need to be particularly careful when a new option replaces an old one — sometimes redundancy is a good thing and sometimes too many ways of doing the same thing make an interfaces cluttered and confusing. It is a delicate process to guide people into patterns where they will be most successful.