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
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
You’ve spent the last six months toiling away at a product design. The last few weeks were especially rough—tying up loose edge cases, closing out bugs, polishing up interaction and visual design details. And now your product has launched, so its time for some well deserved rest, right?
Unfortunately, Bruce Sterling, science fiction author and design professor, got it right when he said, “Design is never done.” Before you know it, there are new features to add, new markets to conquer, and new updates to your application’s content.
Your seemingly elegant design begins to bloat with features, tear under the pressure of localization, and nearly keel over under the weight of new content that pushes it to its breaking point. Before long you give up. It’s time to redesign—again.
Could you have avoided this all too common cycle? Was there anything you might have done to anticipate these changes? One potential answer lies in scalable design considerations. Screen frameworks, user interface structures, and components that enable your product design to gracefully accommodate new features, new markets, and dynamic content—that can shrink or grow—are the cornerstones of a scalable design. Read More