Have you heard of service design? Why do we need it? How do we design services in government? Louise Downe, Head of Design at GDS answered your questions live on Periscope.
Transcript
Giles: Welcome to another GDS Periscope. You’re looking at Louise Downe, who is our Head of Design.
Louise Downe: Hi, Internet.
Giles: Louise, thank you for saying, “Hi, Internet.” (Laughter) Periscope isn’t as accessible as we’d like, so we will be making a transcript of this session available as soon as we can afterwards and posting it on the Internet. We’ll tweet a link to that so that you can see it and read it. Louise, please, for our viewers on the Internet, can you introduce yourself and talk a bit about what you’ve been working on recently?
Louise Downe: Sure. I am Head of Design for government, which means that I look after the design team here and also the design team across government. There are about 300 designers in government, which is very exciting. That’s bigger than the size of GDS, which is also very exciting. We have about 10 heads of design.
My job is making sure that design is taken seriously and that services are well designed. The thing that I’ve been spending most of my time on at the moment is thinking about and trying to work out a strategy for how we scale service design across government. Government is the largest service provider in the UK, so that’s quite a challenge.
Giles: Just before we started, just before we pressed the button to go live, you were describing the nature of service design and our approach to it. Can you just talk about that really quickly?
Louise Downe: I suppose our approach to service design in government is probably a little bit different to the way that it might be outside of a large organisation. We see service design as something very practical and quite simple: it’s the design of services. What we’re working on at the moment is ‘Government as a Platform’. Obviously, it’s a concept and a strategy for all of government to be working towards, and ultimately it means that we’re doing less of the things that we’re all repeating, and doing those things once.
What we’re trying to work out at the moment is what services look like in that world. We know that ‘Government as a Platform’ is composed of a number of common things – data, technology – and common components. Some people call those ‘platforms’ but also ‘services’ as well. Government is mostly services, so our strategy at the moment is to try and think about what services look like in that world.
Giles: Okay. If you’re watching this on Periscope via Twitter, you can send in your questions for Louise to answer. Please, send them in now; now is your chance to make use of what’s in her head. We have one already from Claire Sherwood, who said, “I’m interested in how we design joined-up delivery of our outcomes, creating real change.” Louise, what does real change look like?
Louise Downe: That’s an easy one. Real change is services that meet user needs. Surprisingly, that’s quite difficult to do in government; government is structured around an operational delivery structure that was sort of devised when we had a lot of paper to manage. The paper came in, and we needed people in one place to sort it, and then to do something with it, and then to, presumably, send you a letter back out again.
That isn’t the way that digital services work. Actually, you don’t all need to be working in the same place to be working on the same service. So, what we’re working on at the moment as a sort of cross-GOV community is trying to share a portfolio of things that we’re doing and services that we’re working on, and creating a register of services and transactions so that we know which bits of government are involved in delivering which user needs. In government, for various different reasons, and they stick around for a really long time. It’s quite easy to forget why they exist and to think about them in the transactional process and not necessarily think about what they’re doing for a user.
So, it’s a process – I think I’ve talked about this quite a lot – of a sort of archaeology of going back through those transactions and working out why they exist, what user need they’re meeting, what policy intent are they supposed to be there for, and then restructuring them so that they do meet both of those things. That’s what we’re doing as government, I suppose, but doing that means that we need more designers, more developers, more technical architects, working with the same language, same skills, sharing the same problems across government.
Giles: Cool. Anne posted a comment on a blog post that we published, saying, “If government needs service designers to design services, what exactly is the difference between non-service design roles and service design roles at GDS?”
Louise Downe: That is a very good question, and we actually have a blog post coming out later this week on that. We have quite a clear understanding, I think, of the different types of designers in government. They’re slightly different to what they are outside of government, but we loosely break people into specialisms. Those specialisms aren’t designed to say, “If you are a service designer, you should never make a poster. If you’re a service designer, you should never do interaction design.” That’s not what it’s there for. Some people are very good at lots of different things, but everyone normally has a specialism.
So, we have service designers. Those are people who tend to look at the user need, and the policy intent, and work out what the service should be in order to meet both those things; what the user journey should be; what the process that sits underneath that looks like; what the operating model; what the skills are that need to provide that service; so the real operational structure of what that service is and how it works.
We’ve got interaction designers as well, who are extreme specialists in how people use a particular thing, in a very detailed way. They’re often working with a service designer to finesse that user journey to work out exactly, if you have a form at a certain point in the service, how should that form be laid out on a page? Tim Paul has written a really good blog post, actually, on the design notes blog about this on how you should structure questions across a service. That’s the type of problem that interaction designers get really involved in.
We’ve also got graphic designers. We don’t have a lot of graphic designers in government, but they’re incredibly important; they are responsible for creating a consistent design language and experience for government. At the moment, that has only been on GOV.UK. We’re starting to look at some design patterns and a consistent experience around print and post at the moment, as well. It’s the thing that helps you to recognise government as consistent, but not necessarily uniform. It helps us to scale GOV.UK as and when we need to change it, but the colours are the same, the header is the same, the crown is the same, the font is the same. That’s the job of graphic designers.
Those are the three kinds of designers in that sort of area; we also have content designers who are incredibly amazing communicators. They are looking at complex issues of policy and of legislation, and simplifying them down into language that users can understand but also doesn’t oversimplify it so that people get confused. They’re often looking at service domains and working out what the sort of strategy of content should be around that, creating consistent taxonomies for language and that type of stuff. So, content designers are also part of that.
We work very closely with frontend developers as well. All of our designers can code, so right from service designers to interaction designers. Some content designers can code as well, so that’s a really important part of the way that we work.
Giles: Cool. We had a question from David Kitchen, who said… I think what he’s asking is how do you avoid deadlock in a service environment? What deadlocks do we come up against and how do we avoid them?
Louise Downe: That’s a really good question. I suppose deadlock can happen in a number of different ways. With any large organisation there’s a certain kind of inertia that comes with being very, very big, and making very big change can be quite difficult. One of the things, I suppose, that we’ve always done is to build things, and to show the thing, and to not spend too long talking about what it is we’re going to do and how we’re going to do it but to show people what it should be and how it can be. It’s surprising how fast people change when they see something that they like and think would be a great idea.
You can spend – and I have done in the past – a very long time trying to convince people that something is the right thing to do. Often, actually, if you just go ahead and try and do that and show people some results, make sure that you do it in the right way, do the appropriate user testing, show people that actually this is what users want and this is the way that you think it should work, most… Everyone who works in an organisation is a sensible person; everyone in the civil service is here because we want to make the world a better place for users, so oftentimes it’s just a case of showing people around you what that looks like and making it really easy for them to make that decision.
Giles: Terrific. We have had more questions coming in. There’s plenty more time; if you are watching through Twitter, through Periscope, please, please, send in your questions for Louise to answer. Guy gives just a very simple one: can you give us a couple of examples of service design?
Louise Downe: That’s a very good question. I suppose one of the things we’re working on at the moment, we’re dividing service design at GDS and across government into two quite distinct activities. We’re designing end-to-end services, so working with the rest of government to look at what transactions, what pieces of activity, what forms, what phone calls are all part of an ultimate goal that a user is trying to do.
That’s one way of scaling; we’re also working on service patterns, which are looking across the full spectrum of services that government provides and working out, “Okay, a large percentage of them are actually very, very similar to each other; they’re all licences or they’re all ways of exchanging ownership of something. Actually, maybe we shouldn’t have 45 different words for ‘licence’; we should probably just call them one thing and we should make it consistent, and the technology that sits underneath it consistent, and the way that we do phone centre triage consistent as well.” So, those are two strands that we’re looking at at the moment.
There are some really amazing examples of that type of stuff happening in government now. We’re starting to see a lot more teams working on services that [are verbs], which is awesome. Ministry of Justice have a really great service they’re working on; big up, Ministry of Justice, who are working on a service called ‘Pay for Fees’, so [it will] help with fees. That’s a service that helps people who can’t afford fees for court services, to be able to get those subsidised by government.
It was originally called ‘Fee Remission’, which, unless you’re necessarily part of that service, you wouldn’t really understand what the word ‘remission’ meant or what the fee was involved in that remission and what your responsibility was. So, they’ve completely simplified the service and done a very subtle, small thing of – well, not a small thing, it took a lot of change, but to change the name of that service. That’s a really good example of end-to-end service design. They looked at the paper form, the phone centre, the face-to-face and the digital channel as well, at the same time, and designed them together, so that was really great.
Giles: Thank you. Here’s another interesting question. I’m not sure who this is from; I haven’t got a name for this one. Thank you to whoever sent it in: how do you recruit good service designers? Are there enough out there?
Louise Downe: Oh, my God, no, there’s not. Please, come join us (Laughter).
Giles: Hashtag ‘we’re hiring’.
Louise Downe: Hashtag ‘we’re hiring’; we are definitely hiring. It is really, really hard to find very good service designers, mostly because the type of service design that’s happening inside organisations is very different to what happens in an agency. Historically, service design has been a practice that’s been mostly practised by agencies.
The types of skills that you have there are a lot of stakeholder management, a lot of diagramming, a lot of explaining your process of commoditising a process, often. We don’t do a lot of that, because we don’t have to, thankfully, sell a lot of what we’re doing here; we have the privilege of being able to work right at the coalface of delivery and iterate a service with the people who are actually delivering it, because we work inside the organisation.
So, the types of skills that we need here are being able to spot a pattern, being able to look across 25 different services and say, “These are the same thing and they should work in the same way,” being able to code, being able to understand exactly how services work on the Internet, because that’s very different to the way that they’ve historically worked before the Internet. They need to be pieces, small pieces loosely joined, as it were, so you need to understand not only the end-to-end journey but how you group those things into small pieces that can be loosely coupled into multiple different journeys.
There’s a lot of complexity, but it’s a very practical application of those things. We have had a lot of success in hiring service designers, but it takes a long time. We have some really awesome people here now and we’ve grown by eight people in the last five months, so it’s hard, but we’re doing it, but please, come join us (Laughter).
Giles: Here’s one from Aaron: is digital literacy an issue in the UK public service, and how do you go about tackling that?
Louise Downe: Yes, so digital literacy is always an issue. I suppose what people think of when they think of digital literacy isn’t necessarily the kind of full spectrum of what that means. There are lots of people who simply aren’t online, and there’s a lot of work happening, both in GDS and also in the rest of government, to get those people online and to give them appropriate broadband access – everything from practical stuff like laying cables to opening up library services so that people can use those things.
Having access is the thing that will solve that ultimately, in the end, but there’s a wide spectrum of people who have various different degrees of digital literacy. Even people who spend pretty much all their lives online can still be subject to phishing and scamming, so we do a lot of work to make sure that that doesn’t happen and to protect users from erroneous websites that look like GOV.UK. We’re also very careful about the way that we use email, for example. There are certain rules and regulations that we do to protect people who, through no fault of their own, through no mis-education, would be subject to a scamming sort of situation if we weren’t very careful about those things.
Dealing with digital literacy is something that we deal with in lots of different ways: opening up access, making sure that people aren’t subject to fraud, but also making sure that our services are so simple that you need to know how the Internet works in order to use them. We do a lot of testing with a wide range of users, because ultimately in government our services have to be accessible to 100% of people, 100% of the time. We don’t have an option of 80-20 or any of the other sorts of things that you think about in the commercial sector; we have to be accessible to everyone, so it’s something we take really, really seriously.
Giles: We’ve had another question from Web Butlers: “I’m guessing, as a service designer, you have to manage business change and policymakers. Is that the case?”
Louise Downe: Yes, although I would say it’s not necessarily a case of managing those sorts of things but bringing them along. Yes, a lot of our service designers have a background in certain financial skills: being able to look at cost efficiency and skills distribution, stuff like that that you would expect, potentially, from your traditional management consultant. So, they’re able to do that type of stuff.
I think it’s quite an interesting kind of conversation around how policy works with service design and what the collaboration is between those two things. We’re very much in a space of working out exactly how a service should fulfil ultimately a policy intent, so more or less fish in the sea, more or less road deaths – presumably less road deaths, more fish, obviously. We’re in the business of working out how best to do that and creating a service that does that. Ultimately, that means that there’s a lot more room for much more strategic policymaking in that space, being able to say, “This thing is more important than that thing,” or, “We want more of this and less of that.”
With those really clear policy intents, service design can work really, really well, so we need incredibly skilled policymakers; we need very skilled people involved in business change and financial processes in government to be able to look at this kind of world of future services and be able to say, “Okay, that’s my job and that’s how I do it”. It isn’t the role of a service designer to become the kind of omni-guru for absolutely everything, but it does mean that we need to speak the language of policymakers and speak the language of business people so that we can at least communicate how we want them to be involved in this.
Giles: Cool. A quick reminder if you’re watching: Periscope isn’t as accessible as we’d like it to be; we will be making a transcript and publishing it as soon as we can. Still time to send in a question; we’ve got five minutes, I’m told. Table for Two – this isn’t a question; this is just saying, “Hello” (Laughter). Table for Two says, “We’d love to have you again at our ‘Open Forum Events’ conference in June, so there you go, you’ve been invited to a conference.
Louise Downe: Thanks (Laughter).
Giles: Magnus says, “How do you implement and govern service design across government?”
Louise Downe: That’s a really, really good question and I wish I had a concrete answer. The real answer to that is we’re figuring it out. I suppose the way in which we’re doing that is to try and work out exactly, if we were to understand government from the perspective of user needs and which bits of government we’re meeting those user needs, how would it change?
There’s a lot of fear around that and what that actually means, because you start talking about service governance; it puts a lot of people on edge. Actually, it isn’t as scary as you think it would be. We’re not talking about taking 25,000 people from Newcastle and merging them with another bit of government in Croydon. That’s not what we’re in the business of doing, but what we are talking about is actually sharing the experience of those services. If we have a service that… There’s lots of bits of government that are very good at doing this at the moment; there’s a project looking at ‘One Government at the Border’, so exploring exactly how we involve all of the different departments that are involved in checking whether or not something should come in or out of the country, and working out how we create a service across all of those things.
They’re collaborating very, very well on that, and that doesn’t involve the types of big, scary change immediately, as people think that it does. We’re trying to investigate what that looks like and what, I guess, a service-based operating structure might be, but that’s a long way off and it’s something that we’ll probably spend the next four years trying to achieve together, as government.
Giles: We’ve got another one from Aaron. I think it’s the same Aaron as last time, saying, “What’s the next big thing in service design?” apart from government, I suppose.
Louise Downe: I don’t know; services that work? (Laughter) That’s what I’d like. That’s a very hard question. I suppose we have quite a good saying here that there’s no innovation until everything is fixed.
Giles: That’s a nice saying.
Louise Downe: I think that probably says it all. We have a very, very big challenge ahead of us. Like I said, government is the UK’s largest service provider; we are also the oldest service provider in the UK. We have a lot of diffracted, small silo transactions that need to be stitched together in a way that makes sense to users, so I will be very, very happy when we see a world where that works and government works with people in a way that they understand it.
I think, in terms of service design as a practice, potentially the next thing for service designers is – and I am going to say this: go and work for GDS (Laughter); plug – working inside of organisations, so actually getting close to the problem, designing at the coalface, learning to code, working with frontend developers, understanding data, buildings services rather than just building endless PowerPoint decks to convince people that services should be designed.
Giles: Okay, you’ve had the easy ones; now for the hard one. This is from Paul Clark, our mate Paul; hello, Paul. Paul wanted to know about conflict; he wanted to know about no-holds-barred stories of design arguments, irrational positions, egos, and resolving all of them.
Louise Downe: Blimey.
Giles: How do we get through that stuff? (Laughter)
Louise Downe: That’s a very good question. I’m obviously going to tell you all the stories about naming names of fights and conflicts that we’ve had. I’m not going to tell you that (Laughter), but I can say that when you’re trying to change something as big as what we’re trying to change, there will be lots of people who have been there before and are kind of feeling a bit miffed that actually now it’s sort of possible. They tried at a point where potentially it wasn’t possible, because the Internet has not always been the mature place that it is. That can be a really, really difficult and sensitive situation to put someone who is a user researcher, or a designer, or a developer into that space and to go, “Why don’t you just make it? Why isn’t it just simple?”
We don’t do that, and we’re quite sensitive about the environment, or at least we try to be, that we’re going into and actually bringing those people along with us. Sometimes that means doing what’s right and not what people want and what they think. I guess we’ve started to think, actually, as a design team, of our job being a little bit like a doctor – and this isn’t in any way to denigrate the medical practice and all that goes into that, but what we do is to make sure that we’re giving people the right thing, not necessarily what they want.
Someone might come to us and say, “We want an amazing, all-shiny mega-portal that will do all the things and a user rocks up to it and says, ‘I want to sign in and do this thing.’” That might be an amazing idea that someone has had for the last 20 years, and it might have been based on user needs at the time, but our job is to help explain what needs to happen, not what people want. That can be really difficult, so you need to be a bit tough, but very kind, to the people around you. So, that’s the real story (Laughter).
Giles: Okay, one last one from me, and keep it very short, because we need to finish: are you having fun?
Louise Downe: Yes, I’m having a lot of fun.
Giles: Should people come and work with you?
Louise Downe: Yes. I think I might have the best job in the world; I’m very excited about it. It’s a really massive challenge, but if you like really hard problems and really big challenges, then come and work for government; come work for GDS, or any of the other departments that need really amazing service designers.
Giles: Great, thank you, Louise Downe. Say, “Goodbye” to the Internet.
Louise Downe: Bye, Internet (Laughter).
Giles: We’ll see you next time, Internet. Bye.
3 comments
Comment by Anne posted on
If "government needs service designers to design services", what's exactly the difference between non-service design roles and service design roles at GDS? For example, an Interaction Designer vs. a Service Designer. Thanks.
Comment by David Chassels posted on
There are 2 aspects to "design". First the look and feel of the UI and display of formation for readers. However the most important is the design a d build of the "service" for easy and intuitive user use. You should be aware that users needs in this respect can be articulated within some 13 supportive task types which have been pre coded ready to configure as required. Workflow rules etc all taken care of as is use of legacy as required. V fast build easy change as required and handles simple or complex. Build takes place direct from user input no coders.
As a civil servant you have a duty to seek best VFM unlike suppliers whose duty is to hide such disruptive technology! Failure to do such research could be indeed has been very expensive for tax payers....
Comment by Krister posted on
it's incredibly awesome that this kind of material is published. so interesting.