Navigating the GDS Jungle

How To Get Your Government Website Through a GDS Assessment

With so many rules surrounding the GDS assessment criteria, it can be hard to know where to start. Here’s how you can navigate the key tenets that you must get right from the outset.


"It’s like a jungle, sometimes it makes me wonder how I keep from going under”.
 

Ah! The wonderful wisdom of Grand Master Flash. While it’s highly unlikely that he was referring to the potential pitfalls and perils of getting your government website through a Government Digital Service (GDS) assessment, the sentiment more than applies to this often complicated and confusing process.

In March 2015 gov.uk listed 287 UK government websites who provide essential services to the public, businesses or other parts of the government. The vast majority of these websites went through a rigorous vetting process before the great British public were allowed anywhere near them.

These websites were subjected to a set of far reaching guidelines known as the Digital By Default Service Standard. The standard is a huge repository of information and technical resources available to teams working on government websites. It covers everything from the initial user research, through to having the site tested by the government minister. Ultimately it allows digital teams to deliver world-class products.

Every government website is assessed to ensure that it meets a set of 18 GDS assessment criteria. With so many rules and restrictions, it can often be daunting and difficult to know where to start. There are several key tenets of the standard that you MUST get right from the outset, as you simply won’t be able to backtrack and revise the project if you start without them.

It’s in the way that you use it

At its very core the Standard is designed to ensure that tax payer funded websites are suitable to users’ needs, rather than simply matching the website administrator’s perception of their needs, or the government’s need to impart information to the users. To that end, you should:

  1. Conduct a Discovery Phase where the users’ needs are analysed and properly understood. At BrightLemon we specialise in Discovery lead, user-centric product development. This usually involves workshops with user facing stakeholders and crucially the users themselves. It also involves assessing the different types of users and what services are already being provided to them. The outputs of the Discovery phase will determine the scope of the project as you begin to build your Alpha service.

  2. Conduct users research throughout the project, not just at the start. GDS will demand evidence that your service has remained true to its users’ needs by continued testing. One of the most fascinating types of testing is lab based user testing, in which typical users are asked to perform a set of tasks on the work-in-progress website, often with unexpected results and frustrations. This type of user testing never fails to highlight problems with your user experience (UX) that can be quickly addressed. Other types of user testing include focus groups, one-to-one interviews and surveys.

Agile, iterative and user-centred methods

The user research mentioned above is channelled into a number of user stories that form the product backlog. The delivery team works in dedicated “sprint” periods of uninterrupted work, usually lasting two weeks. During this time a set of stories from the backlog are worked on, and developed. At the end of each sprint there is a new iteration of the service that can be released, and crucially used for testing. The users’ feedback is then channelled back into the product backlog, before the next sprint starts again.

Similar to BrightLemon and the occasional Gazelle, the GDS team loves the agile way of working. Here is a video from GDS explaining their take on agile, how it compares to older forms of project management and how the feedback from real users is crucial.

Best thing in town

GDS puts a huge onus on the selection of your team. Part of the purpose of the Standard is to ensure that the best expertise is sought and put to good use. Some of the key team roles are:

The Service Manager

In agile project management the service manager is the product owner. This is the person who is ultimately responsible and accountable for the service. It is their job to represent the various stakeholders, lead the team, guide the development of the service and promote its uptake by users. This person is usually a civil servant with a high degree of digital literacy.

The Delivery Manager

This would typically be the project manager or scrum master with the supplying agency. It is this person’s job to help the team self organise, remove obstacles, facilitate smooth working, organise meetings and ultimately deliver the work requested by the Service Manager.

Developers

The Developers are of course the makers of the digital service. They are the skilled software engineers who work, write, adapt and maintain the code that makes the service run. Typically a Developer will be deeply skilled in one particular language or platform. In the case of BrightLemon, we are a team of Drupal CMS specialists and are very fortunate to have a wealth of experience and PHP programming language skills.

  • Other roles within the team often include

    • Designers

    • Testers

    • Technical architects

    • Content designers (a specialist content writing role, usually filled by someone within a government department)

It’s not unusual for certain team members (Service Manager, Delivery Manager and Developers) to stay with the service throughout its lifetime. Other specialist roles may be recruited for certain key sprints or phases, which is something that the digital agency model lends itself to very well.

This is by no means an exhaustive list of what you need to pass the GDS assessments - the Standard covers a myriad of other things like security, open standards and licensing, the gov.uk style guide and the four mandatory key performance indicators.

That said, the user research, agile methodology and your team are such crucial foundations of the whole service, they must be in place from the outset.  

Reading the service manual before you do anything else will help provide a solid foundation for any project you’re looking to undertake, and the team at BrightLemon are more than happy to answer any questions you may have – we also promise to avoid any tenuous song quotations in the future.

Update: Breaking News

Since I posted this blog we have had a successfull GDS Beta > Live assessment on one of our clients websites. After a few months in public Beta the Civil Service Resourcing Job Share Finder website has passed its final assessment and is now ready to be fully launched.