Delivering User-Centred Products

Stephen McCarthy at UXDX Europe. Video: https://youtu.be/3JnXTs6xO2M

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

GDS and the legacy of public sector design

[00:00:00] My name is Steve McCarthy, and I work at the Government Digital Service. Before I start, can I ask you to put up your hand if you've ever heard of us or the work that we do? All right, there's quite a few. I reckon about 30% of the audience. We're a team of about 800 designers, developers, user researchers, data experts, writers. Most of us are based in London in the UK.

[00:00:33] For this talk I'm going to give you a bit of an insight into what we do at GDS. I think it's important to set that context, especially because over half of you don't really know what we do or who we are. Then I'm going to give you a bit of an insight into design in government today, and then I'm going to finish off with some insights into how we optimize our processes for better user-centered delivery.

[00:00:52] First of all, I'm going to rewind a bit. Design for UK public services has a long and celebrated history. We might all know Scott's red phone boxes here, or the big red bus, or the London cab, things like that. But the stuff that I'm going to talk about is the more unheralded, big infrastructure projects that for me were the reason why I got into design. One of these pieces is this here. This is Jock Kinneir and Margaret Calvert, in the late '50s, nearly '60s, and this was the first-ever standardized road signage system across the UK. And this coincided with the UK massively expanding its motorway network.

[00:01:36] Interestingly enough, this is Margaret Calvert, who, as I said, was the designer of the system. In the very early days of GDS she acted as a consultant for us, and indeed the typeface that you see on the road signs in the UK is the same typeface that we use on our websites for government digital services.

[00:01:55] Another project that you might all be familiar with is this. It's probably one of the most ubiquitous map designs you'll ever see in the world, and it was designed in the early '30s by this gentleman here, Harry Beck. He was a technical draftsman for Transport for London, and he developed this very, very simplified mapping system. He saw at the time that users don't need to understand the geographic location of where they are. They just need to know what the next stations are and where the junctions are in order to get from A to B. That kind of insight is based on user needs: they just need to know something there and then. And this was really, really effective design.

[00:02:36] Another piece we might all be familiar with is the design system for British Rail. This was designed by a group of people called the Design Research Unit in the mid '60s in the UK, and it was really harnessing the power of graphic design to create a more coherent system for the very, very complex UK rail network. The UK probably had one of the most extensive rail networks at the time, and everything was a bit of a mismatch, and users didn't really know where they were going and when. Just using the power of graphic design for things like wayfinding and simplified timetables really helped people go about their business day to day.

[00:03:14] At GDS we really feel like we're continuing that legacy, this legacy of really infrastructural public sector design. So now I'm going to give you a bit of an insight into what we do at GDS.

GOV.UK and service transformation

[00:03:26] First of all, we built this. This is GOV.UK. This is one website for all of UK government. Well before GOV.UK existed, the UK government website ecosystem looked a bit like this. There were over 300 departmental websites, and there were probably, I think we reckon, about two thousand [?] microsites spun off that. And as you can imagine, these were all different, and it was a bit of a mess. It was really hard for users to find what they needed to find. There was lots of stuff on there as well that hardly anybody ever read.

[00:03:57] So we replaced all this with one website called GOV.UK, as I just mentioned, which means that instead of having lots of different pages of information spread across different URLs, there was just one website for all the information, so that people could get the information quickly. And I know that sounds very simple, but it took a lot of hard work to get there. In government, nothing is simple. And the thing is, it's not finished, and to be frank, it never will be. It's always iterating, always improving.

[00:04:31] Government websites were never really built like this before. They were usually built where government would get an agency in, or pick a big contractor. They'd spend six months probably building the website, and then they'd hand it over: "There you go, it's done, it's finished." And then over the course of months and years the website would simply die of neglect. But at GDS we work a different way. As I mentioned, we're not an outside agency. We're there in the heart of government. We work in multidisciplinary teams, iterating based on user needs.

[00:05:01] But something we realized really, really early on in our journey is that the challenge is service transformation. It's not website redesign. This was something that was really important for us to realize early on in our journey. I've been at GDS about seven and a half years now, and it's something that we often say. So we work with the rest of government to help them make better services. And that doesn't just mean designing websites. It means working on end-to-end service improvement. It means working to improve the relationship between people and government, because it's all about the people.

Service by service, and then common platforms

