"No matter how cool your interface, less would be better."

How long will we keep building software that has 10 search boxes on its search page? Google launched in year 1999, and its user interface has one text field and two buttons(one too many in my opinion). Today we are still building screens with more than 50 items, numerous buttons, drop-downs, long scroll after scroll. When will we learn that users need less not more user interface.Choices = Headaches

Imagine you are building a user interface for the Army, for a battle decision control system, where pushing wrong buttons could result in loss of lives. Now rethink the interface from the army commander’s perspective – how would you present this information. Suddenly you become sensitive to throwing more drop-downs, text boxes and buttons on there. I think you have started to see the picture of the impact of your user interface on the day to day life of the end user.

How do we innovate our user interfaces. Certainly not by “asking” the users what they would like. Innovation is creative solutions to user pains that may come by “observing” the user, their context and their larger world in general. It cannot be accomplished simply by “asking” the user. “Why” is a friendly weapon in an innovator’s arsenal to determine what the user motivations are, and what the current pain points are. Of course, it takes creative software development team to convert the idea into working software that resembles something that understands the user. This is why it is my firm belief that great software can only come from teams that have user empathy at the core of their effort, whether their contribution is that of a requirement writer, designer, developer, or tester. If every single person on the team cannot envision their product in the hands of the eventual user, they will not be able to build a very effective piece of software. Every small decision that a requirement writer, developer or tester takes has eventual impact on the usability of the software. It is virtually impossible to make software development “factory like” work with specifications, in my opinion. The states that the executing code be in at any given moment explodes once developers start converting requirements specifications into executable code. At this point, developer make conscious decisions on the behavior of the software, sort of “reading in-between the lines” of the specifications. How good the product will end up to be will depend on what developer wrote and what the tester interpreted as the requirement to be.This is as much art as much it is science. The quality of your people will determine the end result.

So we owe it to our teams to teach them to write software with less interface and coming up with innovative ways to solve the problems that the users don’t know need solving yet.

This entry was written by Amit, posted on October 6, 2008 at 4:17 pm, filed under Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.