GDS Podcast #16: GOV.UK Design System

Government Digital Service Podcast

We discuss how the GOV.UK Design System works, who uses it, how to measure its value, and other design systems across government.

The transcript for the episode follows:

-------------

Laura Stevens:

Hello, and welcome to the Government Digital Service Podcast. My name is Laura Stevens and I’m a Creative Content Producer here at GDS. And today’s podcast is going to be on the GOV.UK Design System.

The GOV.UK Design System is a collection of tools and resources for designing and building products and services. It provides styles, components and patterns that are accessible. This helps hundreds of teams across the public sector design and build services that are of high quality and can be used by anyone.

The impact of the design system, created and managed by a team of 10 here at GDS, is significant. It’s used in central government, local government and has also been used by the NHS and international governments to develop their own design systems. It saves teams time and money and helps give people a consistent and accessible experience when interacting with government.

To tell us more is Tim Paul, who is on the team who launched the GOV.UK Design System. Tim has also been at GDS for a long time, he was on the team that launched GOV.UK in fact as well. We’re also going to be hearing from people from central and local government about how the GOV.UK Design System has helped their work.

So yeah, welcome Tim to the podcast.

Tim Paul:

Hi there, how are you doing?

Laura Stevens:
Thanks for coming on today. And could you tell us what your job is here at GDS and how you work with the GOV.UK Design System?

Tim Paul:

Yeah so I guess my official job title is Head of Interaction Design. But for the last couple of years, I’ve mainly been kind of doing that as a Product Manager really for the Design System. So that’s a thing that we kind of kicked off a couple of years ago and we’ve managed to build a team around that, and develop a suite of products. We launched those back in summer of 2018 and yeah, I’ve been product managing that and working with the team closely ever since.

Laura Stevens:

So the Design System was launched back in July 2018. But what is the Design System made up of?

Tim Paul:

So it’s essentially a suite of 3 different products. So you’ve got the Design System itself, which is basically a website with guidance and coded examples for designers and frontend developers to use to design and prototype and build public services. So that’s the first thing.

And then there’s a thing we call the GOV.UK Prototype Kit, and that’s a piece of software that designers in particular can download and install, and they can use it to rapidly create very high fidelity prototypes that they can take into user research. And they can test out ideas before their, their team commits to building anything. So they can find out what the right thing to build is.

Laura Stevens:

Yeah.

Tim Paul:

And then the third thing, which underpins both of those, is a thing we call GOV.UK Frontend. And that’s essentially a frontend framework, so it’s all the Javascript and the CSS [Cascading Style Sheets] wrapped up into a nice package that developers can install into their projects. And so the Prototype Kit and the Design System both use GOV.UK Frontend and that means that designers and developers are both drawing from the same kind of library of components and patterns.

Laura Stevens:

I heard you say before that you think of the Design System also as a service as well, what do you mean by that?

Tim Paul:

Yes. So as well as the 3 products that we provide, we also offer support and training. We’ve helped facilitate contributions to the design system and we’ve run community events and we have regular hangouts with our community of users and contributors. So we really think of the whole thing together as being an actual service, and we have you know, a multidisciplinary team to support both the products and that service.

Laura Stevens:

And when you were talking about the different parts of the GOV.UK Design System, for people who are listening and don’t know what a component is or a pattern or a style. Could you explain what those things are please?

Tim Paul:

Yeah, ok, I’ll have a go.

So when we first started out - figuring out how to make this thing, we did a lot of thinking about what were the things that were going to be inside the Design System. There’s no really established language for talking about this stuff. Although design systems as an idea are fairly well established now.

So in the end we settled on 3 definitions. And so we have what we call styles. And they’re the really low level building blocks that everything else is made out of. So it’s things like colour palettes and how your typography works and how your page layouts work and your grid system and so on. So those are the styles.

And then one level up from that if you like, we have things that we call components. And so components are chunks of user interface, UI. So they’re visible things that you can compose onto a webpage and that, and, and that makes your service. So it’s things like drop-down lists and tables and navigation and headers and footers. And all our components are built using code, the code that we provide in GOV.UK Frontend. And so that’s what a component is.

