The MOD issues medals to both serving and previous armed forces personnel, as well as some civilians. GOV.UK is where these users can find out if they’re eligible for any of them, and how to apply.

The GOV.UK content team has been working with the Ministry of Defence (MOD) Medal Office and Directorate of Defence Communications (DDC) to review and improve this medals content on GOV.UK. 

A Corporal of Horse of the Life Guards displays his medals. Photo: Harland Quarrington, Crown Copyright

In September, the Medal Office noticed a number of errors and inconsistencies across the medals pages. So they began talking to users (service community and general public) and medal assessors, to track some of the common issues and grievances with the pages.

Issues ranged from technical difficulties in accessing application forms, to confusion over the medals that the Medal Office does and doesn’t issue. They also identified a general lack of awareness around medal criteria and eligibility, as well as confusion on how to appeal a decision made by the Medal Office.

MOD Medal Office digital officer Alex Peebles brought these concerns to a kick-off meeting with DDC and GDS. The Medal Office had previously seen a spike in traffic to these pages around Remembrance Sunday, so we wanted to address these issues before this year’s date.

A collaborative approach

Given the time constraints, one thing we all wanted to avoid was lengthy interruptions and delays. We were mindful of how others across government had benefited from working closely together, particularly for the starting a business project, and we agreed to take a similar approach. We arranged a date, postponed a few internal meetings and shared out the prep ahead of our next meeting.

Between us, we gathered, shared and analysed information including:

• feedback that users had left on content on the subject of medals
• figures showing the breakdown of user groups applying for medals
• ‘source material’, such as the MOD Medal Office Customer Charter
• analytics for the medals content, including page metrics, search terms and sources

We also drew up a rough content plan to propose solutions to some of the issues we identified.

Working together at the MOD

We started by working through known problems to structure the day. After an initial review, we agreed to completely cull some detailed guidance as it was duplicating content elsewhere on the site. We wanted to focus on designing the mainstream content based on our data and research findings.

We decided to reorder the chapters based on what we’d learnt from the analytics, then split off. Alex and GOV.UK content designer Graeme Claridge worked on rewriting the current pages, and MOD digital content officer Laurence Mallows created new content. Then we held a mini show and tell, helping spot minor errors and improve the flow of both sets of work.

In the afternoon we focused on the specialist medals content, which describes individual medals. There were around 50 individual sections to write, which was far too much for one afternoon.

Instead we took on the 2 pieces in most need of attention as a team, rewriting and stripping back the content to meet the needs of users. That gave Alex and the Medal Office a template that they could roll out across the rest of the guidance.

Going live

We spent the next week or so refining the content in our individual departments. Graeme made a few tweaks to the mainstream guide following a peer review, while Alex collaborated with subject matter experts back at the Medal Office to ensure accuracy in the specialist content.

A few phone calls followed, allowing us each to review and approve these further edits, or suggest a different approach. In keeping with the rest of the project, this proved a painless process due to the patterns we’d established on our day spent at the MOD.

Some final tweaks later, and the updated medals guide and guidance on medal types and eligibility are now live. We’ll review it over the next few months to see how users are engaging with the content.

The latest iteration of the Service Manual is now published. The Service Manual exists to help people across government build services that meet the Digital Service Standard and prepare for service assessments.

Over the past year, we’ve built a new front end and created or updated more than 150 pages. We’ve just added a new homepage.

We’ve made all of these improvements gradually. In September we wrote about some of the work we did earlier in the year. Now, we want to share what the latest steps have been.

Changes we’ve made

Ahead of making any changes, we ran a discovery to find out what the most valuable improvements would be. As a result, here’s what’s changed:

• we’ve been improving topics since we first published in January 2016, and we’ll keep doing that
• we’ve introduced a new information layout for easier navigation: we’ve created new topics, subtopics and guides and we’ll continue to test and improve them
• subject-matter experts have checked every piece of content in the new manual to make sure it’s up to date and factually correct
• we’ve removed duplicate content and redirected content so bookmarks and saved links don’t break
• the manual is now written in plain English and follows the latest GOV.UK style guide
• we’ve standardised the way we present content across the manual so that it's consistent and therefore quicker and easier to read
• we’ve built a new publisher so that it is easier to update the content - previously we updated content via Github

This is just the beginning

What we’ve done has given us a great base to build on, but it’s just the start.

We’ve already started improving content and we’ll continue to do so based on analytics, user research and feedback, and the help we get from experts.

We know that every service is different, and the manual can’t just explain how to build a service in a one-size-fits-all way.

GDS wants to support government to build great services and we want the Service Manual to play a part in this.

Talk to us

The Service Manual is for the benefit of service teams across government. With your help, we can make sure it keeps improving. As we iterate the manual, we want to hear from you.

There is a feedback option at the bottom of every page of the Service Manual. You can also leave a comment below to let us know what you think about the changes.

It’s the time of the year for ‘best of’ lists. In keeping with the season, we’ve been looking back over some of the most popular blog posts of 2016. Here’s a selection:

Service design

In February, Head of Design for government Louise Downe blogged about service patterns, and applying the logic of design patterns to service design. Service patterns make it quicker and easier to build better services and easier to link these services across government.

Understanding Service Patterns: diagram showing the hierarchy or design elements, page patterns, transaction patterns and service patterns

From data to registers

Earlier this year, the first register, the Countries Register, launched in beta. Registers are authoritative sources of trustworthy reference data. In March, Ade Adewunmi wrote about the work of the Register Design Authority, part of the GDS data group, and its work ensuring registers accurately and helpfully reflect the interconnectedness of government data.

Doing the hard work to make accessibility simple

In May, Alistair Duggin blogged about the work he’d started on making GOV.UK accessible. He explained how he wanted to ensure people are not excluded on the basis of a disability from any government sites and services. He talked about how, through moving to a culture of designing with accessibility in mind, services would be made accessible by default.

Head of Accessibility Alistair Duggin

Working at GDS

In June, Fajer Qasem shared her experience of her first month working at GDS with the GOV.UK Notify team. In the blog she talks about finding her feet at GDS and how much she enjoys working with a team of talented multidisciplinary team of developers, designers and user researchers.

It's ok to say what's ok

It takes 2: pair writing at GDS

At GDS we like to make things as easy as possible to understand. In September, content designer Sue Davis shared her experience of pair writing, a technique we use to write simple text that helps our users do things that are often complex. Her post gave a guide on how – and why – to do it well.

Cathy and Sue pair writing

Thanks for reading and for all your comments on blog posts throughout 2016. We’ll be back in the new year.

From a user’s point of view, the definition of a government service is simple: it helps you do something.

But how services are designed and made across government is far less simple. So we carried out a user research project to find out how GDS can better support people at different stages of service design and delivery.

GDS already offers a number of things that help service teams in different ways. For example the Service Manual gives guidance on creating better services. Teams can use common components such as GOV.UK Pay and GOV.UK Verify to build services more easily.

But we wanted to test our assumptions and see if there was any other support we could offer.

Over 6 weeks last summer, I visited 6 government departments and one agency to explore how services are made, from conception to delivery. I spoke to 50 people, including policy advisors, service managers, finance controllers and designers.

Here’s what I found, and what GDS is going to do about it.

