How to Manage Scope Creep

Editor’s Note: This article is excerpted from Christopher Butler’s Interactive column in the January/February 2013 issue of HOW magazine. Visit the iTunes Store for the iPad version of HOW.

It’s no wonder that scope creep is the bane of any designer’s existence: the object of constant vigilance, that thing we expect to be done to us. But scope creep as we typically think of it rarely happens; it is seldom manifest in that big, single “gotcha” event. That scope creep is a red herring.

Instead, scope creep is typically a fine line crossed suddenly by tallying up a long list of little things and finding resources and time wanting. More than any technical hurdle, gap in expertise, hiccup in schedule, lack of funds or even the “bad client,” this sort of scope creep—subtle as it is—is the thing most likely to threaten the success of your project. Rarely can this be blamed on an unreasonable client; we are often the coauthors of these lists. We know this—even if just at a subconscious level—and bearing partial responsibility undermines our authority and puts us on the defensive. Retreat at that point isn’t going to be easy. If only we’d been proactive.

Instead of agreeing through gritted, smiling teeth to every scope-creeping request from your client, you must understand the business goals behind the project and help the client make good decisions by holding them accountable to those goals. Key questions you should be asking them to prompt useful web design ideation are, “What is this website for? How will it attract, inform and engage its audience? How will we measure its success?” Every feature you discuss should be evaluated on the basis of the answers to those questions. If they pass the purpose test, you’re not done. You still owe it to your clients to be critical of their ideas.

illustration by Arthur Chiverton

Learn more about keeping your web design projects on track in our on-demand design tutorial, Manage Your Web Design Projects Like a Pro presented by Daniel Schutzsmith.

Identifying Scope Creep in a Web Project

One way to manage the most insidious form of scope creep is to put every ongoing request or idea—both yours and the client’s—to a three-part test. In this hypothetical example, let’s say the client decides late in the game that they want to add a slideshow to every main page of the website you’re developing. Before agreeing to the additional work, we should ask:

1. Is it usable? A slideshow could be a great way to convey unique messaging throughout the website, but whether users will pay attention to it long enough to make it worthwhile is up for debate. Our client specified that they didn’t want an image limit and preferred that fresh images appear to repeat visitors. So, for the sake of argument, let’s just say that they’re able to create five unique images per slideshow. Will all five ever be seen by a typical user? Probably not. In my experience looking at hundreds of analytics accounts, the likelihood of a user viewing just five pages total in their session is low enough, but the likelihood of a user returning to a particular page five times within a session is approaching zero. So why build a feature for a need the user doesn’t have?

2. Is it manageable? If our client’s site is going to have a slideshow of five or more images on every landing page, managing this feature could be excessively time consuming. Hypothetically, if they have 20 landing pages, each with just five images, they’d need to create 100 unique images. They probably didn’t consider this when they made their initial request. But if we doubt that many users would ever see all these images, is it worth the effort to create them? Pointing this out will probably motivate our client to fall back upon re-using some of those images, but that undermines the whole keeping-it-fresh idea, doesn’t it? The client needs efficiency, and this feature isn’t efficient.

3. Is it affordable? Strategically speaking, I recommend keeping budget-focused arguments against minor functionality in reserve. Invoking budgetary concerns tends to provoke strong emotions, so use them as a last resort and only if user-focused arguments aren’t working.

But if you do go there, the question isn’t so much a matter of what this specific feature costs. Instead, you should ask whether the cost of this feature is in proportion with the overall budget. Generally, you can convert your budget to expected time, and in the same way, you can estimate how much time it will take to build this fancy slideshow. If the budget buys, say, 60 hours of development time, and we estimate six hours for the slideshow alone, we have to question whether a feature that is unlikely to be used and cumbersome to manage is truly worth a tenth of our total effort.

You could, of course, get more specific about the dollars and cents when it comes to prioritizing features. Do what makes sense for the kind of relationship you have, but make sure your need to be profitable is met.

Creative vs. practical is a false dichotomy, so we don’t want to fall prey to the trap of thinking of scope creep in those terms. Your job is to lay a stable foundation for creativity by helping your clients set the right goals, make decisions that are appropriate toward accomplishing those goals, and manage expectations throughout the process.


  • Learn how to keep your web design projects on track with the HOW Design University online course Managing a Web Design Project from Start to Finish, taught by David Holston.
  • Want to grow your web design career? Build your skills and knowledge of interaction design with our superior library of web design books. Visit for new releases and discounts.