Updated November 2020

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.

“They said it would be no problem.  But then refused to build what I wanted without charging me more.”

“I assumed my website would do X, Y, and Z.  But when they finished building it, they left things out.”

“Why didn’t they look at my current site?  I didn’t ask for a new website only to lose existing functionality!”

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.

The Client

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. You need to be clear, and ask your developer for the functionality you want, so they can accurately quote the project cost.

The Developer

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, because we weren’t there when it was built, and we don’t manage the site on a daily basis. 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 and rush to get the site completed on time. 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?


Before we sign a contract, we request this of our clients.  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 and doesn’t have to be incredibly complex. Just a simple write-up explaining what you want user’s to be able to do on your website.

What does a website user flow look like?

Let’s use Amazon.com as an example:

  1. 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).
  2. They can browse through products using a search bar, or browse by category and sub categories.
  3. Once they’ve selected a product, they are taken to a product page.
  4. 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 and recommendations.
  5. Once a product has been added to the cart, they can see their cart total, continue shopping, or proceed to checkout.

The length of the user flow should directly correlate to the complexity of the functionality you want, 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 site users and for your team who will be managing the website 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 as things get missed. It is extremely important that both sides fully understand the build before one single line of code is created.

Collaborating on your user flow 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 of a user flow 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.


Customer User Flow

  1. A customer visits the website, browses through the products. – Our Layered Navigation plugin for WooCommerce allows for quick drill down, helping visitors find exactly what they want, in an instant. Each time a selection is made, automatic results display and all options are adjusted perfectly (no matter the order).
  2. On the product page, when a customer adds a product to the cart, and the product requires engraving, they will be required to enter the pertinent engraving information. (see product details below)
  3. As the client enters the information, a preview will appear with the text they are entering on the image, allowing them to preview the text. As the customer enters their data, the site will make spelling recommendations, which users can click to complete the spelling of more complicated words (medications, etc.). The words for this tool will be provided by the Client in a CSV file, and imported into the tool by Spark Logix Studios.
  4. If the Customer adds a second product, they will repeat this process, and be able to enter and edit the information, and verify and accept that the information is correct before proceeding to the checkout.
  5. On the product pages, the customer will be able to download a printable ruler to use to measure the size needed to enter into the product options. The Client will be responsible for providing this PDF Document.
  6. On the cart pages, the user will again be able to preview their products with engravings, and edit cart quantities. (see cart functionality below)
  7. Once a customer has reviewed their cart, and made any necessary adjustments, they will then click on “Proceed to Checkout”.
  8. They will then enter their payment and shipping details, and complete the order. During Checkout the Buyer may select their country.
  9. All products with engraving as an option will have a link or button (on the Product page in the short description) to a page with Engraving Tips and Suggestions. The option can be created as a Pop Up Modal or open in its own tab (on its own page). Spark Logix Studios will create this page with provided information from the Client.
  10. The Customer may opt in to email marketing (via third party ie: Mailchimp).
  11. SLS will take details from Client’s Mailchimp account and integrate within the checkout process.
  12. The client then receives an automated e-mail, summarizing the order and thanking them for the purchase.
  13. Customers can then log into the site to track their purchases, shipping information, purchasehistory, and order status

Admin User Flow

  1. Once the order is submitted, the site will have automatically pulled in rates from the USPS Shipping System via Veeqo, with accurate shipping costs. The site admin will be able to define shipping rates and add-ons to receive a shipping label from Veeqo, ready for printing within the dashboard.
  2. The Order will be automatically created and synced within the Client’s Xero System, to include the customers information, product summary, billing and shipping costs, etc
  3. Once per day (at a time chosen by the Site Admin) the website will e-mail a CSV file, with the necessary information to be imported into the engraving software for orders placed on that day. Site Admin may at anytime download the CSV or view entries of all submitted forms.
  4. When a customer enters their engraving details the output will be in all CAPS. This same output in ALL CAPS will be displayed as such in the CSV’s provided with engraving details
  5. Admins have the ability to bulk import products into the site using a CSV file, and the information on the CSV file can be edited to update the engraving text the customer has submitted (should they wish).
  6. Admins will have access to a robust reporting system within WooCommerce. At a glance you can check your stores overall performance, or drill down and inspect daily sales, monthly sales, individual product sales, top sells and top earners.
  7. Site Admins will have the ability to reset a Customer’s password, and will be able to access their EMC Data, but will not have the ability to access the Customer’s password directly.

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.

Talk to a Website Development Professional

Want to ask specific questions and get advice? Reach out to us today and we’ll help coach you on how to get your website just right. No obligation or cost!

More From Spark Logix Studios

Check if a Web Page Has Been Indexed (Tool)

Getting a web page on your site indexed is important. This happens automatically if you’re building your website correctly. It’s also important to ensure your directory listings and other web properties (like business directories) are also being indexed (to take advantage of as many ranking signals you can).

9 Types of Digital Marketing (and How to Use Them!)

Digital marketing is not just a buzzword thrown around at networking events. You need to understand the types of digital marketing at your disposal.

eCommerce Categories vs. Attributes

Understanding the difference between categories and attributes when setting up your eCommerce website is vitally important (if you want the User Experience to be just right).