Stages of development

For the research I prepared a hypothesis of the service design journey that broke it down into 5 stages:

Stage 1: Decide to do something

Stage 2: Shape the thing

Stage 3: Write business case (part of the process to get funding and approval)

Stage 4: (Re)design service

Stage 5: Make and run service

Using this hypothesis as my starting point, I shared it with people I visited in departments, asking a set of common questions that included:

• how closely do the 5 stages mirror your own experiences?
• when do you or members of your team get involved?
• where are the pain points?
• who else gets involved at each stage?

2 separate cycles

The research confirmed a few things. It showed that creating government services is a very complex process. It can involve lots of steps and lots of people. And the process varies hugely in each department and from case to case.

One thing that came up across departments is that the process for creating and launching new services can broadly be broken down into 2 cycles: the policy cycle and the delivery cycle.

The activities within these cycles can vary. The policy cycle may contain activities like deciding to do something and then shaping that thing. The delivery cycle may contain activities around designing and making services. The important thing is that there can be little or no relationship between one cycle and another.

One service manager I met said: “Most departments have a really distinct policy profession, a really distinct analytical profession, a legal profession. And then we’ve got digital technology in a separate place.”

Breaking down the barriers

The research found that there is a clear recognition across government that there should be more collaboration between policy and digital to break down the barriers between these cycles. And there is an increasing momentum to make this happen.

Home Office Digital Head of Service Design Kate Tarling recently wrote a blog post titled What do service designers do?. In it, she said everyone involved in creating government services needs to be “thinking about the entire end-to-end service and wider context, not just a small part of it”.

As one department’s Chief Digital Officer told me: “It’s not enough for a service designer just to talk service design, the service designer has to be able to start to talk policy and policy has to be able to start to talk service design.”

And in the words of a policy advisor: “There needs to be more trust between policy teams and delivery teams, because if you walk in their shoes you see they’re great people working hard. Just having those different perspectives means you can get a lot of mistrust, which is why you need to mature the relationship.”

How GDS can help

This research has identified areas where GDS can play a part in helping to increase understanding of the skills and roles of each other throughout the service process. And how we can work with departments and other organisations who are also focusing on this area.

One way we think we can help is by facilitating cross-government service networks. By this we mean networks of people who might be in different roles and different departments but who are all working on meeting the same user need. For example, users who have mobility issues and want to apply for a parking permit. Or users who want to start a business.

We took this concept to the most recent Transforming Together event and got some great feedback. We’re now planning to work with departments to develop this and other ideas, to help the collaboration that is already happening and to support departments in their mission to make better government services.

We’ll be sharing more on this soon.

I’m Anais and I’m a Policy and Engagement Lead at GDS. I joined GDS earlier this year as part of a recruitment round that brought in a number of policy and engagement professionals. Like others who joined at the same time, much of my background is in government departments. I wanted to tell you a little bit about what I’ve learnt over the past few months.

Why I joined GDS

The recruitment round was part of the organisation’s efforts to work with departments to support government as a whole to meet its objectives. GDS is here to support, enable and assure government departments as they go through digital transformation. To do this, we need people at GDS who are experts in digital, data and technology. We also need people who understand how government works. Over time, more of us are developing skills in both areas, but it is a journey.

In essence, the digital transformation of services relies on making policy an integral part of digital delivery teams and vice versa. This is pretty unique to government. So GDS, along with the departments, have to pave the way for this.

I joined GDS because I was keen to help with this endeavour, while expanding my knowledge and skills in the digital space.

My experience so far

It’s been a great journey so far, but it hasn’t always been easy. Being from a different background and having a different role to most of my colleagues means I often have a different frame of reference.

Coming from the policy world, I speak a different language to digital teams. Things that are similar can sound very different. To give some really simple examples, scoping becomes discovery, pilots become alphas and phased roll-out means beta. Learning the vocabulary is half the battle.

At times, I’ve introduced further complexity into our work. For example, when helping my team understand how decisions are made in government. The reality is always more  complex than the theory, and at times it’s thrown some well-formed plans or added a number of steps - like extra stakeholders to keep up to date or more evidence to pull together.

I’ve also been able to make things easier for us and colleagues across government in a number of situations. I’ve helped the teams find new ways to tackle old problems. Helping them speak the language of government means we can connect, partner and agree on things more easily. And I’ve been able to draw on my old networks to point to others who are approaching similar problems in different ways – like the Economic and Domestic Secretariat or Policy Lab.

The different perspective and relations we all bring means we don’t have to pursue our mission of improving government services alone. After all, it’s what most civil servants join government to do. We just need to find new and better ways to do it together.

Improving how we work – together

It’s not easy to integrate into a team when you bring a different way of working and thinking with you. But a few months in, I’m starting to get the hang of it. And while I’m probably biased, my team say that welcoming more people with a background in policy has made a real difference to them, too. If you’re interested in finding out more about opportunities to work in digital, data and technology, do get in touch.

As our director general said recently in a blog post, GDS is here to support, enable and assure government departments in their digital transformation. That means more listening, more collaboration and more sharing between us all.

In this spirit, I spent 5 days with the Ministry of Justice (MOJ) Digital and Technology team at the end of last year. I was invited over to the MOJ offices at Petty France to help them with work they are doing to establish a new specialism: technical writing.

The MOJ has deep experience in content design and digital engagement, but they recognised that technical writing needs a different set of skills. Technical writers must have a strong understanding of both technology and content so we can make technological things easy to understand. These skills are currently not widespread within government and, where they do exist, they often exist in isolation without much support.

Why do we need technical writing?

I’m one of 4 technical writers at GDS and our team is growing. Across government, departments and agencies are starting to recognise technical writing as an important skill – and, in some cases, recruit people to help with technical writing in a full-time role. But there’s still some misunderstanding about what technical writing is and how to improve it.

Development teams build and improve a lot of systems and services across government. Although we design services and systems to be as simple as possible, sometimes users need extra guidance and documentation. Clear technical guidance that’s readily accessible, such as API documentation, helps technology teams learn about best practice and share their experiences with each other, which can save a lot of time and duplicated effort.  

Spending 5 days with the MOJ

The MOJ has a lot of technology-related content that needs to be produced and made accessible so people across the department can work to the same standards and principles. The department also wants to share its technology best practice and experiences with the rest of government, through blog posts and other content. The technology and content design teams thought that a technical writer might be a useful addition to the department. They were keen for me to discover how much of their work actually required a technical writer and also how to get the best out of this potential new role.

I spent a week with the MOJ team to understand how they create, update and share technology policies and other content. I spent time with around 15 people across the department, including:

• technical architects
• security experts
• intranet specialists
• service managers
• engagement teams

Based on our discussions, it was easy to see how a dedicated technical writer would be able to help create and organise that content, freeing technical architects and others to concentrate on digitally transforming the justice system. I collated my findings and advice into a content strategy, and now the MOJ is preparing to hire its first full-time technical writer.

How does technical writing work at GDS?

At GDS, every technical writer is embedded within a team. We move around depending on which teams need help and work with technology experts to produce accessible, accurate content. As I type this, I’m sat with a content designer to my left and a technical architect to my right. Content production is much easier if I’m able to ask both of them questions or advice.

