Mike Gallagher

Earlier this week Frankie and I published a post on the NHS’ Design Matters blog about prototyping in code and the work we’re doing to improve the NHS prototype kit. The post is part of an initiative across NHS England to re-centre our working practices on common foundations using open, accessible technologies. It is an approach that has been popular across the public sector in the UK for a long time, but over time tools like Figma have come to dominate working practices in many places. We wanted to put down a marker that describes our view on the subject and what we intend to do about it.

I want to expand on one of the benefits we outline about prototyping in code. In the post, we wrote that

it allows designers to understand the medium of the web, and its benefits and constraints, in greater depth

This isn’t the main point most people emphasise when talking about designers working in code or making coded prototypes (it wasn’t even in the post until quite late in the drafting process), but it is the one I care most about. To be clear, making prototypes accessible and using the real front-end components is important, but the greater depth of understanding and fluency in your media of choice that comes from getting your hands dirty has benefits that extend across the entire design process. Knowing what your materials can and can’t do is a foundational skill that is easily missed if you only ever look at pictures of interfaces. Working directly in code changes the way you design.

After we published the post, Ananda reminded us about Frank Chimero’s article The Web’s Grain. Its core thesis is right in the subheading:

Every material has affordances. What if we started thinking of screens as a material for digital design?

I remember reading this back when it was originally published in 2015 and nodding along enthusiastically. It rhymes with the way I learned to think about print media, and books especially: paper and ink and glue and thread all have physical properties that you can consciously manipulate to create a desired effect. Books are, first and foremost, physical objects whose tactile qualities speak through how they have been arranged and combined. For example, paper has a grain and if that grain runs in the wrong direction (left to right), the book will feel stiff. If you change the paper’s orientation so that the grain runs vertically, the book will open better, the pages will bend more easily, and the book will be softer. Basically: it will feel better in your hands. But before you can can choose how to orient the paper to gain the desired result, you first need to know that this even is a quality of the material. You need to first know what the material’s nature is.

Designing for digital media is much the same. Different operating systems have their own design idioms and the only reliable way that I’ve ever found to get to grips with them is to make working software for them. There is a huge variety of programming languages and interface frameworks to work with; each and every one of them has a set of in-built possibilities and limitations. Understanding what those are will help you know what design ideas will be easy to execute and which will be really hard to pull off. Having that understanding can save you time and it can inspire new ideas. Constraints are often generative.

I’ve never been able to finish design work in layout tools like Figma or Illustrator. I can get close, but never quite fully there, never quite fully done. Once built, the thing always seems just a bit wrong. There might be a problem of translation between designer and developer, but most of the time the issue is that the details of the layout just feel different when rendered through different technologies. Subtle differences in scale or the way the layout reacts to changing screen dimensions add up to something that is sloppy.

One of the most significant changes to the experience of doing design that comes from working directly in code is that it forces a shift away from how something looks and toward the way it works. When building out a working prototype, the designer will need to think through how their product or service changes and moves when the user interacts with it. Anything that can happen in the product needs to be thought through and designed for. You might try to simulate any and all interactions with a visual layout tool like Figma, but it will never completely reflect reality and thus your work will always fall short of being as precise or as thoroughly considered as it could be. It is far more effective to just build the thing and tinker with it until it works.

For a snappy breakdown of how the work changes when working in code, check out this video about the design of Notion Mail and skip to 14:20. The designer talks through a set of design decisions that simply could not be made in a layout tool alone. That these decisions even need to be made might not be apparent until you have working software to play with.

To a significant degree, the tools we use determine what options are thinkable. Today, tools like Cursor and Lovable provide designers with ways to get working code-based prototypes (and even fully functioning software) up and running quickly. The challenge with this approach is that it has become easy to produce working software but the designer will, by and large, have skipped the process of getting to know what their tools are inclined toward. For instance, in the experiments I’ve done with Copilot to build iOS prototypes, I’ve managed to produce a basic list component at least three different ways. Which is the “correct” way? Does this matter? Copilot has no consistent opinions on this, so it falls to me to read the docs and then ask Copilot to refactor the code. The degree to which this approach helps the designer understand their medium is questionable, but I am interested to see if the trend is a long-term net benefit, and I’m happy that more designers are producing coded prototypes.

Mandating that designers work in code and use the NHS prototype kit isn’t about insisting that everyone become a expert developer. That wouldn’t be practical and it isn’t necessary. It also misses the point: teams have developers who know about all manner of stuff beyond how to whack together a prototype to test some ideas. Rather, working in code helps designers think programmatically. It helps them understand how to use data and how to collaborate with technologists. Working in code is a means for developing a common vocabulary for the team and executing work at a higher level.

I was on holiday when the NHS 10 Year Plan came out, which meant that I got to avoid the initial frenzy of activity that was inevitably going to surround a big new government plan. After getting back I had set aside a few blocks of time to read and re-read the document in an attempt to start working out my own understanding of what it entails.

The thing about the NHS 10 Year Plan is that, as several people have pointed out, it isn’t really a plan in a traditional sense. It doesn’t have much to say about how things will be accomplished but I don’t think that this is a bad thing. The ideas and directives it contains that are related to my little part of the world involve a lot of ambiguity, but this means there is room to work out how best to deliver on the vision in a way that makes sense for our users. We now have a description of where we should be going, the question is how to get there.

The plan has many lists of product features. These all need to be catalogued and scoped and assigned owners. There are people already taking care of that, which leaves me with time to approach the plan from a different angle, namely trying to understand the policy intent that sits under the surface. Much of what is outlined in the section on digital services isn’t quite described in terms that our teams can work with because it lacks specificity on intended outcomes. We need to have a position on things like:

