10 lessons from working with GDS
Early on in my career, it seemed an unwritten rule that the private sector did things better than the public sector. That big companies led the way. That government, councils, universities, and the NHS were miles behind the curve, mired in bureaucracy, and stuck in the past. This remained largely unchallenged throughout the first decade of my career and it wasn't until I joined the BBC in 2014 where, mightily impressed by their culture and working practices, I began to ask questions. Skip forward a couple more years and my first foray into the world of our Government Digital Service (GDS) flipped this entirely on its head.
For those unfamiliar with GDS, it's a part of the UK Cabinet Office tasked with providing a digital front door to government services by building common platforms to help departments make better digital services. GDS employs 750 people and its products and services are used by more than 13 million people each week and are relied upon by more than 1,900 public sector organisations. It was formed in 2010 on the back of a review of the government website, and following on from the successes of redesigning the site the team created the Service Manual that is used to assess all new or redesigned digital services to ensure that they adhere to best practices, and as a rigorous method of spend control.
I've worked with GDS several times in various guises throughout my career, and have distilled my key learnings down into these ten lessons.
The ten lessons
- Focus on users
- Be agile
- Work in cross-functional teams
- Show the thing
- Follow the data
- Apply governance
- Use design systems
- Some users will struggle regardless
- Adopt a service design mindset
- It’s not all about tech
Focus on users
GDS puts the needs and experiences of users at the heart of everything it does and this was a key factor in the success of the products I worked on. It’s not enough to have sporadic user research in isolation or second or third-hand feature requests trickling through to your team - it has to be user-centred design, development, and delivery.
GDS Service Standard #1 - Develop a deep understanding of users and the problem you’re trying to solve for them. Focusing on the user and the problem they’re trying to solve - rather than a particular solution - often means that you learn unexpected things about their needs.
If your organisation fails to focus on users not only will your teams become disillusioned, but your product and perhaps even the organisation itself will be lucky to survive.
Be agile
Not that this was much in doubt following my stint at the BBC, but my time working with GDS cemented the criticality of agile working methods. We utilised Scrum and Kanban methods to deliver products quickly and iteratively, allowing us to respond to user feedback and changing requirements.
Visualising activity, minimising work in progress, swarming on items closest to value realisation - lots of good stuff like this.
Work in cross-functional teams
This is another non-negotiable for me. You simply cannot do it alone - not well anyway. And you can’t stretch people to (and beyond) breaking point and expect them to stick around. You need generalised specialists - T-shaped practitioners who have their own responsibilities but just as importantly are accountable for the whole.
GDS Service Standard #6 - Have a multidisciplinary team. It’s important that people who are involved in decision-making are part of the team, so they’re accountable to the team - and the team as a whole can respond quickly to what they learn about users and their needs.
And collaboration beyond the team is also crucial - GDS set a great example of how to have platform teams that support other teams, such as GOV.UK Notify and GOV.UK Pay, and are big advocates of communities of practice.
Show the thing
Put simply: early and open communication that focuses on working software above all else.
"Whatever you do, don’t write documents about things without showing the things themselves. Give your work that chance to speak for itself." Giles Turnbull, Agile comms handbook (2021)
Those at GDS share information and updates about their products and services with users and stakeholders through a range of channels, including social media and online forums. They advocate lean and open comms (see this GOV.UK Pay blog article for examples, or have a look at the GDS way) within their teams.
Follow the data
Working with government hammered home the necessity of measuring success. And failure for that matter.
We were mandated to outline our key performance indicators (KPIs) and publish data for them monthly on the now defunct GOV.UK Performance Platform. Doing so forced us to track the performance of our products and, crucially, made the team accountable for this. I saw firsthand how this brought focus and enabled us to measure impact.
Apply governance
The focus brought about by the rigour and structure of the GDS assessment process was an unexpected win. At face value the process can look cumbersome and involved, having to go through discoveries, alpha assessments, and beta assessments before you can “go live”, but the advantages of this vastly outweigh the drawbacks, forcing you to walk before you run and ensure that core things (many mentioned in this article) are in place at the right point.
"We posted the Service Standard criteria on the wall in our workspace as a visible reference. Our service designer facilitated periodic review meetings to determine if we were still on target, and what actions we should take if we weren’t." Garrett Stettler, DWP blog post (2020)
Use design systems
Working with the GOV.UK Design System and the amazing community around it was eye-opening.
"The GOV.UK Design System can be a really powerful tool to help teams get services up and running fast. This was exemplified during the start of the pandemic where 52 services were built within weeks, not months, to respond to changing information and policy to help the government provide essential services to citizens. The "Get coronavirus support as an extremely vulnerable person" service was built from concept to live service in fewer than 4 days — it’s estimated this saved the government £10.4m." Trang Erskine, GDS Design System blog post (2022)
Having a common user experience across government products not only benefits users, but it makes life so much easier in terms of user research, design, and development. I’ve been a big advocate of design systems ever since.
Some users will struggle regardless
No matter how good your designers are or how much research you do or how awesome you think your product or service is, there will always be some users who struggle to use your product. It's inevitable. Even with the might of the design system and some of the best product development practitioners in the country (the world?), there will always be room for improvement.
Adopt a service design mindset
Look at the big picture. Not just at your product, or at a problem - taking a step back and considering the whole service end to end. Front to back. Across all channels. The first service designer I worked with (none other than Mr Sam Quayle) was on a GDS project where we redesigned the DfT’s Blue Badge service. Seeing the value of this approach, the insights that bubbled up from really getting down in the weeds, and the empowerment and engagement fostered by involving a cross-functional team had me hooked, and a good service blueprint is one of the first things I try and pull together on any new engagement.
It’s not all about tech
Lastly, building on the service design mindset, is to not to focus solely on the tech of your product. To avoid developing myopia for pixels and bytes. Even for the slickest of products with the simplest of user interfaces, there will always be a big part of your user interactions that are offline. And there will undoubtedly be other offline processes that underpin your product that warrant your attention.
GDS Service Standard #3 - Provide a joined-up experience across all channels. Bringing different channels together means you can design an experience that makes sense to the user, however they use the service. Users should not be excluded or have an inferior experience because they lack access to technology or the skills to use it.
It also held a lens over Marty Cagan’s fourth risk: business viability. So often we found that it wasn’t a tech or product challenge, but a people challenge - policy or funding or legislation or marketing. Ignore this risk at your peril!
In summary
Working with GDS was one of the most enjoyable and formative experiences of my professional life. It firmed up many of my beliefs and taught me a lot that I didn’t know, despite having worked in tech for a decade. For anyone looking for their next role in product development, you could do a lot worse than heading to GDS careers.
Oh and the GOV.UK Service Standard is definitely worth a look if you haven’t read it yet.