We help teams like the Service Manual, registers, Common Technology Services and GOV.UK Verify, and help to run the Technology at GDS blog. We also get involved in other technology-related content, including technical job adverts, policies and writing for user interfaces.

What’s happening in other departments?

We’ve started working more closely with other departments to improve how they share technical knowledge with their users and within their organisations.

As well as my recent work with the MOJ, departments and agencies such as HMRC and Companies House are also heavily involved in technical writing. Both publish technical documentation for developers. For example, HMRC publishes API documentation on its API Developer Hub. As we continue to build services and systems across government, this type of content will only become more important. Government technology users should be able to rely on support and guidance to use that technology, especially if they didn’t build the technology themselves.

What’s next for technical writing in government?

As well as helping project teams with their documentation and publishing user guidance, technical writers across government are starting to evolve their role.

For example, at GDS we’re introducing writing guidance and standards for developer documentation. We’re also building a community to support anyone doing technical writing across government. You can find the community on the cross-government Slack at #technical-writing and on Basecamp. Comment below if you’d like an invitation to the Basecamp group.

GDS and MOJ will be recruiting for more technical writers very soon, so keep an eye on the Civil Service jobs board to find out more and apply.

We’ve just launched the new Service Toolkit. It’s a single page that brings together all the things that are available to help teams building government services.

We recently published the latest iteration of the Service Manual to give teams guidance on how to build great services. Now we’ve launched the Service Toolkit to give them quick access to the resources they need.

User research

We carried out user research with people who use GDS resources and identified these high-level needs:

• people building government services need to find guidance easily and know that it’s up to date so they build a service to the current Digital Service Standard  
• they need their work to be consistent with other UK public services so that users trust the service and are familiar with how it works
• they need to find out the best way to solve a problem and not waste time duplicating work someone else has already done

There are resources available that can help with this. But that won't help unless service teams know about them.

As one user told us: “I would like a much more simple way of understanding what things GDS has that can be used for my services.”

Having one page that hosts all these resources is a very simple way of doing this.

Building with the Government as a Platform principle

The Service Toolkit currently features links to:

• standards: the Digital Service Standard, the Technology Code of Practice and the Service Manual
• design and style resources: design principles, design patterns, reusable frontend code, the GOV.UK Prototype Kit and the style guide
• components to design and build services: GOV.UK Notify, GOV.UK Pay, GOV.UK Verify, GOV.UK Platform as a Service and Registers – open data sets that a service can consume to perform a task
• service data: the Performance Platform
• buying resource: the Digital Marketplace

All these resources have been built so that they can be used again and again and follow the Government as a Platform principles, which include meeting a common need and making things easy for the user.

Resources that reflect the Government as a Platform principles are not only provided by GDS, so over time the toolkit will expand to include contributions from the rest of government.

We’re developing ways for people to contribute to the resources in the Service Toolkit. For example, we already create content in the Service Manual in collaboration with cross-government communities. And we’re looking at setting up a model for collecting design systems across government.

Where there are contributed resources, we will ensure that they go through a rigorous assurance process so that users can rely on them.

Developing links

Building a single page to host all of these resources is only part of the work we’re doing. We also need to ensure that people know about the new Service Toolkit and can access it easily.

We know that most people currently go directly to the tool or component that they need to use. So as much as possible we’re linking back from these resources to the Service Toolkit. For example we’ll be introducing breadcrumbs on product pages that link back to the toolkit.

We’re also developing a set of new product pages. This will give service teams a consistent experience when they want to find out more about the different tools and components available to them. We’re rolling this out across the resources, starting with Notify.

The Service Toolkit will be a fundamental part of all digital training – such as service manager training – so that everyone who needs to use it is aware of it.

Improving the page

We’ve developed the Service Toolkit based on user research, but there are a few questions we can only answer with further feedback.

For example, we need to make sure that the page’s purpose and proposition is immediately clear to users. And we need to make sure our content is structured in the best way.

So we will iterate the toolkit based on what our users tell us.

We’d love to know what you think about it. Please let us know by commenting on this post or using the ‘Is there anything wrong with this page?’ link at the bottom of the Service Toolkit page.

The apprenticeship service passed its private beta assessment in December.

I’m Vanessa, Digital User Experience Manager at the Skills Funding Agency (SFA). I’d like to share how we worked with GDS to get the apprenticeship service to this stage and how we’ll incorporate feedback in public beta.

The apprenticeship service

Apprenticeships raise skill levels and deliver strong returns for the UK economy.

The apprenticeship reform programme makes apprenticeships more rigorous and responsive to the needs of employers. A key part of the reforms is the upcoming introduction of the apprenticeship levy in April 2017.

The levy will take effect on 6 April. It requires all employers operating in the UK, with an annual pay bill of more than £3 million, to invest in apprenticeships.

To handle that change, the SFA is developing a service to help employers manage apprenticeships. We started to build the service in 2015 with just 4 people. Today there are 100 people working on it.

Some elements of the service, such as Find apprenticeship training and Recruit an apprentice, have been delivered. The biggest change will be when a management tool for the levy goes live.

Apprenticeship service private beta

There was a risk that different elements of the apprenticeship service would be siloed. To prevent this, we ran a private beta across the whole service, creating a single user journey for the employers we were testing with.

There were several challenges we needed to overcome:

Selecting employers

Choosing 100 employers with a good cross-section of characteristics was a complicated process. We had to make sure all sizes and types of employers had their say.

Testing legislation that is not yet active

We wanted to test how the flow of data and funds would work, so we simulated the process. Since employers won’t be paying the apprenticeship levy until April 2017, we had no data to use. To test accurately, we created accounts containing simulated funds for the employer to spend. We collected data from employers, which allowed us to estimate the amount of levy they would pay, and gave them an appropriate amount to test with. This created a lot of manual work, but the results were realistic. We tested how the interfaces and processes will function in detail.

Testing behind-the-scenes processes

To manage the flow of funds, there are complicated processes that need to work in the background. We didn’t want to test the interfaces independently of these processes. We worked with our internal data teams to simulate month-ends, so we could show payments entering and leaving employers’ accounts, and test the reports that were then generated. We gave employers specific tasks to do. Co-ordinating them was no small task, so we took on a research assistant, Laura. Laura is an ex-apprentice who helped to manage the work with employers, then collated and analysed their responses.

How did we test?

We tested in several ways to get a rounded set of results. During each round of testing, 15 employers were picked for qualitative face-to-face sessions. We also conducted around 20 moderated sessions, usually over the phone. We sent out around 15 detailed diaries for participants to keep as they worked through the service. Everyone else was sent a survey to complete. This gave us a mix of qualitative and quantitative data to analyse during each round of testing.

Our assessment

Our private beta assessment was run by GDS. Unusually, our assessment happened before our private beta finished and some time before our service was due to go live. With a ministerial deadline looming, we wanted to ensure there was time to take in panel recommendations.

Preparation was essential. We shared our research with the GDS user researcher who would be on our panel. We chatted through the information he’d need for the assessment, which we hadn’t done for the previous one. That was really helpful. It meant he had enough background information before the assessment and we could focus on assessment-specific questions.

Public beta

