Mike Gallagher

My friend Mo is big on theory. Design theory, product management theory, organisational theory – you name it. He loves a framework that helps explain a working situation. He introduced me to Lean UX sometime around 2015, then to the theory of constraints, and onward to a handful of others I’ve half-forgotten. One concept he told me about – probably over a mixed grill somewhere on the Kingsland Road – was the garbage can model. The model describes a theory of decision-making in complex, unaligned organisations using the unglamorous image of a bin into which problems, solutions, and participants get thrown independently, mixing chaotically until a decision happens by collision rather than intention. I come back to it every so often, partly because the name is so good, and partly because it explains so much about where I work. It isn’t a perfect fit for the NHS, but it is instructive.

The Federated Data Platform (FDP) has been in the news a lot lately. Tito Castillo recently wrote an excellent article about it, and while there is a lot to say about supplier selection and national standards, the thing that really jumped out at me wasn’t the FDP story itself, but rather his use of the garbage can model as a framing device and what it reveals about the experience of being a designer in a large public institution. His description of the model:

In a loosely ordered system, the streams move independently. Problems exist without solutions. Solutions circulate looking for problems to attach to. People move in and out of decision-making arenas. And moments of decision arise on their own schedule, driven by budgets, deadlines, or political events.

A decision happens when these streams converge. A funding window opens at the same time that a vendor is promoting a platform, stakeholders are available to approve it, and a recognised problem can be linked to the proposal. The resulting decision is real, but its coherence is coincidental rather than planned. Everyone involved may have acted reasonably within their own context. The system as a whole produces an outcome that nobody quite intended.

If you are a designer, trained to define problems before solutions get explored, the situation described above looks like madness. In a garbage can system, solutions are already circulating before problems are properly defined, and the moments when decisions get made often happen too quickly or too indirectly for careful problem framing to intervene. You can do all the right things – research, analysis, a well crafted problem statement – and still watch a decision get made without fully accounting for accumulated evidence.

The drive to define a problem that teams can work toward solving becomes a never-ending, snake-eating-its-own-tail battle against all of the other streams that aren’t oriented that way. The very nature of the system makes this true. Without reorganising everything, it is hard to see how that changes. Castillo provides a description of how this plays out in practice in the health system (not just with the FDP):

National bodies set direction, but delivery depends on local adoption. Suppliers shape the architecture through product design choices that may not reflect national intent. People move in and out of specific decisions, contributing views that make sense locally but do not add up to a coherent whole.

It is hard not to see this as a form of organised anarchy – a contradiction in terms and another foundational element of the garbage can model. From wikipedia:

Organised anarchies can be characterised by a sense of chaos and dynamism. Problems and solutions are loosely coupled. Proposed solutions change during bargaining. All participants involved do not get the chance to fully participate, and have limitations on their time and energy. Many things happen at once, all competing with each other for attention. Amongst the confusion, participants try to make sense of their role in the organisation.

In a garbage can system, decisions get shaped by whomever happened to be present. Part of the job in this environment is being in the right rooms at the right moments. Not because you’re playing politics, but because if design methods and mindsets are present when the streams collide, the outcome will (hopefully) reflect that. If the lenses brought to bear on a particular problem reflect technology and suppliers and policy, but not users, you have a problem. So showing up and staying in the conversation is itself a design activity.

The NHS is changing. It is always changing. I’ve been here for three and a half years and this is my second org-wide merger. Lots of people are leaving, and with good reason. I wish them all well, and I’m sad many of them are going, but I didn’t take voluntary redundancy and I hope to stay on to try to see some of our work through. Part of that is straightforward: this is the most meaningful work I can put my time into. Part of why I want to stay is probably less flattering: when the streams align and something actually lands, the feeling is disproportionate to the outcome, and I suspect intermittent reinforcement is part of what keeps me pressing the lever, like a pigeon whose brain has been moulded through operant conditioning.

Within the App programme, I have influence over what we work on and how we do it. I contribute to shaping our priorities and the approach taken to the work. What’s harder are the service design problems that require the wider system to change in order to produce a better result for users. I can name them. I can make a case for them. But I can’t force the system to respond. No one team can. The processes and tools that need to change are beyond our reach. I am almost certainly not in the right rooms.

The native replatforming work is a good example of what work looks like when we can reach all of the levers. The team can research, design, and build things. The scope is bounded and the quality bar is ours to set. When moments of decision arrive, there’s something coherent already in place. A codebase. A design language. A team with a working practice. The streams have something to find and adhere to.

