Every project is different, but Agile and XP have taught developers a stable and robust set of tools for managing (development) 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?
Ideally,
- 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.
aka,
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.
When should I Integrate Design with a Development Backlog?
An integrated design backlog is appropriate for small- to medium-sized projects (i.e. teams which can be fed with two or fewer pizzas), focused on a single platform. It can accommodate teams which have designers that code, as well as designers who don’t.
Pros and Cons of an integrated backlog
- PRO: simple, easier to see prioritization
- CON: no design velocity
When should I use a Separate Design Backlog
In the past separate design backlogs have been prohibitively difficult to integrate into an agile team’s workflow, primarily because tracking dependencies across backlogs was too difficult. The game changed when Pivotal Tracker launched its new Mult-Project Workspace View. Now that it’s feasible, a separate Design Backlog is appropriate when you have multiple platforms (e.g. iOS and Android) with design concerns which are independent of platform, or when it’s important to estimate design work without affecting development velocity.
Pros and Cons of a separate design backlog
- PRO: more focused backlogs, handles larger projects, measuring design velocity
- CON: tracking dependencies between design and development stories becomes difficult
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.
UPDATE: part 2, How To Integrate Design Stories in a Development Backlog, is now live!
UPDATE: part 3, How To Maintain Separate Design and Development Backlogs, is now live!
