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.
With software, it's too easy to try to do everything. Yet, in general, most applications benefit from a push to do one thing really well," Right says. "At Liquidnet, we started with a crisp, clear vision-to help large asset managers trade safely at the size they need. That's still the most important thing we do. We've added other things but never lost sight of that core."
The way Right frames all three of these questions-discoverable or efficient, broad or specialized user base, one excellent tool or a toolset-there are no correct answers. Rather, it's a conversation he expects to have all the time with the whole team over lunch, at the water cooler, in requirements meetings-and, yes, when creating actual designs.
From Design Theory to Execution
When asking about design work, I had expected Right to talk about CSS, HTML5, palettes and color layout. Is part of his discussions on design as well?
"Not really, no," Right answers quickly. "Those details matter, they really do. I love discussing type, font, layout, color, visual effects, all that stuff. The thing is, if you get those wrong, they are easy to fix. The icons in iOS are like the paint color of a house; you can just swap them out."
Basic interactions and features, on the other hand, define the application itself. Teams that get that wrong will have a lot of spade-work to do to fix them. That's why Right focuses on things that apply to the whole team and that matter, such as the user base, the discoverability of the interface and the purpose of the software. That's what he means by design literacy.
"Think about making an MP3 player or CD player. There were a lot of companies doing that in the 1990s. These companies were early to market and had products with all the right features, but they weren't simple or beautiful," Right explains. "Today, most of those companies are gone or at least radically different. It was Apple that made the iPod. Creating a beautiful product is more challenging than most people realize." For evidence, he simply points at all the companies that failed while trying.
Bringing Attitude to Design Theory
After an hour, I ask one last question: After people understand these three questions, where can they go to find out the next three?
While there are some classic books on design-Right is a fan of The Elements of Typographic Style-but he's more likely to recommend books about attitude than user interface design. As his first examples, Right mentions Alan Cooper's About Face or Steve Krung's Don't Make Me Think!
"Krung's work makes the point that your user doesn't care about your application; he just wants to get something done," he says. "A good application gets right to the doing-If your users don't even notice your interface, you are doing something right."
Going beyond Krung, Cooper and the design of software, Right's final example is Christopher Alexander's A Pattern Language. This book is about classifying the patterns found in towns and communities. Right says it's "ostensibly about spaces and physical architecture, but its really about the human experience."
Good design, then, is about making the right tradeoffs for your customer and understanding the customer well enough to make those tradeoffs.
I leave with a few ideas, a few reading assignments and more questions than answers to bring to the next project. But if it leads to a better design, then more questions than answers is a good thing, isn't it?
Matthew Heusser is a consultant and writer based in West Michigan. You can follow Matt on Twitter @mheusser, contact him by email or visit the website of his company, Excelon Development. Follow everything from CIO.com on Twitter @CIOonline, Facebook, Google + and LinkedIn.
Read more about consumer in CIO's Consumer Drilldown.
This story, "What Every Programmer Should Know About Design" was originally published by CIO.