What Every Programmer Should Know About Design

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.

How-to: Create Digital Products That Customers Love

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.

Third, Wright 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. Wright 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,” Wright 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.”

Tips: Cloud UI Design Mistakes to Avoid

The way Wright 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 Wright to talk about CSS, HTML5, palettes and color layout. Is part of his discussions on design as well?

“Not really, no,” Wright 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 Wright 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.

Related: Is Your Enterprise iPhone App Really User-Friendly?

“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,” Wright 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—Wright 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, Wright mentions Alan Cooper’s About Face or Steve Krug’s Don’t Make Me Think!

“Krug’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 Krug, Cooper and the design of software, Wright’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.