Weeknote, w/c 3 March 2025

When asked what my job is, I typically say that my main responsibility is making it possible for the team to do good work. Management, coaching, operations, and funding are all obvious elements of that. Strategic design work that sets up future projects is essential. Working with other teams to develop relationships and keep track of where the organisation is going is another big part. One thing I’ve not been in the habit of thinking about lately is how to justify some of our basic working practices because much of that is taken for granted as being important and good, but sometimes this is necessary. Thus we arrive at the question of the week: do we really need to do “discovery”?

There are a few reasons why someone might ask this question. They might not know what the term means. They might not understand that this is not a one-size-fits-all process. Or they might simply think they know the answer to a given problem and can’t figure out why these designery types don’t just get on with it and build something. Many people have written on this subject already, so I don’t think it is worth me writing a complete guide. Instead I want to log, for my own sanity and for future reference, the shortest possible guide to what a discovery is and why you do it. Here it is:

• Discovery is research to understand the nature of a problem
• Discovery will help teams understand why a problem is occuring
• The output of discovery is an understanding of whether the problem is worth solving and evidence of the outcomes you need to create
• It does not need to be a separate phase of work from design and delivery
• It is a mistake to think this is the domain of user researchers exclusively
• The practice reduces the chance of solving the wrong problem
• The practice increases the chance of delivering a valuable product or service
• Assumptions are a valid starting point but untested assumptions lead to ruin
• Most problems are more complex than people realise
• Sometimes people don’t realise that they haven’t realised this

There.

Reducing the risk that we deliver the wrong thing is one of the primary benefits of taking a user-centred approach, but the mechanisms used to accomplish that can be opaque. Specialised jargon certainly doesn’t help, but I think most people would agree that we should try to be efficient and spend time on the most important problems. The trouble then is in the last two bullet points. This is where my job becomes important – helping people in a position of power understand that the space we are working in is complex, that they will not necessarily always have the correct answer, and that if we build the wrong thing we will waste time (read: money) and potentially make the situation worse. So I need to revise what I think my job is.

Outside of work, I spent most of the first nice weekend day of the year watching The Memory of Justice by Marcel Ophüls, a four-and-a-half-hour kaleidoscopic documentary on the intersection of the Nuremberg trials and the Vietnam War. Truly magical. I normally kind of hate it when there is a long introduction to a film, but Phillipe Sands’ mini-lecture ahead of the screening was so good that my partner immediately went and ordered one of his books. I could have sat through a full hour of just his introduction.

On the internet this week I read:

• The door problem. On game design and alignment, by Liz England. I often think that one of the hardest parts of any job that involves getting people to work together is making sure that everyone involved has the same understanding of what you’re talking about. Misalignment here is one of the best ways to end up with wasted effort.
• Designing is imagining. A former tutor of mine used to say that design was an act of science fiction, which is to say it is a way to draw an imagined future into the present and make it more real. This article by Kuba Bartwicki adds an extra dimension onto that idea: “time lenses” as a tool for considering future direction at different degrees of distance from now.
• Why nothing works. Jennifer Pahlka on unintended consequences in the public sector. There is a curious division in thought that I wasn’t aware of that feels relevant to my current life: the different approaches to how government authority should work, as represented by Alexander Hamilton (“centralised authority and expert-led bureaucracy”) and Thomas Jefferson (“individual freedom and decentralisation”). That difference could sum up a lot of the tension in how to run the NHS.
• “It feels chaotic on purpose”. I don’t like the Atlantic, but this article by Matteo Wong is a useful narrative of what happened to 18F.
• Falsehoods programmers believe. I’ve referred to “falsehoods programmers believe about names” by Patrick McKenzie probably a dozen times in the last year (thank you MM!), and it turns out there about 300 other versions of this idea.
• The schedule for Services Week is now live. I’ll be doing a lightning talk on the subject of secondary care and the NHS App with a few colleagues. Ours will be a story about how to design services for a thing that people believe to be unified but which is very much not, at all, unified.