When people think of a development brief, they usually mean a questionnaire that is sent to a client before the project goes into development. However, this questionnaire is only the first step in the briefing process. Pre-project communication with the client is as complex as it is important: if you miss something, the whole development could go south – even if you’ve agreed the terms of reference beforehand. Read on, and we’ll illustrate this with a real-life example.
Every company has its own procedures for drafting a brief. Let’s take a look at how we’ve set up this process at Toimi.
Preliminary questions
Our communication with the client starts with a questionnaire, which, contrary to popular belief, is only one part of a development briefing. Its purpose is to get a general idea of what the client wants.
At this stage, it’s important to gather the following info:
- brand positioning and the company’s values
- goals and objectives that the customer wants to achieve with the product
- TA specifics
- business rivals and desired competitive advantages of the product
- preferred website structure
- design that appeals to the client, colours and fonts, logo and corporate identity
- necessary website features; e.g. online ordering, search bar, feedback forms, calculators, videos, and photo galleries
- whether the client wants an off-the-shelf CMS or a unique website developed using programming languages
- tech stack requirements (if any)
- development timelines and budget
- need for website maintenance after launch
The project manager then studies the brief and prepares for a personal conversation with the client to go over the details – we usually conduct several meetings. In between these iterations, the project manager consults with developers and designers to understand how the client’s needs can be implemented, whether there are better ways of doing it, and how much time and money the project will take. If the developers believe that the client has chosen a suboptimal technology stack, one of them may participate in the negotiations to propose a different option.
When all is clear, ask again
The main purpose of a brief is to get as much information out of the client as possible: what they want from the website and what goals they want to accomplish. Any detail that is not clarified in advance may ultimately send you back to the drawing board.
For example, if the client needs a hotel booking site, it’s important to know what they want to do with it after it’s up and running. If they want to turn it into an aggregator in the future, this will affect the choice of our tech stack, as we’ll need to provide for the necessary functionality and future integrations. That’s why you should ask a lot of clarifying questions during the negotiation phase. There’s an important rule to follow: if everything seems clear, ask again.
Here’s the real-life example we promised: one of our employees was developing an adaptive layout for a client – and just when he was almost done, the client suddenly changed the website design. The developer opened the portal only to see that literally everything had been changed, so he had to start from scratch. And while you could say that it was the other party’s fault, if the project manager had originally found out about the company’s plans for a redesign, the problem would never have arisen in the first place.
Expert opinion
When discussing a brief, it’s important not only to listen to the client, but also to discuss any questionable ideas: our experience enables us to make quite reasonable suggestions on how the functionality should be implemented. In other words, a brief is less of an interview, and more of a joint effort.
We had a client who wanted to develop an English learning app, but didn’t fully understand how it should be structured. For instance, he wanted to include practical exercises both in the theory block and as a separate section. During the discussion, we identified such nuances and made visual sketches of user scenarios. By working together, we managed to find solutions that satisfied both parties.
It can also happen that a client’s requirements for website functionality are outside their budget. Rather than bluntly saying that something is impossible, the project manager should gently steer the client towards a different option. To give you a rough example, if the client wants a massive classifieds website like Avito, we would suggest that they take a gradual, step-by-step approach – that is, start with the first steps without fully committing. This will give them a first-hand understanding of how realistic or unrealistic some of their ideas are and serve as a wake-up call to rethink the design if there are any problems.
Post briefing
After the negotiations, we estimate an approximate budget and draw up a roadmap where we describe every stage. For large-scale tasks, each stage turns into a project of its own: we draw up its terms of reference and sign a separate contract. This is necessary if the product is difficult to plan in advance, as it helps make a more realistic estimate of the timeline and budget and develop a ToR after each stage.
Once the client has greenlighted the roadmap, we carry out a comprehensive audit to determine the exact cost of the project and a specific pool of tasks, as well as develop a terms of reference. In the meantime, we also work on prototypes of the pages for the future website, so that the client can get an idea of what it will look like when it’s fully developed.
Finally, we sign a contract and proceed with the development. And its flow will depend to a large extent on our diligence at the briefing stage.