One of the most common issues that can strain a relationship between a Developer and a Client, is the difficulty in translating what a Client wants into an accurate agreement. We hear these kinds of complaints from prospects who have come to us to help, after being furious with their previous developer.
Do any of those complaints sound familiar? We hear variations on these themes all the time when talking to potential new clients. This, is a problem of communication, and in almost all cases, both the developer and the client are equally right, and equally wrong. It’s important to understand both sides of these kinds of issues, in order to understand how best to avoid them.
When a Client first approaches a developer, their goal is simple. Translate my idea into a website. Build me something pretty, something that works the way I want it to, and has a user experience that is perfect for my particular market. The issue, however, is often that doesn’t translate into something the Developer understands. A Client should never assume that a developer understands what they want, if it hasn’t been explained and detailed in an agreement. What may seem like an obvious request or function to you, may not be obvious to someone unfamiliar with your product, market, or niche.
And a verbal agreement is not enough. It needs to be in your contract, so that it is legally enforceable. We’ve seen too many clients upset with dishonest developers, who promised them the moon, but only delivered what they were legally required to. It’s important to review agreements and contracts, and find a way to explain what you want clearly.
Another major issue, is the assumption that something is easy to code. Just because many sites are doing something, does not mean it takes an insignificant amount of development time to add that functionality, and in the world of development, time = cost.
Developers are not mind readers. We can’t know everything a potential client wants on a website, and provide an accurate quote for the cost, if it hasn’t been explained. Frequently, a client will send us their website, and say “This is what we want”. The assumption they have, is that we will spend hours upon hours testing and documenting every function on the website, to create a blue print for the new website. The problem being, even if we spent 50+ hours testing and documenting as much as we could, we would likely still miss important details or functions. Not to mention the cost of doing that testing.
When bidding, if things are left out, it leaves developers in a difficult situation. Your Client is angry, they assumed a piece of functionality was included, even though they neglected to mention it until two days prior to launch, or detail it during the bidding process. You’re left with two options, let the client know there will be some additional costs and launch delays, or eat the cost yourself. Neither are particularly great options.
There is also a tendency to speak in jargon, and assume your Client understands what you are saying. Too often, the answer is “Here, look at this plugin, read the documentation, let us know if that works.” Clients aren’t developers, they’re leaning on you to walk them through the process.
So what is the solution?
A DETAILED WEBSITE USER-FLOW
We request this of our clients constantly. In simple terms, a userflow is a brief write-up of what you want users to be able to do on your website. It doesn’t use any technical language or jargon, doesn’t have to be incredibly complex, just a simple write-up.
What does a website user flow look like?
A quick example, using Amazon.com:
- A user comes to the website, and sees products that might interest them (based on their browsing history, as well as what is currently popular).
- They can browse through products using a search bar, or browse by category and sub categories.
- Once they’ve selected a product, they are taken to a product page.
- On a product page, they can look through additional photos of the product, add the product to their cart, select their quantity and product options, read product reviews, read the product FAQ, and see other purchasing options.
- Once a product has been added to the cart, they can see their cart total, continue shopping, or proceed to checkout.
I could go on, but I think this demonstrates the point. We usually ask for a write-up for both a site user, and a site admin, to make sure we fully understand exactly what you want, both for your customers, and for your team who will be managing the site going forward. Our team will then take your write-up, and refine it, and ask lots, and lots of questions. This is key. Too often, because of a self-imposed deadline, the scoping process is rushed, and this leads to unhappy developers and clients. It is extremely important that both sides fully understand the build, before one single line of code is created.
Collaboration is the Key
Sometimes these write-ups can be simple. Other times they can become very complex. It just depends on the needs of the client, and how many functions the website needs. But in collaboration, we can hone in on a write-up that includes both the general explanation the Client needs, along with the technical language that the development team needs, to ensure the project is completed to the satisfaction of both, and most importantly, that the pricing is accurate.
Here’s an example from a recent site build we did (some details have been altered, for the privacy of our client). This is only a portion of the write-up, but it gives you a solid idea of what we’re aiming for, and how it will look by the end of the process.
Take the time to get it right the first time.
As you can see, a good user-flow takes both time and effort. But it saves headaches and conflicts down the road, and ensures that you will end up with the website you want, at the price you were promised. There is no guess work, and enables us to provide an accurate quote, ensuring there won’t be additional costs as the project expands in scope.