It can be incredibly difficult to scope out a web development project when little is known up front. Often times clients are not only unaware of what they want, they’re unenlightened to what they need. This issue only becomes more complex with complicated websites and mobile apps.
Spending time crafting a proposal when project requirements aren’t known is not only hard to do, it can be a waste of time for you and the client. There will be instances where someone wants a proposal to bring to their colleagues and they have little to no direction to give you. It’s unavoidable at times. But in most cases there is a key to solving this problem.
A solution I’ve found to best see client website issues and meet their future business objectives is having a Paid Discovery prior to agreeing on any proposal.
During a Paid Discovery investigation, myself and a technical resource from our development team meet with the client to review their current WordPress or Drupal website and discuss their business needs. I’ve found it best to have at least two points of view during this process: an account perspective and a technical one. Each will bring valuable insights to providing a solution for the client.
It’s surprising to me how often I’m face to face with a client and they have been provided no understanding into why their website is the way it is. Of course I’m quick to assume their previous agency simply doesn’t dive very deep into user experience or content strategy. Countless times I’ve been contacted by prospective clients who know their website isn’t functioning the way they need, but they have no idea why. They may have recommendations from their own perspective, but they’re reaching out to us for a solution. We need to provide one.
How can you provide a solution when you don’t know the problem?
Should they put a small fortune into band aids, or is it really more effective to start over? What is developed correctly on their current website? How much of the website is junk?
These are difficult things to know without investigating what currently exists. My recommendation is to not send over a proposal without an understanding of the client’s needs. It may be tempting to throw some numbers in a spreadsheet, but how many times has that come back to bite you down the road?
Theoretically, you were driving blindly. If right now you’re telling yourself a proposal is just an estimate, you’re only reinforcing your own point of view. You can tell a client a million times something is just an estimate, but that’s hard to remember when the bill is significantly higher than expected.
If someone insinuates it’s your responsibility to find out what’s wrong for them without getting paid, they’re wrong.
It can be difficult to ask a client to spend money on discovering their current problems. The ask can be awkward. Responses vary from agreement to insult. The value of actually finding problems does exist. Just ask a therapist. They make plenty of money and for a reason.
Breaking up Paid Discovery into three deliverables has proven to be successful for my team in the past:
Content Audit: Provide a few hours for development team members to investigate the client website as is. Dig around and document the red flags. Sometimes there are only a few. Lucky clients! Other times, it’s a parade. Break out the spreadsheet. The information found during this audit will guide you to making your recommendations from a technical standpoint. It can also serve as informational to the client. For example: maybe they aren’t aware their website could be easily hacked into at any moment.
User Experience: For the most part, this should be accomplished during the client meeting. Asking the high-level questions you will still ask during Discovery in your project is the goal. We’re not trying to map out the journey of a user persona in detail. We’re looking for who is the target audience and what do we want them to do? If a website doesn’t have one clear call-to-action on the entire property and the client is wondering why no one contacts them, this is where things become clearer to you as the service provider.
Wireframe Example: The remainder of your Paid Discovery should be used to have a top-notch UX resource put together a page example wireframe which aligns with the User Experience covered above. You can walk through this wireframe with the client to demonstrate how your fixes or new development will aid in resolving their website shortcomings.
After all is said and done, you will have a better understanding of what the client really requires. This will help in shaping a proposal which actually addresses what needs to be done rather than fitting your numbers into a suggested budget.
At the end of your successful project, the client will be very happy they paid you a little up front to prevent major pain points during the big picture.
This article was written by Chris Bordeaux, featured on LinkedIn.