Work on art tasks often begins with a basic stage: the brief. In this article, we’ll put this term under a microscope and break down what it really means, the effect briefs have on how teams work, what sets them apart from ToRs, and whether they’re always necessary for ensuring high-quality results.
What is a brief?
It’s a preliminary document filled out by the product owner, client, or customer representative to help the contractor get a feel for the task. The document is usually brief, but it’s full of important information for future work—namely the client’s general criteria and strategic focus, which answer the questions, “Why are we doing this?”, “What do we need to do it?”, and “Where do we get that?”
What are briefs for?
A brief performs several important tasks:
- It comprises a document that discloses the goals of future work.
- It provides a list of the required documents and files for the task at hand.
- It gives the contractor a strategic vision of the future work—its scope and client’s guidelines.
- And it gives the contractor a strategic context—a starting point for the work ahead and a rundown of the principles they should adhere to.
The brief is the upper (initial) level of context for the task, whereas the ToR accounts for the more detailed mid level. The artifacts and quantity of objects are described further down the line, in the specification. This is what the estimated cost is based on.
Briefs in outsourcing
A brief for an outsourcing team contains much more context than one written for in-house staff. This is necessary for people who are working on your project for the first time — they need a document with all the requirements that touches upon literally everything that the task might entail.
At times, it may seem as though briefs are written for people who have never worked with similar tasks before. Even if you’re working with the very best professionals in the field, they still need to be given as much context as possible in order to reduce the number of edits later on. A good brief takes into account the negative experience of collaborating with other outsourcing studios.
Briefs in production
Briefs for production teams should take into account to what degree the team carrying out the work is immersed in the project’s general context. A lot can go amiss if work on the project has been ongoing for a long time — some information is most likely clear by default. A brief created for an in-house team should take into account the specifics of the contractors, which involves describing the unique criteria that the in-house team already fully understands. This sets it apart from the more universal kind of brief written for outsourcing teams, the contents of which should be understandable for any studio.
How do briefs help clients?
First and foremost, the brief describes the joint arrangements and parameters that must be taken into account.
The brief immerses the team in a common context, which minimizes queries and fosters connection.
It serves as the reference document in negotiations and the base upon which resources are delegated to complete the task. Often, the brief is largely mapped out during the discussion of the scope of work with the client—when they talk through the problems they wish to solve and the tasks that will help do so.
How do briefs help contractors?
Having a brief makes it possible to skip over questions like:
- Where are the references?
- What should and shouldn’t we do?
- Why are we doing all of this?
It gives a general impression of the client’s needs and motives.
What’s the difference between a brief and a ToR?
Although they’re often mixed, these are different stages of a task’s development. All ToRs start with a brief, and the main difference between them is the level of context. A brief is an overall strategy that answers general questions. ToRs are concerned with tactics and more specific, concrete solutions.
The brief describes the situation — what stage we’re currently working on, what we already have, and what’s yet to be achieved. It details the requirements, goals, and tasks. Think of it as the general state of affairs—without any slides, concepts, or presentations. The brief conveys the key information and reinforces both parties’ expectations of one another.
The ToR, however, is concerned with clear steps and specific actions: “Take this element, do this with it, and keep it like that.” It’s a detailed solution for the broad tasks that were outlined in the brief.
Are briefs always necessary?
There’s a short answer to that: not always.
You definitely need a brief if:
- The task comprises working with a group of similar functional elements that have different requirements but are united by common traits. For example, several kinds of banners that differ in size and purpose but share a common style or principle.
- The task contains various ToRs. For example, a category of weapons (e.g., pistols, rifles, and sniper rifles). Each kind has its own unique requirements, but they’re united by a common system integration and purpose.
- The product has a complicated context, such as a unique gameplay mechanic without any examples. Or perhaps it’s a unique style of product that has a lot of peculiarities and is based on facts that
- require specific experience in a field — such as architectural design, for instance.
- It’s the team’s first encounter with the task.
In all these cases, the client’s first step is to explain the overall task and how all of the elements depend on one another. Only then can the team get to work on the specific points detailed in the ToR.
A brief is probably redundant if:
- The task comprises creating a group of identical elements. For instance, a character in a visual novel who is always depicted in the same pose. Keep in mind, however, that animations, emotions, or multiple poses would all call for a brief.
- The client has specific requirements for objects, and there are no important dependencies on elements that are beyond the scope of this specific task. For example, a group of weaponry with a single form factor — only pistols, rifles, or sniper rifles.
- When there’s just one specific element. Such as an architectural object for a 2D game with steps of development.
- When the work in question has already been carried out several times.
If you have already handled such tasks but still want to provide a general context, a few paragraphs at the beginning of the ToR would most likely suffice. There’s no need to write a separate brief for that.
What does a good brief contain?
When thinking about putting together a brief for an outsourcing team, you need to answer the following question, “How can we make a document that any studio would understand?”
-
Goal/Problem/Solution
This is an important part of any brief. It reveals the client’s chief motive behind reaching out to an outsourcing team.
Goals — the client’s primary interest. What do you want to achieve through working with an external studio? You may have multiple goals.
Problems — a willingness to discuss your difficulties, fears, and doubts creates an additional level of trust.
Solution — your thoughts and hypotheses about ways to attain your goals in collaboration with the outsourcing studio.
Not all developers are prepared to openly disclose their motives for seeking a third-party contractor. You can use conventional language to show where your interest lies.
For example, if you aim to relieve your in-house team of routine tasks, then it would suffice to say, “I’m seeking additional resources for tasks that have clear requirements.”
Examples of possible client goals:
- Employ additional resources to strengthen the current team.
- Select an outsourcing team for collaboration. Test whether a style is repeatable in production. Create a production chain.
- Fulfill an urgent order as fast as possible but to a lower quality standard.
- Scale a proven content production system based on a previously-made ToR.
Examples of possible client problems:
- Game assets need to be created in the absence of the project’s art director—the content has no clear requirements.
- The hourly rate is too expensive.
- The outsourcing team’s work doesn’t meet the requirements. The contractors don’t pay enough attention to the ToR. The process involved too many edits and excessive communication.
- Production time is constantly getting drawn out, so the costs are rising through no fault of the client.
Examples of potential client solutions:
- Hand over the current ToR to an outsourcing studio and check whether they can handle the task. Test the time spent on the task alongside the price and quality.
- Submit the preliminary ToR and check whether the team can pull off the requirements and fulfill the task.
- Use an outsourcing team to scale the content and provide a ToR and team lead for feedback.
This information provides a thorough understanding of what the client is concerned with, which paves the way for new solutions that the client didn’t have before. Aside from this, the team of contractors will understand your issues and won’t suggest solutions that would exacerbate them. This will make it a lot easier to ensure you’re on the same wavelength and equally immersed in the task.
-
Describing a block of tasks
This is a general description of what needs doing. Outline all of the elements that will later be detailed in specific ToRs. This stage is all about illustrating how the individual elements of the project interact with one another, as well as all the important details and unique features to accommodate when fulfilling the order.
Bear in mind from the get-go that the team will probably be seeing the task for the first time, so be sure to provide all the important context that they’ll need.
Example 1
“We need to develop a group of banners for our store. All of the images must have a single execution style — we’ve attached an example of the style we want. The banners should each have a different format, since they’ll be used on three different screens. The vertical banner should be different from the others—with a mask for an effect, whereas the other animations won’t have this. They’re to be executed as a single image of the given size.”
Example 2
“We need to develop a set of weaponry for a top-down shooter (Project A). The game has five types of weapons: melee, pistols, automatic rifles, submachine guns, and machine guns. The weapons have shared requirements and a cohesive style — follow the link for usage examples. They differ in terms of the number of materials used, polygons, and sizes. The machine guns have belts, which sets them apart from the other weapon types — they have a special animation. The weapons have different types of grips, follow the link for examples of how this is implemented in the project.”
These examples are heavily simplified, but the principle is clear. It’s vital to describe how everything works and how to properly understand the material. The brief doesn’t mention the sizes, formats, or quantity of polygons, but it outlines the usage specificities and the differences between the types, as well as highlighting the overarching factors that unite the elements in question.
The more generous the information provided in your brief, the higher the chances that the team of contractors will understand you clearly. Just be sure to avoid waffling — stick to the facts. Each sentence should convey a specific point.
