How to Write a Creative Brief That Doesn’t Handcuff Development

So what is the major difference between a poorly written creative brief and a well-written one? To understand what separates a good brief from a bad brief we must first explore the reason for having a creative brief in the first place. The only reason a creative brief exists is to create a shared understanding between two teams about what a project's roots, goals, success metrics, and future look like.

Yeti, along with the world's most creative teams, have built their entire creative processes on understanding the core problem statement driving a solution. But it doesn’t stop there. If we understand the problem, then we can create many solutions. If we understand who has the problem, we can create solutions relevant to those individuals, ultimately producing a better outcome. Furthermore, if we understand when a specific user encounters a problem, we can create a solution that helps them accomplish their goal (i.e. solve the problem) in an intuitive way by leveraging that additional information.

All of this stems from a shared understanding of the project's roots and goals between two partners. If we understand those core concepts, then we can contribute our expertise back into the conversation. While planning is essential to any relationship, so is adaptation. Without room for modification, a project can’t pivot when necessary to include fascinating new features that give technology personality or address hidden needs uncovered during development.

So whether a client sends me a brief or I draft one for my own uses, I can promise that all of my projects have one. Here’s why:

A Brief Investment for Better Development

You can also think of a creative brief as the set of rules that govern a board game. If the game's creator is the only one who knows the rules, the game is practically impossible to play. In both cases, both clarity and thoroughness are key. A creative brief tells all players the project’s core challenge, its priorities & goals, and the functional roles needed. I rarely get all of that information communicated verbally — even from multiple client conversations — but I can get all of those details and more in a well-written brief.

With a brief in hand, I can effectively communicate internally and provide accurate resource estimates for a project. A well-written brief can actually spark creativity, while a poorly written one can quash it. Briefs give creators a clear direction in which to focus their inventive energies. A creative brief forces all parties — developers, clients, vendors, designers, and more — to take a hard look at the project. With that many eyes analyzing the plan, there’s little chance of something being overlooked. And because it clarifies the project’s timelines and deliverables for everyone, there’s no better catalyst for a smooth working relationship than a creative brief.

Brief-Busting Blunders

While everyone starts with the best of intentions, a relationship can go south if both parties are not on the same page from the start. These common mistakes quickly turn the document into handcuffs that bind both parties in product prison:

• Drafting in a vacuum: As Flickr co-founder Caterina Fake once said, “No successful company has...ever been the product of just one person.” While you might be tempted to write your brief alone, remember that it will serve to guide employees of all roles, backgrounds, and skillsets. Make use of the external experts you hired and learn about their processes to determine reasonable expectations and responsibilities for each role involved.
• Including too many must-haves: It’s important to define key objectives, but including too many hard requirements is a surefire way to stretch timelines and balloon costs. As you write your brief, prescribe only the core experience, realizing other features can be added in subsequent iterations.
• Not planning for experiments and evolution: The most important lessons teams learn in the product development cycle is what not to do. This can sometimes seem like a failure but I can assure you that this is just as much of a success as a launch. If you wanted to find out something was going to fail, would you rather find out now or after launch?
• Not including a phase two budget: No product has ever been launched as perfect. I’ll go a step further, no product has ever launched and not had unexpected or unforeseen features requested from the community. It’s important to be able to react quickly to an evolving market, and the only way to do that is to have budget assigned for the unforeseen functionality.
• Lacking a specific target audience: The key word here is “specific.” Don’t assume you know who will buy your product or service. Be sure your brief calls for a prototype so that you can design with a core customer in mind. While your product could be used by anyone at any time, the prototype gives you peace of mind that you’ve found a solid product-market fit.

Plan for a Product Partner

Rather than building a brief that shackles, here’s how to write one that fosters cooperation:

1. Give the product team a say. Every team works differently, so whether you choose to complete a project in-house or with third-party product developers, be sure you bring the actual builders into the equation. Your brief should lay out workflows for how the team or teams will work together. For this very reason, we involve stakeholders from throughout the client’s company and our own team whenever we conduct design sprints. This makes it easy to solicit and share ideas relevant to everyone on the project. Who will be responsible for interface design decisions? Who will find and brief testers for the prototype? What mile markers call for formal meetings and decision-making?

2. Plan for compromise. Maybe you really want your VR product to be built for Oculus Rift, but you learn it could double development costs and create a hardware barrier for users. Would you consider building it for Google Cardboard instead? When we built Tiny Eye, a seek-and-find VR game, we weren’t committed to Cardboard at first. We quickly realized, however, that it lent a healthy mix of fun and budget-friendly accessibility to the app. Product development, by nature, contains unforeseen bumps and challenges. Realize that if the project is to succeed, you might have to change directions mid-course.

3. Give context to the concept. Don’t hold back when sharing inspiration for your project. The same video, article, or experience that influenced you could lend new creative muscle to other team members. When we worked on the “Gotta Go!” app with Chelsea Handler, Chelsea unloaded about some of the sticky situations her celebrity status put her in. Her stories formed the foundation for the whole project, and many of the goofy excuses we laughed about made it into the final product.

If a relationship is constrained by a laundry list of rules it is destined to fail, but so is one without any expectations at all. So when you’re ready to draft, don’t just roll the dice: call Yeti. Together, we’ll plan, develop, and design an amazing product ready for launch.