• How should patients’ lives be improved if we do this thing?
• How will we know if we’ve done a good job?
• How will we know if we’ve inadvertently caused problems elsewhere in the system?
• What would need to change to accomplish this?

Having a sense of how to answer those questions will get us closer to knowing how to safely deliver on the government’s ambition. For instance, the plan says:

The My Specialist tool will be where patients can make self-referrals to specialist care where clinically appropriate. From the outset, patients will be able to self-refer to mental health talking therapies, musculoskeletal (MSK) services, podiatry and audiology. This will help us transform the working lives of GPs – letting them focus on care where they provide the highest value-add. It will also be how we make sure everyone can self-refer, not just the most confident and health literate. In other cases, the tool will allow patients to leave a question for a specialist to answer without making an appointment.

That sounds logical enough, but how are we determining where this is clinically appropriate? Are we clear on what is lost, in terms of clinical judgement, if GPs no longer act as an arbiter between the patient and secondary care? If the goal is to make self-referral more readily available to people with low health literacy, how do we avoid people booking into specialist appointments when it isn’t the best route for them? What aspects of a specialist’s workflow need to change so that they can be afforded the time to answer queries from potential patients? The healthcare system is complex and we may not be able to definitively answer these questions before we start intervening, but we should at least have some sense of what we think will happen so we can adjust course later on if the results aren’t as expected.

Beyond the headlines, I’ve noticed that there are a set of themes that don’t get much fanfare even thought they are woven throughout everything:

• reducing (health) inequalities
• improving support for people with multiple long-term conditions
• shifting from a transactional to relational service design approach

These topics come up over and over again in slightly different forms. None of the keywords from those statements so much as make it into an h2, h3, or h4, and yet they are everywhere in the plan. This might be wishful thinking on my part – perhaps I am reading a superstructure onto the plan where it doesn’t exist simply because this is what I want us to be working on – but these are excellent cross-cutting themes to align work to. Being able to connect the more granular feature ideas to these overarching goals should be incredibly helpful for guiding teams toward understanding what good (and bad) looks like in delivery.

Translating between policy and delivery is hard. Each step in the translation pipeline is a place where the original intent can be misunderstood, skewed, or lost. We also need to make sure that the things teams learn on the ground when designing and delivering services can be fed back into the relevant policy holders so we can course correct together. We need to be able to fit the top-down (policy) vision with the bottom-up reality (of users), and change some part(s) of the system when things don’t line up. Right now, my main concern is how to set up a structure that helps teams do this for themselves, thus removing the middleman (i.e. me).

This past week we had the latest instalment of quarterly planning for NHS England’s Products and Platforms (the sub-directorate that the App team live in). These kind of cross-portfolio events can be tough – there is so much material to get through and so many details to try to keep in your head – but I found this particular instance of the event to be interesting, productive, and even kind of fun. My hat’s off to Trilly for running the event so well.

With the much-trailed 10 Year Plan due to be released any day now, this was was always going to be a weird event. Attempting to make plans for what digital delivery teams will do over the next quarter in these conditions necessarily involves a certain amount of guess work and an acceptance that things may get uprooted at short notice. And yet, plans still do need making to make sure the show stays on the road. We’ll see what, if anything, needs to change once the wider NHS directives are publicly issued. It is a form of meta-level agile delivery, I suppose.

The exciting part of the event was workshop on a set of themes that intersect all of our various teams, programmes, and portfolios. It took a while to figure out how to approach the discussion (definitions are hard!), but we got there in the end and I left with a sense of energy and enthusiasm for the work to come. In the current climate of change and uncertainty, this is not nothing! The group I was part of managed to make what felt like significant progress, and maybe even a breakthrough, on working through ideas that connect all of the teams represented in the session.

We discussed how a few different services are related, where we were failing to make the best possible use of what we already have at our disposal, and why. To fix this problem, the main lever we have at our disposal is how we arrange ourselves and how we define our internal boundaries. My main takeaway was that there is more enthusiasm than I had imagined for reconfiguring how our teams relate. This could in turn improve our products and services, possibly in a pretty radical way. As ever, connecting stuff is hard, but we have the right people involved. Now we just need everyone to be able to focus on the next steps for long enough to get product teams off the mark. Unfortunately, this is is a place we’ve stumbled in the past.

With so much work to do and so many priorities, staying focussed on cross-cutting work that could reshape the operating environment is extremely hard. When things get hectic (and they are often hectic) there is a natural sort of entropy that sets in, causing people to retreat to working inside their well-defined project or programme boundaries. It is a coping mechanism for dealing with mess and stress, but it needs to be resisted or nothing will ever change. We need to stay with the trouble, so to speak (no, this is not what the book is actually about).

Coming out of the planning event, my main question was what work could be stopped in order to create space for teams to think about, and then act on, the big ambitious ideas that everyone wants to go after. Stopping things we had planned or committed to in favour of trying something that might not work out is a hard sell to the powers that be. Everyone wants the delivery train to keep on rolling. I think this is one of the main reasons consultancies get brought in to explore new terrain. That makes sense, but it also means that the people with the most knowledge of how things work never get a chance to reshape their world in the ways that they’ve been thinking about for a long time. We know what needs to change, we just need space to do it.

For examples of what happens when we aren’t able to fix the routing and connect the bits, see Tom’s monthnote and Ian’s blogpost, both of which are accurate and harrowing.