Just-in-time Design

https://matthewstrom.com/writing/just-in-time-design/

Map the Scopes | Shape Up

https://basecamp.com/shapeup/3.3-chapter-12#organize-by-structure-not-by-person

@mattstrom has a good piece of writing that digs a bit deeper from a few years ago here: https://matthewstrom.com/writing/just-in-time-design/

Mine live alongside the rest of the teams, just with different labels, but it’s useful because they can get tagged as blocking etc. the design tickets, however, don’t get tracked in terms of team performance

I like having everything together so devs can see what I’m doing (and what’s potentially coming up for them)

Couldn’t tell you fully I just know speed between in progress - review  - done gets tracked by management to see performance of each team. Usually design tickets are split (I manage my own tickets) so it’ll be discovery and early concepts, including testing. Mark as done

Amazing, thank you for these recommendations @boren! Curious to hear why you’d recommend against doing design work ahead of time?

Good to know, thank you for sharing. You mentioned discovery and exploration tickets, what usually happens with those after you finish? Are they moved to a “done” column or placed in the backlog or ready to work areas?

I think the context here matters as well— if it’s the iterative update of the existing product, then yes, just in time design is perfect. But if it’s the very first version or a major update/overhaul, we have to design ahead of time to make sure everyone is on the same page.

If you think there’s a linear flow through the whole team, you might want to add design stages on the left side of a board, e.g. backlog → research → design → validation → ready for development → development → testing → staging → production.

I’m not entirely against doing design ahead of time, but I’d be mindful about the amount of work. The world around us changes all the time, and this means that the priorities on products also shift.

Ah very nice. Appreciate you sharing! Could you share more about the tracking part? And once you finish a design ticket, do you re-assign to anyone? A developer or PM? I’m struggling with what counts as “done” for a design ticket, as “done” usually means shipped.

We categorise buckets and add backlog items to relating additional needs and improvements. We usually smash a load of stuff at once that relate so we don’t bounce around too much.

FWIW we use a tool called linear which allows labelling, Kanban style columns, sub tickets and related blocking tickets. Everyone’s tickets live together, and design tickets are just for design, but have related tickets for dev that are ‘blocked’ by completing design tickets.

I’ve seen a lot of good arguments for working off the same backlog and having everything visualized there, if you are a cross functional team.

And then high fidelity would be another ticket, marked as done when it’s ready for dev. These tickets would typically be attached to an epic or parent ticket which has stories etc on

Totally agree with that take, I’m all for iteration.

Curious as a designer on a scrum team, do you have a separate backlog for design tickets? Or do they live in the overall “Backlog” bucket?

Totally understand there, thanks for sharing!!

Awesome, when you finish your design work, is there a separate or related ticket for developing your design? Or do you re-assign to a dev or PM?

Linear gives a ‘burn up’ chart so you can see velocity related to time (you have to be hot on estimating relative sizes of tickets) + keeping tickets as atomic as possible means you can zoom out and see how many in todo for both dev/design - great at getting a progress gut check.

A key benefit of a shared backlog and process is that it’s easy to see what’s going on, identify bottlenecks, work piling up etc.
 
Lastly, something to avoid is doing a ton of design upfront, filling the ready for development with items that *might* be built months from now.

I usually create an ‘epic’ ticket that lives in the backlog that’s purely a parent of all design tickets, so you can see progress. Once initial design ticket is done, dev can start. A lot of design finesse happens in browser so I work with devs iteratively.

In this kind of system, individual items that do not need design can of course skip stages and go directly to the (prioritized) ready for development column.

Releasing products — and design — in small continuous iterations reduces the risk of design ”going stale” or being outdated. As designers we can test things ahead of time with prototypes or wireframes, but I the true validation happens in production environment with real users.

Kinda depends on what comes out of the discovery/exploration efforts. It might turn into multiple dev projects. If it’s straightforward I’ll just reassign (though we’re not working true scrum fwiw)

Ohh, fantastic, thank you! I’ll give this a read 🤓

We were using scrum but experimenting with ShapeUp now so try and scope things end to end eg https://basecamp.com/shapeup/3.3-chapter-12#organize-by-structure-not-by-person and ‘done’ means deployed in prod.

Keeping tickets focused on a single thing helps comments stay clear. Finally we have sep tickets for release/comms/help docs etc so ‘released’ means everything has been completed. Can be stressful but I’m loving the process at the moment!

Very cool. Again, thanks for sharing, that’s helpful!

Posts