Every project is different, but Agile and XP have taught developers a stable and robust set of tools for managing work. What about managing design work? (With apologies to Tolstoy :)
[Development backlogs] are all happy; every [design backlog] is unhappy in its own way.
A designer colleague asks:
I’d love some insight into how other people use [Pivotal Tracker] / attach mocks and keep things updated as stories split and get added. I’d love to learn how to spend more time working on design rather than managing it.
There are many approaches to managing design and integrating design work with development work. I’ve seen projects where Design stories are comingled with development stories in a single backlog (both pointed and unpointed), a separate Design backlog, and an unpointed, kanban-esque (Trello) backlog. I’ve tried index cards, tried Basecamp, tried Excel, and tried just keeping a todo list. Different approaches tend to work better than others, mostly dependent on project type, project phase, and team constitution. How large is the team? How many people are focused on development? On design? On product or biz-dev? How many people switch between multiple roles?
There’s no silver bullet solution, but over time a handful of patterns have shown themselves to be useful. In this three-part series, we’ll examine the problems and principles behind managing design stories, a method for integrating design stories into an existing development backlog, and a method for maintaining a separate backlog for design.
What Problems Should We Try to Solve when Managing Design Work?
- design should not block development,
- design should know what to work on next,
- design can forecast when design decisions will be made,
- design might help drive out product vision,
A workflow that solves these problems enables design and development to iterate on product in a healthy think-make-check loop, and helps teams build awesome products that people love.
Principles for Managing Design Work
A few principles are important to keep in mind. We want to ensure that we’re doing the right amount of design, rather than unnecessarily generating expensive hi-res mockups which repeat documented design decisions. We want to remember that stories are placeholders for conversations. We want to respect the rhythms of design, and keep them in sync—not in lockstep—with the rhythms of product and development. At the start of a project, this often means:
- doing rough design (without a design system) to unblock development, and then
- iterating on product, and then
- building a design system as more is learned about the domain.
Some time before each Big Design Refactor, the design system will break and this cycle will repeat—which is to say, these steps are sufficient to cover all phases of design.
Given these problems and principles, I’ve found effective techniques for managing design stories within a development backlog, and another set of techniques for managing a separate design backlog. Stay tuned for Parts 2 and 3.