Taking the leap: getting staff and patients to use the NHS App

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.

#NextStageRadicals

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.

 

Government as a Platform, the hard problems: part 3 – shared components and APIs

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.

Mind the Gender Gap: The Hidden Data Gap in Transport

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!

 

Own 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.

Transactions v Interactions

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.

A brief introduction to digital government

Eddie Copeland

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

In this photo there is a central circle with lots of postits arranged inside and out. These postits cannot be read clearly but they represent different users of a service and the stakeholders involved in the delivery of that service.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.

Research heresies

Will Myddelton

‘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

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

Proof of concept, prototype, pilot, MVP – what’s in a name?

Bas Leurs and Kelly Duggan – Nesta

Matrix mapping development approaches against maturity and scaleTesting, 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

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.

Beyond human-centred design, to?

Cassie Robinson – Medium

design approach iconsA 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.

 

Technical Intuition

Alix Dunn – Medium

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

Tom Loosemore

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

Stephen McCarthy

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

Lou Downe

‘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