Managing unrealistic customer expectations?

Question

I do some web work on the side, building websites for non-profits mostly.

A, more or less, constant problem I run into is managing expectations when my customer doesn't really have a budget and doesn't really know what they want.

I get specs like:

Make it look all whiz bang.

And then I have to play 20 questions to get a bead on what that means, and inevitably I have to reel them back into reality about what they actually need and reel them a little further to what they can afford.

It usually ends up feeling like:

We want to send a rocket to the moon, but we don't want to buy anything or pay anyone.

-Mkay... Do you really need a rocket or will some party balloons do?

I've even gone as far as to decline a few projects, simply because I knew it smacked of scope creep and ultimately they would spend more than they had on something they wouldn't be happy with.

Is there a trick to walking non-technical people through a technical and financial process while being delicate with their sensibilities?

Or if that's too broad...

Is there a nice way to explain to a customer that they don't need it and they can't afford it?

Answer 1

To preface: I help make enterprise level web software for a living for a corporation who is new to software.

I have learned (at great expense) two important principles that apply here and may help you. So, your official answer is:

Apply the 'Make it Bluer' principle, and apply the Three Bears principle.

(Don't worry, I'll explain both.)

Make it Bluer

Simply put, this principle is about customers not knowing what they want, but "knowing it when they see it".

In other words, they cannot articulate what it is they want (because they don't have the vocabulary to tell you), but they can tell you what is wrong with what you put in front of them.

To apply this principle, make a very quick, cheap as you can, prototype that fits within the vague notions you have gotten from them about what it needs to do. This will be somewhat close to the "mama bear" solution that you will present in the three bears principle.

(Why is this called "make it bluer"? I once had a gig for a small company to make a corporate presence website. Their most important feedback was to make the text bluer. They didn't like how blue it was, and wanted it bluer. So I made it bluer. Then they decided that they didn't want it quite that blue, and could I please make it the blue I had it before.)

For a similar principle, look up Bikeshedding, which is related.

The Three Bears

(In case you are unfamiliar - this is the internet, and not all cultural references are the same - here's "Goldilocks and the Three Bears")

For the purposes of this principle, the Papa Bear solution is the "hard" one. It takes the most time, takes the most resources, costs the most, and is invariably the best, most ideal solution.

This is the "rocket to the moon" that they ask for. Present it with a due diligence estimate, and present it first.

The Mama Bear solution is very little more than a prototype, and just barely (or "bearly"? - DAD JOKES!) does what it needs to do. It can be a few patch ups on your cheap prototype for the "make it bluer" section.

This takes the least time, costs the least amount of money, and might just be enough for your customer. Present it second.

The Baby Bear is "just right". It rides a balance between Mama and Papa bears. You present it last, so that your pitch involves:

• Here's the Papa Bear solution, which fulfills your wildest dreams, and costs more money and time than you've got
• Here's the Mama Bear solution, which is cheap, quick, and kind of looks it
• Here's the Baby Bear solution, which doesn't look as cheap as the Mama Bear, but doesn't have the features of the Papa Bear. However, you can afford it, and it won't take forever to make.

I have used these principles and even the very terminology I present here in front of executives. Non-devs find these terms very approachable.

Answer 2

As a computer programmer, I've faced the issue of end users saying, "make it do [this]," when they didn't really have any idea what they were asking, but it is part of the designer/programmer/architect's job to know his or her area of expertise well enough to be able to put the task in terms that lay people can understand and so they can communicate intelligently about it.

As much of a headache as it sounds like these experiences have been for you, the good news is that they've probably taught you enough by now to help you sort out a system for yourself so that it doesn't have to be so difficult every time.

Hopefully, you're compiling a portfolio of your work, even if this is just a side job. Pull everything out and have a look. Now ask yourself some questions:

1. What categories can you put the businesses or organizations that you've built websites for into?

   Who do they serve (church, disability, advocates/activists, low-income, homeless)?

   How do they serve them (direct service, information and referral, technical information or legislative watchdog, community organizing)?

   What are their funding sources (government grants, fee-for-service, non-government grants, a few philanthropists, community fundraisers)?

   How large is their organization (does the whole thing consist of four or five "board members" who do all the work, or do they have office space, several employees, and some organizational structure)?

Now that you can kind of see who you're working for, I'm sure you can see trends or commonalities.

2. What kinds of a) features, and b) overall website structures do most of the organizations in (pick any category or subcategory from above) ultimately end up being happiest with? What features best serve whatever that kind of organization is trying to accomplish? What do they really need?

If you can walk in with this amount of preparation, you should already be able to trim a half hour of frustration off the top.

After you identify whether there will be back pages with products that they want to advertise with a revolving header banner vs using that area to connect visitors with other websites ... or if they intend to use the website to collect names to build a mailing list for community action alerts ... or if they'll just want an About Us and a landing page with some information that they'll update every few months, then (I think) you'll start talking about page layout. And again, you'll be leading that conversation:

3. Would you like your menu system to be a drop-down, going across below the header, or a vertical menu on the left side showing snippets of the pages they link to? What all menu headings will you want? Etc.

It is at this stage, if they are still not able to give you any answers after you've presented everything you have as patiently as you were able to, that you need to realize that it is OK to tell them,

"I believe it is too premature for me to be here. I think you need to come together yourselves and develop a vision of what you really need in a website. Ask yourselves how you'll use it, get some blank paper and design the layout, think about the menu bar and decide what you want included in yours. Look around the internet and see how other websites for similar organizations work. Find what you do like and what you don't like."

I really believe that if you break this down really well, you'll know exactly what questions to ask to get to the heart of what they need (and if not, the above exit strategy should work nicely). In the end, the only "bells and whistles" most people really want is functionality. They just don't know the language to describe what they want.

It will be your job to bridge that gap, and to know the costs of various features, whether that's your time to set it up or the price tag on a bit of software, or both. Also, use your existing portfolio to show them possibilities. People like pictures!

Answer 3

You need to talk to the clients in end user terms. For instance,

"Is this going to be an informational site or an advertising site? If it's "advertising, then explain that it will cost more because you will need to put more "bells and whistles" onto the site.

"What is your basic message? Who is it being addressed to?"

"Is this site for fundraising purposes? How much do you expect to raise of this? That will dictate how much you can afford to spend."

Answer 4

There are three techniques that I use on a regular basis for managing these types of vague project "requirements".

The first is to focus on their goals in specific terms.

They want it to look "whiz bang"? Why? Is it to increase new visits? Is it to improve retention and engagement? Is it to coincide with a rebranding effort that exists outside of the website? Have they received negative feedback that they're trying to address (if so, ask for the specific feedback as close to verbatim as possible).

Many times the "bells and whistles" requested by customers are indicative of XY problems. They know what is broken, but what they communicate to you is how they assume it should be fixed.

If you don't know what is broken, you may wind up trying to create a solution for the wrong problem (e.g. you create an entirely new design, when all that was really needed was clarification on a few confusing navigation options). A large part of what you're bring to the table is knowing specific solutions to specific problems.

The second is to break tasks into manageable chunks.

If they really have no clear direction, and you're concerned that they'll suffer sticker shock, a price list for specific features and tasks will probably be to your advantage.

Creating a basic color scheme and layout, new navigation, custom animations or effects, image carousels, forms, etc., are all things that can be identified and priced.

If they want 6 different custom "contact us" options, all with different fields and associated validation options, they may change their mind once they see how much each option costs them, and instead settle for a single generic form.

They may really have their hearts set on different custom animations for each and every page, but may agree to just having one on the home page if it will keep it in their budget.

The third is to show, don't tell.

Mockups and wireframes are incredibly helpful. You can describe what you intend as much as you want, in as much detail as you want, but nothing compares to showing them. There have been too many instances where I explained (repeatedly) how something would work, had the customer say "okay, I understand", only to have the customer say "I didn't realize that's what you meant" when they actually saw it on the screen for the first time.

Even if what you show them is crude and incomplete, it is better than any amount of words.

Answer 5

There are some great answers here already, but I thought I'd add a couple of points that have been useful to me and I haven't seen raised already.

1. Make sure your potential customer knows their budget

I don't mean simply "ask them what their budget is", necessarily. The important thing is that they know what their budget is and why. For business websites, there's always a business-related goal for a new site - even if it hasn't been clearly defined. Once they know the goal, your potential customer should be able to work out how much it makes sense to spend on the project, such that the work will pay for itself in a reasonable amount of time. A surprising number of people don't do this work ahead of time.

From there, you/they should be able to work out if the proposed project is even feasible. If it will cost $20K to build a site to sell 10 items a week at a dollar each, the site will take 38 years to break even. I've told plenty of potential clients that what they're asking for is a good idea, but that it's economically impractical to build, and they've all been grateful for the advice.

2. Charge to quote

I only quote from an agreed-upon specification, and I charge to prepare that specification. In my view, you need a specification in order to have any hope of knowing how long something will take, and therefore how much it will cost.

Whether you charge your hourly rate or some nominal fee is up to you. Preparing the spec is a specialised skill that you have and they need.

The spec is a deliverable in its own right that the customer owns afterwards. I tell people that they can take it to other developers to have it quoted on - that way they know they're comparing apples-to-apples.

Paying for this step acts as an effective filter. If they're not willing to pay for a few hours work to specify an important project, then how important is that project? In my experience, most customers are quite receptive to the idea after a friendly explanation, and those that aren't were probably going to become a problem later on anyway.