When I envision a backlog, I imagine some form of a list or Kanban board containing items (i.e. features, user stories, or bugs) that make up the work a development team will seek to accomplish. Each item houses information that helps developers know what they need to do and allows the team to track their progress toward that work. While it’s certainly no walk in the park to manage a backlog, there is a structured process to lean on and tools to aid that process. Managing design work, on the other hand, is typically less straightforward and not always done as a traditional design backlog.
Higher-level features are often described abstractly. Then designers do a great deal of work to define those features further and map out how people will use them. It’s not always worth the time and effort to detail and organize each feature into a list, as things will change through an iterative process. When you have a small team and limited design resources, keeping the work organized takes time away from getting it done. This often results in doing the bare minimum to stay organized, treating managing work as a means to an end rather than a structured part of the process.
Assess the challenge and the opportunity.
While this approach can work just fine, it’s not sustainable for a large, complex project with a bigger team. Say your project involves prioritizing and organizing 20 high-level features, but designers can only meaningfully work on a few at a time. It’s hard to keep track of present details alongside future priorities. In addition, staying aligned with a team of developers throughout this process gets even more tricky. It requires consistent communication and (a different kind of) documentation. A few months ago, a project team I’m on ran into a similar situation, so I proposed an experiment.
Essentially, we needed a better process to oversee our pipeline: what was design working on currently, and what should we turn to next? We didn’t need an over-the-top, do-everything project management platform. That creates more work up front, requires maintenance, and often serves few people.
We just needed a place to stay organized: document to-dos, track progress, prioritize next steps, etc. More importantly, we wanted to do this somewhere it would not create duplicate work for our developers. At the same time, we wanted to provide greater visibility for our client stakeholders to see our work.
Since our dev team and the client were already using Azure DevOps, we set up a design backlog that would run in concert with the development backlog, all under the client’s account. After a few months of running this experiment, our team has noticed a few positive outcomes:
- Design work has been more organized and defined.
- Collaboration with our development team has been more effective.
- Visibility for — and trust with — the client has increased.
Better organize our design efforts.
Setting up a separate backlog helped us as designers, which was the baseline goal. We needed a better process for managing a laundry list of to-dos that ranged in scale and complexity. Often, we found ourselves keeping track of our work in elaborate Miro boards, one-off spreadsheets, or through an array of sticky notes.
This wasn’t sustainable for us as a long-term planning solution, nor was it an effective way to collaborate with our team or engage with our client. We had to recreate something every time we planned, and that made it all too easy to forget our priorities. We needed one place to house planning information that would work well for the entire team, so we set up a new board in our client’s DevOps account, then ported over everything we had from other notes and documents.
As a result, our work has been more organized, better defined, and easier to prioritize (or re-prioritize). We’ve broken down big feature sets into different actionable design to-dos, either as a User Story or a Task. Within each work item, we add notes and feedback from the client, links to our Figma file, and other details that support both design and development. We also avoid having different lists of to-dos in separate documents, another design tool (i.e. Miro or Figma), or scattered across our desks in Post-it notes.With two designers on this project, it has helped both of us and other team members stay in sync with our progress and priorities.
Improve design-development collaboration.
Secondly, we wanted to improve design and development collaboration. We felt having a single tool to manage our collective efforts would help us get there. We noticed that planning our work with other tools made it more difficult to monitor as a large team, especially since we were working on a large volume of different features at the same time. It wasn’t easy for the rest of the team to know what design was working on, or what was coming down the pipeline. And when it’s not documented somewhere, it won’t be remembered. We needed to make our process more visible, and more effectively pass work over to our devs. Since the team was already working in DevOps, we figured we’d give it a shot.
Now, Features and User Stories get drafted in our design board, gain detail and context over time, then get moved to the development board when design work is ready for the team. This process keeps a continuity of knowledge and communication about work in the pipeline, leading to a greater collective understanding of the product we’re building. As work pushes through the pipeline and becomes more clearly defined, both design and dev better understand how complex something is.
Keep clients happy.
Lastly, we wanted to make planning and sharing updates a simpler process. We felt too much duplicate work was happening just to update our client or re-evaluate priorities together. Since there was such a huge list of things we could work on, we found ourselves constantly revisiting the potential work to do, either in Miro or in some document. Often, these artifacts weren’t easily sharable either – it required one of us to walk them through the information or give them access to a document (which created its own challenges). Similarly to our goal with the dev team, we wanted to make our work more visible to the client. At that point, DevOps just made good sense.
Keeping our work managed in one place across our entire team creates greater visibility for our client. And, over time, it builds greater trust between our team and theirs. Clients can easily access our board so they can quickly see our progress or go in to re-prioritize the work in our design backlog if they’d like to. At the end of the day, we’re using their tool. They own it, but we self-manage our work within their space. This has made reviewing our progress, planning the next steps, and sharing out updates much easier for everyone.
Make it work based on the project.
While several tools can manage work on cross-functional teams, they are often intended to serve one discipline more than another. It makes all the difference when a cross-functional team can leverage one tool collaboratively AND make it work for their client stakeholders. Although Azure DevOps isn’t necessarily meant for managing design work, it can. Stripped down to its core, it can be used as a Kanban board and a filterable list. What more do you really need? As long as the tool works for you, your team, and your client, it doesn’t matter much what its intended use is.