Prioritising between agile, product, and user centred design approaches

A venn diagram showing overlapping circles titled agile, product and ucd

A lot of what I have written about here has been about pragmatic approaches to digital and technology driven work. Taking the best practice methods we see in evidence at the Government Digital Service and other internet age organisations, and thinking how they might work within the constraints of smaller teams and budgets, like those we find in many local authorities.

So in that spirit, here’s something I have been thinking about in the last couple of weeks: whether we can prioritise between agile, product and user centred design (UCD) in the work we do – when we need to.

These three approaches to work are almost synonoums with digital age service design:

  • agile – gettign working products into people’s hands as quickly as possible, and iterating on the feedback
  • product – thinking of the things we make as digital products that require constant development and improvement, with a relentless focus on quality and meeting user needs
  • UCD – ensuring that we truly understand our users and their needs with our products and services, considering the outcomes they want to achieve, their expectations, frustrations and so on, and prioritisng these over what might traditionally be referred to as ‘business requirements’

As per the venn diagram illustrating this post, these three things overlap, and they also dovetail in with each other really well. The very best digital products and services combine all of these things to produce amazing results.

However that often relies on having the people and the time, and the budget, to be able to do all these things at once, and that isn’t always possible. It’s a bit like the post I published a while back, looking at which roles can be combined to produce a minimum viable digital delivery team.

Sometimes I think it is necessary to see that some pieces of work benefit from one of these approaches more then the others, in which case you can tailor the approach and therefore your team, to focus on that.

For example, say a department in a council puts a request in to the technology team to digitise a currently manual internal process. It’s a bit of a no-brainer – a process that needs to be carried out, it’s currently happening several times a day, but at great inconvenience to all those that use and administer it.

Now, in an ideal world, we could run a discovery, perhaps look at a true end-to-end service design and maybe remove the need to do this entirely. Or fully understand user needs across the board. Perhaps we could assess the market to see if there are any off the shelf tech capabilities that would do this for us.

All those would be great to do. But maybe this is also the fifth request you’ve had this week, all of which were equally good and difficult to turn down. You really don’t want to say no, but equally you can’t justify spending the time doing all that work on it.

So, instead, you could just acknowledge the need to compromise, and decide to focus on the agile side of things. In a case like this it could work really well – quickly build the thing needed to digitise the process using some technology you have lying around (increasingly I am finding the Microsoft 365 suite of tools very handy for this kind of internal stuff), get people using it and then iterate on the feedback.

In this case, absolutely yes, doing a full discovery with a user centred approach, and having a product manager to write your user stories and prioritise which ones ought to be built with an eye for the future, would improve the work and probably produce a better result. But sometimes something is better than nothing, and if you can focus on the agile side of producing a working thing and are able to commit to iterating it based on feedback, it might just be worth the compromise.

The same can be true of other projects: sometimes the most important thing you can do – perhaps if the outcomes are really unclear – is to focus on the UCD side of things. On others, perhaps there’s a thing that already exists, has been left to rot for a while and is crying out for someone to just manage it like a product to set it right again.

There will often be projects when one or other of these approaches might not add a huge amount of value. A classic example might be when the ability to product manage a project is limited by the use of someone else’s product. Yes, product management could benefit in these cases, but those people could probably create more value elsewhere.

Finally, this isn’t to say you abandon whichever practices you decide not to focus on entirely. A good digital culture in your team will mean that the principles of agile, product and UCD will be well known to everyone, so they won’t forget about the importance of each one, even if they aren’t dedicated to those kinds of roles and approaches.

It’s just another of those compromises that sometimes need to be made, especially within small teams.