Mike Venerable had a post today on simple UI design that stirred up some thoughts. When designing anything, a device, web site, business card, anything, there are two related principles to consider; simple is best, and worse is better. Once upon a time design was about changing the world, lately what we call design tends to be more about selling sugared water or soap. Even worse we draw what I consider to be artificial lines between different design worlds; industrial, graphic, web, software. It can be about seeing something did not exist before, or seeing the true form of something, not just being pretty.
I had the great fortune to have a team at NeoWorx that built some truly great software. The design of this software, and I truly mean design from depth, not just how it looked but how it felt to use, how it ‘thought’, how it was built from the very ‘bottom’ of the deep hooks it had into the operating system to the reports it gave, was truly great. It was great enough to get the company sold to McAfee, and from there strongly influenced the look and feel of their entire consumer product line over the next year.
By far the single most important ingredient to great software design is an integrated team and an integrated design process. If you leave UI until later there will be compromises.
We never felt the need to codify the principles we followed at the time, being a “gelled team” we pretty much thought and acted as though of one mind a lot of the time (which is not to say that we were always in drone like agreement, much to the contrary, but we had good culture of trust and respect that allowed us to hash out things without anyone trying to defend ‘their’ idea to the exclusion of good input.)
If I were to try to codify now the principles we operated under then it would be something like:
Make it easy to find what is needed, and if we need something from the user ask plainly. Most important things easy to find, action the user has to take front and center. Need info? Ask for it in plain English.
Don’t ask the user any question they don’t have any basis to answer. This goes hand in hand with offering too many features.
Better still, don’t ask the question. Too often we demand of users they make choices. To the creator of the device or software it may seem like we’re giving freedom to the user. Really you aren’t, it is delaying what should have been a design decision until the last possible moment. If you can make the system a little bit smarter and save the user having to be bothered, it will be more useful.
Less is More. Don’t overwhelm the user with choices and data, just get to the point.
Good Enough security. This one applied specifically to security software, and is the hardest for ‘serious IT’ folks to understand. Technical people often strive for a ‘perfect’ security solution because it is theoretically possible. The computers should do our bidding and the humans should do whatever it takes to make it so. Of course it turns out that if you make users to unnatural things, like overly complex passwords they must change every 2 weeks, they will subvert the system to make it human compatible again by writing it down. So don’t waste time trying to protect against incredibly unlikely events, instead focus on doing a great job with the things that happen every day. Classic 80⁄20 rule.
Just work dammit. This one turned out to be a problem over time. What’s the perfect spam filter? Just make all my spam go away. Period. Perfect Anti-virus? Block anything bad from getting on my computer. Don’t bug me about any of it, just freaking do it. Oh the irony. In the case of security software it is a particularly insidious problem; if you are doing a great job and being quiet about it the user may be unsure of what value they have received when it comes time to upgrade or renew their subscription. At McAfee we were eventually forced to make the software notify the users of events that strictly speaking were not ‘newsworthy’.
But now the $100mil question; why doesn’t everyone follow these sorts of principles? Because it is hard. It is much harder to make something simple than to make something complex. The normal approach taken to adding a capability is to take what is there and tack on additional material/infrastructure/laws/data fields/etc. to accommodate the change. It is more work, and depending upon the organization involved fraught with political peril, to accept the newly desired behavior and then rethink the entire thing to find the new best form it should take. (We have the same problem with legal infrastructure and policy and procedure at any company over 100 people, this is directly related to why startups are more efficient than large companies and why after 200 years the US government is gridlocked and only able to take action in the face of crisis. But I digress.)
As Mark Twain said “Sorry for the long letter, I didn’t have time to write a short one.”