The Scaling Fallacy and Web Design

Put simply, the scaling fallacy is the phenomena where people wrongly assume that something that works at one size will also work at another size. In this article, we’re going to discuss how this fallacy comes into play in the real physical world, and then we’ll explain how to apply the lessons to your own web designs.

The Scaling Fallacy

Ugh, as if a giant 50 foot tall scorpion could even move, let alone do battle with a demi-god.

I was recently watching the movie remake for Clash of the Titans when this old design principle came to mind. In an early climactic scene, giant scorpions proceed to attack the hero of the movie in an epic battle to the death. The scorpions, scaled to gigantic proportions, were nimble and deadly as you might expect when dealing with such a fearsome foe…

The power of digital special effects nowadays makes it seem entirely possible that such a scaled up monstrosity could occur given the right alignment of Zeus and the Growth Ray from Honey, I Blew Up the Kids (another awesome example of why science and Hollywood should never make babies). However, the reality of a gigantically scaled up monster is physically impossible.

While much is said about tiny insects being able to lift huge weights compared to their relative body size, the sheer reality of that same strength being transferred to a super-sized version of that same insect just doesn’t work in the physical world.

A tiny ant may be able to lift 50x it’s weight, but that doesn’t mean that a massive 1,000lb ant would be able to lift 50,000lbs. The effects of gravity on a tiny insect are virtually non-existent, but gravity becomes a very real power once the size is scaled up. A 1,000lb ant would have a hard time just rolling out of bed in the morning.

The scaling fallacy doesn’t just work on scaling small things to big though – A massive mountain can stand through a thousand rain and snow storms… but a tiny hill of dirt will be washed away by the gentlest breeze.

You get it… what works at one size doesn’t always work when scaled out beyond the original design intentions. The design, function, and usability of just about anything in the entire world are tied to each other by scale. The fallacy occurs when a designer assumes that usability will be retained when a design is scaled up or down.

Applying it to Web Design

The Scaling Fallacy comes into play in web design in two key areas: interactivity assumptions and load assumptions. We’ll discuss both in a moment, but as you read, I want you to consider how easy these scaling problems are to solve.

As the old saying goes, “hindsight is 20/20“… it’s being able to accurately predict the future that’s so darn tricky.

In the majority of cases, solving these design problems is quite simple (adding a pagination system, protecting a layout from oversized images by using the CSS overflow: hidden property, instructing clients to never mess with the navigation system, etc.). All of these tasks are easy to do… it’s identifying these issues before they happen that requires careful thought and preparation.

Alright, let’s dive into the nitty gritty stuff:

Interaction Assumptions

Interaction assumptions occur when you create a design based on an assumption that the user’s behavior will be the same at different levels of scale.

The classic example is of a fire escape plan: A general fire escape plan for a small house is simple: exit the building as fast as possible, call the police. The same exit strategy, when applied to a skyscraper office building packed with people would result in catastrophe. The problem isn’t the design per say, it’s the fact that the design hasn’t accounted for the new scale.

A Web Design Example

In web design, similar interactivity assumptions can occur when you assume that a client is going to populate your web design with content as you expect them to.

For example, the placement, style and size of a navigation bar may perfect sense when a blog only has 4 or 5 categories, but the same navigation bar becomes nearly unusable when 20 or more links are added:

A navigation bar design, as it’s intended to be used.

The same navigation bar, this time with 20 or so links, making it difficult to read or use.

In this case, the solution is quite simple: instruct the client who is using the website to keep his main navigation links limited to a handful (or use a dropdown menu for additional links).

Identifying Interaction Assumptions

Identifying interaction assumptions isn’t rocket science, but it requires a sort of flexible thinking that accounts for different possibilities. In terms of web design, if you design an element under the assumption that it will only be used in a single way (either by a user or the person inputting the content a year after you leave the project), there’s a very good chance that the element will malfunction when it’s used in a way outside of what you intended it for.

Here are just a few examples where simple interaction assumptions are made… these aren’t all of them by any means, but it should give you good idea of how this works:

• Images - Imagine you’ve designed a website that uses all 200px by 200px images. The client later on adds a 400px by 100px image, which breaks the layout.
• Navigation Menus – You design a site with a innovative “docked” menu system that requires a user to hover over a certain area to see the menu… but you neglect to tell the users how to do this.
• Sidebars - You design a sidebar that’s exactly 300px wide, but the client adds images that are 500px wide, breaking the styling.
• Layouts - You design a site that relies heavily on multi-column layout, but the client later on wants to use a layout that uses the full width (without a sidebar).

