Developing the Invisible
Published: May 8, 2006
During my years as an interface designer, I’ve worked with lots of different development teams. From big companies to small startups, the interactions between me—the product designer—and developers have been pretty consistent. We work through what interactions and features are possible given our timeframe and resources. We discuss edge cases and clarify how specific interactions should work. We debate product strategy, information architecture, target audience, front-end technologies, and more. We also frequently encounter the same issue: the need to consider what’s not there.
The way we get there is always the same. I work with the product team to balance user goals, business requirements, and technical considerations to create a product design. That design gets vetted, iterated, and ultimately documented.
Because I mostly work with fast-paced Web companies, I frequently have to create my design documentation under aggressive timelines. This means there is not a lot of time for creating detailed design specifications. Nor is there an opportunity for me to provide templates in HTML and CSS for every part of an application. So I turn over mockups and workflows—in the form of stories or task diagrams—to the development team. What I frequently get back is half of the design.
By half of the design I mean that all of the features, content, and functions are there, and they are working as designed. So what’s missing? Isn’t that the complete product design?
What’s missing is what’s invisible: alignment and whitespace.
Often, user interface elements are not aligned. What’s centered in the design doesn’t appear that way in what’s implemented. What was vertically or horizontally aligned in the design appears ragged.
Padding, or whitespace, often fares worse. In some places, padding is gone; in others, there is too much. Padding is set to different values, leading to columns and rows of varying widths. Changes in padding and alignment can negatively impact readability and obscure visual relationships that clarify how to use an interface.
Figures 1 and 2 show examples of problems with alignment and padding in the implementations of designs. The original design appears on the left; the implementation, on the right.
Figure 1—Do you see the differences between these examples?
Figure 2—Another example showing differences in padding and alignment
Why is this the case? It’s not that the developers deliberately modified the design. It’s not that they necessarily consider alignment and whitespace to be unimportant. It’s just that these elements in the user interface are often invisible to them.
Development teams are responsible for putting interactive features and content into a product. Empty space is neither feature nor content. Therefore, it is not a requirement. For a designer, however, whitespace is often just as important as the content.
As a designer, I spend a lot of time adjusting whitespace to enable effective scanning of content. I also spend a lot of time refining alignment and padding to establish the right prioritization between user interface elements. I utilize both of these design elements to guide users through the interactions on a page. I use them to communicate what’s most important, what’s related, and what needs attention. For designers, these are key requirements of effective communication. And yes, there’s a lot of evidence that shows what’s invisible does make a difference.
Now before you decide I am a whiny designer just getting on the case of user interface engineers for not building exactly what I designed, let me say that I know what the engineering team does in bridging the gap between a product design and an actual product is invaluable.
But just like designers should know what is possible with HTML and CSS—or whatever happens to be their medium—and how to make their designs bulletproof, development teams should recognize that the space between and around user interface elements and the alignment of those elements may be just as important as the elements themselves.
I’d love to see more developers bring the skills and craft they apply to the construction of the visible to the construction of the invisible: padding and alignment. Once they learn to look for these things in a design specification or mockup, they’ll have a better sense of the designer’s intent. A shared understanding of what’s being built—whether visible or invisible—goes a long way toward making products that our users can understand.