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.


Ben Gremillion is a freelance web designer who has learned that clients respond well if you can keep your temper when they lose theirs.

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



  • http://www.webassist.com Jon Crim

    Great article, sent it to a bunch of my friends – thanks!

  • http://www.webbyfreebies.com Webby freebies

    Love your article, keep up the good work!

  • http://sexidesign.com Melody

    Very informative…it’s true, many clients “think” they know what they want but only understand fragments of what is needed to pull off a cohesive design.
    Maybe that’s why design is so underrated–too many people think many projects can be done in 30 mins satisfying all their design needs..

  • http://www.squiders.com Web Design Maidstone

    so much truth in one article!!

  • http://biancayvonne.com Bianca Casimes

    I really like the idea of designers being problem solvers. I think people forget that too often and just assume we are only tools for reaching high aesthetics.

  • creativeblondes

    Great article, i like the examples with problem/solution. This kind of thinking really helps the communication between designers and their clients, which -i belive- is extremely important..

  • http://www.brewerwebdesign.com Ryan

    Thanks for the article! This is a great concept I wasn’t formally aware of. I agree designers, at their best, are also problem solvers.

  • http://www.ev4n.com ev4n

    “Feature creep” is something i deal with every day. I handle quite a few large print + web based news websites which all want to copy each other. I get “i want what they have” every time i design something for one of the magazines. Its funny and frustrating at the same time.
    Unfortunately the people I deal with are CEOs/directors/managers of large organizations and don’t want to hear anything about “why” or “rethink”, they just want “now”.

  • http://www.vunkyblog.net Vunky

    Great article.

    Nowadays I document every little change made after a website launch. I have a pretty good memory, but clients sometimes tend to forget they chose the green button instead of the red one ;)

    I have a three months warranty policy, but where do you draw the limit?

  • http://www.hammerkit.com Paula

    Thanks for the great insight! Gave me good food for thought for planning our sales arguments.

  • http://www.antekklima.com klima servisi

    great article, thanks

  • Adnan

    This article is fantastic (and great visuals!) but I’d really like to see some integration of the 20+ visuals/samples/examples format posts alongside these extremely well written articles. Bravo.

  • http://www.creativeindividual.co.uk Laura

    I’ve been fortunate enough only to have one or two clients who want all the features now, if not yesterday, but will not pay for a rethink – and because their sites are so historic and the coding so dated, it becomes a nightmare to add even the smallest of features and takes so much longer than it should. Sometimes I feel like just ‘taking the bullet’ and updating their website so that it’s easier to work with, even if it still looks like the same dated rubbish!

    Thankfully a lot of my work recently has been new or redesigned sites, so life has been good =D

    Thanks for the article.

  • Zack Jones

    Great article – as long time web developer I have to deal with feature creep or “scope-itus” often. Many times we’ll take a list of all of the requests and then submit a quote to implement them all. The customer then picks the features they’re willing to pay for and we implement those. So far its’ worked pretty well.

    You said:

    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.”

    Be weary of “and the like.” because when the next big thing that everyone is doing comes out your customer can come back to you asking you to implement an interface to it without paying. Their justification is that it falls under the “and the like” category and they’ve already paid for it.

  • http://bailiwickmedia.com Bryan Buchan

    I find it best to handle feature creep during the post implementation phase of the project, and I build in to my contracts a window of billable time where these “Feature Creeps” are addressed, especially if it is a larger client, or a client that is difficult, or has a reputation to be. Communicating to them throughout the process that this window exists and their ‘Feature Creeps’ will be handled causes most clients to not only appreciate that you are in control, but allows you and them to focus on what is most important, getting the website built according to the original SOW.

  • http://wwwnopun.com Noel Wiggins

    In some cases clients may be trying to get the biggest bang for their buck and in other cases they may not know what is a small change versus a hard one, and they might either say “nah” that change isn’t needed after all or would gladly pay the additional money to have the change done.

    As a professional graphic designer it is your job to advice them of this process. Its a difficult balance but you need to be willing to help, while protecting yourself.

  • http://www.ingraphicdetail.co.uk Michael

    God, i know all about this!

    I designed a client management system for a compensation claim business and ive only just finished it after 6 months because the client every week feature creeped, luckily i told them this is more than what we agreed on and after each new feature they agreed i should put it on my invoice and theyre happy with that, should be getting paid for this job soon but funnily im more looking forward to not dealing with them as often as i have been than being paid for the job haha!

  • http://uniyolu.com özel ders

    good article. thanks

  • Fo

    I havent finished reading this post yet but i have to make this comment.

    “The key is to make the client bring problems, not solutions”.

    This has to the best thing i have read today. This is a real eye-opener. I’m definately going to incoporate this to my practice

    Thank you so much for sharing

  • http://thefreecreatives.com Crystal

    Great article. This is the most frustrating problem for me and seemingly the most difficult to deal with! This is a great overview and great tips, thanks!

  • http://www.chotrul.com/ Chotrul Web Design

    The section on problems and solutions was very interesting. I worked previously at a company where the directors could not let go and identify the problems and not pretty much dictate the solutions too. It was real hard to manage this and create something which actually did the job. Sometimes these things are workable, sometimes less so. Sometimes you just have to move on if you are not really able to do what you are trained to do, if it’s that bad!

  • http://design977.com Pusparaj

    Everybody’s issue. Sometimes it feels like i’m not designer, the client is.

  • http://www.zoombits.de/speicherkarten/usb-sticks/memory2go-8gb-usb-stick/5804 8gb usb stick

    Hi,
    Very informative post.It helped me a lot.Problem/Solution examples are really appreciable.I believe this is the primary thing both designers and clients should understand.

  • http://www.mdostudio.com m a r c o

    Very good article… I especially liked the part about changing the tone of the conversation from solutions into design problems. It’s so easy to fall on those “traps” where the client is dictating the entire design process, making changes to requirements along the way and effectively killing your ability to use your design and concept skills. I know when I recently received my Design Bachelor’s degree, I got into situations like that (they taught me to conceptualize, use typography, color, balance and all the other stuff, but they never taught me how to interact with clients). Thank God with time I’ve learned a thing or two…

  • http://www.blogworkorange.net Paweł

    One of the best articles I’ve read recently. Great job. As many people noted, the most important part of it is switching from solutions to problems.

    I, as an open-source developer, face similar, but not exactly the same problems as people who code for specific clients.

    In my case, most often people mistake bug reports and feature requests: the effect is that I receive a lot of “bugs” that can be translated as “it works very well, but it could also do this…”. To manage with that, I always inform in the “Report a bug” section, that the priority is to find bugs which don’t let people use the program. Many people fortunately get it. If somebody makest the mistake, I simply remind them that their proposition is or isn’t good, but the priority is …