Mike Gallagher

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 re-platforming 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. 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.

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.