May 31 2019

Having a design backlog

Spoiler: no answers to be found here.

When we’re working on a product feature, it’s healthy to have involvement from the whole team. From ideation, prototyping and research through to build, features are stronger from having the whole team input throughout.

But there’s another aspect to the design of a product, and that’s having the holistic view. Keeping the product as a whole consistent. Spotting patterns and utilising them across journeys.

I’d argue that sometimes this aspect of design work can be done well in a garret. A lot of it involves comparing interaction design across journeys, that sort of thing.

In our workflow, finding a structured way to get that view amongst roadmapped delivery can be a bit tricky.

Our main product backlog has a “to be refined” column, where items are popped in as they crop up — “fix this”, “look at that” and so on. The trouble with this column is that it’s a mishmash of notes that, (funnily enough) need to be refined. These notes come from all disciplines, and so frankly it’s hard to keep a handle on.

Enter the design backlog (quietly, with an absolute minimum of fuss).

Trello board showing our design backlog

In a bid to work a bit smarter, I’ve made a little Trello board, which contains things that fall into the “holistic” category. For example:

  • tweaking specific interface elements
  • reviewing chunked pieces of content (think “boilerplate” explanations of terms and so on)
  • reviewing journeys to spot interaction patterns
  • dealing with patterns that sit across journeys (for example how we represent opening times)

Example ticket showing a review of forms in prototypes

What this board doesn’t contain is tasks that are part of delivering features from our roadmap. See above about whole team stuff. The structure of this weeknote is crap isn’t it?

The purpose of the design backlog is twofold:

  • tickets from this backlog should be refined to the point where they can dropped back into the main product workflow very easily
  • the backlog itself is another node in our “web” of design documentation

It’s about having a way of stepping back, reviewing, selecting ways to change, then feeding that back into the main workflow.

Importantly, it’s not about going off and doing lots of design work away from the team. It’s about doing just enough. In an ideal world, a well-refined task can go into the main backlog and be picked up very quickly.

Obviously it’s far from an ideal world, so we’ll see how this pans out as an approach.