I’m going to be very honest in this post.

Most of my clients don’t understand websites and how they work (if you are a client of mine, I don’t mean you, I mean my other clients, the ones who aren’t my favourite…) – at least not from a technical perspective. It can be more difficult when they tell us they understand technology, because we end up doing a delicate dance around their assumptions trying to be polite and respectful of what they do know.

Even with something as simple as a WordPress website, common misunderstandings about how queries work, or even the difference between static and structured content, mean we often invent different terms based on the client’s level of knowledge. This, of course, adds hours to a project just to track which terms we used not to mention the time take to educate clients finding a common ground between to different expectatoins. At worst, it causes total communication breakdown.

But as much as this sounds like me whinging (and yes, writing this is a bit cathartic), I’m just illustrating how this creates frustration on the supplier’s (our) side, which can, in turn slow us down in finding a solution because it’s easier to simply say – clients suck and there is nothing we can do about it.

It is ultimately our responsibility to overcome this challenge becuase it’s our area of expertise.

Enter “Test-Driven Briefing”.

This idea is derived from “test-driven development”: an approach to coding that starts with writing a test to define what the code should do (i.e. describing the outcomes), then writing just enough code to pass the test. This process is useful because it forces the developer to define success in a measurable, observable way. For Test-Driven Briefing, we extend this philosophy to how we collect briefs: set clear outcomes upfront.

How Test-Driven Briefs Work

1. Start with the request
   A client might say:
   
   “Can you add a button in the top right corner that links to the contact page?”
   
   That’s a good start, but it’s still open-ended. What if the button looks fine on desktop but disappears on mobile? Or what if it doesn’t take you to the contact page? Without clear rules, everyone might assume “done” means something different.
2. Turn the request into a Test-Driven Brief
   Translate it into a mini-checklist of outcomes:

• The button is visible in the top right corner.
• It shows up on both desktop and mobile.
• When clicked, it takes the user to the contact page.
  Now the brief isn’t about “how” we build it; it’s about what “done” looks like.

3. Write the acceptance test
   Behind the scenes, our developers turn that checklist into a test we can run automatically. Think of it like a robot that clicks the button and checks: Can I see the button? Is it in the right spot? Does it take me to the contact page? If the answer is “yes” to all of these, the test passes. If not, it fails and the work goes back for fixing.
4. Build the feature (just enough to pass)
   The developer builds the simplest version of the button that can pass those tests. At first, it might just be a plain button that works.
5. Refine and improve
   Once the test passes, the developer can safely add polish – design, colours, mobile responsiveness, accessibility – knowing the core outcome (the button works and goes to the contact page) won’t break.
6. Review and accept
   When the tests pass, the project manager can confidently say: “Yes, this matches the brief – it’s done.” No arguments, no grey areas. Everyone agrees because the definition of “done” was set from the start.

Why this helps clients

• You get clear, outcome-driven briefs instead of technical jargon.
• The brief becomes the definition of success, not the process.
• Work isn’t accepted unless it passes the test you agreed on.
• Less miscommunication, fewer surprises, and more predictable outcomes.

👉 Put simply: Test-Driven Briefs mean we define success first, test as we go, and only deliver work that passes the test.

Conclusion

We’re rolling out Test-Driven Briefs across our workflow. Keep an eye out as this shapes how we collect requests and deliver updates. It’s all part of tightening the grey areas, improving communication, and ensuring your work isn’t just “done” – it’s done right.