Do you need what you want?

In my first post as a member of Team Fogg, I thought I’d talk around a point of contention in the world of design. That is to say, in my experience, most clients tend to know what they want, but not many know what they need.

With each new client comes a new relationship to develop and a new business to understand, but not necessarily an unprecedented problem to solve. Our clients by their very nature as successful business people are understandably immersed in what they do. Some are focused to such an extent that they may feel the problems they face are unique to them, when in fact our first challenge with any client is usually the same; building the brief.

But shouldn’t the brief already exist? Is it not supplied by the client themselves? In theory, the answer is yes. A brief would ideally come ready with all the insight and data we need to allow us to deliver the very best solution possible. In reality the brief will quite often ask more questions than it answers.

Our very own James Brooke wrote a blog post in June of last year discussing the value of information gathered from the client – insight – as opposed to being guided by your gut feelings – instinct. Both insight and intuition are essential attributes if you work in branding, and the subject of striking the optimum balance between the two never fails to spark debate.

There are a few schools of thought on how best to obtain the information you need from the horse’s mouth. Many agencies use briefing workshops at the beginning of the process in an attempt to gather everything in advance and in person, to maximise their initial control over the project. Others tend to operate in a more fluid manner and will embrace new and influential information later in the process. After all, ‘control’ means different things to different people.

Different clients tend to present you with different types and amounts of information on day one. Some will hand you reams of paper for you to make sense of, while others may entrust you with a blank canvas. What is certain is that there is no certainty; there is no universal right or wrong way to learn about your client.

What we can do is ensure we approach each case with fresh eyes, offering keen observations by adopting a perspective the client perhaps hadn’t fully considered before. This is the first step in identifying the wants and prioritising the needs.

The reward

I know of no greater sense of achievement than finding a solution to a problem that your client wasn’t aware they had. When you do this you’ve achieved two things; you’ve brought an issue to light before it’s even become a problem, and you’ve offered a solution before you were even asked to conceive one. You’re the prevention and the cure all rolled into one, and it feels good.

Waterfall vs Agile

While I have experienced success using client workshops to gather as much content at the start of a project as possible (particularly digital) I’ve also had the problem of having to make significant changes to the scope mid-project. It’s often the case that the more planning time you invest at the beginning, the more there is to lose later if the client’s needs should change. This can be costly, and it’s a cost that you often need to absorb as an agency.

With workshops the aim is to gather more initial insight to limit these unforeseen late changes to the scope; changes that can sometimes render the brief irrelevant – or even obsolete – and cause big headaches. At best, it leaves you with an outcome that could’ve been better. At worst, a client who is dissatisfied.

These problems are experienced by every agency working in ‘Waterfall’, which is 95% of us.

These agencies haven’t actively chosen to work in Waterfall. We do it by default because it’s been the most common production process in use since the 80s and it’s easy to implement, but it is also the least forgiving.

What is Waterfall?

The Waterfall methodology is a sequential process. It gets its name as it flows like a waterfall, in one direction from top to bottom. There are typically eight stages in the process; Conception, Initiation, Analysis, Design, Construction, Testing, Implementation, and Maintenance. This means that as each of the eight stages are completed, you move on to the next step.

As this process is sequential, once a step has been completed, you can’t go back to a previous step – not without scrapping the whole project and starting from the beginning. There’s no room for change or error, so a project outcome and an extensive plan or scope must be set in the beginning and then followed closely.

The problem with this method is that you’re relying on the client’s ability to give you lots of high quality content upfront, and as we’ve disussed here, no client ever knows entirely what they need at the beginning. How can they? If they did know that then they wouldn’t really need our expertise in the first place.

A certain degree of change mid-project is inevitable. The only productive way of dealing with this change is to embrace it and run with it, not to try and prevent it. This is why ‘Agile’ was developed as a methodology; to work more closely with the client, and to design a product or service that only has features that are necessary for it to succeed. Using Agile means it doesn’t matter if the initial brief is a bit thin. That’s the point.

What is Agile?

Agile is an iterative process. It came about as a ‘solution’ to the disadvantages of the Waterfall methodology. Instead of one long sequential design process with a predefined route, Agile works in short cycles. Designers and developers start off with a simplistic project design, or MVP (Minimum Viable Product), and then begin to work on small modules. The work on these modules is done in weekly ‘sprints’, and at the end of each sprint, project priorities are evaluated and tests are run. These sprints allow for bugs to be discovered early, and client feedback to be incorporated into the design before the next sprint is run. This ensures the client is consistently satisfied, and the features of the product are kept relevant.

The principle of Waterfall is to avoid failure, but there’s often a big surprise at the end, such as extra functionality that wasn’t on the initial brief.

The principle of Agile is to fail early, meaning there are no surprises at the end, just a happy client and an effective product.

If used properly, Agile is by far the most client-friendly and efficient methodology that exists in product or service development. It also happens to be one of the hardest processes to implement and maintain, especially in a creative environment.

Here at Fogg, the way we interact with our clients follows the same basic principles as Agile in that we remain flexible and receptive to change. We’re eager to learn about any fresh thinking that improves what we can offer. By combining this receptive mindset with a passion for quality, Fogg has earned a bright and shining reputation as a team of friendly, focused and efficient professionals who strive to do what we love, and do it consistently well.

michael.ellis@foggassociates.com

01925 226 139