Column: Communication Design

As enablers of online conversations between businesses and customers, Web forms are often responsible for gathering critical information—email addresses for continued communications, mailing addresses for product shipments, and billing information for payment processing to name just a few. So it shouldn’t come as much of a surprise that one of the most common questions I get asked about Web form design is: “How do I deal with international addresses?”

But before we get into the nuances of address variations, it’s worth pointing out that addresses have a commonly understood structure. Through years of experience with mailing and postal systems, people have a pretty concrete idea of what constitutes an address block. This common understanding is so definitive that eyetracking data suggests, once people begin filling in a set of input fields that make up an address, they often cease looking at their labels. The basic structure of an address is so familiar, people don’t need the guidance labels provide. Read More

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. Read More

In a previous Communication Design column, “Refining Data Tables,” I alluded to the importance of Web forms in online commerce, communities, and creation. As arbitrators of checkout, registration, and data entry, forms are often the linchpins of successful Web applications.

But successful Web applications tend to grow—both in terms of capability and complexity. And this increasing complexity is often passed on to and absorbed by a Web application’s forms. In addition to needing more input fields, labels, and Help text, forms with a growing number of options may also require selection-dependent inputs.

Selection-dependent inputs are, in essence, a pretty simple concept: Once a user initially makes a selection from one or more options in a form, the user must provide additional input related to the selected option before submitting the form. Figure 1 illustrates this behavior by showing two steps from the eBay Create a Download Request form. After an eBay seller selects the Sold option in the Listings and records drop-down list, the form presents additional input fields for selecting a date range. Were the user to select a different option in the Listings and records list, completing the form would require a different set of additional options. Read More