And finally one level up from that we have things that we call patterns, and patterns are a little bit more abstract. They’re centred around common needs that users of public services have. So for example, lots of public services require that people enter information about themselves like their name or their address and so on, and so we have design patterns which explain the best most usable way that we’ve found, to ask users for that kind of information.

And, we have even higher level design patterns so for example, it’s quite common that a public service has eligibility requirements that, that, that users must meet if they are able to use that service. And so we have a pattern for example, which explains how best to help users understand whether or not they can use your service, so that they don’t waste time trying to apply for a benefit or something that they don’t actually meet the requirements for.

Laura Stevens:

And so now I feel like I, I know what it’s made up of, I know what those words mean. But why are design systems good for government? And in a previous presentation I found in the Google Drive in my research, you said the national motto of design system teams is ‘efficiency, consistency and usability’

Tim Paul:

Oh yeah, I did say that didn’t I?

Laura Stevens:

Would, is that why they’re good or have you changed your mind?

Tim Paul:

I guess, no that’s almost been one of the most stable beliefs that we’ve held throughout the whole kind of time we’ve been developing these resources. There, there do seem to be 3 pretty stable fundamental user needs that things like design systems are good at meeting. And, and that’s that public services needs to be efficiently built, we don’t want our tax payers’ money to be wasted in people like reinventing the wheel up and down the country in different teams.

They need to be of a high quality. So they need to be really accessible and usable. And they need to be consistent with each other. So one of the big reasons that we made GOV.UK in the first place was to try and create a single unified consistent user experience for all government services because that helps people to be familiar with those services, which means that it makes them more usable. But it also kind of fosters trust because it’s much easier to recognise when you’re using a legitimate government service if they all look the same.

And the way that design systems help with those things is that you have this common suite of components and patterns that are ready made, pre-built, they’ve already been tested for things like usability and accessibility. And so that lifts up the quality because people are re-using existing things, it means that they’re not developing them themselves so that makes teams more efficient and productive. And again because they’re re-using the same suite of components and patterns, it means that different services made by different teams in different parts of the country in different departments, are all consistent with each other.

Laura Stevens:

And I think that’s a point that I wanted to pick up on, is because I think as a user coming to GOV.UK, it looks like it’s just one big website.

Tim Paul:

Yeah.

Laura Stevens:

But it’s actually being managed, and being delivered simultaneously, by different teams up and down the UK.

Tim Paul:

Yes. So like you say GOV.UK presents as this single, quite large website that’s full of different services and information and that’s entirely intentional, that was always the vision for GOV.UK. But we, anybody who’s worked on it knows that under the hood, it’s hundreds and hundreds of separate websites and they're owned and managed by different teams in different departments up and down the country. There is no single tech stack for the public sector or for government, there’s hundreds and hundreds of different ones and we don’t try to control what that stack should be.

And so the challenge that we’ve always faced is like how do we let all of those teams work pretty much independently of each other, but deliver something which is coherent and consistent and feels like a single user experience. And this is, this is what design systems are really good at because they, they provide this centralised resource that all teams can draw upon and contribute back to.

So not every organisation, or large organisation, requires a design system necessarily but I think government is maybe almost the best example of an organisation that can benefit from, from a tool and a service like this.

Laura Stevens:

So yeah, we’ve got GOV.UK as this, appearing as one site but actually being operated by lots and lots of different teams up and down the country. So is that who’s using the Design System, all these different service teams?

Tim Paul:

Yeah, so we think that most users of the Design System are probably designers or developers working in, on, in services teams in different departments up and down the country. And we’ve tried lots of different ways to measure usage, it’s important that we know who’s using our service and how and what problems they might be facing, so that we can improve the service for them.

So one thing we have looked at in the past is, is web traffic. That’s just visitors to the Design System website. And that’s quite useful for showing month on month growth. I think since we launched, we’ve grown the number of visitors to the site by about 250%.

Laura Stevens:

So impressive figures.

Tim Paul:

Yeah, yeah! It’s, we’re happy with that.

Laura Stevens:

I wanted to ask about the community element of the Design System. So people are able to contribute their own patterns and how, so in terms of the number of patterns or number of components now, are most of them done in GDS or do, are they generally done from people who have contributed? How does that work?

Tim Paul:

Yeah. So from the outset really, we wanted to make sure that what we built was owned by the community of designers and developers in government, and was easy to contribute back to. And there’s a couple of reasons for that. One is that we’re, GDS is at the centre of government and that’s really helpful as a way to kind of propagate out best practice and so on, but it does mean that we’re kind of one step removed from the actual end users of citizen facing services and staff systems and so on. It’s really the teams in the other departments that are closest to those users. And so we really rely on them to feedback into the Design System about, about whether components or patterns are working or not. Maybe they’ve found ways to improve upon them, maybe they have ideas for brand new components and patterns that, that we don’t realise are needed. And so like I say, from the very beginning we were trying to figure out ways to, to kind of foster a community of collaboration and contributors.

And so we initially populated the Design System with maybe about 30 or 40 components and patterns that we already knew were needed by government. Some of those we brought in from our previous design tools.

Laura Stevens:

Yeah.

Tim Paul:

But since then we’ve had about 18 new components and patterns published over the last year and a bit. And I think of those 18, about 13 of them have been external contributions. So things that have been built by people in service teams somewhere else in government, from MoJ [Ministry of Justice] or DWP [Department for Work and Pensions] or HMRC [HM Revenue and Customs] and so on, and then contributed back to the Design System.

And so we from kind of experience with our previous tools, our legacy products, that contribution is difficult and it certainly doesn't happen for free and it doesn't happen at all unless you do a lot of work to facilitate it and so on. So we put a lot of effort into developing the necessary processes and the governance and the assurance so that when people made a contribution, they knew what to expect and they knew the criteria that they needed to meet and that there were people available to support that contribution. And then other people who are available to kind of assure the quality.

So what we’re hoping is this, by this, by making this process really open, it kind of encourages trust in what we’re doing, and it means that the work that we’re publishing isn’t biased, in favour of any one department and so on. And that it, and that it actually reflects the needs of teams in government.

Laura Stevens:

So how does it make you feel having so many patterns and contr-and components now being able to be contributed? Because, this, this hard work of making it decentralised, making it open is working.

Tim Paul:

It, I think it is working, I think we’ve learnt a lot along the way. We’ve certainly learned that it’s harder than we thought it would be. I mean we thought it would be hard, but it’s even harder than we thought it would be. I think perhaps we were tempted to think in the early days that contribution was like a shortcut to scaling.

Laura Stevens:

Yeah.

Tim Paul:

That like by opening our doors and letting people contribute, we could grow rapidly and it would like solve all our problems that way. And actually over the last year or so, I think what we’ve realised is that facilitating and assuring contributions is often as much work as doing the work yourself. We should probably have realised that at the time. And so I think it does let us scale but not to the extent that perhaps we thought it would.

So yeah, we think that aside from scaling, there are other real concrete benefits to, and I’m encouraging contribution on one of those, is that when people make successful contributions to the Design System, they tend to be pretty strong advocates so they almost act as like people doing engagement in departments on our behalf.

But also, and perhaps more importantly, the more people from service teams in other departments make contributions to the Design System, the more representative the Design System is of what those teams need. And so it just really helps us make sure that our product is actually genuinely meeting the needs of our users.

If we were doing all the work ourselves in the centre, then, then there’d be a really strong risk that what we were producing was only really meeting the needs of the teams that we were closest to.

Laura Stevens:

And I think that leads very nicely on. Because we’re now going to hear a clip from somebody who uses the Design System who isn’t from GDS.

Tim Paul:

Ah.

Laura Stevens:

It’s from Adam Silver, who previously worked at the Ministry for Justice, or MoJ Digital. So yeah and MoJ is the second largest of the 24 ministerial departments, so it’s a big department.

Tim Paul:

Yeah.

Laura Stevens:

And yeah, he’s going to talk about using the GOV.UK Design System and also about the MoJ specific Design System as well.

Adam Silver:

I’m Adam Silver, I’m an Interaction Designer working at the Department for Education, and previously I’ve worked at MoJ Digital and HMCTS [HM Courts & Tribunals Service] as well.

