Today's #NaBloPoMo post is going to be less hands-on, and more philosophical. It's a reflection on yesterday's post:

🤔 Am I encouraging bad practices when I talk about a workshop to break down a design into user stories to enable engineering to start?

A few weeks ago I got into a small debate with someone online about this exact question. Their argument was something like “You make it sound like two teams pretending to be one team. Where the fully complete output of one team is the input to another. That is, a waterfall from design into engineering”. I hadn't meant to make it sound like that, but I had to admit it had some hallmarks of it.

Instead, the other person was advocating this:

  • Write user stories before design, and if they're big, break them up before you start any work
  • Do the quickest wireframe possible and work with the developers to implement it immediately
  • Get feedback from users with real working software as fast as possible
  • Gradually refine the design in code in subsequent iterations

And in that, they've described Lean UX pretty well. In fact I've worked like that in roughly half my roles. And yet the other half of my roles I feel that although we're not doing that, we're still doing fine. So I'm left with a puzzle: When does it make sense to work that way? Does it always make sense, but it's prevented by team cultures or habits that need to be broken first?

Was what I advocated bad?

It's bad if it's large

We're always working in batches of some kind. The question is the size. If you design a year's worth of work before passing it to engineers, then yes, you're doing waterfall. But if you design a day or a week's worth, I don't think you are. You're just a specialist - it's natural for a specialist to take ownership of something briefly and share the results later.

It's bad if you polish everything first

Delaying a breakdown until the design is completely polished is a bad idea, as I mentioned in my previous post (pattern 2).

It's bad if you don't collaborate

I've seen different modes of collaboration with engineering, characterised by how in-sync you are, from worst to best:

  • Non-existent: designers don't know who the engineers are, and once finished, the design is put in a queue for engineers to start it
  • Brief overlap: designers hand over a design to engineers when it's finished, but it's the first time engineers have seen it
  • Out-of-sync collaborative: designers and engineers are not focussed on the same projects at the same time, but they still involve each other throughout the lifecycle.
  • In-sync collaborative: Designers and engineers start and finish a project together. They're focussed on the same thing at the same time.

Breaking a design into stories can happen in any of those four collaboration modes. It doesn't by itself indicate which mode you're working in.

So what's the answer?

Does it always make sense to do Lean UX, start-and-finish together, and implement straight from wireframes?

That will have to come in another blog post, because I don't know the answer yet, and it's bedtime.