Published: October 8, 2007
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.
An effective screen framework for an application can provide a blueprint for deciding how to integrate new features. Just as an architectural blueprint of a house clearly shows the kitchen, which tells you where to install a new oven, a framework organizes the spaces that make up an application screen.
Consider the screen framework for a Web-based reporting application in Figure 1. A set of key spaces organizes the application into a meaningful system. Tools that help people filter a data set are on the left. Options that let people access different data sets are above the data display area. Data-handling tools—export, save, send—are likewise above the data display.
Figure 1—Screen framework for a reporting application
This representation of the application doesn’t get into the level of detail you’d find in a typical wireframe or mockup. Its sole purpose is to provide a coherent way of assembling the spaces that fulfill the essential purpose of this particular application screen—specifically, in this example, a way to select unique data sets, filter or refine them, display their content, and tools for acting on a particular data set.
Now consider what might happen if—once this product launches—customer feedback tells you that your customers need a new refinement feature. No problem, you know exactly where to place it, and the application design remains intact. What if you need to add something that doesn’t have a clearly defined place in your framework? It might very well be the case that it doesn’t belong in the reporting portion of your application. Just because you could add the new feature here doesn’t always mean you should. In both cases, the screen framework gives you a clear way of determining what to do with new features, without requiring you to rethink your design.
If you do find there’s no place for a new feature in your existing screen framework, but it clearly belongs in that part of the application, your framework might have to change. But if you thought through the framework’s purpose when you first designed it, this should be a rare occurrence.
User Interface Structure
While a screen framework gives you one way of determining where to place—or not to place—new features, the structure you select to house the various components of an application is what determines how scalable your design actually is.
For example, let’s consider the data-set selection feature in this application. Since the purpose of this part of the framework is to let people choose a particular data set they’d like to see, it might be appropriate to use a series of horizontal tabs, enabling people to easily switch between available data sources. Figure 2 illustrates this common design solution.
Figure 2—A structure that doesn’t scale well
Now consider what happens when you need to add more data sets. Do you add more tabs? How many tabs can the application support before important content runs off the page? Or what if your team decides to launch the application in France or Germany where equivalent labels often have twice as many characters as their English counterparts. Quite quickly, you’d find the structure you’ve selected for this part of your application doesn’t scale and, in many cases, that can send you back to the drawing board.
It doesn’t take too much foresight to realize this part of the application might grow in the future, and you should, therefore, consider an alternative design. Perhaps a prominent drop-down menu? Or if you need to keep the choices consistently visible, a series of options in a vertical list? Both of these structures are more likely to scale as your application grows.
Let’s assume you carefully thought through the structure for the data-set selection part of your application. Anticipating the scalability problems a horizontal row of tabs could have, you opted instead to use a list of menu items that can scale vertically, as seen in Figure 3.
Figure 3—A vertical set of options that’s designed to scale well
Unfortunately, you’re not out of the woods yet, because the actual content within your scalable structure is subject to variation as well. For instance, in the case of labels, the quantity of content could change or an individual’s browser settings could scale the content so it requires more or less screen space.
Anticipating these types of changes requires some thought about how each user interface component should scale. On many product teams, this burden falls on the developers. Without specifications from a designer that outline how this component should scale in the face of additional or resized content, developers might or might not do what the designer intended. Compare the impacts of changing the quantity of text in this set of options, as shown Figures 3 and 4.
Figure 4—Here the designer did not think through how this component would scale
In Figure 4, the selection indicator wasn’t vertically aligned to appear at the center of the item. As a result, it rests at the top of the selected option. The height of the background image isn’t adequate to allow for longer text, nor is it set to repeat only horizontally. The line heights of options took into account only their spacing when each option is a single line, not what happens when options span multiple lines. All of these factors add up to a sub-optimal design when content requires scalability.
Your applications will change over time. How much of an impact that has on your existing design depends, in part, on how well you’ve accounted for scalability. Several design considerations can help ensure some level of flexibility and thus scalability:
- Using screen frameworks lets your applications scale to accommodate new features.
- Choosing appropriately flexible user interface structures ensures they can accommodate expanding or contracting sets of features.
- Designing dynamic components that take content resizing and varying amounts of content into account can ensure a layout that scales with the content.
Though none of these methods offers a foolproof solution that lets you completely avoid continual redesigns, together they can provide enough flexibility to ensure your designs can scale as your applications grow.