[00:05:36] Now I'm going to give you some insights into how we've helped teams around government. First of all, I'll call this the service-by-service approach. That's where we gave focused support to specific service teams. We sent specialists and experts across different government departments all over the UK, geographically literally all over the UK, where they acted as consultants, coaches, guides and leaders. We worked right through all of the standard agile development phases: kicking off discoveries, working through alphas, private betas, public betas, right through to live. We initially worked with 25 exemplar programs, high-transaction services, and we've worked on many, many more since.

[00:06:23] This gave us lots and lots of experience of the common problems that service teams around government faced. And one thing we realized early on is that these government teams tend to be fixing the same problems again and again. That led on to our next phase of development at GDS, which was what we call the common platform approach. This meant looking at government not as a series of silos, each one responsible for its own thing, but as a series of interconnected, reusable components. Each component does one thing well, and each component is available for every government service to use. We'd always had this intent; for example, GOV.UK was imagined as a platform for publishing.

[00:07:09] So we set about creating a set of common platforms that make services easier to use and cheaper to run. This meant things like GOV.UK Notify, as you can see here. GOV.UK Notify allows service teams to easily update users on the progress of their application via text messages, emails and letters. And this small little service has vastly reduced calls and case working for government, saving up to about 175 million pounds for the taxpayer on the latest estimates.

[00:07:43] Another thing we built was GOV.UK Pay. GOV.UK Pay, to bring it down to its simplest form, is a common payments platform that makes it easier for users to pay government and easier for service teams to process, refund and reconcile payments. I've been in some departments of government where the processes behind the scenes for refunds and payments are horrendous. It takes up to two weeks, where they're posting different pieces of actual paper from different parts of the organization before a refund can be issued. Whereas now, with this platform that we've built, you can simply press one button and refund the payment to the user. And that's one thing we realized early on in this process: civil servants are users too. If we can make their work easier to do, ultimately it will be better for the end user.

[00:08:27] Another thing we developed quite recently is the GOV.UK Design System, which helps you design services using GOV.UK styles, components and patterns. Like the payment page I showed you previously, these are fully worked out, WCAG 2.1 compliant, very accessible, so that everyone can use them. Now, with the GOV.UK Design System, out of the box you have WCAG-compliant components. Service teams can spin up really quickly and start developing really accessible, easy-to-use government services right from the off. And there are lots of components that service teams can pick from. What this means is that a lot of the hard work has already been done for service teams around government. But most importantly, it means that these teams can focus on the harder, more interesting design problems related to their service.

Guidance, standards and training

[00:09:17] Other things we do to help government teams are around guidance and standards. One thing we're actually quite good at in GDS is documenting stuff, and documenting what you should do, where and when. The Service Manual that I'm showing here goes into the nuances of everything you need for agile service delivery: how to build a fully functional team, how to work in the different phases of agile delivery, right down to the nuances of, in this screenshot I'm showing here, how to run research sessions for people with disabilities. And all this stuff is invaluable for service teams.

[00:09:49] Other things we do: we have a Technology Code of Practice that these teams can look at for how to build safe and secure services. And we also have a Service Standard, where if service teams need to get funding for their project, they have to meet these 14 points of the Service Standard in order to keep going and get funding. And this is really helping to raise the bar for quality services in government.

[00:10:13] Another really important facet of the work that we do is training and capability building. The UK has approximately 400,000 civil servants, I think, and we need to raise the bar for them and their understanding of user-centered delivery. This is Clara here. She's one of our user-centered design training leads, and Clara and her team have trained, I think, about 2,000 civil servants over the last four or five years in what it means to be a designer in government. We're not saying that when these people come out of this training session they're designers, but at least they better understand the language that we use, and they can start planting that seed in their department.

[00:10:55] The things that we teach them are things like the basics of design, the basics of the different design disciplines, designing based on user needs, the importance of accessibility, and an introduction to prototyping. And it's funny how that last one is really terrifying for people. They just don't understand how that stuff works. And when you break it down for them in really simple forms in a half-day training session, it really opens their eyes and helps them understand the medium that they're working in.

Being a designer in government

[00:11:22] I've shown you some of the things that we do. Now I'm going to take you behind the scenes to what it's like to be a designer in government. In my role I'm the head of design for GDS, but I'm also the head of the cross-government UK design community as well. In that community we have over 500 designers now, and not all of them work in GDS. We have about 30 in GDS, and the rest are spread all around the country in different geographic locations, from Plymouth up to Newcastle. And it's really important that these people feel like they're part of a community.