We have already used the private beta feedback to make some important changes to the service. For example, we learned a lot about what our users need to understand before they register for the service, such as who will be on their apprenticeship team and where to find their log-in details. This has helped us to develop content to guide them through the process.

The service is now in public beta and selected employers are being invited to register in phases from this week.

The apprenticeship service is due to go live by May 2017. In the meantime, you can follow our progress on the SFA Digital blog.

Data infrastructure is about building the foundations for the way government uses data. Not just now, but in the future. This work deals with some very technical, system-level infrastructure, so why are we doing user research? Surely you only need to worry about that for citizen-facing services?

Well, no. Whatever you build, wherever you build it, there will be always be users, be they citizens or other people working in government. And if the service doesn’t meet user needs, it will fail. There are a few risks with data infrastructure in particular. We’ve found that if you don’t take account of the diverse needs of users across government, you risk making dangerous assumptions. It’s easy to start building for an idealised data future, rather than the reality of how data is actually being used today.

In this post, I wanted to share 5 lessons we’ve learnt about making data infrastructure user-centred.  

Most government service teams don’t really care about data, they care about their service

If we want to get people to change their data habits and use the new pieces of data infrastructure we’re building, such as open registers, we can’t just tell them to do it. We need to show people how we can help them to improve their service. Understanding this means that we’re learning to make the infrastructure relevant and adoptable because it addresses the real-life problems that services face, rather than just asserting how we’d like people to be using data. That would be our need, not theirs.  

Sourcing and updating data still relies on people

We’d all love to think that there’s a world of fancy data updates and verification processes magically operating somewhere in government. The reality is, finding and updating data still relies on people talking to people. If someone wants reference data, such as a list of prisons, they’ll probably ask someone in their team. If we don’t take account of this behaviour among users, we impede their chances of finding and using the data sources we’re developing.

In government, spreadsheets are the default model for data

Microsoft Excel is everywhere in government. Most civil servants aren’t using specialised data formats. They’re looking at data in Excel. So when they are searching for and investigating whether a dataset is useful to them, they need to see it in a way they’re used to: a spreadsheet. Even if the underlying structures we’re creating are richer and more flexible, we’ve learnt that spreadsheets need to be an option for users who prefer to consume data in this format.

Use metadata sparingly

We thought it would be a great idea to include helpful metadata, so users understand the data before they use it. If you’re unfamiliar with the term, metadata is data about data, such as who created it or why it was created. But most users prefer to see the actual data first before finding out more about the dataset. They may want to see a small amount of specific metadata, like who created the data and when it was updated. But mostly it’s about checking out the data first. Showing users too much metadata upfront is overwhelming and doesn’t reflect how they assess the value of datasets.

Using any third-party data source is about balancing risk and reward

Most services rely on data. However when teams store their own copies of data, such as lists of prisons or schools, it can be difficult to keep it up to date. Out of date data can lead to a poor service experience. So data specialists advocate fetching data from reliable sources using automated services like APIs (application programming interfaces). However, during our research we found many service teams still prefer to store their own copies of data. Understanding this has altered how we serve data in our services. For example, with open registers, users can choose to download the latest copy of a register rather than use the API. This gives them the benefits of using up-to-date data, without any risk.

Does any of this sound familiar?

If you’re building services with data, we’d love to know if these lessons resonate with you. Equally, if you’re using external data in your service, either open or from another government department, we’d love to speak to you to make sure the infrastructure we’re building meets your needs. Get in touch via email.

Today, the Minister for Cabinet Office announced the launch of the Government Transformation Strategy. I’d like to take the opportunity to thank everyone across government who collaborated with us to build on the work we’ve done since the 2012 Government Digital Strategy.

There has been a huge team effort to ensure that the 2017 strategy reflects the needs of the people of the UK by enabling government to work in a modern way. This strategy charts the direction of the digitally enabled transformation of government – in how we work, how we organise ourselves and how we serve our citizens. It’s been designed to be carried out at pace and scale: to deliver meaningful change to the people who need it most, faster and more efficiently.

With the work that we’ve done as part of the 2012 strategy, we’ve truly demonstrated the potential for digital transformation of public services. We’ve redesigned and rebuilt some of the most used services. For the first time, digital professions have been established across the public sector. And, a strong foundation has been laid for departments to share platforms, components, code and best practice.

The collaboration across departments that brought the 2017 strategy into being is the start of what we hope will be a new pattern of work. We know that the work of transformation needs to penetrate deeper than ever before. We need to make sure data can flow easily between departments, allowing us to build joined-up services that run seamlessly across government. This will be how we start to reshape the relationship between citizen and state into one that puts power into the hands of the citizen.

To achieve this we have arranged our strategy into 5 main themes. We will focus on:

• business transformation: continuing to deliver world-class digital services and transform the way government operates, from front-end to back-office, in a modern and efficient way
• skills and capability: developing the right skills and culture among our people and leaders, and bringing together policy and delivery to enable services to be delivered in a learning and iterative environment, focused on outcomes for citizens
• enabling the Civil Service to deliver: building better workplace tools and processes to make it easier for public servants to work effectively, including sourcing, governance, workplace IT, businesses cases, human resources processes, common technology across the public sector and better digital tools for civil servants
• data: making better use of data – not just for transparency, but for transformation across government that will allow us to build joined-up services
• shared platforms: creating, operating, iterating and embedding good use of shared platforms and reusable business capabilities to speed up transformation – including sharing patterns and components and establishing open standards

We’ve been ambitious in the breadth and scope of this strategy. Collaboration across government will not always be simple. However, we’re confident that government is aligned in its digital ambition. And we’re working to establish targets that make sense for everyone. The role of GDS will be to support, enable and assure departments in meeting these goals.

Transformation is a constant process with no endpoint. But, in government, there is a clear need to measure progress. We need to hold ourselves accountable for the work that we are doing. And, we need to prove that meaningful changes are being made.

For this reason, we’ve set ourselves some milestones. The plans detailed in our strategy are set to be complete by 2020. But we know 2020 is not the finish line. The work we want to do should be a foundation for the digital government of the future: a government that is readily adaptable, and able to keep pace with technical change and evolution. We’re already planning for the things we’ll do beyond 2020, and we’ll keep you updated as we go.

As ever, we’ll be keeping our work as open as we can. We’ll be telling you about the progress of individual projects and discoveries. And we’ll keep talking to departments. In the next few months, the dialogue around the strategy will continue on the GDS Roadshow as we travel around the country. You’ll hear more about what we learn from these events soon.

Photo: WN Bishop

UKGovcamp is an annual unconference that’s dedicated to digital in the public sector. The GDS Black, Asian and Minority Ethnic (BAME) network ran a stall and a session at this year’s UKGovcamp on 21 January.

Gender balance is a recurring theme at UKGovcamp, and it provides opportunities for everyone to talk more about diversity. However, it was noted that there is still a lot of work to do in terms of addressing the cultural make-up of the attendees.

One of the UKGovcamp sponsors, Richard Barton from CIO Portfolio, offered the GDS BAME network the chance to attend and have a stall at UKGovCamp.

Committing to diversity

Attending UKGovcamp was a reflection of the network’s commitment to diversity. We had no expectations of the day, but we wondered whether there would be an appetite for discussions around ethnic diversity.

