Mike Gallagher

While the team are making plans for what to design or research or build next, I’ve been hitting the road like some sort of wandering bard, telling the story of the work thus far. This past week I presented an update about our native re-platforming work to a handful of different groups. Some of these groups need to be kept up to date and some are just curious because the project is strange. Telling the story over and over again, modulating the points of emphasis each time, is a nice way to explore what aspects land with an audience.

There is a lot of ground to cover, but perhaps it is not surprising that the elements of the presentations that have garnered the most attention are the areas where we have deviated from our standard ways of working or ways of describing what we do. Texture, place-making, and vibes are the elements of the work that generate the most interest and elicit lots of questions. Those are not common topics around here but they are the words I’ve been using to emphasise how this work is special. The issues at hand are not about the value of a service, the clarity of content, or the efficiency of a journey. Rather, the elements that I have been focussing on are what kind of impression the overall experience makes on the end user. What emotions does it produce? Does it feel trustworthy? Can you sense where you are? What kind of mood does it inspire? These questions are subtle and the answers are elusive.

I realise that in our context, where access to care can be a frustrating or confusing experience for patients, making a fuss about what kind of vibe our products and services give off could sound absurd. It is touchy-feely hippie stuff in a world of brutal efficiencies, and yet everything I’ve seen over the last few months suggests it is really very important. Once upon a time, when gov.uk or nhs.uk were originally being conceived, this may have been a common topic of conversation. Today though, the basics of our design systems are largely settled and stable. Questions about how to produce the right feeling just don’t come up anymore, but providing care always has an emotional, affective dimension (biopsychosocial models of care, anyone?), so why shouldn’t this be part of how we discuss design languages?

We’re starting to untangle how to produce feelings. Our next steps are to isolate the novel variables and research them methodically so we can develop a more robust evidence base supporting (or rejecting) our current hypotheses. Given how interconnected the myriad design decisions we’ve made are, I know that this is going to be difficult.

We’re currently wrapping up our alpha looking at how to use native code to improve the design of the NHS App and this past week we put the the work through our internal design assurance process – imagine something like the mid-point between a standard design crit and an alpha service assessment, and we always include a clinician as part of the conversation. (There is more to say about this process, and why we have it, but that is a story for another day.) Normally, I am part of the panel reviewing the work but this time I was on the other side of the table, being reviewed. It was a lot of work to prepare for (something I need to reflect on so I can try to lower the burden for our teams) but the review itself was quite fun.

On Friday, I spent a bit of time with Dave and Graham talking about how to translate everything we’ve done into a set of public design history posts. I would guess that there will be five or six of them covering the experiments we ran and the functional areas we explored. Across the various experiments, a few high-level themes emerged that we’ll try to elaborate on:

• Platform vs public sector conventions (this is going to be very tricky to balance)
• Trust (it doesn’t take much to impart NHS-ness and we might be anchoring to the wrong design paradigm)
• Place-making (the app isn’t a service, it is an environment; it needs texture and landmarks)

I hope what we’ve learned will be useful to other teams, so I’m keen to get the material out into the world (plus it would make Frankie happy 😘). Before we get to what we learned about the App itself, I thought it would help to describe how we learned about the app because we have worked ourselves into a strange corner.

All of the user research we ran during this phase of work was in-person. We were working exclusively with native coded prototypes, and that introduces a few logistical challenges:

• It is much harder to get the prototype onto a research participant’s device
• If the participant has an older device, they can be excluded completely
• Observing how a research participant is using the prototype is complicated and has hard limits if you aren’t sitting right next to them (e.g. in remote sessions, there is no pointer to observe)

There are ways to put an app onto someone’s phone for testing purposes (TestFlight for iOS and Google Play Console for Android), but the process is a clumsy faff that requires more time and effort than most people are willing to put up with. For this recent work, in which we were testing ideas quickly and moving on just as fast, we’ve found the best approach was to bring along our own devices with the prototypes pre-installed. That means that remote and unmoderated research are off the table, adding to the planning overhead and cost associated with any given round of research.

We used a mixture of pop-in sessions around London and labs sessions in Leeds, running them on alternating weeks. Setting up pop-in sessions requires you to already have a network of organisations to work with or some means of developing one. Doing research in that kind of setting also tends to turn you into ad hoc tech support for a few hours each time, but that feels like a fair price for people’s time. Setting up lab sessions requires a fair amount of advance planning: you have to book the lab and arrange participants through a recruiter. To simplify this work, we planned to use the lab every other week and gave the recruiter a brief to fulfil before we knew what we’d be testing. Between the two approaches, we committed in advance to running research every week, come what may.

Planning and running in-person research every week for a few months is a ton of work but the upside is that it provides for a very rich research situation. You can watch for subtle cues of body language, facial expressions, and tone of voice. You can examine how people use their hands to interact with the device. A common occurrence that felt like an aha! moment happened when we spoke with people who use the NHS App a lot. We’d have a few introductory questions to get to know them, ask them about their current App usage, and then show them our prototypes. Often, you could see their shoulders relax a little shortly after they started poking around. The small changes to visual design, the addition of gestural controls, and the presence of little bits of animation seem to signal something like “this won’t be hard to use”, and people instinctively relax a little. You don’t need people to tell you the thing is easier to use – you can see it in their body language, and those moments make all the extra setup worth it.

