One Team Government Service design

Digital means learning and iterating as you go

Clare Sherwood and Joanne Gillies

At a time when some are feeling a sense of government blogging getting more sanitised and homogenised, it’s good to come across a post so clearly connected to the real experience – good and bad – of people who, as a result, still sound like people.

This post is worth reading for the substance as well. The question of how we best bring together the skills and experience of people expert in government and policy making with the pace and perspective of people expert in service design and solution delivery is one which is still very much with us. The founding premise of the one team government movement was that those two groups each have much to learn from the other: this post illustrates both the power of that insight and how hard it is to act on it systematically.

One quibble with the argument is the way the word ‘digital’ is used. There is a sense that agile, customer-focused, design-led approaches are somehow digital while, by implication, not-digital things are based on different and inferior approaches. That’s not wholly wrong – but it’s not wholly right either, and doesn’t encourage the melding of approaches rightly being suggested here. Success is more likely if it is not ‘digital thinking’ which is dispersed across the organisation, but approaches to problem solving which are valuable in their own right.

Service design

Electric woks or eating together? Time for human-centred designers to care about the community

Matt Edgar

There are exciting new technologies which can improve – and indeed transform – the quality of services. There are many services crying out for better design, to be better attuned to meeting the needs of users of the services. It is tempting – and all too easy – to let those two statements collapse into each other. The risk of that happening becomes greater the more that disciplines such as user research and service design are seen as elements of doing digital, rather than digital being seen as one set of approaches for responding to them.

The general problem with that is that it becomes possible to slip into thinking that the solution people need is the one we happen to have. A more specific consequence is an insidious tendency to assume that the focus of service design should be on the experience of a single, self-contained, individual user. Sometimes that might be the right approach, but often it will miss something important about the wider social context and the wider set of human needs.

This post neatly illustrates that and asks some important questions about moving service design beyond the purely transactional. And you probably don’t need an electric wok.

Democracy Government and politics Service design

Democratic technical debt

Alex Blandford – Medium

The modern surge of digital government has many strengths, but it also has a central weakness. It tends to assume (usually without noticing that it has done so) that the central relationship between individual and state is that between a service user and a service provider. That relationship does, of course, exist and making it work better is vitally important. But if that’s all there is to it, we risk creating something more atomised and more shallow than it could be or should be.

There are two missing pieces from that service led view. One is that the role of a government service user goes beyond the specific interaction or transaction of the moment. The other is that there are legitimate interests in the service and how it is provided which goes well beyond those who are specific users of it. Systems have democratic and social value, as well as transactional value, and to miss that is to miss something important.

This post explores the implications of that in one specific way, as well as more generally. Building on the idea of technical and organisational debt, now democratic debt comes into the mix as well. The slightly unexpected specific point which comes from that is the importance of thinking about user research differently, and recognising that cumulatively it represents a corpus of social research which beyond its immediate use is almost invariably unpublished, unseen and thus unusable. The challenge is to find a way of curating and using that research and the insights it has generated to drive down democratic debt.

Government and politics Service design

Making public policy in the digital age

Richard Pope and Andrew Greenway – digital HKS

It’s worth looking out for things written by either of these authors, something written by both of them should be doubly worthwhile. There is indeed lots of extremely sensible advice in this piece – and that is so despite all that advice being built on a slightly questionable assumption. Good digital services, they tell us, are iterated daily, or better still hourly. Bad policy development, by contrast, is a long and painful process. The solution is obvious: if policy making were more like digital service iteration, the world would be a better place.

That thought is not wholly wrong. Smarter, faster, better policy making should indeed be everybody’s aim, and the suggestions made here are generally good ones. But it doesn’t follow that policy and service design are somehow interchangeable, or as they put it, “the policy is the service is the institution”. Designing policy to be deliverable and adaptable is indeed important, but so is designing policy to be socially and politically effective. Evidence gathering, consultation, legislation and evaluation can be frustratingly slow, but that doesn’t mean that they are best dispensed with. Policy is about service design, but the set of users of a policy is often much broader than the set of users of the service through which it is expressed, and both those perspectives matter.

Service design Work and tools

Designing better organisations: Why internal user experience matters to delivering better services

Ben Holliday – FutureGov

The quality of internal user experience is a good indicator of an organisation’s underlying attitude to user experience and thus of the service the organisation delivers. And of course the more distracting and time consuming internal services are, the less time and energy are available for the organisation’s real purpose.

That’s the core argument of this post and it is one which will resonate with many on the receiving end of such services. The conclusion it draws, that in seeking to transform an organisation, transforming its internal processes is a good place to start, may be less obvious, but is certainly worth thinking about.

Organisational change Service design

Seven public sector trends

Martin Stewart-Weeks – Public Purpose

This is a wide-ranging and thought-provoking survey of the public policy landscape, examining trends setting the context for public sector reform ranging from reversing decline of trust, through rethinking the scope and nature of digital transformation, to blending policy, design and delivery. All of that is bound together by a recognition that these are all systems problems – or, arguably, all facets of a single systems problem – and the test of change in that wider system will be whether authority, money and power flow differently from the way they do today.