Having a stall was a great opportunity for us. It increased the visibility of our group and allowed us to directly engage with a greater number of UKGovcamp attendees in the digital and technology community on the topic of diversity. We spoke to people who didn’t know about the GDS BAME network, so it was a great opportunity to promote what we’re doing and share our aspirations.

Photo: WN Bishop

The atmosphere was welcoming, and those who wanted to pitch an idea or discussion point were encouraged to do so at the morning session of the unconference. There were a variety of great pitches, including a few that weren’t related to digital and technology. Some pitches were about diversity and inclusion in organisations. From the GDS BAME network, Tia Priest, Daniel Sintim and Samantha Bryant pitched: ‘How to attract and retain BAME talent in the tech and and digital industries.’ The audience was energetic and accepting. Our pitch was successful. 

Running a session at UKGovcamp was the highlight of the day. Our session had a great turnout with lots of people from different departments and organisations feeding into our session. You can see what was said in the write-up of the session notes.

More discussion, more diversity

Overall, it was a thought-provoking experience, with lots of discussion and points to take away from the day. UKGovcamp is now looking into treating ethnic equality in the same way as gender. They’ve asked the GDS BAME network to help inform this discussion.

It is clear that simply being present at events like this can have a big impact. It can result in organisers and attendees addressing issues such as lack of diversity within the workplace. The GDS BAME network hopes to attend many more events with the support of GDS and its Diversity and Inclusion manager.

Special thanks to Richard Barton for giving us the opportunity to attend UKGovcamp and to have a stall, and also to Tia Priest for referring the BAME network to Richard.

We recently published our draft 2017 to 2018 roadmap for GOV.UK, outlining the work we want to do over the next year. The goal for all this work is to make GOV.UK – the single domain for government – work harder for users.

Our roadmap blog post talks in detail about what we’ll be doing. In this post I want to talk about why we’re doing it, and some of the principles that will underpin our work.

We want to build on the work that has gone before

GOV.UK is the government’s most mature digital product. We launched in beta at the beginning of 2012. By May 2013, all government departments had migrated to GOV.UK. This means we’ve been the central publishing platform for all of government for nearly 4 years.

In that time we’ve learned a lot about how government publishing works. We’ve worked closely with departments. And we’ve now got the vast majority of government’s content on to GOV.UK.

We’re now in a position to achieve our next goal – to make this content work harder for users. To improve the single domain to meet user needs.

We want to deliver our objectives

We’ve broken our goal into 4 objectives:

• group and transform content
• measurably improve common user journeys
• help users to hold government to account
• improve the platform basics

Within these objectives there are some large and extremely significant pieces of work.

For example: we’ll be working with departments to help them understand how their content is used and understood by citizens. And any changes they might need to make to content team structures, so that content produced by a department continues to be well maintained. Head of Content Design Trisha Doyle has previously written about our content operating model plan.

We’ll be looking at ways to let users see how content has changed over time. And providing a supported API for content so that anyone can take a reliable feed of our content.

And we’ll be working on site search. There will be a stream of work to improve search both on, and to, GOV.UK. This is a fundamental issue that we can’t leave any longer.

We want to continue successfully working in an agile way

The 2017 to 2018 roadmap is a combination of tactical, achievable, visible bits of work, alongside longer term transformational work. All of this is on top of the ‘business as usual’ work we do to ensure that GOV.UK is secure and reliable and performs as it should.

To achieve all of this, we will continue to work in the agile way that we always have. We’ll use the methodology that we have used since the start of GOV.UK, which we used to deliver a piece of national infrastructure.

Throughout this year no mission will be longer than 3 months, and many will be shorter. We will maintain flexibility so that we can change direction if we need to. We’ve set aside time to improve things, but left the details open so we can pick the most useful thing when we get there and so teams have autonomy of scope.

We want to help transform the relationship between citizen and state

As the Government Transformation Strategy says: ‘by harnessing digital to build and deliver services, the government can transform the relationship between citizen and state’.

At GOV.UK we are at the heart of this. Our bit – the publishing platform – is where users interact with digital government services. It is where this ‘relationship’ actually happens.

This is why making the single domain work harder for users is such an important goal. And why our team is ready to do this now.

We believe that successful digital transformation comes not through the choice of a particular technology stack or IT system but through the work of people and teams.

Over the past few years we have dramatically improved government’s ability to design and deliver digital services as well as modernise the critical technology infrastructure that runs our country.

However, there is much more to do.

Making government the employer of choice for digital

Our goal: to make government a major destination for digital, data and technology professionals.

I have worked in many private sector organisations but government is one of the most exciting and rewarding places I have worked: for its scale, the complexity of problems, and the difference we make to people’s lives.

To deliver the ambitious targets we have in the pipeline, we need to fundamentally change how we attract, develop and retain technical professionals in government. In May 2016, our Digital, Data and Technology Profession team was asked to work with departments to make this a reality. Since then, we’ve worked with more than 600 colleagues from across government. We’ve collaboratively tackled issues such as competition for talent between departments, balance between insourcing and outsourcing, pay disparity and clarity in career paths. Here is an update on where we are.

Areas of focus

We have made progress quickly by working collaboratively with departments and technical communities across government to:

• build a common taxonomy of job roles
• set out clear career paths and capabilities
• enhance the pay and reward for critical roles
• develop our learning and training offer
• improve ways of growing our own talent

Common taxonomy of job roles – one national structure

Currently there are myriad different job roles across government, many of which are identical but with a different label. This means it’s not easy to move jobs between departments and it can be confusing for those who want to join government.

As part of building the digital and technology profession, we are creating a single structure of job roles. We’ve reclassified and reorganised job roles across departments into a new taxonomy of around 37 job roles. This will be used to create consistency and alignment across departments.

Immediate benefits include a more visible route for career progression and a better grasp of the huge scale of job opportunities for specialists across government.

Clear technical career paths

We are defining what’s required at each level of the reclassified job roles, as well as a clear set of criteria to test them. We’ll publish these in the open so career paths are transparent. We hope this will encourage technical specialists to have a long-term career in government.

Improving the pay and reward offer

Our salaries are funded by the taxpayer, and this drives a strong value-for-money mindset. But we want our pay and rewards to be competitive.

We are working on a set of new pay ranges aligned to the taxonomy of job roles. One of the methods used to fund this will be to reduce the reliance on contractors and interim positions, and create more permanent roles.

These will give more flexibility for key technical roles, both in terms of increased salary and allowances.

Scaling up our learning and development

We know from user research that continuous professional development is a key driver of retention.

With the Digital Academy, government has built an excellent learning resource for specialists. In the future, we will add to the popular classroom-based courses with other types of learning, for example, online, distance learning, onsite or multi-format.

Departments can tailor learning to their individual needs by drawing on these resources as well as a curated marketplace of training providers.

Growing our own talent

We have done a lot of work on how we attract specialists into government, and most departments have taken big strides forward on this.

But this will only take us so far. In parallel we also need to develop skills from the ground up.

We now have a digital and technology graduate scheme, Civil Service Fast Stream, and an apprentice scheme, Civil Service Fast Track Apprenticeship, both aimed at developing specialists of the future.

We are also retraining thousands of civil servants who currently work outside of a technology role, using both training and on-the-job learning.

