"Scale" is a rather confusing corporate buzzword - people love to talk about it, yet it can mean so many different things at the same time. After all, anyone who cares about their organization’s long-term health cares deeply about scale, and there are countless ways to achieve it. To keep up with a growing product, for example, a sales director might scale his sales team by expanding his operation, a support manager might scale customer support offerings by building out a help center, and an engineer might tinker with a feature to make sure it can scale to a greater load. In all such cases, how a company responds to growth and change plays a huge part in its business success.
Why should designers care about scale? The decisions that a designer makes early in the development process can have lasting implications for how a product, and an entire business, fares down the road for all stakeholders. A good product not only evolves with the times but also has a strong foundation for withstanding change - from introducing new features, to adding more users, to moving into new markets.
It’s clear that designing for scale is incredibly important, but it can be easily overlooked when deadlines are tight. Keeping the following tips in mind, however, can save your product team countless hours in the future:
Develop a solid conceptual model
More than once I’ve been in the situation where, late in the game, a new feature needs to be added to the interface. The question inevitably becomes, "But where should it go?" By making it clear at the beginning how elements relate to each other at an abstract level, it is more likely that new functions will find a natural home in the future. I find it useful to start any design project by making a high-level map of how elements relate to each other (i.e. “this group encompasses these sets of elements, or this group of elements is secondary to this other group of elements"), without getting too literal about where they are actually positioned. It’s similar to designing a house and first determining what kind of rooms need to be included and how they should be grouped.
Leave some breathing room in your framework
Similarly, when designing a product’s structural framework, it helps to anticipate future content. For example, when designing a navigational framework, consider how future information will fit into the pattern you choose. While it may be sufficient to find what you’re looking for now, what will happen when you have ten times as much information to navigate? Perhaps you need to incorporate filtered views or advanced search functions.
Consider edge cases
When reviewing your designs, solicit feedback from stakeholders who understand the extreme conditions the product will have to accommodate. Chat with a few users outside of your typical user profile. Talk to support representatives who have worked directly with customers and understand when and how they will push the product to the limit. Collaborate closely with engineers who understand technical limitations and are invested in making the product as robust as possible.
Design for the probable
At the same time, while it is important to be aware of edge cases, there’s a balance between accommodating extremes and providing an efficient interface for the average user. Edge cases should not drive your design. As recommended by Alan Cooper, a thought leader in the field of interaction design, "design for the probable; provide for the possible." It is best to design a default interface for your most common use case but provide necessary secondary functions on demand. A good product is simple enough to use on a daily basis but customizable and robust enough to handle edge cases when they arise.
All that said, no amount of preparation eliminates the need to iterate after launch. Early and thoughtful consideration into scalability, however, can help your product adapt well into the future.
