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.
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.
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.
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.
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.
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.
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?
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.
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.
Nina Timmers – Futuregov
The easy mantra of ‘fail fast’ is one of many (mis)translated from agile thought and practice. The positive case is easy to understand, especially in contrast with slower project management approaches which consume all their time and money before discovering they have built the wrong thing. But in failing fast, the cost and the impact of the failure need to be understood too. In many public services that cost can be very high and, even more importantly, may fall on those least able to meet it.
This post is a powerful description of an extreme case of that – but in describing the extreme, there is plenty to reflect on for a much wider range of services. Sometimes failure is really not an option.
Charlotte Augst – Kaleidoscope Health
One ever present risk in thinking strategically is to be too strategic. Or rather, to be too abstract, losing sight of the messiness of today in the excitement of the far tomorrows. Convincing strategies address recognisable problems (even if making the problems recognisable is part of the strategic process) and, perhaps most importantly, convincing strategies get to the future by starting in the present. There is no value in the most glorious of futures if you can’t get there from here.
This post is a brilliant example of why that is. How, it asks, with clearsighted perspective of very personal experience, can we hope to deliver a future strategy without understanding and addressing the gap between where we are and where we want to be?
Peter Jackson – IDEO Stories
Not so many years ago, this would have been a very radical post. It is a measure of progress that the core message – services should be designed with an understanding of customers – now seems obvious. But it’s still well worth reading both for the overall clarity with which the case is made, and for some neat turns of phrase. Governments tend to start with a policy which may eventually be expressed as a service; customers experience a service and will discern dimly – if at all – the policy which ultimately drives it. And those two things are not only different in themselves, they can also have different cycle times: ‘just because a major new policy only comes around once in a lifetime, doesn’t mean you only have one chance to implement it.’
There is a sweet spot in any job, or more generally in understanding any organisation, when you still retain a sense of surprise that anything could quite work that way, but have acquired an understanding of why it does, and of the local application of the general rule that all organisations are perfectly designed to get the results they get. Matt has reached the six month mark working in NHS Digital, and has some good thoughts, which are partly about the specifics of the NHS, but are mostly about humans and service design. This is part 1, there is also a second post on creating a design team to address those issues.
Laurence – Global Village Governance
Nothing ever quite beats the description of a service by somebody who has just used it – or tried to use it. This is a good example of the genre – applying for ‘National Super’ (or state pension) in New Zealand. As turns out to be the case surprisingly often, even if all or most of the steps work well enough individually, that’s still a very long way from the end to end service working well. And where, as in this case, one step in the process fails, the process as a whole goes down with it. One common problem, which we may also be seeing in this example, is that service providers are at constant risk of defining their service more narrowly than their service users do.
Cassie Robinson – Medium
Starting with user needs has become the axiomatically correct way of framing almost any government design problem. That’s a great deal better than not starting with user needs, but it also carries some very real risks and problems. One is that it tends to a very individualistic approach: the user is a lone individual, whose only relevant relationship is with the service under consideration. The wider social network, within which we are all nodes, doesn’t get much of a look in. Another is that we risk prioritising the completion of a process over the achievement of an outcome. Both of those addressed in this post, which directly challenges what has become the conventional starting point.
But perhaps what most distinguishes public services (in the widest sense) from other kinds of service is that there are often social needs which don’t always align with individual needs. The post refers to moral and collective needs, though it’s not entirely clear either whether ‘moral’ is a helpful label in this context or whether in practice moral and collective are being used as synonyms.
If we can’t get discoveries right, we won’t get anything else right that builds on their findings. That becomes ever more important as the language – if not always the rigour – of agile expands beyond its original boundaries. This short post introduces three others which look at planning, starting and finishing a discovery. They aren’t a guide to the tasks and activities of a discovery; they are instead a very powerful and practical guide to thinking about how to make a discovery work. There is a lot here for people who know they are doing discoveries, there may be even more for people who don’t necessarily think of that as what they are doing at all
It is also, not at all incidentally, beautifully written with not a word wasted. These things matter.
Chris Yiu – Institute for Global Change
This wide ranging and fast moving report hits the Strategic Reading jackpot. It provides a bravura tour of more of the topics covered here than is plausible in a single document, ticking almost every category box along the way. It moves at considerable speed, but without sacrificing coherence or clarity. That sets the context for a set of radical recommendations to government, based on the premise established at the outset that incremental change is a route to mediocrity, that ‘status quo plus’ is a grave mistake.
Not many people could pull that off with such aplomb. The pace and fluency sweep the reader along through the recommendations, which range from the almost obvious to the distinctly unexpected. There is a debate to be had about whether they are the best (or the right) ways forward, but it’s a debate well worth having, for which this is an excellent provocation.
Kylie Havelock – Medium
Service design in government is hard not because it is intrinsically more complicated than any other kind of service design (though there are plenty in government who like to think it is), but partly because it is universal (we can’t design to exclude difficult or expensive to serve customers) and partly because often the need for a service comes at a time of crisis (which also means that those difficult or expensive to serve customers are those whose need is greatest).
This post makes a powerful case for that to underpin the whole approach to service design in government, and so to ‘aim not just for seamlessness, but for kindness’. And in an interesting gem of synchronicity, there are strong parallels with Kit Collingwood’s post on why civil servants should become experts on empathy, also published this morning.
Zoe G – Medium
Product owners play a vital pivotal role in agile delivery, a role which is simple and clear (which is not at all to say easy) in some ways, but still much less clear in others, particularly in thinking about government services. This post uses the differences between public and private sector contexts to illustrate the complex balancing act that is required of product owners in government. That matters not just the product owners themselves, but to the other players in the wider systems of which they are a part. The underlying intent, the purpose for which a service is being developed won’t always be a straightforward response to a user need, and the articulation of goals and priorities needs to reflect that. This is a useful step towards building and sharing a common understanding.
Richard Pope – IF
Some simple but very powerful thoughts on the intersection of automation and design. The complexity of AI, as with any other kind of complexity, cannot be allowed to get in the way of making the experience of a service simple and comprehensible. Designers have an important role to play in avoiding that risk, reinforced as the post notes by the requirement under GDPR for people to be able to understand and challenge decisions which affect them.
There is a particularly important point – often overlooked – about the need to ensure that transparency and comprehension are attributes of wider social and community networks, not just of individuals’ interaction with automated systems.