Laura Stevens:

Could I talk to you about your work with the GOV.UK Design System on the service claim for the cost of a child’s funeral, which is a highly emotional service and also one that had to be delivered at pace in 6 weeks in fact. So how did having this centralised system help you in that?

Adam Silver:

Yeah so we used the MoJ form builder, which is a tool that lets you create and deploy digital forms live, live to a URL without spinning up your own dev team. And under the hood, that form builder uses all of the components and patterns of from the GOV.UK design system. So that meant we didn’t have to spend a whole load of time thinking about text boxes, radio buttons and all of, all of the good stuff that’s already been solved brilliantly. And we could just focus on the specific needs of our service, and filling in the gaps where the GOV.UK Design System didn’t have a solution for that.

Laura Stevens:

And so in that way, was it saving you time, was it saving you hours of work, what was it helping you with?

Adam Silver:

Yeah, it saved, saved a lot of time. Because instead of focusing on all those things we could focus on just the needs of our service. So for example, we needed to think about how to ask users for their bank details because we needed to make a payment for them for their claim. And we also focused on things like how to upload files because they had to provide evidence for their claim by uploading copies of their receipts. And those, those 2 particular components and patterns aren’t covered really in the GOV.UK Design System. So that’s where we could really focus our attention.

And the other thing was that when we were doing an accessibility audit before we launched, we could focus most of our attention on the new patterns that we knew might not be up to the level of quality, or level of accessibility, that all of the other components that, like the text boxes and radio buttons in the GOV.UK Design System.

Just that it’s so, so real, it’s just so good. Just the quality of the guidance, the quality of the patterns, the components themselves is excellent. It plays really nicely into the prototype kit. And when I have worked on department specific design systems, it plays nicely with those ‘cause. So we’ve, we’ve... At HMCTS and MoJ Digital, we had our own department design systems and we had to extend and build on top of the GOV.UK Design System. So that was, that was another really good thing.

Laura Stevens:

Could you sort of speak then to how important having this centralised GOV.UK design system is to different departments across government?

Adam Silver:

Oh yeah, absolutely. I mean we have several services at MoJ that were asking people for their bank details. And during our research there are many many government departments that have many many services of their own that are also asking for their bank details. So there is a lot of duplication of effort there and a lot of inconsistency between them. Not, not major inconsistency but little inconsistencies and those can, those things can, can add up to creating a less than ideal, tricky user experience.

So having that centralised and standardised in GOV.UK Design System adds a tremendous amount of value along with everything else that is centralised in, in the system.

Laura Stevens:

How does the community behind the design system help you in your work?

Adam Silver:

Yeah, so well, that’s, it’s majorly helpful. It’s one of my favourite things about working in gov [government] actually, is, is the huge design community who are just willing to, to help. On, on Slack, there’s like thousands of people on there and they’ve, there’s always somebody that’s either come across your exact problem or they’ve come across something similar and can help out.

And then the backlog itself, or, or the more specific help around the design system, I mean the team are real-super friendly. You get to know them individually, they’re always there to, to help. And having someone dedicated on support each, each day on Slack is, is massively massively helpful, knowing that you can go to one place to get help is, yeah, I can’t, I can’t just, I can’t commend it enough really. It’s super valuable to me and it’s, I know that it’s been super valuable to other people I’ve worked with as well.

The community backlog is really good because if there isn’t something in the design system then you know that there’s going to be...well there’s a very very good chance that somebody has put their own designs into the backlog. Just some screenshots, just some explanation and then some discussion. And that, that will get you going so you don’t have to start, you’re never, you’re never really starting something from scratch because somebody has always done something. And somebody, sorry. Sometimes somebody has done more than something. There’s, there's a lot of contributions on some of the backlog tickets as well.

Laura Stevens:

So Kellie Matheson, who works at MoJ Digital, also spoke at Services Week 2020 about having two Design Systems and working with that. How do you, how, what’s been your experience of using two design systems at once?

Adam Silver:

