Back in September, I hosted a webinar session on ADPList called “What the brief.” This session aimed to tackle the many issues that crop up when attending a project brief.
My running joke is that calling it a brief is part of the problem.
Most businesses I have worked with try to skip crucial steps to save time and get a project going as soon as possible. This practice is actually costing businesses more time and money.
What is a brief
Before we begin, we need to truly understand what a project brief is, and what the purpose of it is, if we look at Google's definition, it is defined as:
"to instruct or inform (someone) thoroughly, especially in preparation for a task."
Unfortunately, the part that is often left out is the thoroughness of the brief.
If we are working at a larger corporation, most likely the project has come from the top of the chain. If that's the case, most likely the development team and designers have been left in the dark up until this point.
On the other hand, if we are working as a freelancer and are hired by a company to start a project, we will also have been in the dark until the time of the brief.
In both cases, we weren't included in the brief, either due to hierarchy or due to the time we entered the project. The following discussion will apply to both situations.
Redefining how we approach briefs
A project brief should actually consist of three different stages. Each stage is equally important, although it will span over a few days, the cost saving is worth the time invested early on.
The three stages of a project brief are the following:
- Requirements gathering
- Analysis and recap
- Regroup and clarify
Unfortunately, most stop at stage one and entirely skip the last two steps. Let's take a simple example:
If you've ever watched a house remodelling, project building, or related shows. You will notice they always go through these three steps. I've never seen in my life a construction plan gather the requirements and immediately begin ordering materials to start construction immediately.
Construction and physical product commissions always do research to return with a better deadline estimate and what compromises may need to be done if the deadline is set in stone.
If construction were to start ordering materials, the manager or stakeholder will go mad due to the waste of money, materials and blatant oversight on their part. So why do we do it in digital products? My guess is that the cost is not immediately relevant due to the intangibility of digital products.
The cost of building a digital product is harder to measure due to the intangible nature
Let's talk through each stage and see what tasks we should complete to build a successful and cost-effective project.
When working with clients or stakeholders, we need to make it clear that we will be completing these three steps in their own interest. Let them know that after the first stage of requirements gathering we will get back to them after a few days.
During requirements gathering, this is exactly as you'd expect and what is entailed in briefs today. The stakeholders are explaining the requirements for the project while we try to digest everything.
During this stage, it's a good idea to ask specific questions that may help the conversation. There are five questions that may help create deeper discussions:
1. Who are the stakeholders involved?
It's not always the case that the people giving the brief are the ones who manage the project. Allowing yourself to know who the developers, marketing and sales teams involved will allow you to discuss and gather more insights from them later.
2. What problem are we solving?
If it isn't already evident, try to understand where the client or stakeholders are coming from. If the project feels similar to many other applications out on the market, we need to understand how this product differs to help market the advantages.
3. What are the key objectives?
This is very similar to the problem being solved, but depending on the response the way we approach the design could be drastically changed.
4. What is the future roadmap?
If we plan early on for scalability both in the development and design roadmap, the future implementations will be much easier in the long run.
5. How will people learn about the product?
Here our aim is to answer and learn about the different channels and plans for onboarding and migrating new or existing users to the product.
The point of these questions is not just for information, but to open up the floor to see where improvements may be achieved.
Analysis and recap
At the end of the requirements gathering stage and based on the size of the project given, it's important to give the design and development team time to analyse and recap.
The goal in this stage is to start whiteboarding directly with key developers and possibly the marketing team. As someone who is in service or user experience design, how would you plan differently and what could be improved.
Take an outside approach to the problem and ask if the proposal is actually solving the problem. Brainstorming, planning out some basic user journeys and listing out possible edge cases can help scope how large the project actually is.
While going through the plan, keep the intended deadline in mind, is it still feasible? If not, try to come up with a proposal on areas to compromise on and adjust the release plan.
Throughout all of my career and freelancing, I've found that 99% of the time the plan can be improved or changed, and that's okay – that's why they hired you!
Regroup and clarify
Once the team has completed their recap and is confident in the findings and proposals. It's time to regroup with the stakeholders.
During this time invite the developers and other team members that attended the recap sessions and voice your concerns and counter-proposal. If anything is unclear in the journey make sure to address it and finalize any last details in the scope.
The goal of this is to make sure everyone is in agreement and on the same page. Building better products are all about being on the same team and working together. Even as a freelancer, more belief in the product will make for a better working collaboration.
As user experience designers, we cannot isolate ourselves to only the interface. We need to work with business, understand the business needs and try to solve business problems while creating great experiences. A recent tweet from Andy Budd really resonated with me:
I'm seeing product managers become more and more tactical and delivery focussed. Building wireframes, populating backlogs etc. With that in mind designers need to rise up and become more business focussed. How does the work we do affect the companies bottom line?
This is becoming increasingly true with data-driven design and measuring how design affects the direction of products. The goal here was meant to help drive this business thinking.
Perhaps one day someone by the name of Theodore Groves will exclaim that "That's gotta be the best designer I've ever seen."
If this article was helpful to you, please share it with your friends, family and pets. And please sign up for my newsletter to get a monthly recap of my latest articles and interesting internet finds straight to your inbox.