[00:11:55] In this picture here you can see one of our cross-government design meetups. We try to run them every two months in different parts of the country, and we get all the designers in together and talk about the common issues and problems that we're facing. And it's really important to celebrate successes as well. This community is so, so important, because in GDS we're quite lucky. We have about 30 designers. We all work together. We can have a coffee and talk about the problems that we're facing. Whereas if you have one designer in a department up in Carroll Oil [?], he or she might feel quite lonely up there. So it's important that they can get onto Slack. We have a very vibrant Slack channel and Google Group where they can ask us questions straight away, and they can contribute to what is a really dynamic community.

[00:12:41] So what sort of designers do we employ in government? We tend to have four different specialisms. The specialisms are there just to say that if we think someone needs to fit into a certain phase of delivery or a certain project, we'll put that person there. But everyone tends to work across all the specialisms. I'll go through them now.

[00:13:00] We have service designers. To put it simply, service designers design services from end to end and from front to back, and across all channels. In government, much of this is focused on redesigning existing services. Essentially, most government services are a collection of isolated transactions, and many of them predate the internet, for example. A lot of the work our service designers do is like archaeologists piecing together all these different transactions within a service and putting them together into more of a coherent whole.

[00:13:37] We also have interaction designers. Interaction designers design the detailed actions a user needs to take in order to use a service. That's not just the UI. That might be the exact pacing of a number of questions within the transaction, or where to put a login, for example. To put it simply, interaction designers refine and shape user journeys and help remove complexity where it isn't needed.

[00:14:03] The third discipline we have is graphic designers. To be honest, there aren't many graphic designers in government. I'm from a graphic design background, and they play a crucial role. If I was to say it, graphic design, I find, is an enabler for content and interaction design, by influencing how users understand and interact with information.

[00:14:27] The next discipline we have, which is probably the biggest design discipline in government, is content designers. Content designers deal with words, and words in government services are hugely important, because most of them are words. They communicate complex information in simple, plain English that users can understand quickly. The vast majority of our services, as I mentioned, are made up of words, so it's really important that we get this right.

[00:14:58] All the designers that we have tend to work in the same way. One thing that's very important is that we build things. We don't just create pretty pictures of a UI interface and hand them over the wall. We actually understand the medium we're working in. Most of our designers can code, or at least understand the facets of code. We work in a realistic manner, and we know how our things are going to be built.

[00:15:24] And this one's really important: we work collaboratively and in the open. We have very dynamic and vibrant Slack [?] channels. We talk about our successes. We have an opinion on the internet about how our stuff should work and how we approach the work that we do. As I mentioned earlier, we have a vibrant community, and the community is constantly challenging each other on whether or not we're doing the right thing with certain design patterns, or the ways we're doing things. We're constantly questioning the work that we do.

[00:15:54] This one again is really important: user research is a separate discipline. We don't have what you might see as the standard UX designer model, where the UX designer does both the research and the design. We feel that understanding the needs of every citizen in the UK is its own job entirely, and especially we don't want our designers to be marking their own homework. So designers and researchers work together all the time, but they're separate disciplines.

[00:16:22] The other thing is that all our designers are expected to spot problems and try to fix them. We don't want to hear things like, "Ah, the designer in your team is very nice. They did everything that we asked them. It was really cool." That's not the role of a designer. The role of designers in a team is to always ask why, and that's what we encourage our designers to do.

[00:16:44] Our designers work across all the delivery phases here. They work from discovery through to alpha, through the private and public betas, right through to live. You might find certain skills are more suitable for discovery as opposed to beta. For example, if you have a service designer, you might tend to put them on discovery and alpha phases, whereas interaction designers tend to be better when you develop the more intricate prototypes and stuff like that.

Setting the right conditions for your team

[00:17:08] Now I'm going to give you some tips on optimizing team processes for better user-centered delivery. I've split this up into five different topics. The first one is setting the right conditions for your team. The second one is embedding design and research into the heart of what you do. The third one is following the user needs. Then focusing on trust and communication. And then being open about what you're doing.

