Bob Marshall – Think Different
The question of what a customer is (if anything) in the context of public services is one to be approached with trepidation. The bigendian battle has been rumbling for decades, occasionally flaring up into active skirmishing, without ever quite being resolved. One of the main reasons for that is that all the relevant words – customer, user, client, and so on – have a range of connotations, with proponents tending to focus on one set and opponents on another.
Yet another definition won’t solve that, though this one might have a better chance in the fight than most. A customer, this short post suggests, is:
Anyone who receives or anticipates receiving something (e.g. a good or a service) from someone else.
Perhaps the time has come to turn the problem round. Instead of picking a word and arguing about its definition, perhaps we should pick a definition and argue about which word best encapsulates it.
Rachel Coldicutt – doteveryone
This is a thoughtful and important piece which challenges one of the pervasive myths of digital services, and particularly digital government services. More, it argues, is not intrinsically better, for a number of overlapping reasons. Collecting more data than necessary carries costs – human and ecological, as well as financial and technical. In making that argument it challenges the naive equivalence between public and commercial services, and the assertion that the former are somehow failing if they do not ape the latter – summarised in the splendid line
The fact that neither NHSX or BBC R&D will send a rocket to Mars this year does not mean they are not innovative. It means they are not in the rocket business.
Matt Edgar writes here
Unusually for Strategic Reading, this post earns its place not by being new and timely but because it has become an essential point of reference in an important debate. It makes a very powerful argument – but one that is slighly undermined by the conclusion it draws.
It is a measure of continuing progress in the four years since the post was written that the proposition that service design is important in government has become less surprising and less contentious, as well as much more widely practised. It is a measure of how much more needs to be done that the problems described are still very recognisable.
So it’s absolutely right to say that service design is critically important for government and that much of what happens in government is better illuminated by service design thinking. But to assert further that that is most of government most of the time is to miss something important. Much of government is not service design and much of what is service-related is an aspect of a wider public purpose. The function of many government services is only in part to deliver a service, even where there is a service being delivered at all. So the five gaps which are at the heart of this post are all real and all can and should be addressed by service design approaches – but they are not the only gaps, so a solution which addresses only those is at risk of missing something important.
Kate Tarling and Matti Keltanen – Services and service organisations
The question of what a service is is both eminently straightforward and impossibly difficult to answer. This post does a great job of demonstrating the straightforwardness, in five pithy elements of a definition, but in fleshing out each of the five points, it also demonstrates the impossibility.
The problem is not that the definition being put forward is wrong or unhelpful. Quite the contrary. It is that drawing the boundaries of a service requires huge understanding, empathy and insight – and even then is unavoidably a matter of judgement rather than the consequence of the precise application of rules. It needs to be big enough to be clearly about satisfying a need rather than conducting a transaction; it needs to be small enough for it to be practically and organisationally possible to make it better. It needs to be sufficiently self-contained to be addressed as a single challenge, and sufficiently broadly based to avoid the construction or reinforcement of silos and the associated inefficiency of duplication. And across all of that – and more – we also need to be clear about the role of government and about whether that role is inherent or arbitrary. Back in the primordial dawn of digital government, a decision was made not to offer a government change of address service – on the grounds that when people move it’s never just government they need to notify, and that in any case the real service was something closer to ‘moving home’. And for that, government is not the service provider – but then nobody else is either. Perhaps we are driven to the slightly uncomforable conclusion that even with all possible understading, empathy and insight, a service is still defined, at least in part, by what a service provider says it is.
The Tangled and the Trapped
This post neatly captures and crystallises ideas which – as the title acknowledges – aren’t themselves new but have been overshadowed by the dominance of a transaction-focused mentality in much government service design. Sometimes, of course, a transaction is exactly what we are talking about and making them simple and effective is the right thing to do. But often the underlying need is not for the (still necessary) transaction but for something deeper and better connected. Getting closer to that involves
learning when to transact, when to intervene and when to do the thing in the middle, support.
As the original emphasis suggest, the middle category, support, is the key to this. Examples such as Mark Smith’s work at Gateshead and the wider set in Hilary Cottam’s Radical Help show the value – in both effectivness and efficency – from looking at people and the support then need before looking at services and tests for eligibility.
There’s a lot or richness in this post about identifying and applying some simple principles for doing that effectively. But it brings out very clearly that however much the design of single services is improved, the impact will be severely attenuated if there is insufficient focus on the wider context.
Cat Drew – Design Council
The double diamond is simple, elegant and intuitive – so much so that is has the feel of something which must always have existed, of being so well designed that it doesn’t feel designed at all. But of course the double diamond is as it is precisely because it is the result of design processes as well as a tool in many, many more.
It comes as a slight shock to be discover that it took form only 15 years ago, not least because if I were asked when I first became aware of it, I would have guessed longer ago than that, perhaps because I came to it from established ideas around divergent and convergent thinking. But it’s a good moment to step back and reflect on those 15 years and the value and variety the double diamond has offered.
Even better, it’s an invitation to look forward, to recognise that the double diamond has constantly evolved and mutated and that it will and should continue to do so – so if you have a double diamond story to tell or a double diamond prediction to make, this is the place to share it.
Todd Rose – The Star
The failure of product and service design to reflect human variety has been made more visible by work such as Caroline Criado Perez’s Invisible Women and Joy Buolamwini’s work on racist algorithms. Those are important and very necessary perspectives, but in a way they are both special cases of a much more general problem. There is a bad assumption implicit in many of the choices and decisions they and others write about that the average person is a white, middle class, middle aged male. But one of the reasons it is possible to fall into the trap of making that assumption is the more fundamental assumption that it is useful to think in terms of averages in the first place.
This article is a few years old, but it holds up well as a challenge to that assumption, in two important ways. The first and more straightforward is the demonstration that across more than a tiny handful of characteristics, nobody is average for all (or even most) of them. It follows that designing for the average is designing for nobody, not designing for everybody.
The second is that even then, facts are not neutral. There’s a good response to that evidence, which is that pretty much everything has to be to designed in a way which fits systems to individuals, not individuals to systems. But there is also a bad response, which is that if people fail to be average, they should work to remedy their deficiencies. And to complete the circle, it’s probably not altogether a coincidence that the example illustrating the first response is about men, and the example illustrating the second is about women.
Tristan Stanton – NHS Digital
This post – and the app it is about – stands as a kind of metaphor for digital public services much more widely. The app has a mostly slick front end, with a visual design which is both distinctively of the NHS and a clear descendant of the earlier work of GDS. But it sits on top of chaos which it can obscure only to a limited extent. It is a front end veneer for different systems, supporting different sets of functions and so fundamentally is not in control of its own user experience.
The post does a good job of explaining why that is and why, despite that, there is still value in the app. There is a circle which needs to be virtuous where a well-designed front end and a growing user base both demonstrate and create value to GP practices in improving their systems which in turn stimulates adoption and use by patients. But there is a risk that the circle turns vicious, that the expectations set by the modernity of the immediate user is undermined by the clunkiness of what lies behind. The good needs to drive out the bad, but the bad will not give in easily.
Andy Brogan – Easier Inc
This post is a double winner. The post itself, by Andy Brogran, has some important insights, but it is prompted by a presentation by Mark Smith which is a compelling account of what happens when you think differently about the delivery of public services and is well worth watching in its own right.
Brogan’s post includes a particularly clear and succinct account of why a process standardisation model borrowed from manufacturing is particularly unhelpful when thinking about the design of services – manufacturing works to deliver standard outputs from standard inputs through a standard process. But public services do not start with standard inputs and so cannot create value by applying standard processes to deliver standard outputs – and indeed the attempt to do so risks making thing worse, not better.
That serves to frame an account by Mark Smith of the work he has led at Gateshead, breaking into established processes to work out needs and root causes. An overdue debt can be a trigger for enforcement action, at risk of triggering a further downward spiral, or it can be a signal of an underlying need which, if recognised can be addressed. This is a combination of powerful, human examples and pragmatic approaches to understanding and meeting needs:
‘How much of what we do can we do to you?’ That’s not a great question. ‘What does a good life for you look like, how might we help you with that?’ That’s a better question.
Richard Pope – Platform Land
The third part of Richard Pope’s strategic musings is as thought provoking a reflection as the earlier two, though this post is perhaps making a rather different point from the one the headline suggests.
It opens with the idea of small pieces loosely joined, which remains one best descriptions of the web and of quite a few other things besides and leads smoothly into the idea of shared components and services across different governmental organisations. On the face of it, that makes a lot of sense in terms both of system efficiency and of delivering coherent services. Institutional and power dynamics within governments don’t make that easy. The level of trust within governments can be surprisingly low to those who look from the outside and see something monolithic. There’s a whole host of reasons for that, but one of them is the lack of recourse if things do go wrong, with an understandable reluctance to place reputation and service quality on a foundation which is not itself robust. And so the post arrives at the fundamental question, which is not to do with components or APIs at all, other than as the visible symptom of a much deeper issue:
The question governments therefore need to answer is this: what are the appropriate characteristics of institutions capable of operating shared infrastructure for the greater good rather than the priorities of a thematic agency, while remaining accountable?
One answer is to create new institutions whose job is to do that – GDS in the UK is an example. But if, as this post suggests, that model is under threat, that may be a sign it might not be the optimal approach either. So the problem remains very real, the search for solutions continues. Networked government – of small pieces, loosely joined – remains elusive.
Nicole Badstuber – London Reconnections
Algorithmic bias doesn’t start with the algorithms, it starts with the bias. That bias comes in two basic forms, one more active and one more passive; one about what is present and one what is absent. Both forms matter and often both come together. If we examine a data set, we might see clear differences between groups but be slower to spot – if we spot it at all – skews caused by the representation of those groups in the data set in the first place. If we survey bus passengers, we may find out important things about the needs of women travelling with small children (and their pushchair and paraphernalia), but we may overlook those who have been discouraged from travelling that way at all. That’s a very simple example, many are more subtle than that – but the essential point is that bias of absence is pervasive.
This post systematically identifies and addresses those biases in the context of transport. It draws heavily on the approach of Caroline Criado Perez’s book, Invisible Women: Exposing the Data Bias in a World Designed for Men, illustrating the general point with pointers to a vast range of data and analysis. It should be compelling reading for anybody involved with transport planning, but it’s included here for two other reasons as well.
The first is that it provides a clear explanation of why it is essential to be intensely careful about even apparently objective and neutral data – the seductive objectivity of computerised algorithmic decision making is too often anything but, and why those problems won’t be solved by better code if the deeper causes discussed here are not addressed.
The second is prompted by a tweet about the post by Peter Hendy. He is the former Transport Commissioner for London and is currently the chairman of Network Rail, and he comments
This is brilliant! It’s required reading at Network Rail already.
That’s good, of course – a senior leader in the industry acknowledging the problem if not quite promising to do anything about it. But it’s also quite alarming: part of the power of this post is that in an important sense there is nothing new about it – it’s a brilliant survey of the landscape, but there isn’t much new about the landscape itself. So Hendy’s tweet leaves us wondering when it becomes acceptable to know something – and when it becomes essential. Or in the oddly appropriately gendered line of Upton Sinclair:
It is difficult to get a man to understand something, when his salary depends upon his not understanding it!
Matt Jukes – Notbinary
Hertz wants a new website. They do a deal with Accenture to produce one for $25 million. It all goes horribly wrong. And it ends up in court, which is the only reason anybody else gets to know about it. Nobody is particularly surprised.
That’s the point from which this post starts, rapidly homing in on the question of the expertise Hertz should have had, but didn’t have, on the client side, and the delusion of outsourcing the product owner role to the supplier. That’s not really about the contractual relationship (and so is just as important when outsourcing is not at issue), it’s about the nature of the product owner role, which this post captures beautifully.
One thing which comes out particularly clearly is that treating product ownership as an ‘agile’ role, rather than as an organisational role can contribute to the misjudgement at the heart of the Hertz/Accenture dispute. That confusion can be seen in other contexts too – in the UK government, for example, treating product ownership (or in their language, service ownership) as one of the digital professions risks introducing a version of precisely that skew (which doesn’t, of course, mean that it necessarily does in practice) and so makes it even more important to focus on the core attributes of the role, without their being submerged by the process – important though that is for other reasons.
Matt Ballantine – mmitII
Transactions are bounded, manageable and measurable, which makes it makes them appear easy to improve and easy to tell whether some forms of improvement have been achieved. The temptation which results is to focus on improving transactions and, more subtly, on making more things more like transactions. There are some advantages in doing that, which is why it is so often done. But the more things are transactions, discarding the rich messiness of human variability, the less they are interactions.
That’s the starting point for a post which turns out to be about something rather different: how do organisations best support collaboration and effective team working. The connection is that while transactions are readily scalable – that’s almost the point of them – interactions aren’t. So in a world where organisational change tries to make things more transactional in contexts where interaction is vital, working out how to scale and systematise interaction without killing it off in the process becomes particularly important.
Digital government is both something and nothing. It is something because there’s no denying that people use the phrase and think they mean something by it. Digital technologies are a distinctive driver of change in modern societies and economies and they make things possible that would be otherwise harder or not feasible at all. Filing cabinet government. carbon paper government and even mainframe government are all very clearly different from digital government. And yet digital government is nothing. Precisely because digital is everything, calling something digital doesn’t add much to understanding, but draws attention to the technology, which is simultaneously vitally important and not the thing which really matters.
But given that the phrase is not going to go away, some clear-headed thinking about what we should understand by it and how we should apply is highly desirable. And that is precisely what this paper offers. It’s a draft open to public comment, so very much still evolving, but it’s already a useful overview. It neatly and successfully avoids the traps of equating digital with technology and digital uniquely with service design, but is slightly less successful in avoiding the suggestion that digital is done by digital teams.
Rachel Hope – DfE Digital and Transformation
Most of government is mostly service design most of the time. That’s a pithy and powerful assertion, and has been deservedly influential since Matt Edgar coined it a few years ago. But influential is not the same as right – and indeed the title of Matt’s original blog post ended more tentatively with ‘…Discuss.’
This post, which is in effect a case study of acting as if the assertion were true, throws useful light on what it could mean. In doing so it makes it easier to see that there is a risk of eliding two questions and that it is worth answering them separately. The easy first question is whether policy and delivery should understand and respect each other and expect to work in close partnership – to which the answer must be yes. The harder second question is whether the venn diagram does – or should – eventually consume itself to become a single all encompassing circle. Verbally and visually, the argument of this post it that it does, and that argument is powerfully made in respect of the service it describes. But that still leaves open the question of whether the model works as well when the service is less specific or delivered less directly.
‘Start with user needs’ has been the mantra of digital government since the early heady days of GDS. It’s a thought which is simple, powerful and – this post argues – wrong. Or, more accurately, unhelpful: it’s a concept which both lacks precision in its own right and risks being too tightly coupled to the construction of solutions.
This is not some random hit job, but a deeply reflective post which brings out clearly where user research most adds value, by being still clearer about where it doesn’t. In doing so it draws out a point which is relevant and important to a much wider audience. It positions user research as a means of reducing risk – and that is important not just as a way of helping senior decision makers see the value in it, but because basing decisions on unexamined and untested assumptions leads to bad consequences (and has been doing since long before government was digital).
Dan Hill – But what was the question?
This is quite a demanding essay. It demands some time to read, at about 6,000 words, and it demands more time to reflect, not least because it is subtly challenging. How do we design our interaction with our urban environment in a world of new technologies? How do we balance optimisation for individuals against optimisation of wider systems? How, more broadly, do we ensure that social objectives drive the adoption and deployment of technology rather than being driven by them? Or to step back from the detail (and in some ways from the specific subject), there’s a pretty strong consensus on what user centred design means for individuals; much less so on what it might mean for groups of people whose lives and activities intersect and affect one another.
There are clear examples of what new approaches to design might look like and of how they have been applied. But there isn’t much here about the social and political approaches which create the space for those design approaches to flourish. It’s unfair to criticise this essay for not doing something which it makes no claim to do, but the concept of ‘strategic design’ it introduces perhaps has a further level still.
Emily Tulloh – Futuregov
This is a post about what’s involved in doing service design and, taken at face value, it’s a pretty good one. But it also works as an extended metaphor for other kinds of change development, and for strategy in particular. Figuring it out and making it real are presented here as the fundamental stages of service design – but pretty much everything said about them works in terms of strategy too.
One version of that parallel is drawn within the post itself, with figuring it out equated to strategy and making it real equated to delivery. But it also works – and arguably works better – to see strategy as the parallel to the whole service design process: a strategy which does not take account of its own approach to delivery is one with a pretty important gap.1216ethn
Bas Leurs and Kelly Duggan – Nesta
Testing, piloting, prototyping and a few more words besides all mean something similar, but all mean something different – though whether we would all agree on quite what the differences are is another matter.
This post sets out to distinguish and to map the scope of four approaches and to argue for greater rigour in their usage. The distinction is definitely useful and the rigour is definitely desirable, though the quest for absolute rigour of specialist language in general usage tends to end in disappointment. But that’s not a reason not to be as clear as possible, and it’s certainly not a reason for practitioners to be anything other than precise both in their understanding of what they are doing and in how that understanding is shared.
Audree Fletcher – Medium
This is a short, elegant, epistolary post on how design and policy come together – or rather about how they might do so better. There often is a gap between policy thinking and design thinking, though one that’s more an accident of history and career paths than of underlying incompatibility. But the contrast sketched here perhaps over-emphasises aspects of the difference: many politicians are interested in more evidence-based and iterative policy development, the trick (as the post recognises) is doing that in a way which creates a space for things not to work without being labelled as failures. And that should be one of the ways in which more traditional policy making skills complement design-based approaches.
Of course it doesn’t always work in that relatively benign way, far from it. But there are great insights here into how it might work better more often.