Maintaining team alignment with experience briefs
Ah, the creative brief. At once the bane of the creative’s tortured existence and a North Star to guide teams along the path to delivering something great. During my years running a small design studio, I used briefs to help plan projects, and keep clients honest during the design process. Once I started going in-house, my habit of doing design briefs floundered a bit—mostly because my old project briefs were, frankly, a bit heavy for the work I was doing.
A few years ago, I started noticing that my teams were suffering. Projects would go off the rails—approvals would take forever, we’d go through too many rounds of iteration and end up with a sub-par design before we ever got to development. Our designers were having trouble getting their teams and stakeholders on board with the work they were trying to do, and designs were compromised as a result. I needed a way to help us bring focus and clarity back to the work so we could move design through more effectively.
Enter the magical short-form creative brief, made famous by Jared Spool on the UIE blog. Comprised of a few short sections and no more than a page or two long, the brief helps center teams around a concise, brief vision for what they’re trying to create. The basic structure has been adapted over the years, but the main sections include:
- Design problem: a 2-3 paragraph description of the problem we’re trying to solve, and why it’s important to the business.
- Considerations/Constraints: a quick synopsis of any dependencies, business constraints, etc. we should pay attention to during the process.
- Goals: a set of clearly defined business goals for this design (if they’re measurable, even better);
- Key Personas: 1-2 personas (see “Pre-Work” below) that are most relevant to the functionality we’re creating;
- Key Scenarios: 3-5 job stories applicable to the project;
- Key Principles: 1-3 design principles (see “Pre-Work” below) that are most applicable to this project.
- Milestones and Deliverables (optional): for larger projects, this section can be used to indicate the general scope of work, and key milestones along the way.
- Supporting Information: any information that isn’t covered by the above sections. In practice, this may include meeting notes, findings from user research sessions, or links to various competitive analysis.
Working through the brief: the project kickoff interview
Done well, a solid brief is no more than a page and a half of printed text, and can be completed within the course of a 1-hour project kickoff. The key to doing it well is that it’s done alongside stakeholders and the team, preferably during the kickoff meeting. I like to treat the brief as a structured questionnaire, where my role is to listen, facilitate conversation, and reframe what I heard as the text of the brief, which I write in front of the team.
Doing it this way requires a certain amount of thinking on your feet, but the benefit is twofold. First, it creates transparency within the team, and shows that you’re listening. Second, it prevents anyone from arguing that doing a brief “slows down the process,” since it’s happening during a meeting that you’d be having anyway.
Pre-Work to speed up the process
In order to realize the true time-saving power of the short-form creative brief, it helps to have a couple of things squared away up front. Having a set of clear personas and design principles for your product gives you the opportunity to speed up these sections of the brief; instead of “guessing” which personas or principles apply to this project, you can revisit the whole set with your team, and decide which ones to include.
A solid set of personas (which I like to think of as characters, to borrow Indi Young’s term) not only helps speed up the brief-writing process, it helps align the team on a common set of users. Conduct a Character Sheet Workshop with your team to map out the different types of people your product serves. When creating personas, think not just about demographics and user roles, but the person’s context within your problem space.
If your product or team doesn’t have a clear set of design principles, now is the time to create them. While it’s common for teams to come up with abstract design principles, such as “Clean” or “Intuitive,” I have found in practice that design principles work best as directives from our users to the team. “Make it easy to figure out what I have to do next” is more powerful/useful than “Intuitive,” particularly in an enterprise context.
Create a template
As your team continues to create briefs for projects, it becomes much easier to create a template that you can grab and start filling out on the fly. Here’s one of mine that you can use.
When it comes down to it, being a good designer requires much more than pushing pixels or learning the next interesting prototyping tool. You have to help your teams prioritize, reframe their problems, and stay aligned through the messy, thrilling process of creating something new. This makes the creative brief a small but incredibly powerful tool in your design arsenal.