Designing for Scalability

In: Columns > IAnything Goes

By Jeff Lash

Published on June 23, 2004

All Web sites will scale over time. No site will remain the same as it was when first launched—nor should it. The rise in popularity of content management systems shows that the old days of launching a site, and then not maintaining it, are over. Designers are now working on the same site for months or even years. Over time, new needs will be identified and new features will need to be added; a site needs to be flexible to change so these post-launch updates can be made quickly and easily.

On the one hand, there is the need to create a design that will function effectively for the present, without regard for how and when the site may change in the future. On the other hand, there is the need to allow for change and expansion by creating an architecture that will support transformation without requiring a complete overhaul. So where can we find this balance?

The importance of scalability

The main reason to design for scalability is reduced cost and effort. If a site had to be totally redesigned every time a new product or service is introduced, every time the business goals shift, or new user research identifies new needs, sites would be in a continual state of being redesigned. Major changes will inevitably occur, but the cost and effort of those changes can be reduced by allowing for easier, iterative updates and transformations, thus saving the major redesigns only for when they are really needed.

Whether one believes that major re-launches are unnecessary or inevitable (there are compelling arguments on both sides), it should be clear to all that any site needs to be able to easily support some level of flexibility and scalability.

Too often project teams underestimate the amount of maintenance required to keep a site current and to make normal day-to-day changes. When even normal operational tasks are not anticipated, it is obvious that there will be no understanding of the long term effort needed to make major changes. Additional sections and content may not be able to fit into the initial design and a massive redesign would be required for even the smallest expansion.

Sometimes, though less frequently, project teams focus on the long term without an understanding of the present situation. They look at where the site will be several years after launch and design for that amount of functionality and content without acknowledging and designing for what is currently available. Leaving space for additional navigational elements, for example, is a good idea, but if those additional elements will not appear for several years, it hampers the current design of the site by making it appear barren and incomplete. The initial design needs to be successful enough to ensure the site will still exist in several years, when these long term plans will come to fruition.

Underestimating the amount of scalability that will be needed, and over-preparing for expansion, are both problems that can present themselves in a development process. The key to avoiding them is to have a thorough understanding of the business goals and user needs, for both the short term and the long term, and using that understanding to drive the design and scalability needs of the site.

Getting back to goals

Since business goals and user needs will change over time, some may say it is more important to focus on the current situation and not be hampered by future uncertainty. Business goals and user needs will indeed change, but there are certain basic principles that will not. Knowing today’s long term business strategy will provide a foundation on which to plan.

For example, let’s take the example of two hypothetical record companies. Both Company A and Company B produce children’s CDs—“edutainment” recordings for the under-10 crowd. Both have roughly the same number of recordings, target the same age groups, and sell their products direct-to-consumer. Their sites should be basically the same, right?

Company A advertises their products in media oriented toward seniors, targeting grandparents who buy gifts for young grandchildren. They are thinking of starting to produce children’s DVDs, as well, since CDs and DVDs are complementary items and would be an easy sell to buyers familiar with their current products.

Company B advertises their products in media oriented toward children—like cartoons or kids’ magazines—to get the children to ask their parents to buy the CDs for them. They are sticking to CDs, but are thinking of expanding their offerings to older children since they have a market of growing children who already know the company’s name and recordings.

Think for a moment how these two sites, if designed today from scratch, would need to be different. The short term business goals are probably the same—to drive sales of their current products—but their current user needs are probably different since the needs of grandparents may not be the same as those of parents. It is these differences, in the long term business goals and user needs, which will create the distinctions between the sites.

A site designed for Company A today would need to support their move into DVDs. It should focus on CDs for now, since that is currently their only product, but make it easy to add a section for DVDs, and related material, when those are added several years down the line.

Today, a site designed for Company B would not need to worry about adding a section for DVDs but would need to allow for more differentiation by age groups than Company A. Company B may also need to focus on the children themselves, as primary customers, since older children may be more influential in the buying process and more likely to be heavy users of the site.

One other important factor to consider is the actual likelihood of additional areas being added to the site. Business plans do not always pan out. Some ideas for new products, features, or changes in strategy sound grand on paper but never make it to fruition. Designing for scalability means weighing the likelihood of each type of scalability. This is a tough decision, since business owners do not tend to admit that their plans may not reach the market.

Without a clear answer, it is best to look at all the future plans and consider which of the different features or products are most likely to occur. The comparative probability of success is more important than the absolute; even if all of the areas are eventually added, having some sort of priority order is beneficial for planning purposes.

In the end, the decision needs to be a weighing of the complexity and depth of the new feature or content area, the timeline for this addition, and the comparative likelihood of it actually occurring. It is better to spend time worrying about a small feature that will probably be added a year from now than an unlikely large change that would not take effect for several years.

Successful design teams acknowledge that some change is inevitable and balance their short term and long term priorities, creating site architectures that are flexible and scalable. A successful design team will revisit business goals and user needs on a regular basis and make changes as necessary.

Related Topics: Information Architecture, Planning, Web Design, Web Maintenance