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.
Champion Advertisement
Continue Reading…
Screen Frameworks
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.
Components
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.
Summary
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.
Luke, you brought up a topic that we always need to keep in mind.
I also agree with Sterling that “design is never done,” but I think it goes without saying that we also need to acknowledge that most (all?) designs inherently have limitations.
At the end of the day, it comes down to balancing out an equation with variables like scalability, requirements, aesthetics, and so on. As far as the Web site presentations go, a single design doesn’t really last more than three years—rough number. With reasonable coverage—as you have highlighted some—most cases can be handled during that time.
A more difficult problem, in my opinion, is to figure out how much scalability are we willing to risk while matching todays’ requirements and maintaining a usable design.
Very good article. With screen frameworks, what kind of audience would they best be suited for?
Could they potentially be used for discussions around the group placement of features and content on a particular Web page with stakeholders?
With my situation, I have an executive audience that can’t visualize anything but the final design of the product comps—and probably wouldn’t be able to conceptualize frameworks effectively—unless you could suggest how to present the concept to this sort of group.
Sarven, you raise a great point that scalability needs to be balanced with other variables. It just tends not to be considered as often. However, where we may disagree is on the longevity of designs. It’s often market pressure—the need to layer on additional features—that forces good designs to change, not the limitations of the design itself. There are also many examples of designs that manage to remain largely unchanged, because of a well thought out structure.
Daniel, every situation affords different schedules for projects. But even with limited time, designers at least thinking about scalability can approach their work with an eye toward future requirements. Are you suggesting added time for these considerations is necessary?
Robert, I’ve found frameworks to work well with design and engineering audiences. Some, but not all product leaders can also appreciate their utility. Andrei Herasimchuk would take that even further and suggest his “box exercise,” a variant on frameworks, is a crucial part of getting all stakeholders on board with a design. He’s teaching a course on it now.
“Are you suggesting added time for these considerations is necessary?”—Yes, for the most part.
I suggest that there are companies who probably allow for extra time in a design schedule to really think design problems through. Other companies expect designers to churn out designs like a factory conveyor belt.
As designers gain more project experience, they are probably able to wear a few different hats quickly—user, business, technology—while being able to consider future needs.
Thanks for the article. This is a great overview of the visual design implications of making things scalable. But what about from information architecture point of view? I’m often asked to create a site structure that is scalable for future changes and additions. When trying to accommodate this request, inevitably we end up with really general labels for content buckets in order to accommodate things that could be added in the future, but are unknown at the time of IA conception. It may be scalable, but it doesn’t necessarily serve the users’ needs, because the bucket label is not specific enough for what they are looking for. Any thoughts on this?
Good article. Use cases plays a vital role in designing an application to be effective as well as scalable. Would prefer if you’d touch a bit on the role of effective use cases in achieving scalability in an application.
Good article. It all boils down to planning ahead, with some things being a given for any project.
For example, unless there are explicit company or management edicts in place that say SEO, accessibility, or I18N initiatives will not be considered or done for a given project (Why there would ever be such edicts, I cannot begin to explain.), then it is best to include and plan for these ahead of time, so as to avoid just these kinds issues after the fact.
These sorts of things should not have to be planned out or reworked for every project. Once the process and the standards are in place, they are just applied to any project.
The common arguments against this approach is that there is not enough time or the items get overlooked or the implementation staff is not knowledgeable enough to accommodate the efforts. Whatever the case, the question, as it so oftentimes is, is this: Is it really more expensive to do it up front or wait and have to rework and retrofit?
Guidelines, standards, patterns, templates, frameworks, and so on all help to ensure these items are accommodated within any project. Having the foresight to plan for the worst-case scenario helps a lot too.
I bet you have already moved forward into the (X)HTML age with the rest of us, preparing your CSS accordingly. Scalability, in my humble opinion, is a thing of the past.
Consider your customer and target group and base your design on that. If you are new to this business—sure you will take a lot of beatings. However, if you have had a few troublesome customers, which all of us have, you should have learned from your mistakes by now.
Instead of scalability, I think, placeability is a much more important issue, meaning that if your design is really that good, it will be relatively easy to move a few components around—even in navigation.
This is an excellent and short introduction to scalability, especially in the context of global or multi-language content. This also applies in the contexts of multi-market or user-defined content. And that’s why in the world of Web 2.0 especially, scalability is more important than it was before.
To respond to “extra time” for designers: Often, when the business strategy is not clearly defined—that is, the purpose of the project/product in itself has not been explored or shared with the design team—it becomes the responsibility of the designer to foresee that goal. Scalability should inherently be one of the assumed requirements for any project.
For the sake of argument, I’ll submit that scalable design always has tradeoffs—time in the design phase to think through the tradeoffs, more targeted and optimized task-based layouts, elegant and aesthetically displayed whitespace, etcetera.
Might be the most appropriate business / product decision. But might also apply more to large-screen displays with more established conventions—for example, Web navigation bars, windows, menus—than for, say, mobile phone, music, TV, or in-car displays.
Minoru, I think finding the appropriate screen framework is mostly an interaction design and IA process. There are certainly visual implications. But understanding the content areas, how they interact, and how they vary goes beyond visual design. Or are you simply referring to a site-map style IA?
Per K, Given how many Web applications are built, I’m not so sure we can say scalability is a thing of the past! I’ve encountered many well-built X-HTML/CSS applications that don’t scale well, with changing features and reprioritization.
Andrea, Tradeoffs exist in any design decision. By virtue of selecting one option, you opt not to use others. So to that end, scalability has tradeoffs. But they don’t have to come at the cost of elegant designs.
Thanks for the interesting article. It happens lots of times. In fact, most of us designers create a style guide for applications, without explicitly mentioning scalability issues for the developers. We only mention such-and-such pixel dimensions, fonts, button placements, and so on. Often the thought behind is missing. I’m working on a style guide project in which, apart from the usual style guide elements, I’m documenting the rationale behind them and the modification rules. Something like a designer’s journal, where you mention, for example, when to use tabbed navigation and what to do if you end up with umpteen tabs. Cheers
Before joining Google, Luke was CEO and cofounder of Polar and Chief Product Officer and cofounder of Bagcheck. He is the author of three popular Web-design books—Mobile First, Web Form Design, and Site-Seeing: A Visual Approach to Web Usability—in addition to many articles about digital-product design and strategy. He was also the founder of LukeW Ideation & Design, a product strategy and design consultancy. Luke is a top-rated speaker at conferences and companies around the world, and was a cofounder and former board member of the Interaction Design Association (IxDA). Read More
