What Every Programmer Should Know About Design
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.
Mon, July 15, 2013
CIO — 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 Wright was the first designer hired to help with Liquidnet Products. Instead of trying to "bring design in" by building an empire of designers, Wright took a different tact: Offering design education to the staff. Today, Wright is the firm's creative director, and though the company has a few designers, it has what he calls basic design literary.
What does Wright 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, Wright recommends asking three questions about design.
First, Wright 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?
Wright 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, Wright quickly asks, "Do you mean more efficient or more discoverable?" This starts a conversation.
Second, Wright 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.