Keeping the right problems alive is hard. In the garbage can model, resolution – where a problem and a solution genuinely meet and get worked through – is the rarest way decisions get made. Most happen through oversight, where a decision is made so quickly that problems don’t get a chance to attach to it, or flight, where problems simply detach and drift away because the moment has passed. The main risk isn’t that a problem gets solved badly – it’s that it gets outpaced or abandoned. Plans don’t get completed because there’s a new plan to supplant them. To stay relevant you need to maintain and resurface and reattach the problem to the other streams. That is less glamorous than designing a new interface but it is arguably the more important skill in this kind of environment.

In practice, this work doesn’t look like much from the outside. You run research that no one asked for to investigate a hunch. You articulate a problem that isn’t part of one of the big plans to surface what you’ve learned. You document the work so that it outlasts you. You turn up to basically every meeting there is, even if it doesn’t obviously concern you, because the participant stream determines what mindsets direct the decision-making. None of that is control. Done consistently though, it builds influence to keep the problems you care about alive and in the conversation for a little bit longer.

While the garbage can model mostly fits, the work might be better described by a different image. A garbage can implies waste, destruction, an ending, a lack of care. The work of keeping problems alive by working within a complex ecosystem lends itself to gardening as the obvious replacement, but perhaps that is too genteel. Better still might the image of a compost heap: it is messy and a little terrifying, it confounds easy analysis, it has a certain life of its own and over time, if you keep turning it and adding to it, it becomes generative. When the conditions and season are right, there’s something there to meet the moment.

Patience and persistence, yes. But not just waiting. Tending.

We’ve just had quarterly planning again. It is a big event that involves bringing all of the App teams together for two days. Lots of presentations, lots of discussions, a fair amount of negotiation. During these events, my normal role has always been to float around between teams as a roving advisor. For the last two editions, my energy has been focused on working with our native transformation team to distill their plans. In this latest instance, that pattern has flipped itself inside-out and I am now once again roving around, this time on behalf of the native transformation team. We need to get other teams – who have never really worked on properly native software before – to start thinking about how they’re going to redo their bit of the app in native code.

The planned changes mean designers must rethink how their parts of the App function. Native apps work differently than websites – something I don’t think we’ve ever fully internalised. With the web version sharing a codebase with the mobile app version, everything had to work in its lowest common denominator setting (the web). In a world where the NHS App exists as three codebases and leans more heavily on mobile app design conventions, that’s no longer good enough. Teams will need to take platform differences seriously and design everything three times. This sounds bad, but it is also necessary: this is how we get the best out of each respective platform we build for, this is how we raise the quality bar.

Everyone seems up for the challenge, which is encouraging, but it is still a real challenge. New skills need to be learned and old habits need to be un-learned. That isn’t a surprise, but it is real work.

I began the process of getting people into the right headspace several weeks before quarterly planning started and continued that work during the event. Thus far, I’ve spoken to five teams about the topic. Some of them have an entirely new project to work on. For them, it makes sense to start by designing for the native app to come. These projects should be quite fun: they get to start from something like a nearly blank slate, inventing new ways of designing App stuff. (Have I mentioned that we don’t have a design system or anything like a settled approach yet?)

Other teams need to make smaller changes to extant features and services. During this process, they can and should translate their area of the App into the more app-y future state. This will cause work that initially looked small to become significantly larger. That condition has led me to start prepping product and delivery managers about how this work will affect their timelines and capacity. I don’t think I’ve made too many enemies here, yet – the work has the full-throated support of senior leadership (bit of a plot twist, that) – but I am mindful of being the “well, actually” guy, slowing people down. This is a new way of working and we haven’t developed processes or muscle memory for it, yet. We’ll get there.

After planning was wrapped up, I dipped in to the NHSE design huddle to spread the word amongst the wider design community. I covered the origins of the work, what we’ve done over the past year, where we’re at now, and where we think we’re headed. Overall, I got the impression that people were enthusiastic about the work, but there were some very good (read: hard) questions raised about what this means for approaches to design and prototyping:

Will all designers need to learn Swift and Kotlin?

No, but people working on features or services for the App should! While it remains entirely possible to design in layout tools like Figma, I don’t think it is a good idea. Everything I’ve done over the last six months suggests that understanding a technology, platform, or channel is best accomplished by working with it directly, by getting your hands into the machine. Designers will need to develop new skills and that will take time, but I am not convinced you can really get the feel for how designing a native app is different from designing a website until you’ve wrangled the specific technologies used to make them.

Will there be a new, native prototype kit?

We think so, but we don’t know what it will look like yet. The NHS Prototype Kit relies heavily on Nunjucks, but there aren’t many analogues for native code. Things like Stencil and GRMustache.swift exist, but I’m not convinced they will offer us much benefit (it also isn’t clear whether these are being actively maintained). SwiftUI and Jetpack Compose are relatively expressive and easy to grasp (imho), so it might be better for designers to just work directly with the code and skip using a templating language. Unfortunately, setup and deployment are all significantly more complicated as compared to a web prototype, so we will need to find ways to make that easier. For now, we have teams picking up the prototypes we’ve made and trying to figure out how to reconfigure them for their needs. I am guessing that we’ll learn a lot about how to create reusable tools by watching how teams get on over the next few months.

