Bring Back the Brief
During planning of new projects for the design team, we realized we had a gap. How would we define, track and measure a project? Which framework would we use to ensure design is contributing to the bottom line? To ensure we were making the right decisions and enabling the company to be more efficient? To ensure we were hitting our goals as a team and as an organization?
The one known aspect was that these projects would vary drastically. Some would require engineering (some not). Most would include implementing a process, as well as talking with internal and external stakeholders. One project might be creating a new set of sales collateral, while another could be creating an internal application to empower the customer service team to reduce churn.
For development tasks we knew we would follow a quasi-agile process. Since our design team includes engineering talent we preferred doing proper sprints with pointing and story writing. However, this didn’t solve the larger problem. How could we track all tasks on a project, not just development tasks? From a high level we needed a single source of truth for the following information:
- The Team: Who is working on the project? Who is in charge of the project? Who is the project for?
- The Problem: What problems are we solving? Where are the inefficiencies? Where are we failing users?
- The Model: What are our mental constraints? What drives the team forward?
- Benchmarks: What can we measure against? What are the expected outcomes? What are our stated goals?
- Revenue: Where are the opportunities for revenue generation? Revenue enablement?
Aside from these high-level concepts we also needed supporting documents to keep track of requirements and KPIs.
If we consider the design team as an agency functioning inside of the larger organization the answer becomes obvious as to where to store, track, and manage this plethora of information. We create a design brief.
I’ll be the first one to admit that design briefs feel old and dated. In the agency world they’re almost interchangeable with proposals—meaning, they become outdated quickly and no one really puts the time in to update them. So they die. In addition, briefs typically include irrelevant information to a team working internally. One would hope their team already knows the answers to questions typically found in a traditional brief (“who is the target market?”, “what does the competition look like?”, etc.).
What we needed was to reinvent the brief to fit our needs and that’s exactly what we did. By using the five key concepts from above (Team, Problem, Model, Benchmarks and Revenue) we started working with a preliminary brief that we’re hopeful will grow into an invaluable tool for completing projects, hitting goals, and measuring the success of the design team.