Innovation Service design

Usability of Key Distribution in BlockChain Backed Electronic Voting

Terence Eden

This is a good post on the very practical difficulties in establishing secure digital identity, in this case for the purpose of voting in elections. It’s included here mainly as a timely but inadvertent illustration of the point in the previous post that even technology fixes are harder than they look. Implementing some form of online voting wouldn’t be too difficult; implementing a secure and trustworthy electoral system would be very hard indeed.

Innovation Service design

A New Approach to Digital Identity

Chris Yiu and Harvey Redgrave – Institute for Global Change

Digital identity (like digital voting) sounds as though it ought to be a problem with a reasonably straightforward solution, but which looks a lot more complicated when it comes to actually doing it. Like everything with the word ‘digital’ attached to it, that’s partly a problem of technical implementation. But also like everything with the word ‘digital’ attached to it, particularly in the public and political space, it’s a problem with many social aspects too.

This post makes a brave attempt at offering a solution to some of the technical challenges. But the reason why the introduction of identity cards has been highly politically contentious in the UK, but not in other countries, has a lot to do with history and politics and very little to do with technology. So better technology may indeed to be better, but that doesn’t in itself constitute a new approach to identity. Even if the better technology is in fact better (and as Paul Clarke spotted, ‘attestation’ is doing a lot more work as a word than it first appears), there are some much wider issues (some flagged by Peter Wells) which would also need to be addressed as part of an overall approach.

Service design

What do we mean when we talk about services?

Stephanie Marsh – GDS

A service is not an interaction on a website; it is not an immediate transaction. A service has a beginning, a middle and an end. The problem is that the service designer is at risk of only seeing the middle, and while a well designed middle is a good thing, it is not the whole thing. From the point of view of the person who has a need they want to resolve, the starting point may come much earlier and the resolution much later.

So it’s very encouraging to see GDS recognising this and making it clear that service design should be seen broadly, not narrowly. There’s room for debate about where the lines are drawn from the supply side perspective (the difference between ‘supporting content’ and ‘things which support’ is lost on me, for example) and perhaps more significantly a definition of a user journey which is too producer focused. But the underlying approach is very much the right one.

Service design

Why it’s never a good time for service design

Lou Downe

headless chicken deliveringIt’s really hard to do things as well responding to a crisis as when they are properly planned. It’s really hard to do proper planning if all your time and energy is taken up by responding to crises. Service design is one of the leading indicators of that problem: there’s no (perceived) time to do it when it’s urgent; but there’s no urgency to do it when there’s time.

The solution to that conundrum argued here is very simple: slow degradation over time has to be recognised as being as bad as the catastrophic failure which occurs when the degradation hits a tipping point – “we need to make doing nothing as risky as change.”

Simple in concept is, of course, a very long way from being simple to realise, and the lack of attention given to fixing things before they actually break is a problem not limited to service design – slightly more terrifyingly it applies just as much to nuclear weapons (and in another example from that post, to apparently simple services which cross organisational boundaries and which it isn’t quite anybody’s responsibility to fix). Changing that won’t be easy, but that doesn’t make it any less important.

Government and politics Service design

Designing digital services that are accountable, understood, and trusted

Richard Pope

This is a couple of years old, but is not in any way the worse for that. It’s an essay (originally a conference presentation), addressed to software developers, seeking to persuade them that in working in software or design, they are inescapably working in politics.

He’s right about that, but the implications for those on the other end of the connection are just as important. If the design of software is not neutral in political or policy terms, then people concerned with politics and policy need to understand this just as much. Thanks to Tom Loosemore for the enthusiastic reminder of its existence.

Innovation Service design

… which way I ought to go from here?

Dave Snowden – Cognitive Edge

This is close to the beginning of what is billed as series of indefinite length on agility and Agility, which we are promised will at times be polemical and curmudgeonly, and are tangentially illustrated with references to Alice (the one in Wonderland, not the cryptographic exemplar). The first post in the series set some context; this second one focuses on the question of whether short-cycle software production techniques translate to business strategy. In particular, the argument is that scrum-based approaches to agile work best when the problem space is reasonably well understood and that this will be the case to different extents and different stages of an overall development cycle.

Dave Snowden is best known as the originator of the Cynefin framework, which is probably enough to guarantee that this series will be thought provoking. He positions scrum approaches within the Cynefin complex domain and as a powerful approach – but not the only or uniquely appropriate one. It will be well worth watching his arguments develop.

Service design

Eight things I’ve learnt from designing services for colleagues

Steve Borthwick – DWP Digital

Civil servants are users too. Indeed, as Steph Gray more radically claims, civil servants are people too. And as users, and even more so as people, they have needs. Some of those needs are for purely internal systems and processes, others are as users of systems supporting customer services.

In the second category, the needs of the internal user are superficially similar to the needs of the external user – to gather and record the information necessary to move the service forward. That for a time led to a school of thought that the service for internal and external users should be identical, to the greatest possible extent. But as this post recognises, there is a critical difference between somebody who completes a transaction once a year or once in a blue moon and somebody who completes that same transaction many times a day.

