The Magical Short-Form Creative Brief

Something this simple shouldn’t have such wide-spread, long-term effects on the quality of a team’s work. Yet surprisingly, it does.

We first saw it with one of our clients. It was this weird ritual at the start of every meeting that discussed one of their designs.

One of the team members, always a different person, would read the exact same document out loud, word for word. The document, about three-quarters of a printed page, contained a tiny creative brief about the design they were working on. Reading it out loud was how they started every design meeting, whether it was a brainstorming meeting or a design review.

Typically, this little pledge-of-allegiance-like ritual took about two minutes to complete. Not much really. However, it completely changed the tenor of the meeting.

Making Sure Everyone Is Working on the Same Project

Like many teams, this team had several projects happening simultaneously. They created a different creative brief for each one. By reading a project’s specific brief at the beginning of the meeting, they made it clear to everyone in the room what they were about to discuss.

What happened after the reading was really interesting, too. The project’s leader would turn to the group and ask the same question, “Everyone agree that this is what we’re working on today?” Most of the time, everyone nodded in agreement. Occasionally, someone would ask what was meant by one of the phrases in the brief and there’d be a quick discussion clarifying some important detail.

In a couple of meetings, a discussion broke out about whether the details in the brief were still relevant. Since the last meeting, there had been changes in the direction of the overall project. The team took this opportunity to discuss how those changes might affect this specific part of the design. Sometimes that resulted in a rewriting of the brief. (On one occasion, the change was substantial enough that they postponed planned design review until the designers could incorporate the new direction into their work.)

Separating Where We’re Going From How We Get There

Talking about the creative brief at the start of the meeting has an interesting outcome we should’ve thought of before: It lets us separate our discussions of where we’re going with our design from what we build to get there.

Talking about the goals of the project is important. Often we only have these discussions during a project’s kickoff. Then we jump into the details of executing and never look back.

However, things change. New people come on board. The organization updates its offerings. Market opportunities and technology changes start to creep in. We hit constraints and challenges that make us rethink what we’re trying to do.

Dedicating a moment at the start of each meeting to discuss these changes and get everyone in the room to agree on the project’s current path is a brilliant move. It prevents a litany of time-wasting activities that happen when people are on different pages about what they’re building, who they are building it for, and why it makes the design better. Reading this short-form creative brief out loud short circuits those endless debates and lets the team focus on the problem at hand: does this design get us where we’re trying to go?

What’s in a Short-Form Creative Brief?

The trick to the brief was its brevity. We’ve seen creative briefs that weren’t brief at all—they were 200-page “thump books” (called that because of the thump they made when you dropped them on a table). These tomes, filled with every possible piece of thinking and research about the project, wouldn’t make sense to read out loud at every meeting. At best, they were read once and then long forgotten.

Instead, this team had honed their briefs down to four key components: the project objective, the key personas they were building for, the key scenarios those personas would try to use the design for, and the key design principles for this round of the project. Each of these were just a few sentences. It was simple to create and simple to read during the opening ceremony of each meeting.

Part 1: The Project Objective—This was 2-3 simple sentences about what this specific part of the project was trying to accomplish. For example, one team was working on a call center application for airline reservation agents that had a project to help with distressed passengers dealing with an unexpected flight change.

Objective: Build an automatic sidebar selector that appears when the passenger calls in. The application detects that the current itinerary needs a re-routing and provides the agent with the best new travel options to recommend to the passenger.

The idea is to keep the objective simple, so the brief doesn’t get into all the constraints and requirements. The team has all those things written down, just not in this document. They only included enough so everyone knew what this project was trying to do, relative to everything else they were trying to accomplish at the same time.

Part 2: The Key Personas—The team would list one or two personas they were designing this particular functionality for. They chose these from a larger set of personas they had created earlier. What they listed on the brief were the most important personas for this round of design. This helped eliminate discussions about personas and scenarios that they explicitly weren’t trying to deal with at this time.

Key Persona: Walter—a 17-year veteran of the reservations center, who primarily works with premium and global services customers. He is a walking encyclopedia of the reservation system arcana and often supports other employees on difficult problems.

Like any good persona description, the team would only include details that would play a role in key decisions they were facing. Their personas reflected real people they had researched themselves, so they intimately knew these people and what they were trying to accomplish. The personas often came up during the design discussions because they were fresh in everyone’s mind, having been just read out loud.

Part 3: The Key Scenarios—Here the team would describe up to three short scenarios that the design was trying to solve. Like the personas, they chose these from a larger set that had come out of their research. While everyone knows there are other important scenarios, the ones listed in the brief are what the team is now solving for and where the discussion should focus.

Key Scenario: Walter was called in special to help with a huge snowstorm that had cancelled many flights along the Eastern Corridor. The current call is from a passenger whose Philadelphia-to-Denver delayed flight (which hasn’t departed yet) will cause him to miss the only connecting flight to Seattle. This passenger needs a rerouting that will get him to Seattle today.

The scenario provides enough detail to make the design rich. By including a couple of these in the brief, the team can explore different angles of the problem that can help derive the design.

Part 4: The Key Principles—Like many teams, this one had come up with several guiding principles. In the brief, they listed one or two that they wanted to focus on for this iteration of the design. They would change it up as the design progressed, to ensure they were considering all the principles they thought were important.

Key Principle: Passenger Delight over System Efficiency-The design should provide a great passenger experience even if it incurs an expense or inefficiency in the flight system.

Like the personas and scenarios, the principles came out of the team’s research of where their customers were frustrated and how to bring out great experiences. They had a half dozen of these and would choose a new one for each design iteration.

A Simple, Yet Effective Ritual

We’ve been bringing this ritual to many of our clients and were shocked at how successful it’s been. Because it’s such a simple technique, everyone finds it easy to adapt into their current process. The elegance of the solution is what makes it work so well.

A short, concise brief about what we’re trying to do can focus our design discussions and keep our meetings productive. The end result is better designs that get regular, constructive feedback, without the baggage of dealing with the ever-so-common disconnects teams often experience.