How to Deal with Feature Creep

If any assumption is safe, it’s that six months after launching a website (or sooner?), its owners will have a list of things they want to change, from minor typos to entirely new functionality.
Is it possible to accept feature creep as a natural (or at least inevitable) process?
Many websites begin to fail when their goals change or their scope expands.
Feature creep sets in when a client asks for one tiny adjustment that takes only a minute… and then never stops making requests.
Accepting feature creep as a natural process requires an ability to distinguish between a genuine need and a run-away imagination or “Wouldn’t it be great if…”

Clients naturally want to squeeze as much work from a budget as they can. Sometimes, designers and developers must say, “No, that’s beyond what we agreed on.”
But not all requests for change are penny-pinching; and like the web, projects and businesses change over time: stores have seasonal sales; businesses develop new products; online services refine their processes; publications release fresh content. Change happens.

Avoid Solution-Creep

Clients may know their business, but they hire web experts for their web expertise. Feature creep sets in when clients forget that and treat designers as tools instead of problem-solvers.
Being able to explain to overly enthusiastic non-web folks which techniques and technologies are not appropriate for a given website is a tedious war of attrition.
But designers presenting themselves as problem-solvers, and not mere coding monkeys, is vital to their relationships with clients.
The key is to make the client bring problems, not solutions. Say the client learns about Twitter. It’s all the rage, they’re told. So they want it. Now.
In the long run, the effort of writing tweets will prove frustrating unless the tweets create measurable benefits. Instead, ask the client whether they need a Twitter account that posts to the company blog or simply need higher-quality blog posts?
Here are some examples:
“I want a vibrant design” is a solution, not a problem.
“What would make the website look vibrant?” is a design problem.
“I want a search tool” is a solution, not a problem.
“Customers aren’t finding our products” is a design problem.
“I want an RSS feed” is a solution, not a problem.
“What means of communication are visitors to our website most likely to expect and use?” is a design problem.
“I like this other website’s design” is competition-envy, not a solution.
“You’re not them,” isn’t an adequate response either.
Rather, “How do you want customers to perceive your business or organization?” would get the conversation back on track.
If your question, “What do you think of this logo?” is followed by uncomfortable silence, then turn it around with a one-two punch: “How do you want customers to view your brand? What visuals would your customers associate with those qualities?”
In each case, the feature creep can be handled by turning “I want” into a question for the designer, not the client, to solve.

Question Everything Up Front

Learning to ask seemingly unrealistic questions is important and, with some practice, surprisingly fun.
For example, when would a website need more than one home page? Or what if a coffee shop started selling videos?
Such questions only seem ridiculous if you’re thinking about immediate problems.
Consider multiple home pages. Returning visitors might not need the full introduction that newcomers would. In that case, a home page that shows recent highlights would work alongside a home page that has a general overview.
Google’s Website Optimizer helps track which of your home pages generates more meaningful traffic.
One strategy is to triple your highest expectations. Imagine three “Contact us” pages, thirty categories instead of ten, and three levels of navigation instead of one. Or how would you handle a page of content if it became three times as long?
Another strategy is to cut everything by one-third. What if you wanted to design web pages for mobile devices? How could a 960-pixel-wide design fit into a 320-pixel-wide screen? What if the website generated only ten sales per month instead of one per day? How would the “About our team” page change if the staff of 15 were cut to 10?
Before signing any contract, scan for these crucial words: “a,” “an,” “the” and “one.”
Before: “The website will have a list of services.”
After: “The website will have several lists of services organized by topic.”
Before: “The contact form will send an email to the owner.”
After: “The main contact form will send emails to the owner and, depending on the subject, facility coordinator, technical support or lead salesperson.”
Before: “The header will be orange.”
After: “The home page header will be orange. Inside page headers will be half as tall to emphasize the content.”
Before: “Membership profiles will include a phone number and email address.”
After: “Membership profiles will contain contact details, including phone numbers (office, home, other), fax numbers, email addresses and three open fields for mailing address, Twitter and Facebook accounts and the like.”
Before: “The blog will be organized by date.”
After: “The blog’s default screen will show posts by date. Posts will be organized with tags; the page will be designed not to look empty when it has only five posts; and visitors will be able to browse at least 500 posts.”
The best plans aren’t limited to a specific design but account for a range of parameters. Problems are only ridiculous when you’re handed one at the deadline.

Genuine Needs

No system can account for every scenario.
Most can adapt to small, incremental changes over the website’s lifespan, but when band-aid solutions outnumber the initial problems, it’s time to bring up the word that no client ever wants to hear: “rethink.”
When starting from scratch is more efficient than fixing the changes that solved earlier problems (but broke other things), the biggest hurdle is convincing everyone involved that drastic change now is better in the long run.
Then you need another word: “cost-effective.”
Patching code or tweaking layouts appeals to designers, developers and clients because it’s quick. They scratch an itch with minimal effort. And the more people cringe at fixing a website that breaks with the slightest touch, the less likely anyone will suggest a bigger headache.
But that’s a sure sign that change is necessary. Draconian feature creep happens when technical folks and designers genuinely dread making changes. You know the project: the one with the case history with its own filing cabinet, with the owner whose voice makes people shudder, and the rambling processes that require user manuals that no one has the time to write.
Such projects cost more than money. They’re morally draining resource hogs that sap attention from newer, nimbler projects and cause enough teeth-gnashing to carry dentists through the recession.
War against this type of feature creep begins by defining problems, including the problems that arose from the symptom-solving solutions.
Approach complete rethinks by looking long-term, both into the past and future. The website was great back then, but things have changed. Technology has improved. The client’s products or services have evolved. Customers are more (or perhaps less) sophisticated or have different needs.
Devise a plan to make this transition practical. The details depend on the nature of the website but amount to the same thing: convincing the client that the drastic cure is no worse than the current chewing-gum-and-bailing-wire course. This is psychological war as much as it is technical problem-solving.

It Will Happen

Most feature creep takes two forms: an itch that a client wants to scratch and a genuine need for change.
If you can phrase the demand as a question, then you position yourself as a decision-maker, rather than someone who follows the client’s every ill-informed whim.
Realize that change will happen. A website that never changes is a black pit.

How do you deal with feature creep?  Please share some of your experiences with us…