This builds a stronger skill base and increases our pool of readily available talent for current and future needs.

Join the transformation revolution

The only way that we can transform public services is by attracting, retaining and growing the right technical skills in government.

We have started the journey, but there is a lot more to do to make government the destination of choice for digital, data and technology specialists.

Our approach is, as ever, driven by user needs, working collaboratively and making continuous incremental improvements towards our goal.

If you would like to join the transformation revolution in government, visit our Digital Careers Gov Twitter page to see current opportunities.

Arif Harbott is head of the Digital, Data and Technology Profession team at GDS. Follow Arif on Twitter and don’t forget to sign up for email alerts.

Last year on International Women’s Day, we publicly announced the GDS Parity Pledge. It said that:

In future, no-one from GDS will take part in a panel discussion of two or more people unless there is at least one woman on the panel, not including the chair.

In future, no-one from GDS will speak at an event unless the event's organisers are clearly working hard to address gender diversity on stage. It's hard to put a number on this sort of thing, so we will make that decision based on what we see on each event's draft agenda

We'll hold ourselves to the same standards where GDS is the host, for internal events and public ones too.

Ideally, when GDS is invited to supply a guest speaker for an event, we’d like to send women to speak just as often as we send men.

So one year later, how have we done on our pledge?

More gender diversity at external events

Since 8 March 2016, we’ve sent 151 people from GDS to speak at 143 external events. We’re excluding small meet-ups from this as we don’t have a way of tracking who is speaking at these types of events. Occasionally, we’ve sent more than one person to speak together, or in different sessions, at the same event.

Of the 151 that attended, 88 were men and 63 were women. That’s 58.3% men and 41.7% women.

This time last year the figures were roughly 75% men and 25% women. So although we’re not quite at 50/50 equality a year later, we’re much closer to it.

More gender diversity at internal events, too

Internal Civil Service events are tracked differently. To find out what progress we’ve made with these, I looked at 4 events that took place within the past year:

• Civil Service Live 2016, which took place at 5 different venues across the country
• design community meet-ups every 2 months
• ConCon 3 and ConCon 4 – 2 separate content design events

At Civil Service Live, GDS ran a ‘digital hub’ with 6 presentations from speakers representing all our major programmes of work. Across all 5 locations, we sent 51 individual speakers with a breakdown of 29 men (56.9%) to 22 women (43.1%), slightly better than our external figure.

The design community meet-ups usually attract about 100 attendees. They are a mix of updates from senior leaders, guest speakers and show-and-tell sessions from design teams. From March 2016 to March 2017 there were 6 events with a total of 97 speakers, with a gender split of 59 men (60.8%) to 38 women (39.2%). There is overlap of speakers where the heads of design are largely the same at every event, though. Once again, a very similar total to the external events figure.

ConCon is a biannual event run by the Content Design Community. Each ConCon event is a mix of keynote speeches and workshops. For the last 2 events (ConCon 3 and 4) there was a gender split of 24 men (46.2%) to 28 women (53.8%).

How did we get there?

The figures show a definite improvement, and we believe that it’s largely a result of that public pledge. Having it online as a shareable post has made it easier for us to explain our diversity values to event organisers.  

Our conversations with those event organisers have varied. In a small number of cases, we’ve had to pull out of conferences where the organisers did not demonstrate a commitment to the same values.

Organisers have said things like:

• they “invite only the best people to speak at events, it just happens that they are male”
• “women are not suited to a career in business, we will not invite them to speak simply to suit your agenda when we do not see that there is a problem”

We didn’t speak at those.

Making a difference

But the majority of our conversations with event organisers have been extremely positive.

Many are eager to learn how they can improve on diversity at their events. Some said that they struggled to find diverse speakers. We helped where we could by providing lists of colleagues across government and at GDS who are experts in their fields. Others said that, during the past year, they have taken action to make their events more diverse. Some have actively and openly adopted the same pledge.

In addition, the GDS Women’s Group and in-house Creative Team have set up presentation and public speaking training sessions. Over the past year we’ve trained more than 270 people at GDS to deliver presentations, and worked closely with 10 women on a longer, more detailed trial version of that training, spread over 6 weeks. It covers everything from writing Call for Paper submissions, to preparing slides and being able to present them confidently.

Being the change we want to see

Our pledge has made a difference. Better representation on stage helps to encourage women to apply for roles they didn’t think were for them, or to attend conferences where they didn’t think they were welcome. It encourages women to be part of the discussion and it welcomes different points of view on stage.

There are so many amazing women working in tech and digital fields who don’t get the opportunity to speak on stage, and don’t get the same level of recognition as their male peers. That is something that we still want to change.

As we said last year: “This is not tokenism. This is important. This is us doing our bit, and taking action.”

And through taking action, we’re starting to see change happen.

Follow GDS on Twitter, and don’t forget to sign up for email alerts.

Karen is a Publications and Information Officer in the screening team at Public Health England. Nick is responsible for public and professional information for all the national population screening programmes, including leaflets and online content.

Since 2013, we’ve been helping about 300 colleagues in the Public Health England (PHE) screening team to write content for screening reports, both printed and on GOV.UK. We knew from user feedback that some of these reports were too long – users didn’t have time to read them.

Our digital content team was also getting these reports and other publications as PDF files or after they had been signed off, when we couldn’t make changes or help much.

User need

The national Screening Quality Assurance Service team asked us to train their assessors to write effectively before we started publishing some of their content on GOV.UK.  

We saw this as an opportunity to work more closely with everyone who writes across the organisation. We wanted to train everyone in PHE screening on what content design means and how best to work with us, not just how to write well.

We knew that GDS offers training in clear writing for everyone who publishes to GOV.UK, so we spoke to them. They weren’t able to train all 300 people in PHE screening, but they wanted to work with us.

Plan of action

We worked with GDS trainers to adapt the clear writing training they were running.

We found examples of content that worked for our writers, and looked for research that supported how we were asking them to write. We also added in a section on writing for blogs, as we needed to help people write blogs for the PHE screening blog service.

The writing workshops

The course focuses on writing user-focused content, which helps everyone at PHE Screening write better reports, emails and blog posts. We offer training to small groups, so we get to know everyone on the training.

Content designers need their colleagues to understand what content design is and how to work with content teams effectively. We raise understanding in the course by talking about user needs, how people read, accessibility and the data that content design is based on. We also practise pair writing, so they know of one great way to work with us.

Each session lasts for 3 hours, and is run by 2 people from our team. We review the slides for the next session based on how the course went and the feedback we got from attendees. The course changed a lot after the first few sessions, but it’s settling down. We think we’re meeting our users’ needs now.

What’s happened

We knew that the training would take up our team’s time and might be a bit scary. It helped that we worked with GDS to create the training, and they gave us feedback after the first 2 sessions.

But we think it’s been worth the time and trouble.

We’ve got stronger relationships with the people we’ve trained. They know who we are, and they’re more likely to come to us before content is signed off or turned into a PDF. We’ve even started pair writing sessions with subject matter experts.

We’ve now trained about half of PHE screening staff, and plan to train everyone else here by summer 2017. Although we were nervous about running the training ourselves, it’s become the best bit of the job for some of us.

You can do this too

