Beyond service design – craft, collectivism and being human

Last week I was at Service Design in Government – an annual gathering of publicly minded design & digital folk from across the UK and around the world. I’ve not been for a couple of years (I’ve been busy becoming a parent and renovating a house!) so it was a great opportunity to catch up and to think about what might come next.  

It was a busy three days, and there was much that was thought provoking and inspiring – even in just the sessions I could go to – so I can’t possibly do all of it justice here. I’d definitely urge you to check out the programme and any materials that are available (including via #sdingov on Twitter). I’ll also link to a few things at the end of this post.  

Meanwhile, here are a few overarching themes that stood out for me, based on what I saw and heard. Each of these deserves more space than I can give it here, so I may return to some of them in future posts. I’d also love to hear if these resonate with you – whether you were at the conference or not! 

Designing the future

The scope and scale of ambition on display was really striking. The shift in focus over the last few years –  from improving digital experiences, to services (beyond digital), to an awareness of systems – extended out last week to wider society and even the planet as a whole. There was a sense of longer timescales too, and a growing acknowledgement of the consequences – intended or otherwise – of the interventions we make, and the insight that drives them.

Both Cassie Robinson and Cennydd Bowles each urged us way out of any comfort zone in their Keynotes: things cannot continue as they are, change is inevitable, what role are you going to play? How can we imagine a better future? And design it?  

Even beyond the Keynotes very few of the sessions I went to were simply about services – they were all looking beyond that – at how to influence people and organisations to behave differently, how to collaborate beyond organisations, how to have impact on a wider system. However this definitely wasn’t about abstract ideas – far from it, there was a real focus on practical pragmatic approaches. The desired outcomes might be ambitious, but the methods being used to deliver them were reassuringly familiar: insight led, user-centred, experimental, iterative, open. (Cassie & Cennydd both rightly challenged us to think beyond being user-centred, but for most teams, as a starting point, I think being user-centred is definitely preferable to being policy-centred, or finance-centred or org-centred!)  

It was encouraging to meet so many people who were working across the boundaries that may have limited impact in the past. (I’ve so often come across teams labelled as “digital” or “user experience” or even “service design”, who recognise that the approaches they’re familiar with could solve much wider problems in their organisation or service area, only to be slapped down for straying beyond their brief.)  However, I do realise this was a fairly self-selecting crowd, and I know this isn’t yet the reality for a lot of people working in the public sector.

It’s complex

Complexity came up a lot. Both in terms of the need to understand and influence complex problems and systems… but also in recognising that even getting started and “fixing the plumbing” can be difficult and complicated. There was a refreshing amount of honesty on display about this (kicked off by Carrie Bishop sharing her unsexy experience of trying to crochet together something coherent and sustainable amidst the craziness of the City & County of San Francisco!)

There was a broad consensus that helping organisations (and society) to do things differently and achieve better outcomes can be slow, hard, messy and often frustrating. It’s also nuanced and very context specific. There was very little patience for neat models or polished artifacts. There was a lot about starting small, joining the dots, finding collaborators. About listening, inclusion and empowerment. About testing, learning & sharing. 

Getting crafty

This may have stood out to me because I share my life with a potter and therefore spend a lot of my time with craftspeople and at crafts events! However, there was no denying that the term “craft” was in the air. I think this again reflects the recognition that methods and models will only get you so far when you’re dealing with complexity, and with human needs. I’ve always said that service design (and before it product management) are as much an art as a science.  I now think craft is a better term, because it’s where skill and technique meet experience and intuition. It’s about producing things that are both functional and beautiful. It’s about attention to detail, and quality… and it’s also something that only humans can do. 

Alongside developing our craft, we were also urged to use our imaginations (very movingly, by Cassie) and to tell stories. There was definitely an appeal to creativity in its widest sense – way beyond conventional design skills. 

It’s all about change 

If there was one word that I heard more than any other over the three days, then that word was change.  It felt as if this was really what the whole event was about – how to bring about change, within services, within systems, within society. How to inspire change, and how to help people to think and work in new ways. 

This resonated through all the sessions – from the macro (Cennydd’s powerful message about climate change) through to the micro (Emily Bazalgette on how to create the space for colleagues to trying something new or Service Works supporting public servants as they learn through doing).  

And there was a general recognition that this couldn’t be top down –  that the best way to start to change a system (or a society) is through small experiments, collaboration, imagination & storytelling. Both Cassie and Cennydd spoke about the role of the collective as a way of connecting and amplifying individual effort. The challenges may be huge, and the systems may be complex, but at the end of the day, it’s people – separately and together – who bring about change. I think this is why teams who feel they are stuck in the plumbing can also take hope – the small changes in how you work, and how you behave, in the language you use and the people you involve, these can make a difference. 

On a personal note, I came away feeling  energised and inspired – and also with a sense that I hadn’t just been to a conference, but had in some way found and joined a movement. This may sound emotional, but these are emotional times, and if there was one thing I learned last week, it’s that we’re going to need all of our creativity – and each other – if we want to change things for the better.  

Links & further reading

I’m going to keep adding to this as things become available!

Conference programme 

Conference hashtag


Cassie’s talk is here.

Adam Groves and Nerys Anthony from The Children’s Society shared how they’ve moved from service design to systems change. Here’s a previous post from Adam that covers some of the same ground 

Kirsty Joan Sinclair’s tweet review of Sohila Sawhney‘s session on their 7 year service design experiment at Bernados.


A lot of sessions used or referred to Liberating Structures for encouraging discussion and collaboration 

Several people used versions of the Future Cone 

And there were sessions on / references to Speculative Design 

States of Change on “innovation craft” (not from SDinGov, but on the theme of craft!)


Several people referenced Aaron Dignan’s Brave New Work 

There was a lot of love for Lou Downe’s Good Services 

Cassie mentioned Bill Sharpe’s Three Horizons: The Patterning of Hope 

Speculative Design came up a few times… as did probability cones.  This book deals with both 


The power of ‘so that?’

‘So’ and ‘that’ are two little words that pack a mighty punch. If you’re trying to bring about change or want to spend your time delivering more useful things then they can be your secret weapon.

Roses in guns - my kind of secret weapon!
Deploying your (peaceful) revolutionary secret weapon. Image by Shepard Fairey.

Over the years I’ve found myself using them in conversations with senior leaders, product managers, tech evangelists, school governors and even friends and family.  Usually this happens just after one of these has told me, with great conviction, about a thing that must be done, or written, or bought – to which I respond simply (and sometimes skeptically) ‘so that?’

I realise this might seem pretty annoying at first, but it’s amazing how it can lead to really useful conversations about what it is they actually want to achieve – the end and not the means.

It all started with a story

If you’re already familiar with using user stories to express needs to be met, then you’re probably already a fan of ‘so that’. I first learnt to express what I wanted to achieve in this format as a product manager working with agile (Scrum) delivery teams – but I’ve since realised it’s powerful in pretty much any context.

If you’re not yet familiar with the user story format, it goes like this:

As a [person]
I need [to achieve this goal]
So that [this outcome/benefit is realised]

So for example

As a home owner
I need to provide accurate readings of my electricity use
So that I only pay for what I’ve used

(This need used to be met by letting someone in to read the metre, then you could do it over the phone, then online, and now via a smart metre. The solution has changed over time, but the underlying need and ‘so that’ hasn’t).

Or even

As a finance director
I need to understand the benefits of your proposal
So that I can approve your budget

Creating more productive places to work

I spend a lot of my time now helping organisations figure out how to make the best of digital opportunities, and that often includes having to change how they approach things like approvals and reporting. It’s amazing how often I’m told “we have to fill in this template and send it to these people” or “we have to produce this report for this board”. These are exactly the sorts of statements that I meet with a simple ‘so that?’

What’s important is understanding the need that lies behind the task, so that you can work out if there’s a better way to meet it (or indeed if it needs meeting at all).

So, for example, if the need behind writing a report is that the senior management team need to see what progress you’ve made, so that they can continue to support your work… why not encourage them to come along to a regular ‘show & tell’ where they can hear direct from the team, rather then you and them having to invest time in a static report that’s out of date by the time it reaches them? Or if they can’t make it in person, why not film the session and share it with them, so they can catch up on your progress at a time that suits them?

Organisations are stuffed full of processes and habits that people follow because that’s just the way it is. These are the things that slow us down, sap our energy, and get in the way of change. They give the illusion of progress, because people are busy and forms are being filled in and meetings are happening… but are the right outcomes actually being achieved?

It’s all about people!

At the end of the day organisations, and their internal workings, are created and shaped by people. If we use user stories to understand the needs and motivations of our external users and customers, so that we can build things that they want to use, why don’t we also apply this same approach to our colleagues? Afterall – they are all people too, with needs and motivations… even finance directors!

The great thing about ‘so that?’ is that it doesn’t seem threatening or revolutionary. It’s just a very simple question that anyone can ask.

So next time you’re faced with someone suggesting or demanding something that doesn’t sound quite right to you, and you think they’ve jumped to a solution without explaining what it is they really want to achieve, I’d recommend deploying the ‘so that?’. You might be surprised by what it can achieve.




It’s good to talk. It’s even better to draw.

The title of this post could actually apply to any situation where grabbing a Sharpie or a board marker provides more insight than just talking.  Which in my experience is pretty much all situations!

However, this is specifically about a game I’ve developed that helps people to share the things that get in the way of doing great work, and to come up with some practical suggestions for how to overcome them. The instructions for the game are included below.

A “Cadavre Exquis” by Tanguy, Miro, Morise &  Man Ray in the MoMA collection

Along the way I’ve accidentally channelled Freud, tapped the Surrealists, and shown rooms full of conference delegates pictures of naked creatures with tennis racquets for feet. (It turns out this is actually quite tame compared to the things produced by the delegates themselves – examples at the bottom of the post!)

I first experimented on the obliging folk at UX Bristol 2016, and then played it again with the rather more international crowd at Service Design in Government 2017.  Both groups really went for it, and people asked me to share the format so they can try it on their unsuspecting colleagues. This is for them, and for you too if you’d like to have a go.


Childish beginnings

The idea originally came from the game of paper consequences I played when I was a child – the one where you take it in turns to draw parts of a body and end up with something cute and innocent like this cat produced by US school children.

Then I discovered it was also something the Surrealists did when they were exploring their subconscious, under the influence of Freud. They called them Cadavre Exquis (Exquisite Corpses)… which is clearly a totally appropriate thing to adapt and try at a conference, right?

I went for it, and this is the version we played.

Setting up

The game is best played by small groups of people sitting at shared tables, 4-6 people per table is good. You can have as many tables as you like, but it’s ideal to have 4 or 8 tables so that everyone has a go at each part of the body.

Each table needs a sheet of flip chart paper, some post-its  and enough pens for one per person, preferably in a range of colours. You may also want some blue-tak to create a  gallery at the end.

What’s stopping you?

You need to agree 4 common blockers to work on. The first time we played we only had 60 mins so I crowd-sourced a few themes on Twitter in advance, stuck them up on the wall, and asked the participants to vote for their top 4.   The second time we had 90 mins, so we sourced the themes from the room.

IMG_0244Each participant takes a few minutes to think about what stops them doing the work they want to be doing (e.g. great service design). They write one blocker per post-it, and add these to a wall where clusters of similar post-its should start to emerge. Once you have some clear themes give them snappy titles and ask everyone to vote for their top 3. You can do this with stickers, or just ask people to mark them with their pen. You can then pick the 4 themes with the most votes.

(If you’re interested, the 4 themes at UKBristol were: 1. People thinking UX just means design 2. The “business” adding things that don’t help the user 3. The opinions/preconceptions of colleagues 4. Not enough time.  At SDinGov they were: 1. The effort of bringing people along with you 2. Organisational silos 3. Confusion around what “service design” means 4. Not enough time.)

Get ready to play!

Before you start each table needs to fold their sheet of paper in half from top to bottom, and in half again, so that they have four equally spaced horizontal strips across the sheet.

These are then the instructions…

  1. Write the first blocker top left of the top strip
  2. Does this sound familiar? What does it feel like? Discuss around the table for 5 mins
  3. Someone who fancies having a go at drawing captures the conversation – using a head. This needs to fill the right hand part of the strip, and you need to leave a bit of neck sticking out over the fold
  4. What might help in this situation? Discuss around the table for 5 mins (this is the really valuable part, so you can taken longer on it if there’s time)
  5. Capture the main suggestions as bullet points, next to the picture
  6. FOLD! Pass it on to the next table…

Repeat the above 3 more times – drawing a body & arms for blocker number 2, legs for blocker 3 and feet for blocker 4. Someone needs to be strict on timings and keep things moving along.

At the end of the last round you can unfold and admire your work!

Where do you go from here?

As produced at SDinGov17

It’s good to stick your creatures up on a wall and have a chat about what you see.

Are there some similarities? (e.g. when we looked at “The effort of  bringing people along” at SDinGov two of the groups had drawn two headed creatures, so we could talk  about why that was).

What suggestions stand out? What are you actually going to take away and do differently?

Regardless of what gets taken back to the day job everyone involved is likely to have benefitted from an opportunity to get things off their chest, to realise they are not alone, and that there are things they can do to unblock their work.

These are in fact rather similar to the benefits of running an agile Retrospective… but with more two-headed creatures and tennis-racquet shoes.

Some of the offerings from UXBristol


Service design is for everyone

There’s a lot about service design that’s good and powerful and exciting for the public sector, but as interest starts to grow there’s perhaps also a risk of some unintended consequences – particularly for smaller or less well funded organisations.

What’s in a name?

To begin with there’s a lot packed into the term service design, so it’s potentially open to misinterpretation or even abuse.

My personal take is that there are three main things going on. I’m not suggesting that this is the definitive way to view it (far from it!) I’m just breaking it down in the hope that it helps to make more of the good stuff happen. I’ve also hugely simplified things in the interest of brevity.

1. Culture

Firstly – there’s a mindset that can be applied to improving services and which involves understanding things from a user’s perspective, end to end (from trigger to goal), in a pleasingly holistic way (internal, public facing, partners etc).  Let’s call this first thing ‘service design mentality’. It’s about culture and attitude.  Even starting to achieve this in a deeply siloed, process or policy driven organisation can be hard work.  

(As an aside… ideally this mindset shouldn’t even be limited to services, but should instead start by looking at an area of need or a desired outcome and asking how those needs or that outcome can best be met. So success might actually involve designing the service out of existence altogether.)

2. Tools

Secondly – there are tools, activities and techniques that can help people with a service design mentality to make improvements to services and outcomes. Many of these are highly visual and collaborative, and draw on various kinds of research. Some of them have been around for a while (like empathy maps and user journey maps) but they’re starting to be brought together in more joined up and powerful way.  There are a lot of tools and toolkits out there – some of them are more helpful than others. None of them will be very helpful if you haven’t already got a service design mentality.

3. People

Thirdly – there is a relatively new (to government) professional design discipline called Service Design (I’m going to capitalise it from now on). The Royal College of Art now offers a MA in it. There are an increasing number of people out there who describe themselves as Service Designers and places like GDS and FutureGov have been hiring them.  In very simple terms a Service Designer could be described as a professional designer who is employed to have a service design mentality and use service design tools to improve services/outcomes.

However, I strongly believe that you don’t have to be a Service Designer or hire Service Designers in order for you and your users to benefit from service design.

As Matt Edgar very eloquently noted last year – most of government is mostly service design most of the time.  And, as he also says, it ‘can and should be everyone’s business’.

Don’t make it too exclusive

In an ideal world everyone who works in public service should have a service design mentality, and should be able to access, understand and confidently use service design tools.

I don’t think this should be a specialism, I think it should be a defining characteristic of the public sector.

That’s not to say that the Service Designers don’t have an important role to play, particularly in these early days. We need them to lead the charge, show us how it’s done, and develop even better tools.  But we also need to guard against the perception that service design belongs to them alone, particularly as there are large swathes of the public sector that probably won’t be able to find or afford them.

Here are a couple of other things that I think we need to watch out for:

Don’t make it too Kool

There’s a fine line between creating a buzz and creating a cult.

We need to guard against a cult of Service Design just as we still need to guard against the cult (or tyranny) of Agile. (I’m a big fan of both, but not of the dogma that can sometimes come with them.)

As summed up nicely by Lindsey Keighley on behalf of GDS the important thing is to ‘be agile, not do Agile’. Similarly, let’s get on with delivering successful services and outcomes using the best means possible, rather than on ‘doing Service Design’.

It’s useful to create a buzz about something new and powerful, and to have a hashtag and a conference or two, but let’s do it in a way that’s accessible to everyone who might want to give it a go. More common sense than dark art.

Don’t forget about delivery!

In her post on what GDS mean by service design Louise Downe is very clear that

‘For us, service design isn’t about mental models or double diamonds. It’s about working with users and delivering services.’

A sentiment very much brought to life by Harry Trimble, one of the Service Designers in her team.  

This is definitely reassuring, and I don’t doubt that where GDS are involved the services that are designed will also be deliverable and delivered.

However, amongst the less determined I think there’s always a risk that design activities might become dislocated from delivery.  The world is already full enough of dysfunctional teams where designers (or policy makers!)  hand over beautiful but unrealistic designs to baffled developers or front line staff. One of the major benefits of the agile ways of working championed by GDS and others is that a multidisciplinary team work together on delivering working solutions, one iteration at a time. I know it’s not intended that Service Design should become an up front idealised design activity – but in the wrong hands it could.

This toolkit poster, for example, seems to imply that service design stops after feasibility, but if that’s the case you’re walking away before anything has actually changed for the end user. Service design isn’t just a phase of work – it actually needs to deliver outcomes! 

What next?

So how do we make sure that everyone who works on or uses public services can benefit from good service design?

Some teams will be privileged enough to work with professional Service Designers – but not all.  How do we enthuse and support the rest? (Including, of course, people in local government.)

Teams that have already had experience and success sharing honest and quantifiable stories is a good start – which is where the blogs, hashtags and conferences come in handy. But this does need to reach the people who commission and run services – not just the people who follow the latest design or digital trends.

Sharing tools and techniques will also be useful – although in context rather than in a vacuum. The right tools applied with the wrong mentality can be definitely lead to unintended consequences, and can also start to really muddy the waters (I’ve seen that a lot with the use of agile).

And how to you foster a potential ‘community of practice‘ for service design if that community could potentially involve… everyone?! Particularly if the people who need the info and support don’t see themselves as service designers.

This post is already long enough… and I don’t have tidy answers.  But I do believe that service design in its broadest sense has the potential to unlock so many benefits for the public sector that it needs to be owned and embraced by everyone.


Discovering discovery

Not enough people actually begin at the beginning.

Often when I meet teams working on service transformation, or digital change projects, I find that they’ve begun somewhere else. Perhaps their work began when someone decided the organisation should be using a particular system, so they’re busy trying to implement that, or someone thought a particular process should be put online, so that’s what they’re doing. They’ve been presented with a solution and told to make it work.?

And all too often the people dictating those solutions are being driven largely by internal factors – the need to make short term savings, a contract coming to an end, a budget to spend by the end of the year, a boss to impress.

This tends to result in teams who are doing their best, but are feeling rather put-upon and disempowered; teams who find that the priorities and targets aren’t entirely clear, or that they keep shifting; teams who can’t really explain the purpose of what they are working on, or who it is for, or what will happen to it after they’ve finished their particular project.

Worse still, the people who ultimately have to use the product or service are also likely to be unhappy – faced with an experience that doesn’t really work for them, because it’s based on managerial assumptions, or because it’s had so many things bolted on along the way that it’s become unusable.

The art of discovery

In my experience the best way to avoid ending up in this painful and often expensive mess is to go through a ‘discovery’ process upfront. The time you spend on this, whether it’s months, weeks or days, will be time extremely well spent. It will help you to focus on your users and their needs, and to come up with realistic plans that the whole team can buy in to.

As far as I’m aware there’s no fixed formula for ‘discovery’ and although other people (like GDS and the Design Council) agree that it’s valuable there aren’t many detailed templates or guides out there. I’ve therefore developed an approach that makes sense to me, and (more importantly) to the teams I’ve worked with.  It isn’t possible to cover all the detail here in a single post, but I’ll share some of the main principles and steps.

It’s as easy as 1,2,3

The way I see it, there are three stages within discovery:

  1. Learning (about your users, and about business drivers and constraints)
  2. Sketching (generating and testing ideas)
  3. Refining & planning (prioritising and working out what to take into delivery)

I tend to present these as a diamond (similar to the Design Council’s) as this helps to illustrate that the team are opening up their thinking before focusing in on specific solutions and plans. (And it really is important that it’s a team going through this… more on this below.)

The main stages of discovery
The diamond of discovery

If you’re tight on time –  and provided you’ve got access to the right data, research and people – you can rattle through this in a week or two if you really have to. But if you’re working on something new or complex, or if you need to do some fresh user research then things might take a little longer. (The government Service Design Manual recommends 4-8 weeks of discovery.)

Who’s in the team?

There’s no one answer to this, but ideally you need to involve:

  • Someone to keep things moving along. In an ideal world this is the product or service “owner” e.g. in places where you have specific Product Managers. However,  this could also be a project manager supporting the service owner, or it might even be an external facilitator. The most important thing is that they understand the purpose of discovery and can bring together the right people in the right setting to keep things moving in a productive direction.
  • People with real insight and experience – about your users and their needs, about the business and its priorities and constraints, about the technology context and possibilities. A well run discovery process will tap in to all of this and help everyone to share what they know and work towards solutions they can all support. (Some of these people might just come along to certain workshops rather than being involved on a day to day basis.)  What you don’t want is observers and passengers – if someone doesn’t have relevant insight or experience to share then they shouldn’t be in the room!
  • The people who will be delivering the solution. Often these will be some of the people with the best insight and experience – so we’ve already got them covered.  You won’t be able to invite all the people who will be involved with delivery, but you definitely want the key areas represented. Often this will be an internal tech lead, perhaps your lead user experience person, and someone representing the business and/or customer service teams who will be involved with running the service. If your delivery is largely outsourced then you’ll need to involve your suppliers along the way to bring insight about how their world works – but be wary of letting them dictate solutions, particularly if you’ll be putting things out to tender.

Often the people brought together during discovery might never have met or spoken before, even though they’re all involved in aspects of designing and delivering a service. Discovery helps to cut through internal silos and bring together a group of people who can look at a service holistically and develop a shared sense of purpose and ownership.

Nitty gritty

There are various workshops and activities I use to take teams through discovery. These involve everyone in the team, a wall, and a lot of post-it notes and marker pens. Discovery is driven by conversation rather than documentation, so the approach needs to get people talking and thinking and sketching and asking questions. The wall becomes a living repository of all of this, and a reference point for the team.

Two teams mapping user needs
Two teams mapping user needs

The main events tend to be:

  • What do we know?workshop This sets the scene and gets people sharing existing headline data, research and insights. I tend to cluster things in a few key areas: User and their needs, Business context (drivers, targets, constraints), Tech and delivery context, and sometimes also Process and workflow context.  By the end of the workshop everyone has a shared understanding of the context they’re working in, and some of the problems they might want to solve. They’ve also identified and prioritised gaps in their knowledge to focus on filling in the next few days.
  • User needs mapping workshop This helps the whole team to walk in the shoes of their users, identifying needs from trigger to goal. It depends on having access to real insight about those users. I find it helps to start by building an empathy map of each prioritised user group, and giving them a name. These names are then a handy shorthand throughout the process, as everyone knows the set of characteristics and needs summed up by “Anita” or “Bill”.
  • Sketching workshop The team start to identify possible solutions to meet the needs of their external and internal users. I build things up in layers, starting with the user needs at the top, and ending with candidate solutions at the bottom.

In each case the workshops are designed to trigger the thinking, talking, researching, sketching, testing and planning that the team then go off and do. i.e. the real work happens in-between the workshops, ideally facilitated by daily stand ups in front of the wall.  This also presents lots of opportunities for other interested people to see how things are going – using the “show don’t tell” approach to governance and comms.

One of the hardest things is stopping people jumping to solutions too early. It’s really important to stick with needs, data and evidence until you’ve really understand the problem you’re trying to solve, and the outcomes you’re seeking to achieve – and only then get in to sketching solutions. You’ll be surprised at how many options you can come up with by doing this, giving you lots to then prioritise and potentially iterate – one “why” and many “whats”. Discovery can give you the foundations for a whole roadmap of service improvement.

So is this ‘Agile’?

I believe that a discovery process is valuable regardless of the approach you then take to delivery.

If you are going to be using an agile approach to delivery then a good discovery process can produce a prioritised backlog and a roadmap. (This could be a backlog of detailed user stories or perhaps just a list of epics to refine later, depending on the time available and the preferences of the team).

If your solution is going to be largely (or partly) delivered by suppliers you’re likely to be a much more confident and discerning client if you’ve been through discovery. You’ll be able to articulate your requirements in terms of the problems you want solved, and the outcomes you want to achieve, and you’ll be able to assess the solutions they propose based on what you’ve learnt in discovery.

And if you’re really keen you may even find yourself applying the principles of discovery to small everyday tasks too. If someone starts a conversation by stating “what we need is…” then maybe push back and ask “what’s the problem we’re trying to solve? What evidence do we have? How will we know we’ve been successful?”.  We all have a tendency to jump to solutions and to make assumptions – but if we do that, we’re not really beginning at the beginning. And as Maria once taught us – that’s a very good place to start.

Julie Andrews telling it like it is
Julie Andrews telling it like it is

If you’d like to have a chat about the detail of discovery, and how it might work in your organisation, then do get in touch via the comments below, or via my About page. 


Could the devolution of power to cities and regions help super-charge the work on local digital services?

As I write this post the debate around the devolution of powers to UK cities and regions is

Bristol at night
With thanks to

hotting up. No doubt by the time you read it the details will have changed – but it seems highly likely that whoever is running the country after May 2015 they’ll be conceding some powers and funding, or fundraising opportunities, to some of our larger cities and regions (“metros” as the City Growth Commission calls them).

Much has already been said about the approaches or models that might help deliver high quality digital services across local government – with “one site to rule them all” at one end of the spectrum, and voluntary standards at the other.

Much as I admire and support the great work being done by practitioners like LocalGovDigtal, my view is that bottom-up voluntary best practice isn’t going to be enough. Even if I believed that this alone would get us to consistently good and affordable services eventually (which I don’t), we simply don’t have the time to find out – the funding situation is too acute, and the expectations of citizens accustomed to interacting 24/7 online are already raised too high.

There are also far too many chief execs, service directors and elected members who don’t yet understand the need for digitally enabled service redesign (including assisted digital), or the scale of the opportunity, or the extent of culture change required to bring it about.

We need to get their attention.

Even amongst the more engaged there seems to be a leadership vacuum. At events I’ve been to with representation from DCLG, the LGA, and Solace as well as execs and councillors from local authorities, everyone has been happy to agree that standards need to be raised, skills developed, opportunities seized, and that some leadership is needed… But no one has been prepared to step forward to lead, or even to suggest who might.

In central government, when GDS was created, it wasn’t enough to have a team of experienced people, or to say what good looked like, or even to show it via Alphas and exemplars – the new digital standards had to be made mandatory, and tied to access to funding (specifically spend controls). Yes, there’s a nice juicy carrot in positive user feedback and improved performance indicators (including savings), and ideally this would be enough to incentivise change, but I don’t think this alone will bring about the shift needed. I suspect we also need some stick.

I believe we need a new mandate or settlement or hard incentive to accelerate the pace of digitally-enabled change across local government – and that perhaps the devolution of powers to cities and regions might provide that opportunity.

Imagine a devolution deal which insisted that x% should be spent on digitally enabled service redesign, to an agreed set of standards and even a timetable. Or, if that degree of ring-fencing is too strong, how about mandating standards or expectations with targets and metrics attached, regardless of spend? In July Ed Miliband suggested that his version of devolution would come with “checks and balances”, with the introduction of local public accounts committees and the requirement to publish performance data. If this approach gets developed I’d want to see digital and service design standards as part of it.

Sticks aside, stronger cities and regions could also lead the development and sharing of digital expertise. Some commentators and practitioners are, probably rightly, sceptical of a central (London based) digital team for local government – but what if there were centres of excellence in each of the large cities, each perhaps running digital academies or events for council staff in the surrounding authorities?  Would it also be more acceptable if the guardians of digital standards were up the road, rather than inside the M25?

So, do I think we need national standards for service design and digital? Yes I do. Do I think these need to be mandated in order to be truly effective? Yes. Does this mean a central team in London taking control? No, it needn’t. I think we need many centres of excellence, not just one, and I’m hoping that if we get devolved cities they might help lead the way.

GDS for local? A shopping list, not a monolith.

There’s been a lot of renewed chat recently (see below) about  “a GDS for local government’ or “GOV.UK for local goverment” but I’m curious about what people really mean when they use these terms. What is it that “GDS” represents in these conversations – a central team of specialists? A set of standards? A publishing platform? A mandate? All of the above?

I’ve only spent a few months looking into and working with local government, so my thoughts are still forming and I still have much to learn and observe. However, even with that caveat, I’m already convinced that the current approach – where over 300 authorities spend their increasingly scarce resources independently trying to meet the same set of needs and solve the same set of problems – is fairly bonkers. Particularly when in many cases the solutions they end up with are way more expensive and less flexible than they should be. Oh, and not great for their customers either.

This isn’t sensible, and it isn’t sustainable. It’s also not fair on the amazing people in local government who know it isn’t ideal but who don’t have the tools, or support, or budgets to change things. It’s one of the things that got me out of GDS and involved with this in the first place.

Being a user-centred agile kinda girl I’m not comfortable jumping to solutions before I fully understand the problem, but I’m also not comfortable with the way that “a local GDS” and “GOV.UK” are being used – sometimes interchangeably – as shorthand for some kind of fairly abstract all powerful centralised solution, something “monolithic“. (With apologies for Rob for singling this out!)

It may well be that some of the approaches GDS have taken, and some of the things they have delivered, should form part of how local government delivers information and services in the future. But that covers a lot of different activities and products. Maybe we should think about which of those might be useful in the context of local government – to move from the abstract concept of “a GDS” into the constituent parts.

So as a starter for ten – if there were a shopping list based on the types of things GDS is currently providing for central government, which would you be buying into for local government? And who might be providing them?  That list might include these kinds of things (illustrated with central gov examples for now):

This isn’t a complete list, but the point I’m trying to make is that GDS represents many things, some of which would be more difficult or controversial than others to apply across local government.

I’m interested in having a more practical conversation – one based on the needs to be met and the opportunities to be realised, and only then the models and structures and teams and technologies that might best deliver against those.  If you start by talking about the governance and politics you may end up in an unhappy place. If  you start with the problem you are trying to solve, and think about it in manageable chunks, you can end up achieving something extraordinary.

(Some notable recent contributions from Ben Welby, DXW, Phil Rumens, Rob Miller and Socitm. Also interesting to see the programme of events, training etc that DCLG are offering this year.)


Post-launch survival tips

On Friday I popped in to see the fantastic team at FutureLearn to congratulate them on launching their new MOOC platform. They invited me to share some tips on post-launch survival so I came up with my top 5.  This is my personal take, not anything official from GDS, but I do use government examples because that’s what I’m involved with at the moment. They’re pretty straight forward (and the FutureLearn team seemed to have most of this nailed already!) but here they are in case they are useful to anyone else…

1. Look after yourselves and each other.Look after yourselves
(Human bugs are more difficult and expensive to fix than bugs in your code).

We all tend to over-do it in the run up to a launch or big release, but you can’t survive forever on short nights, adrenalin and donuts.  Post-launch you’re responsible for running a live service and that is a long game, not a sprint. Most things CAN wait until tomorrow – especially if you’ve got good processes in place to monitor and resolve issues.  Happy rested people are more likely to come up with creative solutions anyway – and if “the unit of delivery is the team” you’re all going to suffer if one of you is suffering. If you’ve lost your sense of humour that’s probably a sign that you need to take a break!

Respect the process2. Respect the process.

Actually, respect YOUR process – you should own it (as a team) you should review it (as a team) and you can iterate it (as a team) – but always respect it. This could apply to the process for adding things to the backlog, or for triaging user feedback, or for responding to stakeholders or Tweets or the press. When things get hectic you all need to trust that the processes you’ve agreed will be followed, and that no one will be going off piste… something that is likely to generate more work and a lot of noise.

3. Know your story.Know your story
(And publish it!)

Everyone in the team should know or have access to the story you’re telling about the product you’ve just launched/your latest release.  Ideally this should be published -partly because it’s more efficient to say it once and link to it than to answer the same question over & over again – but also because you’ll be part of a conversation and the people who engage will give you valuable feedback.  (At GDS we famously blog about pretty much everything, or publish things as part of the Service Design Manual.) The same principle can apply internally, for things you’re not yet ready to share publicly. You can use a Google doc or a wiki page or another shared place to publish the latest on evolving thinking – that way everyone can take a look and if you need to get together for a discussion you can, rather than having distracting and repetitive conversations going on all the time.

IMG_21264. Use your data.

This should be pretty self evident, but the data you have about your users and how they are using and responding to your product should be informing the work you’re doing to iterate and improve, and also be a big part of the story you’re telling – internally and externally.  This is likely to be a mix of the usage data you’re capturing, but also insights from user research and feedback.  Decisions that are based on data are usually better decisions, and easier to explain and to defend (if need be!).  Have a think before you launch/release about the questions you’re going to want answers to post-launch. Are you set up to capture the relevant data? Do you know where to look for it or to to ask when you need it?

5. Manage your stakeholders.IMG_2127

Just as you’ll have processes in place to manage feedback from your users, so you’ll want to have processes in place for interacting with your stakeholders. If you don’t it could get noisy and frustrating for all involved. Be proactive and prepared. Let them know in advance the most effective channels for feedback, and the best way to get the latest info. Where should they look? What can they expect?  Ideally have someone in the team focused on managing this, to make sure you’re hearing the priority suggestions or concerns, and that your stakeholders are kept well informed. The amazing @jennijjmoss and @ElisseJones definitely showed us the way on this one at GDS.

Girl talk

October 16th 2012 was Ada Lovelace day and it prompted a small flurry of articles, posts and podcasts bemoaning the lack of women in tech and wondering what could or should be done about it.

Ada Lovelace by Alfred Edward Chalon
Ada Lovelace by Alfred Edward Chalon

I didn’t join in at the time – perhaps because I was rather busy launching GOV.UK that night – I and many fabulous and talented colleagues, male and female. We reached over a million people on the first day and made it simpler, clearer and faster for them to interact with the UK government.

I could perhaps claim that being the proud if exhausted Product Manager of that product, on that day, was a more fitting tribute to Ms Lovelace than any tweet or comment or turn at a women’s networking event.

But that would be to suggest that, in the midst of all the hard work and euphoria, I was thinking about Ada, or even conscious of being “a woman in technology”.  And if I’m honest, I wasn’t.

What I was conscious of was everything that can be achieved when passionate, creative, experienced, proactive people come together and listen to and respect each others’ views and skills – regardless of their gender.

So it is only this evening that I’ve finally found and read those articles, and looked for those networks, and that’s because I went to listen to Martha Lane Fox speaking at a Nesta event and the subject came up. Again. In fact, I even tweeted Martha’s comment that women in tech should “Stand up, lean in & shout!” and in doing so I realised I’d sort of joined in, and perhaps it was time to form an opinion.

So here is my opening salvo.

What strikes me is that the discussion too often seems to centre around the relationship between girls and computers and how they need to be encouraged to “do IT “at school, or to write code – as if this alone will redress the gender imbalance at the top of tech companies and in the tech community as a whole. (The Indy took a broader view, but only just).

But surely computers and code are now a means to an end, many ends in fact – digital technology is about connecting people, and understanding their needs, and communicating, and being creative, and solving problems, and collaborating, and creating products that people want to use.

And, unless I’m missing something, I think girls tend to be quite good at those things – in fact possibly better than boys at some of them (I have no data – I’m just jumping on the gender stereotype bandwagon! But I also speak as a woman with a degree in English Literature who’s never written code, but who’s been able to work on some pretty big digital projects).

The computers and the code are the tools that make all of this possible, and yes, we absolutely do need talented people who know how to wield them skilfully – be they male or female. But TV is about more than cameras, newspapers are about more then typesetting, and creating great digital products and experiences is about more than computers.

So maybe, in 2013, we could talk less about IT and more about digital products, less about coding and more about understanding the needs of real people, less about “geeks” and more about creativity. And perhaps if we did that we might do better at attracting the full spectrum of people who will show us where digital technology can really take us… regardless of their gender.

Changing the world, 1% at a time

Last week I agreed to take part in a “global co-creation event” which would involve “running with the cheetahs” and meeting “fast moving changemakers”.  No, I had no idea what any of that meant either, but there were some enthusiastic Dutch people behind it, and it involved spending a day in the excellent Hub Islington so I thought I’d give it a go.

The gang behind the event run the 1% Club, which they define as:One Percent Club logo

The online platform that connects people who have smart ideas with people, money and knowledge around the world.

I was interested in the suggestion that people could lend their professional skills to projects in developing countries via a digital network, so was disappointed to find that there only ever seem to be 5 or so projects asking for that kind of support on the site. I’ve since realised that these are only the projects posted in English, with another 40 or so in Dutch, but even so the requests for funding seem to outnumber those asking for skills by a factor of 6 to 1.

The 1% Event, however, is all about taking this principle of donating skills and making a day of it.  They had identified 11 development projects from around the globe, and created 11 teams to tackle them.  Or at least, to spend a few hours trying to tackle them.  Four of the teams were in Amsterdam, with others in London, Nairobi, Cape Town, Kampala, Cairo, Buea and Ramallah.

I think the concept that underpins both the site and the event is an interesting one, and worth exploring,  but to my mind they fell down a bit on the execution.

The 8 locations were all connected via live streams and Skype, which was ambitious, and sometimes brilliant, but often unreliable.  There was also quite a bit of time spent on pre-amble, and even group singing (in Amsterdam… watched in bewilderment from London!), before things really got going and we were given our briefs.  This only left 3 or 4 hours for our small team to understand the project, do some research, discuss options with the project owner, refine, and prepare a short presentation.  I suspect some of the world’s problems may take more than 3 hours to solve… but perhaps it’s a start!

In spite of my cynicism, the serene Dr Fatumo who gave us our brief seemed genuinelySomali women pleased with what we came up with, and hopes to make real use of it. She works for a charity called Hirda working on a range of projects in Somalia and they were looking for ideas to help boost a campaign they’re running to combat FGM, which is rife in Somalia with 80-90% of girls being circumcised by the time they are 8 years old. (For the less squeamish amongst you, FGM stands for Female Genital Mutilation, which isn’t something I thought I’d be learning about on a sunny Friday in London, but I’m glad that I did!).

The aspect of our proposal that was most relevant to SmallSeeds was the suggestion that they use radio and the fixed and mobile internet to tell the stories central to the campaign.  Both a fictional story (perhaps creating a radio soap that follows the lives of a range of families, those that do and do not practice FGM) and the real and very powerful stories of the women who are willing to share their experiences.  The World Service recently ran an item on the use of soaps to deliver health messages, and Hirda have already found that the most success they’ve had is when girls share their stories – the web and mobile can help amplify those in a vast country with some of the highest mobile phone usage in Africa.

So in spite of the heat, the group singing, the flagging live streams, and the insanity of trying to understand a complex and sensitive issue in such a short space of time, I do feel it was a day very well spent.  I also think there are some interesting ideas worth pursuing around how people in an increasingly connected world could make quite a big difference by lending a small amount of their expertise.  I’m sure there are other organisations out there who are also exploring just that, so my plan is to find them and see how they stack up.

In the meantime, hats off to those crazy ambitious Dutch guys, and thanks to The Hub for their hospitality!