The added cost inherent in the approach we’ve taken has a second dimension. We bang on about designers prototyping in code, but up until very recently that meant web code – HTML, CSS, and a little Javascript. Those skills are moderately common across the sector. So far as I can tell, native code skills are much less common. When I’ve told friends and colleagues how we were working I’ve gotten some raised eyebrows. No one I’ve spoken to has experience of all of the designers working across a large app prototyping in native code directly.

My worry is that this approach won’t scale beyond the current team, in which we have two exceptionally talented and curious designers who were provided ample time to learn new programming languages outside of the normal delivery grind. Once designers know how to work this way, I am convinced it produces better results, but I’m wobbly on how we get people to that point. If anyone out there has experience of this, I’d love to hear about it.

When asked what my job is, I usually say something like, “My job is to make it possible for everyone else to do a good job.” That breaks down into spending a lot of time out ahead of teams, lining up new work and then acting as a sounding board, coach, and critic for designers once the work has started. This maps nicely onto the Venn diagram of “solve the right problem / solve the problem right,” sitting at one level of remove from the people in product teams who do the doing. However, it isn’t as tidy as it sounds.

If I were to list the elements of the lead designer role for someone new to it, I’d tell them the job involves mentoring direct reports, reviewing design work, establishing communities of practice, planning new initiatives, arguing about priorities, making friends with other teams, and doing an ungodly amount of admin. There is a fair amount of variety in that list. You get to work across three registers (down: teams, across: programme, up: portfolio) and overall it seems well balanced. In reality, a huge portion of my time is spent attempting to stomp out the multitude of brush fires that are constantly bursting into life. Staying on top of every new project that needs something from the NHS App takes a lot of time and attempting to create cohesion is like herding cats.

The reactive side of the work can be overwhelming and all encompassing if you’re not careful. It often is for me. It is too easy to be carried along, forever dealing with whatever small problem is sitting right in front of my nose. It is difficult to escape the apparent urgency of fighting fires so that I can step back, assess the landscape, and plan new initiatives. The quarterly planning cycle helps a little, but I do need to occasionally remind myself to actually do this kind of work. The odd thing is that, so far as I can tell, it is my prerogative to choose what I work on and how I do it. It took me a long time to realise this was true, which seems foolish in hindsight because Emma told me that I would have this freedom before I started working for the NHS. The day-to-day grind obscures the amount of agency I apparently have but recent events have revealed it to be true. It is a privilege that isn’t afforded to most people and I should take advantage of this situation more often.

This past summer, having spent the better part of two years intermittently pushing to do a big weird piece of work (see: exploring how we use native code), I found myself scrambling to figure out how to be part of it. I had deep regrets about not involving myself more in previous large projects that I had originated. Several past initiatives hadn’t gone as well as I would have liked and this time I knew that I needed to be in it. I also couldn’t shake the feeling that this kind of work (design pathfinding) is something I have deep muscle memory for and that I could be far more helpful to everyone if I just dug in and made some stuff, as opposed to coaching and advising others. Or maybe I was just bored. Or maybe I’m a control freak. I dunno. In any case, choosing to step fully into a project is novel for me in this particular role. I’ve never managed to do it in the three-ish years I’ve worked for the NHS, and I have tried before.

When I announced that I would work on this project directly, no one tried to stop me and a fair few people seemed rather happy about it, which surprised me. I had assumed this declaration would elicit at least some nervousness. Perhaps I am not as important to the smooth running of this place as I had imagined! Since then, I’ve managed to work directly with the project team most days. I have done a decent amount of design work and written a bunch of terrible (read: just good enough to prove a point) code, but the bulk of my time has been split between acting as a creative director and being a researcher. I can’t give all of my time over to the project as there is still all of the other “normal” work to do, but thus far splitting my time hasn’t been a big problem. The trouble is that this arrangement was always meant to be a limited-time endeavour. Now that we’re wrapping up the alpha and theoretically moving into private beta (check back in a few weeks!), I am trying to work through the question of what my role should be going forward.

I now find myself at a cross-roads: can I persist with the 50:50 split between management and project team work that I’ve had since September? There is definitely enough work left to do on this project to make that worthwhile. I know the team expect it and I want to stay involved, but then I need to re-plan what the next six+ months look like to avoid neglecting our other teams and areas of work. The primary question now is: where am I most valuable? There are several possible answers:

• As an experienced designer, choosing to focus on one high value project at a time
• As a manager, spreading what I know across the wider team
• As a catalyst or agitator, looking for opportunities to “make good trouble” (to quote Dave)

At this point, I truly do not know what the answer is or if there even is one correct answer. I’m certain that the current work is important, but it is hardly the only important thing going on right now, and I have my hand in at least four other pieces of work. Further, if this place has taught me anything, it is that hard problems require a lot of setup and advocacy if they are going to be dealt with. It is thus worthwhile for me to be thinking about what’s next, even if my involvement in the current big project will last for at least another six months.