Mike Gallagher

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.

I’ve spent a lot of time over the past few weeks translating. Translating ideas between groups of stakeholders. Translating intentions and concerns between people who need to work together. Translating artefacts from one platform to another. I sometimes feel like an osmotic membrane or a post-processing engine, perpetually stuck in the middle. I don’t dislike it, mind you, but it does leave me feeling saturated. In most situations I have to hold multiple versions of reality in my head and flip flop between them.

I’ve been working in some version of this role for years, and yet it remains a fascinating place to be. Probably because the lived reality of the work is nothing like what people imagine. Design leadership does not feel like how pop culture portrays “leadership”. It doesn’t feel like standing on a hill shouting directions, or sitting behind a giant desk in the corner office making serious decisions while in conversation with a shadowy figure in an expensive suit. Instead it feels like being in the middle of a crowded room, furiously rewriting notes as they are passed from hand to hand to hand. Each note that reaches you has already been shaped by someone else’s priorities, and by the time you pass them on again they will have been shaped by yours.

All design work involves some degree of translation. When you work in a single team you absorb signals from users and the organisation and try to determine the right direction. When you work across a handful of teams, you also take on responsibility for maintaining coherence across the projects in your orbit. Even if each team is doing good work individually, someone still needs to help their efforts fit together. Beyond that scale – when you can no longer reasonably be involved in the specifics – the work becomes more outward-facing. The amount of time spent with people outside the teams increases, often dramatically. The centre of the job shifts from making things to interpreting and communicating them.

Organisations are full of groups that optimise for different signals. Every role has a set of trade-offs baked into its respective discipline. Each will pursue outcomes based on their values and speak in a way that emphasises what they care about. None of them are wrong on their own terms, but they do vary and sometimes clash. Without someone translating between them, the conversation can quickly become a series of near misses.

At that point the real skill becomes audience awareness. Not just occasionally adjusting a slide deck for senior leadership, but actively modulating how you present ideas depending on who you’re speaking with. The shape-shifting becomes the job. This is a form of politics. The centre of your working life becomes the act of translation, rather than creation. I can’t decide if I think this is extremely obvious or somewhat arcane knowledge. I spend so much time with product and delivery managers thinking about how to engage with different groups that this all feels like my default mode of existence, and yet I find myself compelled to explain this way of working on a semi-regular basis.

Once you start thinking about communication this way, it begins to resemble a familiar design problem. The process is basically the same as user-centred design, except applied to teamwork and communication: Who are the users? What do they need? How do we satisfy those criteria? How can we tell if it’s working? Easy enough when you have a single audience. Harder when you are surrounded on all sides by different groups, each with their own expectations, motivations, and constraints. The role becomes particularly confusing when you need to fully inhabit each of those worlds yourself.

On a recent episode of Finding Our Way that covered a survey about the state of the design field, Peter Merholz and Jesse James Garret discussed why design leaders can feel like they’re being pulled in multiple directions (I’ve lightly edited the quote for clarity):

They’re living in two worlds. […] They’re spending half their time in design – being generative, being creative, and nurturing exploration – but then they have to turn around and interpret that mode of working to a broader organisation that is more calculating, more business-centred, more spreadsheet-oriented. They also need to be able to speak the language of the dominant business values and bring that into their team so that their team is maintaining relevance.

Moving between those worlds requires more than context switching. It requires vocabulary and mindset shifting too. Each group expects you to show up in a slightly different way. It helps if you can speak each group’s lingua franca and understand what motivates them. This doesn’t need to be devious or manipulative – you aren’t trying to wear someone else’s skin – but you do need to understand where people are coming from in order to find common ground. This might sound obvious, but utilising design methods this way – applying them to the people and groups inside your own organisation – is a critical skill.

Being a mediator or membrane doesn’t mean you shouldn’t have an agenda. Of course you should. That’s why you were hired in the first place. The challenge is that constantly acting as a human cipher can make it easy to lose track of your own perspective. If you are always translating other people’s ideas or inhabiting other people’s point of view, you can start to lose your own sense of identity. That kind of shape-shifting can be exhausting. Some people respond by retreating into dogma; others lose touch with their own point of view entirely. Resist both of those outcomes. It might help to occasionally step out of manager mode and spend some time doing hands-on design work to remind yourself what the craft feels like. Even if your job is to move between worlds, translating the versions of reality back and forth, you still need to remember what you’re there to represent.