So it’s not, it’s not the ideal situation. It’s because, the reason why I think design systems appear in departments is, is because, well for 2 reasons. One is that GOV.UK Design System just can’t go fast enough in accepting contributions which is kind of what I was talking about earlier. They’re just not resourced enough I don’t think. It takes a lot of effort to build out a component.

Laura Stevens:

Yeah, yeah, yeah.

Adam Silver:

So that, that’s one reason where a department could move a little bit faster. Quality might be a tad lower but they can move a bit faster. Because they’re not worrying about the needs of the whole of government, they’re just worrying about the needs of their department of the needs of a programme within a department, sometimes that’s the case. And the other reason is because there are literally department specific patterns. But I see it as a temporary solution while, until the GOV.UK Design System can pull those patterns in.

Laura Stevens:

And you, on your blog post, you also contributed a pattern along with your colleagues Amanda Kerry and Gemma Hutley, what was that pattern?

Adam Silver:

That was how to ask users for their bank details. So as part of the, as part of the Child Funeral Fund service that we were designing, the main, the main point was that the user is claiming back the costs. So to do that they need to provide their bank details and that way we can, during the claims process, make that payment to them.

Laura Stevens:

And what was it like to contribute your own pattern to that, or your team's pattern to that?

Adam Silver:

The reason why I wanted to contribute the bank details pattern was because while we were designing the service, there was no actual pattern existing for the bank details. And we looked in the backlog and we talked to people across government and in our own department as well, and there was no, there was no solid example of how to, how to ask for it. There was lots of different good examples but there was no one way. So that’s something that we had to tackle during the 6 week period.

And so it would have been a real, it would have saved us a lot of time if that did, if that pattern was part of the GOV.UK Design System. So we thought ok well look, we’ve learnt quite a bit about it by searching around what other people have done, and we made a decision ourselves for our service. So why don’t we use what we’ve learnt, work a little bit harder and contribute it back.

Laura Stevens:

So I’m sitting here with Tim Paul...And so you can ask him anything, what do you ask him?

Adam Silver:

Hi Tim, I would ask you how to quantify the value of a design system?

Laura Stevens:

So a nice easy question there.

Tim Paul:

Yeah, thanks Adam!

Laura Stevens:

But I did actually hear there was, I did actually see this was, this was your talk in Services Week 2020, wasn’t it?

Tim Paul:

Yeah. Yeah. So first of all, that was really good to hear from him. And yeah. One of the things we’ve always known that we need to do, and any team will need to do, is to somehow quantify the benefits of the thing that you’re delivering. Design systems are no exception. But it is quite hard to do that because of the nature of the service and the products I think. They’re not transactional services, you can’t watch people kind of go through them, people aren’t signed in when they use it and so measuring how many people are using your service and product is tricky enough.

And then quantifying the actual material benefits is also not that easy. It’s all about productivity and that’s quite a hard thing to measure. These aren’t small tasks that can be done in a few minutes where you can, can easily measure how much faster people get. These are tools which help people over the course of days and weeks and months in quite unpredictable and subtle ways.

So we’ve always struggled a little bit. Although I think this quarter we’ve gotten a little bit better at this stuff. And so we were joined by Roxy, who’s a Product Manager in GDS, and she’s really helped us deliver a kind of economic model and, and a business case for how, how much benefit the Design System is, is giving people. And so we did a fair amount of research, we did lots of analysis of things like repos on Github.

And we fed all of this information into an economic model, we worked with an economist called Parri. We, we, we had lots of other data points. Our user researcher Rosie did, at quite short notice, did some really good research where we interviewed around 10 designers and dev-developers from different departments, and we got them to talk about their experience of using our tools. We got them to do the very uncomfortable thing of like trying to, trying to tell us how much more or less productive they were using our tools and not using our tools.

Laura Stevens:
Yeah.

Tim Paul:

Which is a, it’s a really tough ask. But people did tell us and we got enough data points that we figured taking an average and going with a conservative version of that average was sufficient. And so feeding all of this stuff together, and thinking about how many teams are actually using our products and for how long and so on, we got to a kind of round figure of, we think we’re probably saving the government about £17 million pounds a year right now

