Subscribe / Unsubscribe Enewsletters | Login | Register

Pencil Banner

What every programmer should know about design

Matthew Heusser | July 16, 2013
What does a lead designer for a Madison Avenue technology firm think every programmer should know about design? Sneak preview: Interfaces actually matter less than you might think. But that's just the tip of the iceberg.

After spending the day visiting the technical staff at the trading firm Liquidnet, I was moved by the company's attention to design and how it impacts customer service as well as products development.

Before I walked out the door, though, I had one final request: I wanted to meet the designer.

Eric Right was the first designer hired to help with Liquidnet Products. Instead of trying to "bring design in" by building an empire of designers, Right took a different tact: Offering design education to the staff. Today, Right is the firm's creative director, and though the company has a few designers, it has what Eric calls basic design literary.

What does Right mean? There is no good, "correct" design. Instead, design is all about tradeoffs. Design literacy is "understanding enough of design to be involved in a conversation about those tradeoffs, to understand where the designers and product managers are coming from when they communicate about the product," he says. "At the end of the day, it's the front-end implementer [who] will decide what the user interface really looks like."

Questions of Good Design Are Open-Ended
To achieve design literacy, Right recommends asking three questions about design.

First, Right emphasizes that the designed interface should be intuitive. But the word intuitive sets off alarms, as it could mean two things: Is the interface efficient, or is it discoverable?

Right says that a discoverable interface is one the end user can figure out without a lot of training. Angry Birds and iOS are discoverable. An efficient interface, on the other hand, takes training-but once you are trained, it is more powerful. An efficient interface lets you do things more quickly and, eventually, more easily. When the product manager says a design needs to be intuitive, Right quickly asks, "Do you mean more efficient or more discoverable?" This starts a conversation.

Second, Right is keen to discuss is the user base. Is it homogenous, where all users represent one type of person-say, a statistician-or is it something like a word processor, where users have varied skill level?

The example here: iMovie vs. Avid. Apple iMovie offers powerful simplifications and auto-complete features that are usually good enough, most of the time, for an introductory audience. Users can get to completion quickly.

Avid Media Composer 7, on the other hand, is a tool for professional movie editors and therefore has complex tools that take more time to learn. From a distance, the two products appear to compete, but up close, the "right" feature for one might be wrong for another.

Third, Right asks, "Is the tool a screwdriver or a Swiss army knife?" A Swiss army knife is a set of tools, each good enough for its task. The screwdriver is a single tool that does a single job extremely well. Right tells me that, in the physical world, we understand the tradeoffs: Weight needs to be traded for strength, power for space and so on.


1  2  3  Next Page 

Sign up for CIO Asia eNewsletters.