One of the designers in the team has been on holiday for the past two weeks so I’ve stepped in to cover. This meant getting to grips with designing and prototyping for Android. This has been, shall we say, a learning experience.

Figuring out how to use Android’s programming language and interface framework (Kotlin and Jetpack Compose, respectively) is one thing – they aren’t so different to their equivalents for iOS, with which I’m moderately familiar. The syntax and vocabulary are similar enough that it hasn’t taken too long to figure out how to do comparable things. To my eye, Kotlin looks a little messier as words on a screen while being simultaneously easier to understand. I am still pretty bad at writing Kotlin code but having Copilot on hand to test out ideas or query a method has vastly sped up the process of getting good enough to make shitty but functional prototypes (surprising precisely no one, at this point in the AI hype cycle).

The bigger issue has been trying to understand the design ethos of Android and Material Design. It is a visual paradigm that I haven’t had to really design for, given that the NHS App doesn’t currently use Google’s design system. To get my head in the game, I’ve been reading documentation and trying to hunt down useful reference applications, but it is one thing to understand the gist of the system and something else entirely to be able to use it well. Is there an Android-y way to design the NHS App and should that be distinct from how things might work on iOS or the web? What would that consist of? These have been my research questions for the past two weeks.

Asking those questions presupposes that it is acceptable for the NHS App to have to have different design expressions on these three platforms. This hypothesis is foundational to the work we are pursuing right now. It follows on from the idea that we should align how we design to platform conventions and has some interesting implications. For Android and the current incarnation of its design system, Material 3 Expressive, just how expressive should the NHS App be? We are talking about an official digital channel of the state, after all. Material 3, as shown in the documentation, is rather jaunty and very colourful. Is that really the best way for the NHS App to feel? Probably not, but a certain amount of visual and interaction alignment to Material 3 seems important for signalling “this thing works like your other apps”, which we already know lowers the barrier to use. On iOS, this is a relatively straightforward thing to work out because the ecosystem is fairly homogenous. On Android, there is precious little consistency in how apps use the design system, making our challenge significant.

To compound this challenge even further, Material 3 isn’t the only design system we need to contend with. We also need to use as much of the NHS design system as we can. Not literally of course, but if we are going to create a new set of mobile apps that matches user expectations and maintains trust in the organisation, we need to provide some degree of continuity with other NHS services.

Finding a middle ground isn’t a simple task. The current version of Material Design seems to be optimised for obviousness. It is extremely bold and makes liberal use of intense colour. In the abstract, those aren’t bad things – I welcome the drive toward making interface elements obvious! However, very few apps seem to use Material 3 to its full extent, which isn’t a huge surprise given how easily it might overwhelm a company’s branding. Articles by Google give many examples of how to make the system work, but pretty much all of them are entirely too vibrant for an NHS product and they don’t fit well with our colour palette. We risk falling into a strange netherworld where the app feels neither like standard NHS services nor like obviously Android-y apps. Little by little, I think we’re starting to get the hang of it, but were aren’t there yet.

In the last round of user research, we explored how much branding and customisation we could remove before our prototypes performed worse than the web app. The research clearly showed that there are limits to how much we can strip back the design to platform defaults. Below a certain threshold, users start to react negatively. The information architecture and task flows all work fine – in fact, they still work better than the web app – but users don’t like the experience as much and they don’t trust what they’re looking at. An ultra-reductionist summary would be “the NHS App needs to have a decent amount of blue in it”, but this misses a lot of nuance. NHS services have a certain way of organising content and tasks that users have become familiar with. If we are going to make users comfortable and maintain trust in the app, we need to find a way to utilise NHS design patterns and represent the brand in way that feels natural on the Android platform. We need to channel the spirit of NHS services via the medium of Material Design.

Eventually, if we arrive where I think we are headed, we will have three aspects of one design system, each tuned for a particular platform. The NHS App may very well look and work differently on each. I think that is fine, so long as it produces the same outcomes in each place. The task now is to find the Android-y and iOS-y expression of the NHS brand and design ethos.