And that’s based on the assumption that without the Design System, government would need to spend about that much money to deliver the same services of a similar quality. So yeah.

Laura Stevens:

And were you, did you think the figure would be about £17 million or did you...

Tim Paul:

Yeah..I don’t know. I guess it was higher than maybe I was expecting.

Laura Stevens:

Yeah.

Tim Paul:

Yeah. Yeah. But one of the things we’re really keen to do is focus as much as we possibly can on, on the more qualitative benefits of Design Systems.

Laura Stevens:

Sure.

Tim Paul:

Rather than treating them as a kind of efficiency tool. They definitely do help teams work more productively but what we’re really hoping is those teams use their excess capacity to deliver better services. And so Adam kind of touched on that. Because they don’t have to worry about checkboxes, and radio buttons and headers and footers and making those all accessible and usable, they can spend that time that they’ve saved focusing on the actual service itself, and the content design, and the service design and the policy design and so on. And that’s really where the gains are to be had for individual service teams.

Laura Stevens:

Adam also referenced about how there are other individual organisations using their own design systems, they’ve made up their own design systems. Why do you think places have created their own versions?

Tim Paul:

There have always been other design resources made by other teams and departments in government, and that should come as no surprise. For the most part these are people with quite similar missions and goals to ourselves.

Laura Stevens:

Yeah.

Tim Paul:

They’re trying to solve the same problems but at the level of their individual programme or department. And so a couple of years ago when we were initiating this work, we made a conscious decision to, to not treat them as rivals or competitors or in some way a symptom of failure. They’re really just people who are trying to solve the same problem.

And so we, r-rather than go around and try and s-shut them down or anything like that, we made friends with these people, these people are now contributors and we try and work closely together with them

Laura Stevens:

And not only is the GOV.UK Design System helping in central government, but it’s also being, helping across the public sector in local government and the NHS. And we’re now going to hear from Emma Lewis, from Hackney, about her experience of using the Design System in a local authority.

Emma Lewis:

I’m Emma Lewis, I am the Lead Frontend Developer at the London Borough of Hackney.

Laura Stevens:

What is the London Borough of Hackney doing with design systems?

Emma Lewis:

So we have our own Hackney Design System and Hackney Pattern Library, and both of those are based on top of GOV.UK Design System and GOV.UK frontend respoistry. So we have our pattern library is called LHB Frontend. Which is essentially a copy of GOV.UK frontend which also imports GOV.UK frontend and we build on top of that.

So we have a bunch of different components, some of which are basically identical to the GOV.UK components but they have sort Hackney, ‘Hacknified’ styles or small colour changes, spacing tweaks, things like that. We have some components that are actually identical to GOV.UK and some components that are completely new to Hackney because they're more local government focused.

Laura Stevens:

What have been the benefits to you working in local government, for using a central government design system?

Emma Lewis:

I mean it’s been huge. So having all of these things just out of the box sort of we can use, it’s such an enormous time saver. But also having things like we, you know, we know they are accessible. So it means the services that we’re providing to residents and staff are so much better than they would have been otherwise.

Laura Stevens:

And I think a lot of people respond to with the GOV.UK Design System is also that community element of it. Has that helped you as well at the council?

Emma Lewis:

Enormously. There’s no-one else really experienced at frontend development that I work with, and having that community of people who I can ask questions to, is such a positive thing. And likewise I am so grateful for the GOV.UK Design System that it means I want to contribute and I think other people feel like that.

So I’ve contributed a couple of pull requests that are like really really tiny minor changes but feels good to do that. And it’s something that I want to do. And I think you see that with other people in the community who aren’t necessarily working centrally at GDS but have benefited from it so want to contribute something.

Laura Stevens:

Why is having a design system a good thing for local government?

Emma Lewis:

It’s...there are lots of different reasons. The main, the first reason is consistency. So it means that you know, any of our products that use that design system are going to look the same and that means, that’s really good for lots of different reasons. It means we’re not duplicating code in lots of different places. So you know, if something changes we don’t need to update it in loads of different places, there’s just a central place where all of that stuff comes from. And that’s something that developers love.

Laura Stevens:

Yeah.

Emma Lewis:

