Stop it with the handoffs
In the last few emails I’ve been talking a lot about software development principles. But front-end development is fun because we also get to work very closely with designers. Many front end developers also have design responsibilities.
One of the debating points that comes up on social media time and again is How to do design with an agile software team. This is a question I’m often asked too.
If you look at responses to this debate, you’ll typically see discussions of experiences implementing staggered sprints (where design activities take place a sprint ahead of development) or of design sprints where a collaborative sprint focusing purely on design may lead a more prolonged development ‘phase’.
But for me, the trick to start answering this question is to listen very carefully to how it is asked. The phrasing is important. Compare these two different ways of asking it:
How should we design for an agile team?
vs
How should we do design work in an agile team?
In the first question, the way it is asked strongly suggests that design is being treated separately and there is an assumption that there will be some kind of handoff of design deliverables to the team.
In the second question, it’s implied that the design capability is embedded within the team, and possibly that design is more of a shared activity than a precious deliverable to hand off.
However you manage the mechanics of integrating design and development activities, you can’t iterate towards something that works for you if designers and developers are not collaborating regularly.
In their book Lean UX, Josh Seiden and Jeff Gothelf identify fifteen (!) principles. The last of these is Getting Out of the Deliverable Business. To quote directly:
Documents don’t solve customer problems - good products do. The team’s focus should be on learning which features have the biggest impact on their customers. The artifacts the team uses to gain that knowledge are irrelevant.
Recently, Josh Clark also wrote about how only one deliverable matters - the end product. Everything else along the way (wireframes, prototypes) is just a tool for getting there.
What design deliverables are you still working with? Do you really need them? Can you replace them with more collaboration and communication instead?
All the best,
– Jim
