Redesign along strata, not down boreholes

Picture this: you’re working on an early-stage product. Perhaps it’s about a year old. You’ve iterated it to the point where it’s starting to prove its value to potential customers and users. Things are looking promising.

But you’ve already picked up a chunk of product and design debt. Specifically, based on what you’ve learned through explicit feedback from customers and through usability sessions, you’ve identified some fundamental design changes that you think will make a big difference.

This is to be expected. After all, if you’re iterating based on user and customer feedback, challenging assumptions and discovering how wrong you are about what users need, it’s highly likely that initial product design is off the mark too. It may need some fundamental re-structuring.

This can be a dangerous situation. The temptation is to bite the bullet and take on redesign work in one chunk. Sometimes the designer(s) will volunteer to take this on themselves. Sometimes the whole team will commit to pausing feature development to do the work together.

Both of these approaches have a track record of dragging on for far longer than anyone expected, putting other milestones at risk.

Even teams that use a lean, hypothesis-driven approach to product development can find themselves abandoning it in favour of a mini-waterfall project when it comes to sweeping redesign work. Why?

I believe it’s because we think of redesign work in much the same way as large-scale refactoring work. It’s seen as an internal project. We’ve already built all this functionality. All we’re doing is re-purposing it in some way. So the same agile and lean approaches don’t really apply, do they?

But of course they do. If we’re taking on redesign efforts for the direct benefit of users, we can and should be measuring the impact of what we’re doing, in small batches, using feedback to guide us.

After all, right at the top I said “you’ve identified some fundamental design changes that you think will make a big difference (to users)” (with added emphasis and clarification).

Those design changes are assumptions. They can be translated to hypotheses and measures. They are bets and increments just like any other piece of work. So they should be treated the same. That means working cross-functionally and not just letting a designer or two create a long-lived redesign branch with a big bang release (and associated merge nightmare).

One thing I’ve seen really help with planning meaningful release increments for both new feature development and redesign work is story mapping.

Jeff Patton coined the term. It’s pretty simple and anyone can grasp the basic idea almost immediately. Here’s an example story map for an email and calendar client from Agile Adoption Roadmap:

User story cards are arranged horizontally by user journey, with a ‘backbone’ of stories representing the core value of the product. Additional ‘value-add’ stories are prioritised under the backbone.

This story map also shows a single ‘increment’. The intention is to identify the smallest possible releasable slice that adds meaningful user value across the user journey. In lean terms, this can be thought of as comparable to a Minimum Viable Product - the smallest possible increment that will provide actionable learning.

For planning redesign work that’s intended to improve user experience, it’s far better to plan a series of horizontal increments that you think will impact some behavioural measure, than it is to ship new buttons, or go screen-by-screen.

By slicing the work in user-journey increments, you’ll have a much more direct measure of the impact the redesign work has made, and be able to make course corrections along the way accordingly.

All the best,

– Jim