But also I think accessibility is a huge thing. The time and resourcing that goes into making a design system like GOV.UK, like I’ve never seen the amount of effort that goes into a component be put into that kind of thing outside of a design system.

Laura Stevens:

Yeah.

Emma Lewis:

And so making sure that it is accessible means that it’s usable by all of our residents and that’s really important. And we, one of our missions at Hackney is to create digital services that are so good that people prefer to use them.

Laura Stevens:

Yeah.

Emma Lewis:

And in order to do that, they need to be available to work for everyone and that’s like incredibly important.

Laura Stevens:

So this is a bit of a, like a retrospective question. What do you wish you knew, or to anybody who is listening from a local authority, from a local borough, before you started creating the Hackney Pattern Library?

Emma Lewis:

I think 2 things that spring to mind. One of which is how important your decisions are when you start doing something like that. So I think I hadn’t appreciated how difficult it can be to change things down the line. And this is something that...so Nick [Colley] and Hanna [Laasko] who work on GOV.UK frontend actually we’re really kind and came into Hackney to talk to us about the design system. And they were talking about how hard it is, or how bad it is to make breaking changes.

Laura Stevens:

Yeah.

Emma Lewis:

So you know, changes to the design system or pattern library that are going to break things for users of the older versions. And that’s something that I wasn't, I hadn’t really thought about much until that conversation. And now, we’re sort of 6 months into our first version of our pattern library, and I’m starting to see, ‘oh I wish I’d done that differently’. And you know really feeling empowered to take the time at the beginning and think about those considerations about how you’re doing something and whether it is the right thing and what possible use cases there might be down the line, can be really helpful.

Laura Stevens:

So how, what are people using it, what sort of stage are you at?

Emma Lewis:

So I’m doing some work at the moment with our mapping team, who create all sorts of maps for residents and for staff to look at, from things like where water fountains are, are in the borough to planning applications and all sorts of different things. And we’re coming up with, I suppose sort, it’s sort of similar to a design system in a way, we’re trying to come up with this sort of map template that we can use to show all different kinds of data. And I was just showing them really quickly yesterday how to use the design system to put a header and footer on the page, and their faces were just like lit up. It was so exciting that this was suddenly all available to them.

Like using the GOV.UK design system has been an incredible time saver. Like I can’t, we wouldn’t have a pattern library now if we’d had to build everything from scratch. It just. We have so many different projects on and we don’t have the people to build something like that, and by having that, it’s mean that, not only that we can use it on projects going forward, but we’re also massively reducing the amount of time it takes to build all those individual projects as well. So it’s been, it’s just been enormous in terms of the time it saved and like I said, the community around it.

Laura Stevens:

Yeah.

Emma Lewis:

The support that’s been provided with it.

Tim Paul:

That was really really nice to hear that. It’s so, so gratifying I think to all of us on the team when other people reuse our work.

Laura Stevens:

Yeah.

Tim Paul:

It’s one of the best things about working in government and in the public sector is that we can be happy about the fact that people are stealing our work. In fact we kind of strongly encourage it. So yeah, that’s, that’s great. It’s, it’s doing exactly what we hoped it would do.

So we’ve known for quite a while there’s huge potential beyond central government for, for the work that we’re doing, not just ourselves but alongside our contributors, to, to benefit local government and even as far as international governments. We’ve, we’ve got I think we know about 5 different local authorities which are in some way using GOV.UK Frontend, and we’ve got a couple of other governments from other countries who are using our work as well. So this is really really good.

Laura Stevens:

And in both those clips, both Emma and Adam, they both spoke about accessibility and how having it tested to the level AA of the Web Content Accessibility Guidelines or WCAG.

Tim Paul:

Yes.

Laura Stevens:

Is that right?

Tim Paul:

That’s correct, yeah.

So this is, this has turned out to be a huge driver I think for adoption of the Design System because there this standard called the Web Content Accessibility Guidelines, it’s been around for a while, it’s in version 2.1 now. But the thing that has changed recently is that meeting level double A of that standard has now become an actual requirement, not just of central government services but the whole of the public sector by this September.