[00:17:39] This first one is extremely important. How do you go about setting the right conditions for your team to succeed? On day one when I was at GDS, I saw a big, badly designed but good poster on the wall that said, "The unit of delivery is the team." And that message has stuck with me, and stuck with the whole organization for the last eight or nine years since it's been going.

[00:18:05] At GDS we have multidisciplinary teams working on really hard problems, and very smart people doing very challenging things, and it's really important that we create a culture that helps them to do this. I think Kevin touched on this earlier: it's really important that you take the time to hire the right people, and that is really, really hard. It's important that you put diverse people together who can learn from and teach each other. And I'm not just talking about disciplines here; I'm talking about skills and mindsets as well. You need a good mix of people to deliver. That's not just the big thinkers and the people with the grand vision. You need delivery people there who can curtail them and bring them in the right direction. So it's really important to understand the team dynamic and help them achieve what they need to do.

[00:18:50] Another thing, almost a protection around the team, is that you need to have principles that the team can follow and refer to. These are our design principles. They were developed about seven years ago, and our design principles to this day are still key to our approach. They guide everything that we do and how we do it. And where they're really most important is in our hour of need, when we're flagging a little bit and asking the difficult questions. We always refer back to these. There are only ten, and they're hugely important.

[00:19:17] I think it's important to read them out one by one. I'm not going to go into the nuances now, but if you just type in "GDS design principles", you'll be able to see examples of them. But I'll read them out loud. Start with user needs. Do less. Design with data. Do the hard work to make it simple. Iterate, then iterate again. This is for everyone. Understand context. Build digital services, not websites. Be consistent, not uniform. And make things open: it makes things better. You're going to see me jump in and out of these principles as I deliver this talk. I've already mentioned some of them in different guises earlier on.

[00:19:58] Another thing that's really important as well is to set expectations about the softer aspects of office and team culture. This is one of the posters we have on our walls at GDS, and it tells new starters about the office culture they can expect. It's the things that they should know that might not be told at an induction: that it's okay to ask for help, for example, or it's okay to forget things, or it's okay to ask why. And these things are really important for the general culture of an organization.

[00:20:31] On this topic, another really important thing is to protect the team and remove barriers that keep colleagues from doing their jobs effectively. That's things like the bureaucracy and small-p politics.

Embedding design and research, and following user needs

[00:20:42] Now I'm going to talk a bit about embedding design and research into the heart of what you do. Design and research should always be a few sprints ahead of development. One of our more experienced designers at GDS said this the other day, and it resonates: "I'd say it takes at least three research iterations, so about six weeks, to get confident about an approach."

[00:21:01] If you look at a typical development sprint, imagine that line is about two weeks. You have your planning phase, then you have your development phase, then you have your show and tell, and then you go to the pub. And if we look at a typical design and research sprint, which runs concurrently with this, this is a team that's building prototypes, probably in private beta. Maybe on the Tuesday and Wednesday of the second week they'll have a research day in place. So you'll have your planning phase, and then the designer will design and prototype. At the same time, they'll work together with the user researcher and develop the script for the research day, and they'll recruit some participants. You'll have your research day, then you'll do your analysis, and then you have your show and tell, and then you go to the pub.

[00:21:49] Generally, sprints work a bit like this. In sprint one you'll have your high-level design, multiple sketches and prototypes. In sprint two you'll narrow down that approach to maybe one or two prototypes and put them in front of users. And then in sprint three you'll choose that approach and refine your design solution and put it in front of users. And yeah, brilliant. The next part is the really hard part, and that's making sure that this work feeds into the product development backlog.

[00:22:12] And that leads me to my next point, which is follow the user needs. As a team, you need to make sure that the product is being led by research, not by adding features or developing for the sake of it. It's really important here to keep an eye on the long-term vision for your product while doing the shorter-term feature iterations. One of our really experienced lead PMs said this to me here today, when I was talking about this presentation: "We try to draw out the whole service on a wall at the beginning of each sprint, just to maintain focus."

[00:22:43] And I'm not talking about waterfall delivery here, where you say, "In two years we need X, and we need the product to do this." This is still agile, but it's trying to keep an idea of where you want to be and where you want to go. You're probably going to have product pivots, and things are going to change as you go along, because essentially, as it's been said before, agile is making it up as you go along. But it's really important to have this vision, because if you don't, and you just keep adding features for the sake of it, you'll have a bit of a Frankenstein product concept, and a Frankenstein interface as well.

