Interface Mason

UI design fundamentals: Do you have the right stuff?

User interface design happens as surely as the sun rises in the east. It's inevitable. Whether you let your developers design your UI or your BA or your PM or an experienced user interface designer, someone or some set of circumstances is going to determine your user's experience of that software.

The only question is whether or not that experience will be a constructive one.

UI design is tough because it's highly conceptual and many of the other disciplines involved in software design are far more linear: They have beginnings, middles and ends. The temptation in some of these other disciplines is to decide UI design is sort of a fancy suit you dress your software up in to make it more presentable when it's all done.

True, UI design has its more superficial components: what is the color scheme? what will the buttons look like? what fonts should be employed?

But UI design is not JUST these things any more than a tasty cake is just the frosting. Effective UI design, to really extend the metaphor, is a crucial ingredient that must be mixed in from the beginning and baked into the process.

In the words of Steve Jobs, "Design is how it works."

Which means that if you're coming up with some new product, some new application designed to address a unique business need or client requirement, you have set about to determine how something will work. And if you're doing this, you are facing a number of unknowns.

One way to handle unknowns is imitation. How has another successful product handled a similar problem in the past? Imitation is a powerfully persuasive solution because it is presented alongside direct evidence of its viability: "See, if it's good enough for Microsoft, it's good enough for us -- case closed."

The problem with this strategy, of course, is that Microsoft or whichever other vendor's solution is under consideration may well have been boosted from some other application -- which in turn, may also have been boosted from some earlier application and so on. Bad ideas can persist in this way for years and the more they're copied, the more entrenched they become. If you're building software in a competitive market, you're not in the business of doing whatever everybody else does, you're in the business of getting to the exact right idea and enbracing it fully. When Firefox started eating Microsoft's lunch in the browser market, Microsoft's next version of IE featured tabbed browsing just like Firefox's. Do you want to be the copier or do you want to be the one being copied? As of this writing, Firefox has seized 24% of a browser market once dominated relentlessly by Microsoft. And this diversity has opened the door in the minds of users everywhere to the idea that some other player may be building a better mousetrap after all. As of this writing, Microsoft's browser marketshare is down to 59% and Google's Chrome and Apple's Safari are gaining ground every day.

So if you can't just do what the other guy is doing all the time, what CAN you do to assure the relevance and ultimately, the success of your software?

You have got to focus on what makes life easier for your users. To do this, you must understand their goals. For B2B, your user's goals all fall into one single category -- getting their job done effectively and moving on. They don't want to be impressed, they don't want to read your help files and they definitely don't want to call your help desk.

The single most important factor in determing the efficacy of any user interface, according to Human Factors International is SELF EVIDENCE. Which means the user's workflow has been anticipated by the application's designer, which means that whomever designed it considered the user and that user's goals.

This simple act of stepping outside ourselves and really looking at our product from the user's point of view is the first step toward delivering something they will want and use. Not taking this step in earnest is the best way to deliver a product that garners complaints and costs you references.

In an attempt to drive this fact home for a previous employer, I played the following scene from the 1981 film 'The Right Stuff' to a room full of stakeholders. I analogized the product to the space capsule and the users to the Mercury astronauts. The goal was to make sure no one could analogize our team to the NASA engineers as depicted.

"We want a window." A more poignant analogy for user frustration with a product that has failed to anticipate their needs does not exist. 

The press milling outside I analogized to the product's reputation.

So to all of those stake-holders in corner offices everywhere, and to those among them who think functionality is enough and reputation doesn't count, remember: "No bucks, no Buck Rogers."

Understanding your user's goals, in the end, is the only way to show YOU have the right stuff.

When Tuftean ideas get misinterpreted, "less is more" can run amok

Edward Tufte is clearly one of the most important thinkers in recent history on the matter of representing data visually. Letting data speak for itself means getting to its essence and dispensing with fluff that not only doesn't ADD to the informative value of graphs, charts, or diagrams, but actually SUBTRACTS from it -- leading the eye away from essential meaning.

Dispensing with fluff and getting to the heart of the data aren't always the same thing, however.

Tufte's ideas can often get abbreviated down to a "less is more" strategy. I know because I've made that mistake myself in my own designs on occasion. You think you're letting the data speak for itself and you get the feeling that if Dr. Tufte himself were standing next to you in that conference room as you all stared in amazement at the Powerpoint slide on the scrim in front of you, he'd slap you on the back, give you a hearty "well done, m'boy" and invite you out to the university as a guest lecturer. But your audience is scratching their head instead. Suddenly Tufte isn't the one standing next to you,  it's your third grade teacher and she's got the red marker out.

Why?

Well, sometimes when you're showing super-cool, cutting-edge Tuftean design to a room full of Microsoft devotees, anything that isn't blue with a fade and sorted into a box is going to be met with criticism.

But sometimes it's because less is often NOT more -- sometimes it's just LESS.

Tufte's ideas have helped me produce far more eureka moments for my designs and made them better received than any other single influence. But sometimes you really have to watch where that line is -- the line past which you've reduced away too much and let your interface design veer cold and ungenerous, if not downright alien.

When you have let your design drift in that direction, it's admittedly of some comfort when you realize other experts can make the same mistake.

Especially when it's the guy who designed the interface of the Edward Tufte Web-site!

Now THAT page was designed by someone who took Tufte's ideas too far into a less-is-more realm. The whole top half of that page looks like a site that lost its stylesheet.

Sometimes MORE is more and sometimes data can't speak for itself. As a UI designer it's up to you to give that data a voice and find that perfect middle ground.