That shouldn’t be an excuse for complexity and confusion: just because people on the payroll can learn to fight their way through doesn’t mean it’s a good idea to make them. But it is one good reason for thinking about internal user needs in their own right – and this excellent post provides seven more reasons why that’s a good thing to do.

Meanwhile, the cartoon here remains timeless – it prompted a blog post almost exactly ten years ago arguing that there is a vital difference between supporting expert users (good) and requiring users to be expert (bad). We need to keep that difference clearly in sight.

Government and politics One Team Government Service design

Digital government: reasons to be cheerful

Janet Hughes

This is an energetic and challenging presentation on the state of digital government – or rather of digital government in the UK. It’s available in various formats, the critical thing is to make sure you read the notes as well as look at the slides.

The first part of the argument is that digital government has got to a critical mass of inexorability. That doesn’t mean that progress hasn’t sometimes been slow and painful and it doesn’t mean that individual programmes and even organisations will survive, or even that today’s forecasts about the future of government will be any more accurate in their detail than those of twenty years ago. It does though mean that the questions then and now were basically the right ones even if it has been – and is – a struggle to work towards good answers.

The second part of the argument introduces a neat taxonomy of the stages of maturity of digital government, with the argument that the UK is now somewhere between the integrate and reboot phases. That’s clearly the direction of travel, but it’s perhaps more debatable how much of government even now is at that point of inflexion. The present, like the future, remains unevenly distributed.

Government and politics One Team Government Service design

Forget policy — start with people

Beatrice Karol Burks – Designing Good Things

This is a short polemic against the idea of policy, and by extension against the (self) importance of those who make it. It clearly and strongly makes an important point – but in doing so misses something important about policy and politics.

It is certainly true that starting with people and their needs is a good way of approaching problems. But it doesn’t follow that anything called policy is necessarily vacuous or redundant. Policy making, and indeed politics, is all about making choices, and those choices would still be there even if the options to be considered were better grounded.

None of that makes the practical suggestions in this post wrong. But if we forget policy, we forget something important.

Service design

The Parts of Customer Service That Should Never Be Automated

Ryan Buell – Harvard Business Review

This is a useful summary of the limitations of automation in service design. Only humans can be genuinely emotional, humans are still preferred to resolve problems, and automation doesn’t always stop human work, it can just shift it from provider to customer. So far, so good. But this has the feel of an article which could have been written almost at any time in the last decade or more and it does not touch at all on whether these attributes are absolute, situational or (for example) generational. People who design services are always at risk of over-representing their personal preferences, which are often to automate and streamline. Conversely though, there is no doubt that what it widely seen as normal changes over time and there is no very obvious reason to think that the balance of preferences has become more stable than it was in the past.

Organisational change Service design

What we’ve learned by being ‘DOTI’

Lucy – Snook

One of the reasons why large organisations find change hard is that inevitably new things are at first small in relation to established things. That’s not – in the short term – a problem for the established things: they can just ignore the new thing. It’s very much a problem for the new things: they need to find ways of operating in a system optimised for the old things.

This post is the distillation of a number of discussions about how to do design from the inside. It’s interesting in its own right in suggesting some responses to the challenge of making things happen from the inside. But it’s doubly interesting precisely because it is about making things happen: design on the inside is a very close relation of change on the inside.

Organisational change Service design

How to Innovate on the Operating Model of Public Services

Eddie Copeland – NESTA

A recurrent criticism of governments’ approach to digital services has been that they have been over focused on the final stage of online interaction, leaving the fundamental organisation and operation of government services unchanged. More recently, design has more often gone deeper, looking at all elements of the service and the systems which support it, but still largely leaving the underlying concept of the service in question unchallenged and unchanged. This post takes that a stage further to look at options for the underlying operating model. Eight are set out in the post, but it is probably still true that most government service design and delivery happens under the first two heading. What are the prospects for the other six – and for all the others which haven’t made it onto this list?

Curation Innovation Service design

Innovation Toolkits

Airtable

How many design innovation toolkits are there? The answer seems to be that there are more than you might think possible. Over a hundred are brought together on this page, which makes it an extraordinarily rich collection. There are lots of interesting-looking things here, some well known, others more obscure – though it’s hard not to come away with the thought that the world’s need for innovation toolkits has now over abundantly been met.

Service design

The Hawaii Missile Alert Culprit: Poorly Chosen File Names

Jared Spool – UX Immersion Interactions

A couple of weeks ago, the people of Hawaii were told that they were under missile attack. They weren’t, but that didn’t stop the warning being terrifying.

The cause was quickly narrowed down to poor user interface design. But poor user interface design is of course but one step in the chain of whys. This post follows several more links in the chain – giving a level of detail which at one level is more than most people will want or need, but using that to make some important points of much wider application. One is that critical designs need critical testing – and more generally that the value of design is not in the presence (or absence) of veneer. Another is that maintaining things is important and can be particularly difficult for systems funded on the basis that when they have been built, they are finished. The consequences of that approach may be irritating or they may be close to catastrophic, but they can be addressed only when there is recognition that, as David Eaves put it, you can either iterate before you fail, or you can do it after you fail, but you’ll do it either way.