Starting in April, GDS will be offering training for content designers to help them train others in their departments. If you want more information, please get in touch with gov.uk-training@digital.cabinet-office.gov.uk

Read about the PHE screening team’s work at the PHE screening blog or email the team at IEPP@phe.gov.uk if you want to know more about their experience of this training.

Follow GDS on Twitter, and don’t forget to sign up for email alerts.

The Department for Environment, Food and Rural Affairs' (Defra) new online fishing rod licence service recently moved from private to public beta. You can read more about this in service manager Claire Quigley's post about the move.

Head of Digital at Defra, Sally Meecham, explains why the service is so simple, a child can use it.

Photo by Vegar Norman, used under Creative Commons Licence

I watched a show-and-tell by Claire and delivery manager Mark Sherwood, and was really impressed with what I saw. Here are the four things that really stood out for me.

User research, user research, user research

This team did an unbelievable amount of user research. I know that those of us working in digital government bang on about user research a lot, but there's a reason for that: it matters. It informs the work, and it helps the team understand what to build and how to build it. It helps them avoid building the wrong thing, in the wrong way.

That's why this new service is doing so well. It meets  user needs, because the team behind it took the time to talk to them in detail.

So simple, a child can use it

The rod licence service is one of the few Defra services – in fact, one of the few government services – that is available directly to young people. Anyone aged 12 to 16 can get themselves a fishing licence using the new service. They don’t need a parent to help or give permission. And the junior rod licence will be completely free after 1 April 2017.

This is important for 2 reasons.

Those teenagers will be adults in a few years, and for many of them, the rod licence application will be their first experience of using a government service online. It will set their expectations for the future, so that in a few years, when they need to use more government services, they will already know what it feels like. Using the rod licence service will set a new standard for what ‘normal’ means to them.

To best meet the needs of those young people, the team building the service didn't just make assumptions - they actually went and spoke to young people. They arranged visits to schools where they spoke to current and potential anglers. This was just one aspect of the user research done for the entire service, but it proves the point that research matters for all users - even the ones who aren't yet old enough to pay tax or vote. The result is a digital service that is literally so simple, a child can use it. Because young people are allowed to use it.

An empowered team is a successful team

During the show-and-tell, Claire said: "We've been lucky - we've had autonomy from the start, we felt empowered and trusted to get on with it."

That comment really struck me, because it sums up a powerful truth: if you get the right team together in the right place, and give them the freedom to get on with doing the right work, amazing things will result. That's how things like GOV.UK were made, that's how dozens of other services have been made since then. That's the model I want to see spreading further across Defra.

We have lots more teams working on lots of other services. Right now, a lot of them are still in very early stages of development - discovery or alpha. I see it as part of my job to help the teams working on those projects, to give them the freedom to move ahead with their work in the same way that the rod licensing team did.

Mistakes that make us stronger

Claire said something else that got me thinking: the first time this service went through the Digital Service Assessment run by the Government Digital Service, it failed.

Both Claire and Mark pointed out that after the initial disappointment, the team felt re-energised. It was a setback, but it was also an opportunity to learn and move forward. As a result, they built a better service.

An award-winning service

The new service is already gaining traction and recognition.  In a single day (Thursday 2 March), it sold 1,601 licences, generating over £40,000 in revenue. Since Monday 13 February, it has sold 15,124 licences worth over £273,000. It also won an internal Defra Corporate Services award for making things simpler. Congratulations, team – that was well deserved.

To me, all of this is a sign of the positive change, both cultural and organisational, that’s going on in Defra. The fishing service team have been learning from failure, they’ve been doing the hard work to make things simple, understanding context, and designing with data. This is what digital change looks like. This is what’s happening in Defra right now. It makes me very happy to see it.

Follow GDS on Twitter, and don’t forget to sign up for email alerts.

Not so long ago, product roadmaps in government were viewed as experimental and optional. Now, they’re seen as an important tool for delivering better products and transforming government services.

Exploring roadmaps in the community

Each product manager in government should be managing a roadmap for their product or contributing to one at the portfolio level. That said, exactly how roadmaps should look, what they should capture and how they should be managed varies.

We were keen to explore how different departments approach roadmapping and what challenges they face, and discuss good practice. Our monthly cross-government gathering of people interested in product management – Product People – seemed like the right forum to do that.

The benefits of roadmaps

Neil Williams, Head of GOV.UK, kicked off the February Product People meet-up by talking through why GOV.UK had started using a roadmap. He discussed the roadmap’s evolution from a paper-based list into its current format, which sets out GOV.UK’s mission from 2017 to 2018.   

Neil explained that a roadmap is a high-level visual summary mapping out the development of a product over time. It’s a useful way of showing the vision and direction for a product, and ensuring that everyone is working towards common goals. Roadmaps suit agile ways of working because their format is lightweight, simple to engage with and it allows for frequent adjustments based on changing priorities.

Portfolio roadmaps and delivering value

Next, Scott Colfer, Head of Product at Ministry of Justice (MoJ), talked about using a roadmap format to see the development of several products in a portfolio at once, which is something they had been doing at MoJ.

Scott showed us the MoJ roadmap and shared some useful learnings from his team so far. He said that portfolio roadmaps work best when you have a good understanding of what the service you’re building is, who its users are and what value you are trying to deliver.

Consistency, not uniformity of roadmaps

Toby Smith, a product manager at Home Office, showed the Home Office’s experiments in roadmapping and introduced the idea of standardising roadmap formats not just within departments but across government.

The team at Home Office found that one size doesn’t necessarily fit all in practice. But Toby believed there was some evidence that a consistent approach could make roadmaps more credible in the eyes of key stakeholders. This provoked a good debate and we agreed to reconvene to explore a common set of cross-government principles to support roadmaps.

Future community gatherings

Our session on roadmaps was another good example of getting together as a community to learn and make the most of the wealth of skills and experience across government. It’s the sort of opportunity that makes you challenge what you know and enables you to get support from others. It’s another example of how we are working together to grow the right people, skills and culture to transform policy and service delivery in government.

Product People meet-ups take place in London monthly, with other regional meet-ups popping up across the UK. Comment below if you work for the UK government and would like to find out more.

You can follow Ross on Twitter, and don’t forget to sign up for email alerts.

At the start of the year we launched the Service Toolkit. It’s a single page bringing together all the available things to help teams that are building government services.

As we said in our blog post about the Service Toolkit, one of the user needs for the page was to make service teams aware of the different resources available to them.

In response to this user need, we’re also introducing new product pages and a new technical documentation format that can be used by the resources the Service Toolkit links to. To provide consistency and help users recognise that a resource is provided or curated by GDS.

The user need for consistency

There are a number of ‘products’ that GDS offers to the rest of government. These include software components like GOV.UK Pay and GOV.UK Notify.  

These different products and components have been designed, built and are operated by different product teams, all following the Government as a Platform approach. They all looked slightly different.

The teams that run the different products carried out user research with their service team users, and they found that people want to be able to recognise products that came from GDS.

To help achieve this, we wanted to provide one product page design and one technical documentation format that could be used by all these different things.

Creating the product pages

The new product landing pages use a blue banner for visual consistency. They all have short sentences at the top of the page that describe what the product does. For example, the  GOV.UK Pay product page says: ‘Take and process payments for your service’, and the GOV.UK Notify page says: ‘Send emails and text messages to your users’.