And so suddenly there’s a real strong need by teams everywhere to make their services fully accessible. And that’s pretty difficult. There’s lots you can do it make it easier like building in accessibility from the very beginning is probably the best way you can make your life easier here. Retrofitting accessibility is, is always a terrible experience for everybody.

But it turns out that making even simple things like buttons fully accessible across the full range of assistive technologies, devices and browsers, is actually pretty involved, difficult work. You’ve got lots of testing to do, you’ve got, the state of assistive technologies at the moment is still probably not as mature as it could be, which means there are lots of weird little bugs and kinks.

Laura Stevens:

Yeah.

Tim Paul:

Funny little idiosyncrasies across all the different technology stacks. And so the work that we do in the centre is to do all of that testing and iron out all of those bugs and figure out how to make these things work across all of the assistive techs that we know that people use. And that level of work, that depth of work is probably not a thing that an individual service team could or should be spending its time doing. They’ve got the full service to worry about and they really shouldn’t be spending the amount of time that we can spend on, on making low level components fully accessible.

So it’s one of the things I’m happiest about because it’s something that we can really contribute to.

Laura Stevens:

And in, you mentioned as well that we’re not only helping central government, local, NHS but we’re also going abroad as well. And in March 2019, the New Zealand Digital Service published a blog about how they used the GOV.UK Design System to help create their own. So, and they had a quote in there saying: “We decided not to reinvent the wheel so we’re building on the GOV.UK Design System, a system with years of development. It’s a mature and proven Design System with full rigour and accessibility and testing”. So what does having that sort of reach and international impact feel like for you and the team here at GDS?

Tim Paul:

It’s really nice, it’s kind of flattering. Yeah it also feels a little bit scary.

I think Emma alluded to the issue of having dependencies and breaking changes and things like design systems. And that’s a thing that we’ve experienced as well. So if you’re working on a service team in an agile environment, then the idea that you can iterate rapidly and fail fast and all of that, it’s great, it works really well. It doesn’t quite translate when you’re building a central code resource because if you’re iterating rapidly, if you’re failing fast, if you’re making lots of breaking changes, then you’re disrupting the work of everybody who’s relying on your code base. And so we end up being a lot more conservative, we end up moving slower and at a much measured kind of careful pace. And that’s because we are intensely aware that everybody using our tools is going to be disrupted by any breaking changes we make.

And so when we hear that you know, another country or local government authority is using our service, it’s really really good but it really hammers home to us how careful we have to be not to break things for them as well.

Laura Stevens:

Do you think there’s a way of fixing that? Or is that just an inherent problem with having a central design system?

Tim Paul:

I think probably the way to address that challenge is to not try to create some uber design system for the world, which would be the egotistical response to that challenge.

You know the internet is supposed to be made up of many parts loosely coupled, and that’s what we should be trying to do here. So making sure that people can use our tools as the foundation for the things they need, and that we have nice productive feedback mechanisms between, between those. That’s probably the right way to approach this.

Laura Stevens:

Is there anything where you’ve seen the Design System used in a way that you just never expected it to be used, or it popped up somewhere that you...

Tim Paul:

We’re, we’re sometimes asked about doesn’t, don’t, don’t these products make it really easy to make fake versions of GOV.UK, which is a really valid question. And the answer is yes, they do. They make it easy for anybody to make things look like GOV.UK. But to be honest if your motivations are to trick people, then it’s always been pretty easy to make fake versions of a website.

Laura Stevens:

Yeah.

Tim Paul:

So we’re not making it that much easier for the scammers, but we’re making it a lot easier for the service teams who are building legitimate services. But yes, every now and then we see, we see a dodgy looking GOV.UK site and we see our own code in there, and that’s kind of weird but you know there’s a whole bit of GDS which is dedicated to spotting that stuff and getting it taken down so.

Laura Stevens:

So thank you so much to Tim to coming on today and also to Emma and to Adam for talking about the GOV.UK Design System. And you can listen to all the episodes of the Government Digital Service Podcast on Apple Music, Spotify and all other major podcast platforms. And you can read the transcript of Podbean.

So thank you again and goodbye.

Tim Paul:

Thank you.