Do the obvious thing first
In my last post I said, “I think we know what good looks like now.” I want to expand on that, because it comes with caveats.
Where research still pays
There is huge value in doing user research, most of the time, for example when you don’t yet know what problems you should be solving. But some things don’t need it.
Digitising government services
Some things are so obvious they just make sense. When I started in Barbados there was a basic government website, and each department had its own, in various states of readiness. There were over 1000 services. You don’t need a long discovery to work out which ones to digitise.
Once a service is online, usage data and research show you what to improve.
Shipping is cheap now
Building is now so cheap, with AI, that you can’t afford not to ship something. In Barbados in May, over dinner and from my phone, I asked Claude to build a prototype for a check-in system for health clinics, it started with a text from a stakeholder. It was good enough to give to a product manager to show to the people who asked for it the next day. Working software overnight. I think that’s the norm now. The check-in service went live in October.
Teams working like this get data more quickly. If you put it on the web, you get data about usage. If nobody is using it, you can ask questions like: is it because it’s not findable, because it’s hard to use, or because it doesn’t solve a problem?
Why it usually helps someone
In my experience, building something normally helps someone, somehow. Yes, it could be better, more refined, but getting it out helps. In a commercial organisation, that is normally some variant of how can we make this profitable? In government, the question is usually whether you can make it so simple that it gets out of the way. Nobody really wants to do government admin.
New teams still need to do research
Research matters most with a new team. It’s easy for me to say skip it when I’m working with an experienced team who know what good looks like. If you’ve never done this before, that’s a struggle. I learnt by doing user research, and every time I learnt something.
Delivery as discovery
But when shipping is cheap, the consequences are low and the team is experienced and has a clear vision, you can skip discovery and treat delivery as discovery. Some people call this test and learn.
When teams move faster, research has to move at the same pace. A long discovery at the start of every piece of work is too slow. Do the obvious thing first, then use usage data and research to improve it, at the appropriate time and in the appropriate amount.