The pages all have ‘Contact the team’ buttons that allow service teams to contact the GDS teams in charge of them. They also link to the product’s technical documentation – the information that describes how the product operates and can be integrated.

But we also had to make sure that we balanced this consistency with flexibility. The pages need to work for a number of different types of products.

So, teams can change the options on the top navigation. They can add links to trial accounts. And they can embed videos explaining how the product works.

The teams running each product will carry out user research, and the product pages can be iterated in response to this.

Creating the technical documentation

In the same way that we found teams using lots of different formats for product pages, we also found they were using different templates for their technical documentation.

Lots of teams were using existing platforms, such as Gelato and Github Pages, so we carried out an audit to see if there was a platform that we might be able to build on.

We decided to build a template based on the static site generator Middleman. We tailored the platform to suit the needs of the users, who are generally developers, and the technical writers who would create content for it. We also worked to make it accessible.

The technical documentation is currently formatted as a single web page. In the user research this came back as something developers are comfortable with – we saw them using the ‘Command-F’ keyboard shortcut to search for words and phrases on the page.

It was also important that we made sure that the layout was responsive. This is because we observed that developers often use multiple, resized windows on their screens for coding, documentation and previewing their work. On smaller browser windows and mobile devices, the table of contents presents as a full-screen overlay.

Using the new product pages and technical documentation

All the products linked from the Service Toolkit are currently using versions of the new product pages. GOV.UK Platform as a Service is using the new technical documentation format and the other product teams will implement it soon.

We’re iterating both of these things based on feedback from the teams who are using them.

We’ve also published an example of the product page and a template for technical documentation.

Follow GDS on Twitter, and don’t forget to sign up for email alerts.

I recently joined GDS as the Head of Editorial for our cross-government blog network. I’m already impressed with the blogging work my colleagues are doing across GDS and beyond.

In this post I look at some of the highlights of March 2017 across our digital blogs. Here’s your chance to catch up on what we published that month.

Supporting users to verify

The team at GOV.UK Verify are committed to ensuring that their users receive comprehensive support when verifying their identity online.

In one of their March blog posts, Ciara Green and Kay Dale talk about how the team carried out research and interviews with their certified companies to better understand how they support their users to verify.

GOV.UK Notify is now open for use

After 9 months, 3.5 million messages, 32 live services, 850 code deployments, and 500 hours of user research — GOV.UK Notify is available to all of central government.

Read Pete Herlihy’s post to find out more about the launch of Notify and what the next steps are.

Improving navigation and search on GOV.UK

The team at GOV.UK has been doing a lot of work behind the scenes.

For example, they’ve been experimenting with how to organise the 300,000 pages on GOV.UK to make the navigation and search work better for users.

Mark Hurrell blogged about what exactly the team has been doing and why their work is about to get more visible.

The first national framework for technical roles

Over the course of several months, cross-government working groups have brought consistency to the multitude of technical roles that exist in the public sector.

They have built a single structure of digital, data and technology job roles and career paths that can be used by departments to help them find, develop and keep the people they need to build the best public services.

Read more about the framework and its benefits in a blog post from the Digital Data and Technology Profession. 

Using Trello on the GOV.UK Publishing Platform

The team at GOV.UK use Trello to support their Kanban process.

In March, Alan Wright blogged about how the team use the app and other plugins to optimise the Kanban process.

Roadmaps in government

Not so long ago, product roadmaps in government were viewed as experimental and optional. Now, they’re seen as an important tool for delivering better products and transforming government services.

Read Ross Ferguson’s post about how roadmaps are being used in government.

Launching a user research panel for GOV.UK

A user research panel is a database of people who have volunteered to share their details – such as name, contact details and basic demographic information – so they can be invited to participate in user research sessions appropriate to them.

Katie Taylor’s post talks about how the panel works.

Building a design culture

Kara Kane blogged about the essential steps to building a design culture. Read her post to learn more about the importance of strong design leadership, collaboration, flexibility, support, shared tools, and keeping design fun.

Writing clearly to help the whole organisation

The national Screening Quality Assurance Service team at Public Health England (PHE) asked GDS to train their assessors to write effectively before they started publishing some of their content on GOV.UK.  

Karen Manser and Nick Johnstone-Waddell blogged about how GDS worked with PHE to deliver this project.

Did you find this round-up useful?

Leave your feedback in the comments below to let me know if you’d like to see a round-up like this one each month.

Follow GDS on Twitter, and don’t forget to sign up for email alerts.

The relationship between citizen and state can only transform if we create and maintain meaningful relationships with government departments.

That means explaining what we do in GDS and how we can help, but it also means listening. As an organisation, we must get better at listening to our colleagues across government. I believe that face-to-face meetings are the best way of making that happen.

I’m really pleased to say that the inaugural GDS roadshow has led the way in developing those relationships and facilitating conversations.

The roadshow gave us the opportunity to hear people’s views on the challenges departments face when delivering the Government Transformation Strategy and how GDS can support them. It gave us a chance to understand departmental priorities and explore what more we can do to support and enable transformation activity.

I’d like to share some of what I learned from the roadshow.

People are happy to see GDS outside London

Just the act of getting on a train and leaving London for the regions showed we were committed to working collaboratively and the organisation is a credible transformation partner.

Senior leaders from GDS travelled to Bristol, Manchester, Newcastle, Leeds, Glasgow, Birmingham and Sheffield (Swansea and Liverpool are still on the roadmap) to meet with other departments and local authorities.

People told me how glad they were to see us outside of Aviation House having face-to-face conversations.

The atmosphere at each location has been informal, interactive and designed to encourage participation. For this first series of roadshows, we limited attendance to between 40 to 60 delegates which gave everyone the chance to be heard. We’ll be adapting the roadshow to ensure that the right people know about them in good time.

...and GDS people are happy to be outside London

I couldn’t help but notice how much our own staff enjoyed interacting with colleagues they’d perhaps not come into contact with on a day-to-day basis.

It is so much easier for our colleagues across government to learn about our products when there is someone from GDS at hand. The delegates at the roadshow are users of our services and there’s no better way to ensure that we’re meeting user needs than when they’re right in front of us giving feedback.

GDS staff gained energy when they heard from users and were enthusiastic when they were asked for help or advice.

Getting local

The feedback we’ve had from the roadshows has indicated that there is a desire for GDS to be more local.

In terms of improving the national visibility of GDS, the Digital Academy will be a huge part of our efforts.

Back when it was owned by the Department for Work and Pensions (DWP), the purpose of the Digital Academy was to provide learning opportunities for civil servants. The courses on offer enabled them to work on agile digital development projects that build services to meet users' needs. As GDS adopts the Academy, we’ll be expanding the curriculum to offer more learning opportunities in data and technology.

Next stop

We know that every objective in the Government Transformation Strategy is important, but  hearing about the challenges people face in the pursuit of transformation helps us to prioritise.

We’ve learned a lot about ourselves as an organisation - not all of it has been easy to hear - but we’re committed to iterating and improving.

Our next roadshow takes place in Swansea on the 20th April. Email gds-events@digital.cabinet-office.gov.uk if you work for the UK government and want to find out more.