Kickoff: Yes. Design Brief: No.
Every so often, someone in an organization gets the idea that what the design team needs to be successful is a brief. On the surface it makes sense: everything designers need to know upfront, so they can hit the ground running. But the reality is a brief can set a designer up for failure and can reinforce organizational silos.
Taking a step back, I should talk a bit about how my team is set up because all of these recommendations stem from that organizational configuration. We operate as a Centralized Partnership, meaning we have a single design team with members spread across several cross-functional teams. There’s a balance to strike between the Design Team and Cross-functional teams, with value added because the two act as a check on the other as projects progress.
Even in its best incarnation, a design brief sends the signal that a designer’s role is to execute someone else’s vision, instead of collaborating on a visual strategy. The later a designer is added to a project, the more an organization is reinforcing the old Agency model–where the organization essentially becomes a client for the design team. The problem with this setup is that the two treat each other accordingly.
By contrast, we want designers to be engaged at the very beginning of a project, working alongside Product Managers to devise strategies. The more of a voice Design has at this stage, the better chance we have at solving a problem elegantly and efficiently.
What We Do Instead
Description Template
Instead of a brief, we create two documents that work together to define the work that needs to be done. The first of those is the EPIC description template–for us, it lives on an EPIC Trello card but can transfer to any kanban-style of management.
In general, our template makes sure the most important information is ready for a designer at the start of a project. In a lot of ways, it’s a way of making sure that everyone else has their ducks in a row before trying to pull a designer into a purposeless project. Sections include:
- User story
- Links
- Timing
- Success Metric
- Other Guidelines
Here is the actual template, which you’re free to use. It uses markdown, so it will automatically format properly in Trello.
User Story
==========
As _____________, I would like to ______________ so that I can _______________. (user stories go here)
Links
-------
[Link](#)
Timing
-------
Does this project have a target launch date?
What blockers do we have to get started?
Success Metric
-------
Other Guidelines
-------UX Strategy Doc
The second and arguably much more important piece is the UX Strategy Blueprint, which is generally completed by the UX Lead.
We use a UX Strategy Blueprint to help guide our UX strategy for each project. Our strategy should identify the challenges at hand, and then clearly map out how we will work towards the outcome we need.
Having a solid strategy document helps us drive the direction of the project. It gives us a place to point towards if someone starts to prioritize an idea that runs counter to our original strategy. That doesn’t mean that we can’t ever shift direction, but it does mean that we want to be very measured when we do.
Our actual doc comes directly from Jim Kalbach’s excellent article. I won’t go into the details of how to use the doc, because he says it better than I could.
However, one thing I want to stress is that the one thing the Blueprint does beyond help plan is to establish the expert on the project. Whereas a brief puts the role of project expert on the person filling out the brief, the UX Strategy Doc establishes that the team’s UX Lead is in charge of how design work should be handled. For us, that has made all the difference in which projects are successful and which are not.