Service design in the public sector is, as Lou says, 10% innovation and 90% archaeology, and never more so than when working in a great national institution in its 70th year.
Realising I needed to learn more about the history of our National Health Service, I asked the Twitter crowd where to start. Here’s what people said:
Lorna highlighted the work of the NHS at 70team, to create a shared social history of the NHS
Dean recommended starting with the 1942 Beveridge Reportwhich set out, in the middle of the Second World War, a comprehensive new vision for post-war social welfare
This is part two of some personal reflections on my first six months at NHS Digital. Catch up on part one here.
The design team we need.
Many of our designers are highly motivated by the mission of the NHS. They must also be critical friends. Friends don’t let friends settle for second best when it comes to what’s possible with user-centred design. We need our new recruits to bring to the table diversity of background, empathy for all our different users, and a wide range of skills to conceive and realise a continuously improving service.
We’re still finding the balance between working embedded with programmes while being a unified team. In the next phase, a tactical approach to recruitment needs to give way to a strategic structure organised around user archetypes and needs states.
There are so many open goals for user-centred design in the NHS, and not enough players on the pitch to score them all. Partly we’ll grow the numbers by recruiting more people to our team. While recognising that some skills are hard to find right now, we don’t always need to fish in the same tiny pond as our job market competitors. We can also do more to grow our own talent, from entry level through to making great designers into future design leaders.
I hope very much that we are developing a team culture of consistency, fairness and respect. We need to develop and maintain parity of esteem between our three main design specialisms: service, interaction and graphic design. While they differ in the materials they work with, they all share a core user-centred practice.
The foundation of a successful design team is simple: designers talking to each other.
First, designers lead other designers to achieve more together than they could alone. The growing team becomes self-organising as they share their work, seek advice, and give constructive peer review. It’s a joy to see designers stepping up like this, and important to give them space and trust when they do so.
Next, design as a practice starts to lead the wider organisation to achieve better outcomes. This requires confidence, capability and visibility among the design team, and a keen awareness of what the organisation’s non-design leaders are trying to achieve. I feel fortunate that many here are open to new approaches. More often than we realise, we’re pushing at an open door.
Some things I will remind myself to do every week:
Today it’s six months since I started at NHS Digital. Along the way, I’ve written a bit about how we work on the NHS Digital Transformation Blog. For today though, I wanted to share some personal reflections here on my personal blog. I’ll do it in two parts, starting with the digital experience we deliver, and the platform for learning and delivery. Part two has more about building a team and design capability. These thoughts may not all reflect the opinions, strategies or positions of my employer — but I’m working on that :)
I’m still learning about the breadth of digital experiences we need to enable in health and care.
In every show and tell I’ve attended, every research session I’ve observed, there are unique nuggets of insight that show the sheer scale and diversity of the user needs we are here to meet. But there are some themes that come up time and again.
Simpler, clearer, kinder. Even more than other public services, we owe it to our users to make everything simple and clear. Many patients are the unrivaled experts in their own histories and conditions, but clinicians hold the medical knowledge and experience. Service insiders see and do procedures many time a week that their patients may encounter only once a lifetime. People who can perfectly well navigate complex services when in the best of health come to us at a low ebb. Fear and urgency act as temporary cognitive impairments. We need to make things simple, but never simplistic. We need to find ways to support people along journeys that seem straightforward in the abstract, but have many twists and turns as individual lived experiences. Often the best thing digital service can do is to get out of the way.
Sometimes an answer is not the answer. There’s evidence that people with knowledge, skills and confidence in managing their own health and care have better health outcomes across many conditions. This “patient activation” means moving beyond a learning paradigm of knowledge transmission – to a coaching-led approach, in which users construct answers that make sense in their own lives, and make up their own minds, with appropriate support. Before we get carried away about artificial intelligence, let’s build on our users’ human intelligence.
Design for humans, together and alone. Even when delivered by a cherished nationwide institution, healthcare is always personal. This plays well to our practices as user-centred designers. Throughout design and delivery, we aim to involve the individual beneficiary of the service. In health, however, that user is rarely one person, alone, accessing the health service for themselves. We must broaden our perspectives to perform not just person-centred, but family-centred, locality-centred, even population-centred design. The further down that list we venture, the more we must borrow tools and techniques from other disciplines, from policy and the social sciences.
Own the line of visibility. The line of visibility on a service blueprint separates the stuff that happens “frontstage” – seen by the service user – from “backstage” activities that may be just as vital to the delivery of the service but need not be witnessed by its beneficiary. Sometimes the curtain is there for a reason. To glimpse behind it would be a needless distraction. Sadly, many NHS communications are still filled with backstage jargon. That only baffles and disempowers the public. On the other hand, information may be withheld because it is wrongly assumed to be of no value to other parties. Letting people see behind the scenes can put them in control, and make them creative participants in the improvement of our service.
I can see the makings here of a platform for innovation across health and care.
One of the most rewarding days so far was the one I spent with colleagues and collaborators thinking about design principles for health and care.
This system is complex, in a Cynefin sense. We cannot control and understand it all, but we can probe and learn what patterns of digital intervention work in different contexts. The people who succeed here do so by working with, not against, the networked nature of the NHS. If we can grow enough of those people, and make it easy for them to run safe experiments, then we’ll have a platform for lasting system change.
A learning platform. We start by understanding the intent behind the things we’re trying to make. We prioritise and make decisions based on the best evidence available. Working at pace, we make prototypes and test to see if they have the impacts we intend. Sometimes it takes time for these impacts to be felt at the point of need. But when felt, they’ll be stronger, and scale faster, because of the care and attention put into learning in tandem with delivery.
Emergent patterns and standards. When I see a piece of work from one of our teams, I often ask myself, ‘are we trying enough different ways of doing this?’ We need to diverge before we converge on proven solutions. Only patterns that have proved themselves should make it into our pattern library and service manual.
Everybody wants to help. It’s been humbling how many people have been in touch wanting to help with design for digital in the health service. Thanks to all of you, and apologies to those I haven’t yet managed to meet with. We have lots to do here, and will need help in many different forms.
On the last day of Foocamp 2011, after a whirlwind of other fascinating conversations, Edd Dumbill introduced me to the business strategist and researcher Simon Wardley. Over a tasty Californian street food lunch Simon proceeded to draw me a literal back of a napkin sketch of his “pioneers, settlers, town planners” model.
I was intrigued because this tripartite structure seemed to mirror my own experience at Orange/France Telecom Group, in a division dedicated to the “industrialisation” of solutions pushed by the company’s powerful research and development division. At the end of our chat, Simon took my business card; on it he wrote, “Settler”.
Ever since, I’ve followed Simon’s writing, and, more recently the well-deserved success of his mapping technique as a way for large organisations to acquire some semblance of situational awareness. You should check out his highly readable and enlightening series of posts. In fact, the rest of this will only make sense if you have at least a passing familiarity with Simon’s model. But there are some aspects of the model that bother me, and this long-overdue post is to share them with you.
I write from the perspective of a serial settler. I’m the one who moved from print to new media just as America Online was carpet-bombing the developed world with connection CDs. I joined a mobile operator the year its customer base doubled thanks to first-time, pay as you go, phone buyers. I arrived at the Government Digital Service the week the first, 24-department, transition to GOV.UK was completed.
We settlers occupy a precarious yet privileged position. Simon’s other two archetypes can always reach for a handrail at one or other edge of the map. There’s always something so bleeding edge that only the pioneers geek out about it, and something so commoditised that only the town planners can get excited. But settlers are stuck in the middle, constantly jostled by both of the other tribes. I reckon this positions settlers well to see the others’ points of view, as well as to appreciate the pitfalls of the model.
My first big lesson is this: do not structure your large organisation by pioneers, settlers and town planners.
I know because I’ve been there. In 2009-10, Orange Group wasted valuable months that could have been spent learning about user needs for iPhone and Android apps on a turf war over whether to treat the app store as a site of innovation, industrialisation or commodity. Rather than seek consensus about where on the map any given component sat, each group was incentivised to claim it for their own. This set up a permanent three-way tug-of-war between the tribes.
As anti-patterns go, it’s not much better than the rightly derided “bimodal” approach to managing technology. By all means recognise that the map has different kinds of context, with different attitudes required. But put all the attitudes into cross-functional teams – that way they have a fighting chance of being able to respond as one when the world changes.
My second insight is that evolution is complicated – much more so than you’d guess by seeing the simple x-axis of Simon’s maps. As I traced in my post on the three lives of the front-facing camera, actor-networks form and re-form; unlikely components gain visibility; others recede. Things flip from commodity to innovation and back again.
The use of the term “evolution” bothers me. It carries strong implication of an inevitable unidirectional process. Only with the benefit of hindsight can evolution be said to be a straight line, and that’s just a trick of perspective.
In the words of Michael Mullaney who analysed 20 years of Gartner hype cycles, “we’re terrible at making predictions. Especially about the future.” Gaining a better grasp of the here and now – “situational awareness” – seems more useful. But mapping should not be mistaken for a tool with predictive power by implying that things naturally move from left to right.
Figure 20 from Simon’s Medium post titled “Everything evolves”
It also troubles me that the axes on a Wardley map are not truly independent. There’s a clear correlation between visibility and commodification, which sees most maps take on a top-left to bottom-right drift. This begs some questions. Is there a causal link between the two axes, and if so in which direction? Or might there be a third factor at play?
My experience of organisational dysfunction and dissatisfaction with “evolution” as an axis combine to one big conclusion. Accept this conclusion and I think mapping can be a valuable practice.
Here goes: All maps are socially constructed. Wardley maps are therefore an artefact of social science, not (despite the Darwinian metaphor) a life science. The x-axis shows not evolution but level of consensus.
Exhibit, this table of the different characteristics at different stages. It’s a chart that can only have come from years of astute people watching. Whether he knows it or not, Simon is an ethnographer par excellence…
Table showing characteristics and general properties of the different stages in Simon Wardley’s model
I say that as a good thing, not a criticism, but it has 2 important implications…
the process of mapping is itself part of the social construction. The act of observing always changes the outcome
a common manoeuvre to secure consensus is to create an illusion of objectivity, so maps contain the seeds of their own misinterpretation.
When we map, we are never disinterested observers. We all have agendas, and whether consciously or not, will use the mapping process to advance them. Elements only move from left to right on Simon’s maps because people move them! And not moving them, or moving them backwards is always an option.
Likewise, whether things are visible or invisible is often a matter of contention. People seeking prematurely to commoditise an element may claim that “users don’t care about x so we can treat it as a commodity.” For example, when it comes to matters like encryption, or where their data is held, user research shows that users don’t care – until one day suddenly they do.
As I was puzzling over this point a few weeks ago, Simon tweeted that: “All maps are imperfect representations. Their value is in exposing assumptions. allowing challenge and creating consensus.”
That is true. But one could just as easily use maps to launder assumptions into facts, delegitimise challenge (and still create consensus). If I wanted to lie with a map, the implied inevitability of evolution would be very convenient to me.
When historians of public service come to write the chapter for the 21st Century, more than a footnote must surely be devoted to the One Team Government unconference of 29 June 2017.
What I witnessed at Impact Hub Westminster was not the start of anything new. The roots of this movement go back years – from Martha Lane Fox’s 2010 letter to Francis Maude, through multiple UKGovCamps, and departmental digital transformation strategies. At times the event felt more like a school reunion.
Nor was it the end of our journey. Frustration and mutual incomprehension remain a reality between digital doers, service designers and policy people in many parts of the public sector.
Yet the way the event was conceived and realised felt like a functional prototype of the networked, empathetic, multi-disciplinary leadership that all big organisations will need if they are to flourish in years to come.
The purpose that animates One Team Government is itself a sign of a maturing movement. The digital pioneers won some early victories, but progress often stalled. Fortunately, from among their number is emerging a group who have figured out how to make friends with other tribes. Meanwhile the smartest people in the worlds of policy and strategy are drawn to collaborate with these designers and doers. Together they’re embarking patiently on a project to create shared new ways of working.
Paul Maltby is doing a great job of prototyping the One Team Gov manifesto, so there’s no point in me repeating here the full set of qualities one team leaders will display. Instead, I’ll focus here on some behaviours that came up in discussion as especially important at this time of synthesis.
They start by assuming that other people mean well and are doing their best. Harry Metcalfe reminded us of the risk of contempt culture, of looking down on others not in our chosen circle. I know I see that frequently among digital designers and developers. I’m sure it is present too among the policy and project crowds. “When people don’t understand each other they sound dismissive of each other,” observed Phil Martin. If we are serious about being one team, that stuff has to stop. Instead, as Lucy Knight put it, “make friends and don’t assume you know everything.” Find the thing that neither of you knows, and seek out the answer together.
They hold out for high standards of user-centredness and evidence. Being part of one team doesn’t mean lowering our standards to the lowest common denominator – it demands that we patiently explain to each other why we set the standards we do. This came across in the session led by Emma Gasson and James Reeve to share what they learned in the original #oneteam on the apprenticeships service. For service designers, this might mean insisting on ethnographic research methods to really understand what’s going on for users. For policy teams, it’s more than OK to seek robust evidence that triangulates the findings from design research. Share the video of the user struggling with the current service. Include the people who will operate the service, as well as those who will use it.
They’re militantly tolerant and inclusive.Kit Collingwood-Richardson, Janet Hughes, and the One Team Gov team worked incredibly hard to make the event a safe, diverse, inclusive space, and I hope their efforts paid off. In her opening talk, Department for Environment, Food and Rural Affairs Permanent Secretary Clare Moriarty encouraged everyone to “bring themself into work”. And that should also go for the people who weren’t at the unconference too. The scientists, the artists, the patient leaders, they may not fit the traditional mould of civil servants, but government needs their involvement more than ever.
They work at their most confident in the open. Clare reminded us of civil servants’ duties to be open and transparent, to maximise the benefits to society, and to account for decisions. We also need safe spaces to consider and make those decisions. Increasingly those spaces will be online, in digital public spheres. It was interesting to hear that when the Institute for Government sought to research among middle-ranking civil servants, the ones willing to talk to them were those working on digital services. I sense that for One Team Gov leaders, working in the open is far more than a legal obligation; it’s an emotional and practical necessity.
They’re not waiting for permission. Here’s the thing: these future leaders are forming their own networks and making stuff happen for themselves. They’re #OfTheGovernment not on the government. Please take that as a promise not a threat: they are a powerful force for good in the organisations lucky enough to have them. I’m quite sure that somewhere in the room that day was a future head of the Civil Service.
The One Team Government unconference was awesome. I’ll write another post about the event overall. For the time being, here’s a quick write-up of my session, in which I revisited the Gaps Model of Service Quality and how we might use it to embed #oneteam working in our organisations.
I might have done a better job of pitching my excitement about Parasuraman, Zeithaml and Berry’s seminal work from 1985, because when it came to the session, only two people turned up. But they were absolutely the best two people: thanks, Nayeema and Liam, for taking the time to talk this over with me.
I started by sticky noting the key features of the model, last cited on this blog in the post “Most of government is mostly service design most of the time. Discuss.” The authors propose that if we want to know why organisations so frequently fall short of meeting their customers’ service expectations, we should look to 5 gaps in the typical operating model where information and understanding get lost or misinterpreted. Becoming #oneteam means closing those gaps.
Nayeema, Liam and I talked though the gaps, and the tactics we might use to overcome them. As we talked, I tried to map the notes to the relevant parts of the gaps model.
These are some of the things we talked about…
Gap 1, between user expectations and organisational understanding
The importance of understanding the end-to-end service, which may be larger and more complex than the bit that our organisation or team delivers
We noted the positive trend for departments and agencies making big service maps, for example the Ministry of Justice’s digital justice landscape
The rising tide of user expectations, shaped by other digital services, making user needs a moving target that demands constant re-discovery
Gap 2, between understanding users and specifications that will meet their needs
We talked about the value of prototypes as specification – why describe the thing when you can show it?
But also the danger of confusion between a “vision prototype” and a functional one – when we show an alpha, we need to be clear what we mean it to prove
Risk of the team’s commitment to meeting user expectations being eroded in the face of organisational reality. We need regular top-up doses of primary research to keep us connected to users
Gap 3, between what we specify and the service we deliver
Are a user story and an epic enough? Probably not! The team needs to communicate and use multiple methods to make sure the intent becomes reality
Delivery is more than just the digital thing. We need to include everyone who contributes to the user’s experience early and often, not expect operations to come in at the last minute and fill in the gaps without context
Is it time to kill the concept of “business as usual”?
Gap 4, between what we communicate to users, and what we deliver to them
Rather than saving up for a big bang reveal to users, agile teams should be telling their story a little and often
We need to consider when to start communicating and to whom
As well as end users we should consider the expectations of other actors. Frontline workers’ past experiences may make them suspicious of change, and their cynicism will be communicated to users
Gap 5, between expectations and perceptions
This gap is different because it’s the cumulative result of the other gaps, rather than something we can influence directly
If we work on a service that people use repeatedly, we have more chance to influence their perceptions through experience of the service itself
Services with less frequent or one-off use profiles still come with expectation – but they’re more likely to be shaped by other services than our own
I asked whether this 32-year-old model was still useful to us in 2017. The consensus: yes, but we’d need to adapt it. We would…
Draw the gaps model to emphasise the feedback loop to understanding
Look for ways to cycle faster through changing understanding, specification and delivery to meet user’s rising expectations
Match the pace of introducing new ideas to delivering them
Minimise the hand-offs by asking one team to go on the whole journey together