[00:23:16] Another thing we say at GDS is that everyone should be engaged with the research and design process. Every person in the team, developers, PMs, DMs, sorry, product managers, delivery managers, should spend at least two hours every six weeks engaged with research.

Trust and communication

[00:23:33] Next I'm going to talk about focusing on trust and communication. Trust and communication are very important between roles. You need to trust your teams and colleagues to deliver, whether that's designer and user researcher, designer and developer, or product manager and user researcher. It's really important that you don't work in silos. There should be no team black holes of knowledge. Everything you do should be open. So don't just throw stuff over the wall to each other. This is really obvious stuff to say, but I've seen it time and time again. You have to really train yourself not to do this.

[00:24:04] You need to understand and respect each other's disciplines. Figure out what your teammates need from you and what you need from them. I always say this to the more junior members of the design community, and it should really, really hit home: you need to involve people in your processes. You need to understand [?] their frustrations and what they want from a certain thing. The development team should know the hypothesis and research behind the design. If they've been going to research and doing their two hours every six weeks, they should have a general gist of it. But if they don't, take the time to explain it to them.

[00:24:32] So I encourage all designers who are embedded in product teams to verbalize their design ideas, to state assumptions, to tie all their ideas to research, to build a shared understanding of the work that they're doing, and then to document design decisions. This one is really important, because in the modern workplace, design teams and organizations are in flux. People change, but the products will hopefully be there for years and years. So you need to understand the context of decisions that have been made. That's why it's really important to document this stuff, and it's really, really hard to do.

[00:25:01] Designers should also get involved in planning and story estimation. They need to make sure that they know how a feature is going to be rolled out, and design for that. There should be no loose ends at any stage. Let's say design and research have signed off the design of a product feature. The dev team estimate it'll probably take about 12 weeks to do, but we're going to release a minimum viable feature after four weeks, and hopefully at eight weeks we'll have a second iteration, and that should be done by about twelve weeks' time.

[00:25:31] It never happens like that. What happens is they'll release the minimum viable feature, and then at about six or seven weeks they're like, "We have a delay." There are always problems that come into play. In the meantime there might be a bit of a product pivot, because a big client or a big department wants a certain thing. And if you haven't designed for this first phase, it could be there for three, four, five, six months, and it might be a really, really bad user experience. So it's really important for designers to understand how this feature is going to be rolled out, and to design for each phase, so you don't have a bad user experience.

Be open about what you're doing

[00:26:01] The last point I'm going to talk about is probably the most important thing, and it's really helped us as an organization to develop and work: be open about what you're doing. That's as colleagues with each other, but also outwardly as a team and as an organization. Some tips to do this: use your wall space. I've been in so many offices that look absolutely beautiful, but there's nothing on the walls except for a few pieces of artwork. And I find that a bit jarring, especially when I go into a modern agile workspace.

[00:26:36] Don't keep everything in Trello or Jira. Walls trigger better conversation and engagement, and especially design and research walls. They generate conversations and keep people informed about what's going on, and they help improve the product as well. Especially at GDS, we might have, say, 20 different product teams. You might have someone from another team who will walk by your wall space and say, "Oh, we're working on something similar. Let's combine our research. Let's combine the work that we're doing to make this better." So this is really important.

[00:27:02] Another way of doing this is having regular show and tells. I mentioned that you always go to the pub, but show and tells are just really good for engaging the wider team and the wider organization with what you're doing. So try to have them in an open space, and invite everybody to them. It's always helped the work that we're doing. I'm sure a lot of you probably do it already, but it's just a really effective way of internal communication within organizations.

[00:27:25] Next is to blog about your work, including the failures. This is something that I have to get better at; everyone has to get better at it. You don't read enough about things that went wrong. It's really important to celebrate successes, but it's also really important to blog about the work that you do. In GDS we have a lot of different blogs, and the design blog specifically is called Design in Government. If you just type that into Google, you'll be able to find the genius [?] blog.

[00:27:53] This leads on to the last design principle that I mentioned earlier on, which is make things open: it makes things better. It's really important that we create an open culture in our organization, where people are comfortable talking about the things they're doing and the challenges that they face. Everything we do is for the public and for government users, and our code, our designs, our thinking, our work, it's all in the open. Because being open means that people understand what we're doing and why. And like the road signs and the Tube map, by being open, our work today is being used around the world. Thanks.