Category: Service design
Transactions v Interactions
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.
A brief introduction to digital government
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.
How service ownership works in DfE
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).
The city is my homescreen
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.
Two sides of service design
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
Proof of concept, prototype, pilot, MVP – what’s in a name?
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.
Design in policy
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.
Beyond human-centred design, to?
A year ago, Cassie Robinson wrote a great post on why the mantra of starting with user needs was too narrow an approach to understanding the wider context of service design. This post builds on that one to explore eight types of design, or rather eight approaches to design thinking.
They don’t flow from one to the next in a completely sequential way, but they do broadly represent a gradual zooming out from the simple base case of individual user needs, starting with relational design (thinking about those directly affected by a service, not just the individual service user) and going all the way to life-centred design, the recognition that design takes place in an ecological context, at every scale from local to global.
It’s pretty clear that these eight approaches aren’t discrete or sequential, and indeed that they blur into each other. So the response of the designer should not be to pick the one or two which seem most immediately relevant, but to reflect on how the presenting problem is best understood in the wider context. This post is a great starting point for framing that thought process.
Internet-era ways of working
Tom Loosemore – Public Digital
This is a deceptively simple list which describes ways of working in internet-era organisations. The GDS design principles are clearly among its antecedents, but this is a broader and deeper approach, setting out how to make things work – and work well – in organisations. It’s hard to argue with the thrust of the advice given here, and in any case it ends with an admonition to do sensible things in the right way rather than stick rigidly to the rules.
That doesn’t make the approach beyond criticism, both in detail and in approach, though it does have the happy consequence that challenge and consequent improvement are themselves part of the model being advocated. With that starting point, there are a couple of places where a further iteration could improve things further.
One is the instruction to treat data as infrastructure. The thought behind that is a good one: data matters, and it matters that it is managed well. Well ordered data is part of infrastructure at every level from the national (and international) downwards. But data is also part of the superstructure. Managing, processing, and creating value out of data are fundamental to the purpose and activities of organisations. Both aspects need to be understood and integrated.
A more subtle issue is that while it might be clear what counts as good internet-era ways of working, much of that work happens in organisations which are barely of the internet era at all. Precisely because it does challenge established approaches, established power structures and established infrastructure of every kind, the path to adoption is far from straightforward. Looked at in that light, this list is oddly impersonal: it is couched in the imperative, but without being clear who the orders are addressed to. There is a dimension of behavioural and organisational change which never quite makes it to the centre of the narrative, but which for organisations which are not native to the internet era is critically important.
None of that is a reason for not following the advice given here. But some of it might be part of the explanation of why it needs to be given in the first place.
One of the unavoidable problems in curating a site like Strategic Reading is that lots of the posts and articles end up slightly blurring into one another. That’s a good thing in many ways: ideas build on each other, views of the world coalesce, but it can sometimes feel as though there isn’t much really new thinking.
This post is different. It is deliberately disruptive and challenging and provides some useful insights into a problem which has existed for a long time, but has been largely overlooked. What counts as the right kind of knowledge to understand and use technology effectively? It isn’t in itself technical knowledge – telling everybody to learn to code is no more effective than addressing transport management problems through the medium of car maintenance classes. And it isn’t stepping away, leaving such issues to the priesthood of the initiated. The limitations of that model are increasingly obvious in a world where big companies refuse to acknowledge or understand the sociology of technology.
The answer suggested here is something called ‘technical intuition’ (which is a slightly odd label, since it’s about being knowledgeable rather than intuitive), which allows people who are not technically expert to imagine, to inquire, to decide and to demand. That’s then brought to life in an example about an individual deciding whether to sign up for a supermarket loyalty card. That’s fair enough in its own terms. Personal understanding of the implications of technology related decisions is really important (and closely related to what Rachel Coldicutt calls digital understanding).
But that leaves us with two essential questions, which are left implied but not addressed. The first is where this intuition is to come from. If it is a body of knowledge, how is it to be assembled, conveyed and absorbed – all of which are preconditions to its being acted on. The second is how it then scales and aggregates – both in terms of where the social (as opposed to individual) acceptability of loyalty cards comes from, and, very differently, how that leads to confidence in other kinds of decision making. What is the technical intuition we should expect supermarket executives to display in designing loyalty cards in the first place? And in some ways, that is the most important question of all.
Usable to Understandable to Responsible
Rachel Coldicutt – Doteveryone
This is a great set of slides which (among other things) teases out the idea of ‘needs’ in relation to public services, clearly and powerfully making the point that it is not enough just to consider the needs of individual end users.
The picture is in the presentation, but came originally from a post by Cassie Robinson a few months ago. The GDS admonition to start with user needs is not wrong (quite the contrary), but there will rarely, if ever, be a single set of answers. And as Tom Loosemore observed, prompted by that illustration and quoting Richard Pope, ‘sometimes the user need is democracy’.
But there is more to the presentation than just that insight, important though it is. Ease of use is not the same as depth of understanding, and the simplicity of a service design does not mean that it is simple or self-contained in the way people come to it and use it. Needs are important, but so are interests – which means that service design has to embrace much more than the transactional experience.
Interview in Offscreen Magazine
Behind this remarkably anodyne headline is some compelling reading. This interview tracks Tom’s working life over more than twenty years, but in doing so is hugely illuminating about the intellectual, moral, and political history of digital public services, up to and beyond the creation of the Government Digital Service. As ever, understanding how we got here is indispensable to a good understanding of where we are.
The interview very clearly brings out why it was important for GDS to be set up in the way that it was, needing to avoid the existential risk of getting trapped by the inertia of large organisations.
The idea was to build a bubble in which the main strategy was delivery: let’s deliver great stuff so quickly that bureaucracy can’t catch us.
It also shows how important it has been (and continues to be) to put creative effort into making things which had been obscure more visible, in ways which shift the balance of power away from institutions and towards individuals. That recognition may though have obscured the extent to which that can only be a part of what people need from government. – which is perhaps one reason why the original emphasis of GDS was so much on better information provision, with the recognition of the importance of government as service provider only coming later.
Then we realised that the real heart of public services isn’t just providing information, it’s transactional service […] It’s great to have a website that tells you what to do, but doing the thing, that’s the actual service. And that’s a much harder problem to solve.
Perhaps the most powerful point – and one still not sufficiently recognised – is the recognition that modern, effective and efficient government is not the same as uniform, self-service and largely invisible government.
In government the risk of ‘designing for people like us’ is much greater than for most businesses. Many of us are in a position from where we see anything government-related as a hassle. We want it to disappear or reduce the friction of government interaction to zero. I think that’s a dangerous over-simplification, because the people who really need government the most don’t want the government to disappear. Quite the opposite. For those who are really struggling – and it could be any one of us at some point in our lives – the government is a safety net, and that safety net cannot be invisible nor completely frictionless. We need to facilitate a proper relationship between someone with a difficult problem and a public servant.
Of course the reason why teams such as GDS and its comparators in governments around the world need to be set up to subvert the stodgy institutions of government is precisely that they are stodgy. No doubt influenced by the audience of the magazine in which the interview first appealed, the heroes of the battle against the stodge turn out to be tech people
We need people to go in there and ruffle some feathers, show good leadership, and inject a new culture. If the machine rejects you, fine, try another way in or do something else. As someone working in tech you’re not going to struggle to find a new job, really.
There is a very real danger of hubris in that attitude, not so much from Tom himself, but from many who have followed him into (and often back out of) government. The policy traditions of government undoubtedly need to absorb the shock of digital, but that won’t be successful on a sustainable basis unless those who embody the digital perspective also make the effort to understand government, politics, and public services.
Do you think an improvement in service delivery is enough to regain the public’s confidence in government and politics in general?
That’s our only bloody hope!
Government service delivery needs to improve, for all the reasons Tom argues for. But that is far from being our only hope, and seeing it as such risks missing something important about government – what it is, as well as what it does.
Designers as power brokers
If designers can redistribute power, the choices they make are political – the distribution of power, and the choices it enables, being fundamentally what politics is about.
That is, of course, true regardless of whether designers recognise or acknowledge that that is what they are doing. This post does make – and celebrate – that acknowledgment, without perhaps fully following through the implications. The claim is a strong one:
As a designer in government my role is to give power to those people who often feel disempowered.
Giving power to the powerless is not a self-evidently neutral ambition. Digital is inescapably political.
That’s not to say that that ambition is wrong or is one that designers should not pursue – or even that expressing it in those terms is necessarily politically controversial. But “to redress the balance between the powerful and the disempowered in our society” is inescapably political – and so leaves us with the question of whose choice that is or should be.
15 principles of good service design
‘What is good service?’ is a question which is simultaneously very easy but remarkably difficult to answer. It’s easy because, as service users, we all have a strong sense of what is good and bad about our own experience – perhaps including those times when the best service is no service. But it’s very hard because those impressions don’t readily translate into a reliable way of telling whether a service is good, still less so whether a given design approach will result in one which will be good.
This post attempts to fill that gap with a set of principles of good service design. It’s presented as a first attempt, with an invitation to make comments and suggestions – but there is nothing sketchy or ill thought out about it and the list very much stands on its own merits. But in the spirit of that invitation, it’s perhaps worth asking a question and making a suggestion.
The question is about the intended scope of these principles. Reasonably enough, their starting point will have been the design of government services and more particularly their design in a modern digital context. But that’s not the only domain of service experience or service design. Are these universal principles, as applicable, say, to the service experience of going to a restaurant as to the service experience of getting a passport? Or is there something sufficiently different about them that different principles apply – and if there is, what is that difference, and what effect should it have?
The suggestion is rather simpler, a candidate additional principle, partly prompted by the idea of a thing avoided as well as of a thing experienced:
Be in the background whenever possible; be in the foreground whenever necessary
Digital Government and Public Service Transformation
This simple and powerful set of slides does an extraordinarily good job of summarising the key issues in digital transformation, not least in being really clear about the extent to which all of this is a technology issue (not as much as it looks) as opposed to an everything else issue (much more than it first appears). The section on ‘deciding how you want to work’ gets twice as many slides as ‘thinking about your technology needs’, which is a pretty strong indicator of the approach being taken.
It’s certainly possible to challenge some of the details. The arresting assertion that ‘we can broadly take for granted that technology can do whatever we want it to do’ perhaps has more power than precision – though the slightly lesser claim the technology needed to support government processes already exists is indeed a useful reminder that appeals for technological exceptionalism are very likely to be misguided. The insistence that agile projects can’t succeed in organisations which retain traditional approaches to funding and governance is both wrong and unhelpful: wrong because there are plenty of example of where it has succeeded, and unhelpful because every organisation has to start somewhere, and if agile can’t work at all unless everything is agile, there is effectively no way of making that start.
Overall, though, the strengths far outweigh the weaknesses – and this is a beautiful example of doing the hard work to make things simple. As a further bonus, the slides are open for comments, and have already sprouted a rich set of observations from Matthew Cain.
Digital Transformation at Scale – a review
It’s probably not news to most readers that some of the leading creators of the Government Digital Service have written a book. Many have been swift to observe the apparent irony that the book in question has been published only on paper, with no digital version available. That’s a fairly major obstacle fort those of us with a strong preference for the latter.
But now an alternative solution presents itself, in the form of a thorough and balanced review by Matthew Cain. The creation of GDS by Mike Bracken and his team was an enormous achievement and, despite its detractors, much good continues to be done there well after the first generation of pioneers moved on. But the founders’ vision was a narrower one than they ever quite acknowledged and the government context in which they found themselves was more unusual than they realised – or as Matthew puts it, ‘The section on political sponsorship basically tells readers to have a political sponsor called Francis Maude.’
Update: 22 June 2018
The publisher have helpfully made contact to share the good news that the book is now available on kindle, and apparently is due to appear in other formats. But that leaves unanswered the perennial mystery of why publishers find it so much harder to produce electrons than paper.
Designing public services for Mars
This is a session pitch for an event which has not yet happened, so it’s a tantalising paragraph rather than a developed argument. But it’s getting a mention because of the power of the thought experiment which lies behind it. Maybe the day will come when the design of public services for Mars will be an immediate and necessary question demanding answers. But we don’t need to wait for that day to ask what it would be like to design public services if we were not constrained by everything which has gone before – which ends up being very similar to Ben Hammersley’s provocation. Down here on old Earth we can’t wish away the installed base, which makes things harder (though we do have a breathable atmosphere, which balances things out a bit), but we don’t have to let our goals be constrained by it.
To take the next step on digital, we dropped the word ‘digital’
James Plunckett – Citizens Advice
The word ‘digital’ has long been both powerful and problematic. It’s powerful because new technologies and, in some ways even more so, new ways of developing and applying new technologies have made many things better, faster, cheaper – and often very different. And as Tom Loosemore, perhaps the leading proponent of using ‘digital’ in a sense which transcends a narrow, technical meaning puts it:
You find you need a name to describe that new way of working that is shorter than user centric multi disciplinary iterative open agile etc…
— Tom Loosemore (@tomskitomski) May 24, 2018
But it’s also problematic, because it stretches the meaning of ‘digital’ so far as to drain it of content. It has become a vague word, implying modernity and goodness and not much more. More seriously, it puts the emphasis in the wrong place: digital is a means, not an end, and there is always a risk that in focusing too much on means, we lose sight of the ends.
That’s not to say that ‘digital’ has not been a useful word. In many ways it has been. It’s more to say that the time has come – and is arguably long past – when we should move beyond it. That makes this post a really interesting sign of what may be to come: Citizens Advice has chosen to replace its Chief Digital Officer with a Director of Customer Journey, and its reasons for doing so are well worth reading.
The role of truth in designing interfaces to public services
At GDS’s Sprint 18 last week, the team from the Land Registry presenting their work on online registration of mortgage deeds made an arresting statement: while they could provide instant confirmation that a transaction had been successful, their customers expected there to be some processing time, and were much more reassured by a short delay while the system supposedly updated itself.
Land registry has deliberately built in a delay to the "Sign your mortgage deed" service as users mistrusted a too quick confirmation. Love it! #Sprint18
— Amanda Payne (@mandalyn97) May 10, 2018
That prompted the re-circulation of this thoughtful post from a year ago. If you want to be pretentious you could say it’s about the ethics of form design. If you want to be pragmatic, you could say it’s about how to stick to the rule of thumb that users should only be asked the questions which are necessary to move the service on while also meeting their need for a sense of closure and completeness.
The post rather neatly resolves the tension – and makes an important point in its own right – by recognising that people have emotional as well as transactional needs, even of something as apparently straightforward as a simple form. That can result in a situation where a service can be made better by being less honest, which is not a comfortable place to be. Lots of good food for thought even for – perhaps especially for – those of us who don’t design forms for a living.