Poorly written creative briefs are the handcuffs that prevent even the best teams in the world from doing good work; A well-written one however, can help the best teams produce amazing products.
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:
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.
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:
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.
At our last Django Meetup Group event, Jayden Windle, the lead engineer at Jetpack, an on demand delivery company, talks building APIs with Django and GraphQL. Watch the video to learn more.
At the last meeting of the San Francisco Django Meetup Group, Wes Kendall gave a talk on how to make a bulletproof Django application by testing it with pytest. Check out his talk here!
Part of the Yeti Lunch and Learn series - our amazing developer, Resdan, gives a presentation on creating a reusable component library. Enjoy the video!