How do you use native prototypes during user research?

Thus far, all of the research we’ve done has been in person. We’ve run a combination of lab (participants come to us) and pop-in (we go to participants) sessions. I’m not sure if that approach will be required of all teams forever, but the possibility of that being true is a concern for us. Teams getting out into the world more to meet users where they are is a good thing, but it takes more time to organise and execute compared to online sessions, and the COVID-induced approach of doing all research online has been hard to shake.

For remote research, the big challenge is getting a native prototype onto a participant’s device, and then making it easy for them to share their screen back to the session. We need to investigate tools like Appetize – it looks promising, if also not quite what I am looking for. With everything going on right now in AI-assisted development, this feels like a market opportunity for some enterprising young person. (If you make this, please tell me!)

So yeah, lots to work out. One nice development is that the week before last I attended the first cross-gov mobile apps meet-up, organised by the HMRC app team. (Visit the #mobile-apps channel in cross-gov Slack if you want to get involved.) About 25 people from across government attended. After a few demos, we had a mini-workshop in which we discussed future topics for the meet-up, many of which mirror the questions we at the NHS App have been trying to work through. It’s nice to know we aren’t in this alone. Perhaps the answers we develop to the questioned listed above can help other teams across the sector. After all of the planning and negotiating, I’m rather appy indeed.

Work on our native re-platforming continues. The work is still moderately experimental but we’re inching closer to a plan for what the first release will be. It is likely that the first user-facing release will be quiet chunky, but I’ve been resisting calling this an “MVP”.

In general, I dislike the term for its over-used vagueness. I have yet to find two groups of people who use the term in exactly the same way. Most of the time when people say “MVP” they just mean “the first (small, slightly crappy) thing we intend to ship”. Last week, on the train, I read Scott Colfer’s “Escaping the product operating model trap” (very interesting on its own terms regarding where a “product operating model” fails in large organisations) and was reminded of the essence of an MVP:

‘Minimum viable product’ is a metaphor for ‘testing our assumptions before making a decision’. It’s about running experiments to manage risk.

That definition is coherent and useful, but it covers a few different working practices. The classic use of an MVP is to test assumptions as a way to figure out whether your product or service should exist at all, as you search for product-market fit. That’s not the situation we’re in. We know the NHS App should exist – it has users, it works, and it delivers value. Viability isn’t the constraint; quality is. The whole point of this re-platforming is to raise the bar for the user experience. We’re not asking “should we build this at all?” We’re asking “how do we make this better?” Treating these questions as if they were the same thing is one place where the confusion creeps in.

Some of what we’re doing now is, in effect, a translation: taking existing functionality and reimplementing it in a new architecture, with new components and patterns. For these parts of the work, we have high confidence about what the outcome should be because this stuff already works (mostly). The goal is to find a new way of expressing what we already have. Other parts of the work involve entirely new features – ideas from our alpha last year that we believe in and want to pursue, but which are simply too complicated to go after right now. That kind of work can be approached like a traditional MVP; we just don’t have the headspace for it while there is so much translation still to do. I mean, the app is rather big.

The translation work is also, in a deeper sense, the foundation work. The goal isn’t just to release something small – it’s to establish a structure that is coherent and clear on its own terms, so that each subsequent piece of work has somewhere sensible to attach. This means being deliberate about what we re-platform first. The elements we tackle now should, in theory, make it easier to pick off further changes one by one in a clean and logical fashion. It won’t be complete, but it will be a good start. Working this way has meant we can choose to defer some decisions and create optionality. We don’t need to resolve every detail upfront and our more ambitious ideas can wait until we have better foundations to build from.

Releasing changes incrementally creates its own challenge: for some indeterminate period of time, some parts of the app will be fully native and some parts won’t. Designing ways to handle that hybrid state as gracefully as possible is something we’ll be exploring further in our next round of research. I don’t think there’s a perfect solution, but we have hunches about how to minimise confusion and we have the kernel of a plan for how to proceed beyond an initial release.

In the end, I suppose you could argue that this work is an MVP. We’re planning to release something we can add to and iterate on. We’re leaving some decisions open, accepting that we’ll learn as we go. And yet the term still rankles. Even stripped of its worst connotations – shipping the worst thing you can get away with – it collapses two distinct and useful ideas into one: learning what to build and learning how to build it right. Both are valid and important, but they’re not interchangeable. We’re not trying to discover whether we’re building the right thing. We’re trying to lay a foundation: something coherent, something we can build from, something that makes the next thing easier. That’s not an MVP. It’s a start.