Good UX design is essential for digital products to win, most of the time. But often teams don’t know how to work with their designers effectively, to get the competitive edge they expected from Design.
Design activities can feel alien to engineering teams and designers can feel isolated, since they’re often in a minority. Designers with limited experience can struggle to influence team practice, or take the lead at the key moments when they should.
I did this talk with Dean Broadley to offer some viewpoints and practical ideas about how agile teams can use design and designers more effectively.
A few highlights of what we covered…
1. A case study of an organisation here in South Africa called Healthforce. They have used human-centred design to create a successful telemedicine and record-keeping product for clinics in pharmacies. A classic B2B issue: the nurses who use it every day are not the paying customers. Often this type of situation leads teams to focus on building what will impress the buying decision makers, rather than what will help the people who actually use the system. Healthforce has managed to make it clear to everyone, from their own development and management teams all the way through to the buyers, that adoption and use by nurses is key for ROI. They’ve used design to focus on that and it’s been a winning strategy.
2. Symptoms that you have a design problem. This slide got some positive feedback…
I think product teams live with these issues every day, to the point where some don’t even notice them any more. But from my perspective, (UX) Design has a major role to play in making them go away.
3. If you have too few designers, you’ll get very little benefit from them. Lining up and colouring in your UI doesn’t solve the problems above. But one junior designer will only have time to do that, and is unlikely to know how to extend the conversation in the team to anything bigger. As Dean said, imagine you’re a junior developer and you sit in a room full of lawyers, who are discussing complex legal issues all day. You’ll be battling to get them to understand the value of your software, or the importance of many key development activities you know you have to perform. You’ll have no-one to review your work or sound out ideas with. It’s not going to end well.
As John Cutler points out having too few designers actually messes up team workflow to such an extent that it’s counterproductive.
4. Design for agile means continuous discovery and delivery. And that requires conscious change. There are some good recipes for it out there. Our suggestions included:
- Draw up and agree a new process with the whole team.
- Make discovery an explicit thing with its own docs and tickets.
- Have a discovery workshop for each relevant epic.
- Have a discovery kanban board/experiment board, because your discovery tickets won’t behave like your delivery tickets.
- Have a discovery room (if you’re feeling deluxe) where the whole team can go for immersive discovery activities
- Keep each epic ticket in a special, visible location and annotate it with with links to the dashboards you’re using to measure their success.
- Declare and celebrate “business impacts”, not shipped code. Make sure teams get a round of applause when the metics show the positive growth in revenue-generating activity that they aspired to. Making these declarations into a big deal, means people won’t forget to measure continuously too.
We also touched on purpose and vision, edge effects, how to argue, the value of making artefacts and waste. Here are the slides. Enjoy.