Half-Baked Software Features

by Krishna on February 6, 2007

Here are a couple of examples of features which seem to have started as good ideas, but were never thought out through or probably tested in real user scenarios:

  1. In Yahoo! Mail, when you hit the Send button after composing an email, you will be shown a form to add the email address into your address book. This screen has the email address along with two textboxes to enter the first and last name of the person.

    The problem is this: In many cases, the person would already be in my address book, but he has just used a different email address. I want to add the new address to his existing entry in my Yahoo! address book, but there is no option to do that except manually copying the email address.

  2. Google Talk informs me whenever a new mail arrives in my Gmail Inbox. When I click the small notifier icon, it shows me the message. The problem is that there is no Delete button on this screen. Also, the Inbox link always opens a new window. The lack of Delete button is rather frustrating because I typically get a lot of emails that I just want to read and purge. I am not talking about spam — there are Google Alerts that send me emails on new search results for keywords I watch.

In both cases, I can understand the intention of the user interface designer. They may have thought that the particular feature would be useful to all customers, but they only thought of one particular scenario. For example, it is very likely that the Yahoo Mail team decided that if the email address is not in the Address book, you always want to add a new entry. They didn’t think about the possibility that people could change email addresses, because very likely, nobody on their team has ever changed their email address for the past several years.

Also the Gmail team probably thinks that since Gmail offers gigabytes of data and easy search, people never need to delete stuff. They can just archive emails. But a person like me hates keeping unwanted stuff around, even in the basement. I prefer throwing it out as soon as possible. Other people may save every last bit of paper for eternity, but that is not me.

The moral of the story is “don’t force your paradigm on your users”. While what you are doing makes complete sense to you, it may seem very foolish to me. Whenever you make assumptions about the habits of users, you may be unconsciously projecting your habits or way of thinking onto others.

This doesn’t mean that your vision is wrong. It could be right and it may very well be what the majority of users like. But there may be a significant number of users who may deviate from your way. Instead of writing off such possibilities outright, do some research to actually find out what people really do.

Many projects land into trouble because of project stakeholders who think that end users work in a certain manner and sometimes don’t even provide architects and designers the opportunity to talk with them because the stakeholders consider themselves as the “right” persons to provide the requirements. When the software is released, they are genuinely surprised to see a lot of pushback from end users who find it bearing little resemblance to reality. Sometimes, it is too late by then.

Comments on this entry are closed.

Previous post:

Next post: