How to manage client feedback during wireframe phase

Question

My team and I offer freelance web development services, often to non-technology personal.

We started to incorporate a wireframe phase in our web software development process (as opposed to outsourcing it). Often times, clients would review our wireframes and request features to be added that meet any or all of the following conditions:

• features are in conflict with specifications with other features
• features will result in poor user experience
• features are half-baked ideas that I know will not work if explored further

I believe I can prove each of my points above if we devoted substantial time to exploring them. However, our clients are on a tight budget, and I can't justify spending over 50% of their budget explaining to them why their ideas are bad. They would rather we spend that budget on actual development.

Options I'm considering:

• Find a way to reduce client involvement in the wireframe phase. However, how does my team know if the product design has satisfied business objectives?

• Do whatever the client says. However, from my experience, 3-4 months from now, clients will complain how "such and such" is not user friendly, and throw a tantrum until we volunteer our time to upgrade their product.

• Something else?

We're currently using wireframe tools for the wireframing phase. So the actual drawing is fast. But the talking, and trying to explain everything to the client is taking too long.

Any management techniques you guys can suggest would be greatly appreciated.

Answer 1

Working with your stakeholders is the most important thing you can do. Your brilliant product is garbage if your client does not buy it. Build time and budget into your plan to allow for this.

You need to remember why you are there. The solutions you develop are there for the benefit of the business, not the other way around.

Answer 2

Using an agile methodology, or some approach that package deliverables into smaller, bite sized, easily digestible chunks may help avoid doing a lot of work for free. When using such an approach, you estimate one small piece at a time, collaborate on the ideas with the client, build it, release it to the client, get paid, and then repeat the process with the next phase.

If the client then wants to change something after it's been built, you would then renegotiate this as an additional phase of development. In my experience doing some freelance work in the past, the iterative approach is generally more favorable for both parties. If it isn't favorable to your client, then it might be a good idea to reflect on your target market and consider the cost/benefit of searching for clients who understand the software development game.

One thing you might suggest with the client is that they can help lower the overall cost of the project by coming prepared with exactly what it is that they want to do. Also, you might consider including these meetings in the estimates and timing these meetings so that if you start to hit the cap for what's budgeted for meetings, you can then let the client know they must then make a decision.

Being up front with the client and encouraging them to prepare for these meetings can help keep them shorter, keep their costs down, and also ensure that the product you build meets their needs. In short, a client/vendor relationship is just like any other give and take relationship. Both parties must participate.

Answer 3

As others have said, a core part of your job as project manager is establishing scope with the client and managing/maintaining that quote.

There is no easy answer to this question; clients who are on a low margin have a vested interest in obtaining the most services for the money, while you have a vested interest in obtaining the most moeny for the services. These are in intrinsic tension.

In your situation, I'd probably first read a lot of books on negotiation theory and tactics. Then I'd develop a series of quotes for the client. - one for the base service, and additional quotes for each package. The ideas that are bad are priced higher.

If the client wants to discuss the quote that takes up their time and yours. That ought to discourage extended negotiation. If not, you can impose an additional charge for negotiations beyond the second hour, or beyond the fifth email. You owe it to yourself and your clients to do you best to optimize the explanation of those prices. That is a core part of the service you provide.

You also need to develop and market your reputation for integrity, for treating the customer fairly, and for fair assessments that are in line with the market.

If you're going to go after low margin clients, I suspect you're going to have to deal with a low capture rate. If you want to improve your capture rate, drop the low margin clients.

No easy answers. Best of luck.

Answer 4

Your concern for your client's time is a sign that you are looking out for them and the fact that you have identified conflicts in their new "requirements" is a sign that you know what you are doing. However, if they are paying for your time, to a certain extent they get to call the shots.

I would bet that you can demonstrate to them that some of their ideas are off base. But the question is "Will that make them happier with you or just tick them off?" And that's the bigger question here, assuming you want more of their business. If you have a bunch of other clients lined up, then maybe you can move on to one of them. But in the long run, you want to have a long trail of happy clients. Even if some of them had to learn the hard way (by paying your development time for their own education).

Do not reduce client involvement and keep doing the wireframing. Despite some of the negative results you are currently encountering, it is a very strong tool to help bring out the best feedback from your customers and help get full requirements from them. Getting full requirements reduces the amount of time you have to add to the schedule later because you or the client didn't think of various features that really are important to the product. And though they may not say it, they will quietly blame you (at least partially) for features (and cost) that are added later in the process.

What you should have at this point is a long list of features. You need to work with them to prioritize and schedule those features. If there are some that you think are not going to work, try to negotiate with them and schedule/budget those later. But don't just say "No" if they are standing firm.

Prototyping is another strong tool. It requires more work than wireframing, but if done correctly, it's considerably less work than full production-level code. See if you can get them to agree to just prototyping some of these features, seeing if they are truly useful, and only then doing full design/budgeting/scheduling on them. And see if you can do that prototyping later in the development process where possible. And they pay for the prototyping. Non-negotiable.

Are the meetings with them to explain their fallacies really taking a lot of your time or are they taking more energy than you thought they would? You state upfront that these folks aren't always very tech-savvy. You need to have low expectations about their ability to envision the conflicts that you are correctly identifying and bringing to their attention.

Stay engaged. Educate them as best you can. Try to conditionally budget and use incremental development to your advantage in cases where you think they are making mistakes.

Answer 5

Not engaging early is a bad idea - as well as just doing what they ask of you. Both are easy paths to take, and will ultimately cause heartache on both sides.

You must engage the client during the wireframe phase, and guide them in the design of the project. If their ideas are shite, then persuade them of their folly. That is why you are a consultant - use your expertise to consult them on the best path forward.

Answer 6

It sounds like you are finding yourself in situations where you feel you have made some informed decisions that you feel are based on a solid understanding of what your client is trying to accomplish, but where it is difficult to explain those decisions to your customers.

One thing I would ask is how explicit are you being with your customers when discussing things prior to the wireframing stage? Are you discussing what their overall measurable goals, target users, and priorities are? Based on what you are saying, it sounds like you think you've got a good feel for those things, but how explicit are you being with your customers about these things? Are you documenting them and specifically referring back to them in later discussions?

We often see clients that hear about some nifty new widget that they immediately want to incorporate into a system. Often times, simply asking how including that widget helps meet their stated goals or improve life for their target users can either get them to lower the priority on it, or help them communicate to you what the actual value is and why it should be a priority.

Answer 7

Wireframes and Prototypes

It seems to me that the presenting issue here is that you haven't clearly identified (or perhaps effectively communicated) the purpose of your wireframe phase. In my personal experience, wireframes are most useful for asking:

Is this user-visible feature set sort of what you had in mind?

If the answer is yes, then you have a starting point for discussions about cost and complexity. If the answer is no, then you need to revisit your specifications or assumptions.

Possible Phase Transitions from Wireframing

If you have a clearly-defined wireframe phase, you shouldn't be jumbling it in with your development. The output of each wireframe phase should be input to another milestone. For example, a wireframe phase may lead to:

1. Another wireframe iteration.
2. A return to requirements-gathering.
3. The start of a level-of-effort estimation phase.
4. Directly to a development iteration.

All of these are valid things to do, but I'd personally try to avoid going directly from a wireframe iteration to a development iteration without a distinct estimation phase that takes the wireframe as input.

Estimation and Communication Are Essential

Only the development team can provide accurate estimates. The goal is to use a client-approved wireframe as input to that estimation process. That allows you to have an honest discussion with the client about the trade-offs involved in design decisions, and to give them sliders to control time, quality, and scope.

Here are your main concerns, along with how estimation and communication can help.

1. Features are in conflict with specifications with other features.

   Conflicts in the specification should be clearly communicated. You don't have to "prove" them; you're offering a professional opinion, and hopefully giving the client the benefit of your expert advice in how to avoid the conflict.

2. Features will result in poor user experience.

   Again, a client is usually paying for your expertise. Requirements-gathering and wireframing aren't meant to be one-way conversations; they are discussions to iron out specifications and expectations. If you think a given feature will have a negative impact, discuss it with the client and document the assumptions and results of the conversation---perhaps even add it to your project's risk log if you have one.

3. Features are half-baked ideas that I know will not work if explored further.

   This is part of estimation and planning. Again, communication is key. If an idea will be hard or expensive to implement, your post-wireframe estimations should reflect that. If an idea is "half-baked" (in the sense of being incomplete) then it needs to be sent back through the process for refinement. If you simply disagree with the decision, then provide constructive feedback and let the client make an informed business decision.

Poor Change Control is the X/Y Problem Here

[C]lients will complain how "such and such" is not user friendly, and throw a tantrum until we volunteer our time to upgrade their product.

This is your real issue. Everything else is trying to solve the problem without addressing the underlying cause.

If your process is transparent, iterative, and remains closely-engaged with your client throughout the project, then they will be able to make decisions and necessary corrections along the way. They are in the driver's seat; if they send you down a wrong path, it's their decision---but one they can easily correct in the next iteration.

However, if you treat specifications, wireframes, and other inputs as inviolate one-way communications, then you need to transfer all residual risk to the client. This is usually a contractual issue, and involves a lot of documentation and client sign-offs. This will usually prevent the need for unpaid re-work, but certainly won't build trust or rapport with a client.

Ultimately, the issue you're dealing with (e.g. how to avoid working for free) is a contractual change control issue. To fix the real problem, not just its symptoms, you need to inspect your contracting process, as well as how your company wants to handle change requests and how well it educates the client on the agreed-upon change control process.