Mike Gallagher

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.

Out of all of the government design principles, “make things open: it makes things better” is probably tied for memorability with “do the hard work to make it simple”. It sounds bright and modern, almost the opposite of how most people perceive government behaviour. Today, an appeal to make things open is so common that it sometimes feels like a stock phrase that people tack on just because it is the done thing. Underneath this snappy motto, however, is an entire worldview. This is worth unpacking.

The materialist justification for this principle is straightforward: everything we work on is paid for by the public purse, making it public property. This is true regardless of whether you are permanent staff, a contractor, or a consultant. It is one of the defining characteristics of public sector work and represents a fundamental distinction to working for enterprise. To deliver on this, we need to ensure that the things we learn and make are easily accessible to all so that they don’t need to be re-learned or re-made, unnecessarily draining limited funding. Making our work open to everyone is a civic responsibility and a contractual obligation.

For those new to the public sector, this situation might be uncomfortable because it runs counter to the late-capitalist ideology of competition and resource extraction. If you were raised in an environment where success was associated with exploiting a niche or disrupting a market (shudder), it will be bizarre to consider the possibility that giving away your most precious ideas might be desirable. This has a particularly bizzaro-world quality in technology spaces, where instead of the copyright-happy ethos of Silicon Valley, we find a community intent on making sure their work is reused freely. Rather than angling for a payout, perhaps we can encourage people to steal our work?

The alignment between this principle and the open-source software movement should be clear. Less obvious might be its deeper historical roots. Typically, when we speak of “internet-era ways of working”, we are referring to the expectations of end-users that have been set up by a world of smartphones and apps. There is another side of these ways of working though: the perspective of the makers. The early internet promised a world of connection fostered by the free flow of ideas. People were meant to be able to find fellow travellers by sharing their interests online. This was supposed to result in new communities. For a while, it did.

Corporatised social media soured the promise of early internet spaces, but since early on in the UK public sector’s adoption of contemporary methods of digital delivery, organisations have taken up blogging as a means of sharing what they’re learning and building community. Individuals working within departments have also been very active online. This was such a significant element of early GDS that there is even a sticker that reads “I survived the week all the famous bloggers quit”, commemorating when most of the founding team departed. Blogging was core to the identity of this new, internet-oriented way of working. It represented a new way for government departments to exist in the world, one grounded in transparency and directness.

The phrase “the digital commons” isn’t in vogue anymore, but the notion of collective, community assets is a major artery running through the body politic of public sector design and technology. Publishing endeavours like design histories and design system backlogs extend the knowledge pool of individual blogs to incorporate and expose institutional memory. To that end, the NHS App team has recently added three posts about our work exploring native technology:

• Exploring a spectrum of possibilities
• Native form flows
• Utilising the web app

There will be more posts in this series, and hopefully more posts about all of the rest of the work happening on the App. We’ve also recently made our native hypothesis backlog public. We’ll document what we’re investigating and what we’re learning there as we go. It might not be valuable to other teams right now, and that’s fine. Much like design system backlogs, the things the team is learning are now searchable on the open web, making them a durable public asset.

Making this backlog public was something we had to argue for. Our organisation can be risk-averse, and for good reason. It helps that there is no working code in the repo. The worst thing that can happen is that we’ll look like idiots by exposing how little we know. Showing or describing what you’re working on in a public place, be that an open Slack channel or the whole dang internet, adds an element of risk to whatever it is that you’re doing. Maybe no one will be interested or you’ll find out you’ve done something wrong. Conversely, maybe others can learn from what you’ve done. To work in the open, one needs to bracket anxiety about not being good enough. That isn’t easy, but the potential payoff is significant. The chances of getting useful feedback go up. The possibilities for building a community around the work expand. The likelihood of finding fellow travellers is increased.

This very blog is an attempt to foster exactly those conditions. I’m not doing this to be a “thought leader” (yuck), but rather because I’ve had enough conversations about the topics I tend to write about here that I began to wonder if it would be worth taking the time to write it all down so people outside my immediate orbit can engage too. Over the course of the last year, I think the core wager has paid off. At times, it is a terrifying endeavour. I’m not an extrovert and I don’t need to publish what I write to personally benefit from the writing process – I can do that all by myself, regardless of whether anyone else reads it. I’m doing this not only because it might foster connections beyond the people I already come into contact with, but also because it can serve as a catalyst for discussion with people I work with every day.

If you’ve only ever known Twitter or YouTube comments as models for direct digital engagement, it might be surprising to find out how supportive most people in this domain are when you start putting yourself out there. I’m not a significant contributor to cross-gov Slack, but I appreciate its existence. The amount of time members put into helping one another, entirely of their own volition and in addition to their actual jobs, is a marvel. The result of that community labour is a design and technology hivemind, built on knowledge gained from years of doing the doing. The phrase “make things open: it makes things better” gets tossed around a lot and sounds simple, but I think it encapsulates a profound set of ideas that define what is specific to working in the public sector. We need to continue to sing this song so that future generations know what we mean and why we mean it.