Just do it

A good user interface does what the users asks. The user shouldn’t have to fight the computer at every step. They want the computer to do something, so just do it.

In this example, we are awarding a contract to a supplier. After selecting a supplier, the user pushed the toolbar button:


 Rather than awarding the item, the user is presented with a rather unfriendly error message:

Not very helpful

This isn’t very helpful. The user asked to award a contract to this supplier. She did not ask if it was already awarded to someone else. She isn’t even given a hint by the software as how to proceed. At least we could be helpful and tell her who the other supplier is:


But we’re not really accomplishing what the user asked. If there is no way for her to award the item, then she should not have been able to reach this “error” condition in the first place:


Disabling the toolbar button makes it clear that what she wants is just not possible. Rather than being led to believe they can award an item, and then having the rug pulled out from under them – it’s understood from the beginning that they can’t. But there’s still a better way.

If the user is allowed (i.e. there is a process, and they have permission) to unaward contracts from one supplier, and give them to another, then do so. The user wants it done, so just do it:


This way everyone’s happy.

  • the computer does what the users asks
  • the computer is satisfied that it has given the user fair warning; that the user might be making a mistake
  • the computer is forced to do the grunt work, which computers are good at

1 Response to “Just do it”

  1. 1 Bryan April 26, 2007 at 3:11 pm

    Great example and very good alternate design. We see these types of messages all the time. I think what happens is that instead of trying to get the software to “just do it”, the developer is the one being told to “just do it” by their boss. Probably there is a tight timeline and the developer received a ticket asking them to prevent multiple items from being awarded. In the developer’s mind they just need to satisfy the request then move on to the next ticket. What’s good for the software isn’t always what’s good for the developer nor the project timeline, and hence you get the error message instead of the software offering to solve the problem.

Leave a Reply to Bryan Cancel reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

April 2007
    May »

%d bloggers like this: