Thanks to Amy Hupe, I learned that there's such a thing as National Blog Posting Month (#NaBloPoMo for short), and it starts today. So here we go with post number 1.

Yesterday I needed to help a team break down a design to get it ready for development. I enjoy this because it's quite high leverage work, can open interesting debates, and although I find it challenging, I feel confident leading it. There are certain patterns that help it go smoothly. And once it's done and the panic of 'oh gosh… where do we start?' has lifted, you can all feel really good and get cracking.

So how does it tend to go, and what are those patterns that help me do it?

Screenshot of a design with stickies around it in Figma

The Figma file from my last breakdown with stickies all around it. Blue are outcomes (potential releases) and yellow are stories.

Pattern 1: Be clear on the outcome and opportunity

To start with, I hope everyone on the team already knows the product outcome you're striving for, and what specific opportunity this design aims to tackle.

Pattern 2: Do this at the right moment

Do this with a design that's at the right level of 'done' - enough to have a clear idea what needs to be built, but not so complete that you've wasted time on details that might get de-scoped, or wouldn't affect the estimation and sequencing.

Pattern 3: Be clear on the end-to-end journey

Now you'll need to present the designs and help everyone understand the proposal. The absolute best way to do this is as a walkthrough with a realistic scenario. Don't just point out features in the design randomly. Help the team imagine they were a real user with a real goal and walk them through how the design will achieve it. But you need to start before and finish after. In other words, what would the user be doing that triggers them to enter this workflow? And once it's complete what will happen next?

Pattern 4: Work at the right fidelity

Now, designs are great but you need something else to start exploring the slicing and sequencing with. You need to confront all the work at once, without getting distracted with too much detail. And the best thing for that is stickies. You can place them spatially to represent relatedness, priority, sequence, etc. And it's easy to add / edit / remove them. You can also do it with bullet points in a Google Doc, but you lose the two-dimensional freedom.

And on the stickies you just capture the principle things that need to be built (ideally user-facing value, but sometimes there are technical things too). You can call these user stories, and if you lay them out horizontally in a journey, you can call this user story mapping.

Pattern 5: Accept the CoWs

Now here you might raise a few objections:

  • why are we writing user stories after the design was already done?
  • why are we writing stories that represent things to build rather than genuine user needs?

And I hope you'll believe me when I tell you I'm not some maniac who does everything backwards. Before and during the design I'll be working with another set of user needs, that I might call Jobs to be Done or Use Cases, which came out of research. They'll be as close to pure user needs as possible. But once the design is ready for development, you need another set of artifacts that are the right shape and size for development (i.e. follow the INVEST acronym). And I think it's fine if these are CoWs (chunks of work).

Now that you completely trust me again, I hope, let's move on.

Pattern 6: Carpaccio

Slice thinly. Developers are really great at story splitting to find ways to break multi-day/week stories into smaller and smaller pieces of value. Don't get disheartened that your grand vision is being chopped to death. We're just talking about the order to build things in, which should be a balance between highest value first, and bringing forward technical risks early. We're not throwing away all the good stuff of your design.

Pattern 7: Identify releases with outcomes

Now it's time to group the stories into releases. Do some stories build on top of others? What the minimum set of stories that gets an end-to-end slice into users' hands as quickly as possible?

Make sure each release has a meaningful outcome - i.e. it's not just a feature name, it should unlock some genuine value.

You don't need to sequence all the work. Often it's enough to define the first one or two releases and come back to sequence the rest later.

Pattern 8: Design for interim releases

Sometimes the slicing strategy presents new design challenges: how should this section look when it's missing this thing? Maybe you need a temporary layout change so that things don't look odd, or to rethink how something works or is labelled when it doesn't support all the use cases yet.

Pattern 9: Be prepared to trim the tail

OK, I admit there is a risk you won't get everything you wanted. It's common — responsible behaviour in fact — to trim the tail of a project, and move on to something else when it's 80% complete. So long as you put the most valuable 80% first. This can happen intentionally when the team feels they've delivered most of the value. Or unintentionally when a surprise new priority comes along. Then you'll be thankful that you worked in small slices, releasing value as you went, rather than wrapped it up in a big batch that never got finished.

Pattern 10: Check in against your appetite

If it helps, do some quick estimation. Now's a good time to make sure everyone's on the same page about the effort. If one person thinks a particular story or outcome is high effort, and another assumed it was small, you'll run into trouble agreeing a sequence until that information is flushed out.

Pattern 11: Allow enough time

This kind of work is hard, and a little time consuming. My last session was nearly 2 hours long. But once we'd done it, the designer had clear focus on what needed design polish, and two developers had very clearly scoped tasks to get cracking with that would keep them busy for the next 2-3 weeks.

See you tomorrow for another topic.