Most of these problems should be easy to fix… just a few additional lines of code or a simple educational meeting with a client can prevent any problems from ever occurring… but what I want you to take away from this is that you must always anticipate scenarios where your designs are used in ways that you don’t originally plan them to be used.

Load Assumptions

Load assumptions are a little bit different – they occur when a designer assumes that the stresses on a given system will be the same at every scale. Load assumptions happen a lot on the development side of a web design project; Making assumptions that an image heavy web design that works when 1,000 people visit the site a month can be blown out of the water when more than a million people visit in a day and put additional stress on the server. The same principle can apply to the actual visual design of a site too…

For instance, you design an image gallery layout that is incredibly easy to browse when there are just 10 images… but by failing to provide a proper “pagination” system, the entire layout becomes difficult to browse when more than 25 images are added.

A pagination system is perhaps one of the simplest examples of tweaking a design to account for scale.

The solution is pretty simple in this case: by adding a simple pagination system, the very same design can be made “scalable” with a few small tweaks. A numbered pagination system is added, and whallah!, your design is usable again… at any reasonable scale. You would only encounter the scaling problem again if your library of images exceeded the reasonable limits of the pagination system… at which point you would have to consider a more refined tagging and search system.

Identifying Load Assumptions

Identifying load assumptions is pretty simple too: just imagine that any specific part of your design being stretched to it’s limits in terms of content… then plan accordingly. The solution might be a design or UI tweak (like the pagination example), but it also might be as simple as instructing users what the limits are. If your design only allows for 100 images and there’s nothing that you can do about it, just tell the users that up front. See how simple that is?

Screen Size Assumptions

The last type of assumption that I’d like to describe is one that most of you are familiar with: screen size assumptions. This topic alone is worthy of it’s own blog post (more on this next week), so I’ll try to keep this brief:

If you’re designing a website and never stop for a moment to test out how it looks in a different resolution, stop right now and do it!

Long gone are the days where 75% of internet surfers are browsing on a 1024×768 monitor. Nowadays, people are surfing the net on screens of all shapes and sizes… from tiny iPhone screens to massive HD televisions.

Designing a website under the assumption that everyone out there has a certain screen size isn’t just short-sighted, it’s undermining the core usability of your site. While it might not make sense to create a different website for each different type of device out there, it’s certainly worth taking an hour or two to at least consider how your site will fare on different screen types and resolutions.

Finding just a few adjustments that you can make during the design phase of a site will save you a lot of grief in the long run. Here’s just a few quick tips for avoiding screen-size assumptions:

• Don’t rely on complex menu systems that require a mouse to accurately use. Hint: 8pt font isn’t finger-friendly.
• Consider adding a mobile-friendly fallback theme to a WordPress site.
• Avoid designing “full screen” sites (sites where the core content occupies more than 960px wide) unless the site can scale itself down for smaller screens.
• Don’t use Flash for core navigation, unless you have a damned good reason (or an HTML fallback method)
• When in doubt, make all of your body text 2 points bigger… it won’t hurt the readability on normal monitors, and mobile users will actually be able to read your text.

Avoiding the Scaling Fallacy

No plan of battle ever survives contact with the enemy.

The only real way to avoid the scaling fallacy is to constantly be on the lookout for it. Throughout the design process, you should be aware of your own tendency to make these sorts of assumptions.

Don’t just design under the assumption that everything you create in Photoshop or Fireworks will stay the same when the website gets launched. Unless you are on a project where you’re going to be the sole entity that designs and adds content to the site, chances are high that someone, at some point, will add content that will break your expectations for how that design was intended to be used.

Likewise, avoid designing things that only work in a severely limited scale. As we all know, making customizations and revisions to a web design can be a painful, arduous and expensive process… designing under the scaling fallacy only makes these problems multiply as you’ll be required to revisit your old designs as often as people’s behavior falls outside of your own assumptions.

Conclusion

That’s it for now! I hope everyone finds this post useful… The Scaling Fallacy is one of those enigmatic principles that’s easy to explain in the abstract, but hard to nail down in concrete designs… so it takes lots of practice and constant vigilance to avoid the major pitfalls that come from the assumptions that we discussed.

If you liked the post or have something to add, post it below in the comments. Cheers!