So the Necessary May Speak

By Luke Wroblewski

Published: November 3, 2005

“When you design an interactive product, you are creating the setting for thousands of conversations, which will be spoken between product and person.”—Marc Rettig

“It is ultimately the presentation of an interface—layout, look and feel—that tells users what a product has to offer and how they can make use of it.”

Though carefully structured organizational systems and well architected interactions are key components of effective interface designs, it is ultimately the presentation of an interface—layout, look and feel—that tells users what a product has to offer and how they can make use of it. As a result, creating usable and engaging interactive products is dependent on our ability, as designers, to communicate with our audience. The better at communicating we are, the easier it is for our audience to understand our messages and intentions and the easier it is for them to use and appreciate the products we design.

Interactive products, by their very nature, tend to be complicated. They allow us to create and control large amounts of information and enable many unique interactions. As a result, there’s a natural tendency for interface designs to over-communicate, or establish multiple forms of dialogue and vocabularies within a single application or interaction. Complicated concepts require more explanation, right? Not always.

“The ability to simplify means to eliminate the unnecessary so that the necessary may speak.”—Hans Hofmann

Consider the simple table in Figure 1. It’s telling you about a certain set of data points and their corresponding values. The problem is that excessive visual noise and redundant content obscure the values themselves—arguably the most important elements within the table. It’s hard to concentrate on the values, because the background color and the thick borders continually compete for your attention. The varying thicknesses of the table and cell borders actually make them even more distracting. In other words, the table itself is talking louder than the data it’s trying to communicate.

Figure 1—A simple table

Simple table

Our first inclination, therefore, might be to reduce the table’s volume by removing its background color and dark borders. This gives us the table in Figure 2.

Figure 2—The table without its background color and borders

Table without background color and borders

The values and their labels are now clearly the focus of the conversation, but this design requires a lot of bouncing back and forth between the labels and the values to understand what the table is telling us. We’re not being told anything about the relationship of the values until we take the time to read each one. We’ve also lost the message that this is a unified set of data. Once we remove the border, there’s no visual grouping of the elements in the table, so our table may blend in with other items on the page—depending on their visual treatment, of course.

In order to communicate the relationships among the labels and the data in our table, let’s bring back some of the visual elements we just took away. This time, however, we’ll use only the minimal amount of visual contrast necessary, as shown in Figure 3.

Figure 3—The redesigned table

Redesigned table

The light, single-pixel border we added has just enough visual weight to group the content in our table, without being visually distracting. The light background color meaningfully groups related content within the table—such as the numbers of admissions and numbers of discharges over various time spans—without introducing multiple visual elements like the borders between the rows of the table we had before. We also reduced the contrast of the table header, which was getting undue attention.

Things are looking pretty good, but we can do even better. By eliminating redundant content—such as the repeated phrase Number of—and putting the visual emphasis on the values we care about rather than on their labels, we can simplify the design of the table even further, as shown in Figure 4.

Figure 4—The redesigned content

Redesigned content

In our final table design, the visual elements are just noticeable enough to group related content without distracting from it. We’ve made the labels within the table easier to scan by removing redundant content and emphasized the values through the use of bold type.

“Clear, concise design is a key factor in the success of all user interfaces.”

Through this rather simple example, we’ve seen how we can reduce both visual design and content elements to the minimum amount necessary for effective communication. Clear, concise design is a key factor in the success of all user interfaces, especially when you consider the amount of information we’re all required to parse in today’s digital world. Design so that the necessary may speak.

11 Comments

Another simple, elegant example from Luke. His site has many other clear and concise examples on the basics of UI design, in case you’re not already a reader.

One thought I had is that examples like this can highlight some of the conflicting goals of programmers and designers. The “before” tables are likely much more easily created and maintained, especially in a dynamic environment where there are thousands of possible outputs from large data sources. Allowing for fairly easy maintenance and the nice “custom” visual design that’s tailored to specific cases is an interesting challenge, and is partly the reason why I keep digging into code myself…

I didn’t understand the title until I got to the quote :)

Great job, Luke. You wrote just enough to illustrate your point.

That quote has been a cube decoration of mine for a long time.

Great article Luke.

Jed- you raise a great point, though the data isn’t different in each stage of the redesign, the code may be. Usually it is easiest for developers to output the contents of a database as name, value. The example above not only groups some of the values but also adds unique formatting for values vs. labels. Not THAT big of a deal, but introduce enough of these types of changes and it might become a bit tedious. That said, I’m sure a sharp developer can build even the trickest of output and turn it into a slick reusable function to boot!

Gilbert- thanks for the note~

Great article. I think it is very important to design interfaces based on human perception rather than computer based model of information organization. I actually propose some additional “improvements” to the design of the table on this page - Table design improvements

Thanks Andrey!

Deva Prasad also suggested some redesign ideas that I discussed at: http://www.lukew.com/ff/entry.asp?328

Keep ‘em coming :)

Thank you, Luke. Again, your article is very informative, straightforward, and uses pictures. I’m a very visual person, so I appreciate your articles a lot.

It is a great article.

But as a semantic fanatic, I would recommend that in your Figure 4, the label elements ought to be visually removed. By this I mean: Apply a CSS style that hides them, but they are still there in the markup semantically for accessibility reasons. And for free, you get the programmer’s issue solved. (@jed)

BrianK—If we removed the labels, wouldn’t that impact information legibility? How would people know what each data value represents. I think you’d have the same problem as Andrey Smagin’s design here: http://www.lukew.com/ff/entry.asp?550

Sorry to be late in the discussion, but the only problem I have with this solution—as much as a love it—is that the highlighting of the New Admissions only suggests to me that there is something special about that group of data.

I think, to avoid this implication, it might be a better idea to use a lighter shade of blue instead of white.

Just my opinion.

The change in the <TABLE> definition actually lends itself to a change in tag. While a table is semantically correct, I’ve found that definition lists are another good way to group two-column data (one key and one corresponding value). They have the additional advantage of reducing markup (W3C’s specification). To duplicate the form above, the definition list term (<DT>) is floated left with a hard width and the definition (<DD>) has a margin-left equivalent to the term’s width.

CSS: dd {   float: left;   width: 100px; } dt {   margin-left: 100px; }

Join the Discussion

Asterisks (*) indicate required information.