Designing Digital Services For Government

This is the story of the work I completed on the National Apprenticeship Service (NAS) at the Education & Skills Funding Agency (ESFA) over a period of 24 months.


Working within the public sector is not without its challenges, but it can also offer a unique opportunity to gain exposure to some truly user centred design practices with resources & budgets rarely seen outside the public sector.

I was fortunate to gain exposure to a system of delivery of design at scale, using best practices from public sectors all over the world to deliver a high level of usability & accessibility to an audience en mass in a fragmented & silo-ed organisation.


My experience was a nice contrast to the commercial sector & I gained valuable perspective to working in both, further illuminating my understanding of the various cultural challenges of the role of the designer.

Designing Digital Services For GOVERNMENT 

Government Digital Services (GDS) framework

Digital service design for government must adhere to the standards set by the Government Digital Service (GDS).  The Digital Service Standard is a set of best-practice principles for designing and delivering government services. It sets a framework for agile experience design to build services that are simple, clear and fast & conform to a design framework.

A part of the framework defines a set of patterns & tools that allow designers working on public services to share best practices, both inside and outside of government all over the world.

Government design principles

1. Start with user needs
2. Do less
3. Design with data
4. Do the hard work to make it simple
5. Iterate. Then iterate again
6. This is for everyone
7. Understand context
8. Build digital services, not websites
9. Be consistent, not uniform

 

Note: An updated Service framework is due to be release at the end of June 2019. This is not dissimilar to the one in effect during my time at the ESFA, but for reference I use that which was in effect during my time.

Martha Lane Fox, UK Digital Champion & instigator of the Government Digital Service,

on strategy for government services

 

“…the citizens’ champion with sharp teeth

for transactional service delivery…”

Do the hard work to make it simple

 

GDS DESIGN PRINCIPLE

 

THE SYSTEM

TRANSACTIONAL INFRASTRUCTURE

The core product I worked on was essentially an online ledger where employers manage funds in their National Apprenticeships account. Core users of the system are large scale employers, with multiple hundreds of apprentices and organisations which provide training & assessment for apprentices for these employers.

The product was a legacy system, with an inherited core set of high volume/high influence users as early adopters. My work focused on a balance of enhancing the product functionality, whilst maintaining the UX & workflow for the high influence existing users.

As a transactional ledger system, adhering to the GDS design principle of one action per page, the screens for the system are not visually distinct or engaging, which is often the case for government UI. With office scenarios as its main use case, often in HR or payroll departments, our stats showed that 99.8% of users worked via desktop, however designs were created with a mobile first, responsive approach.

This is for everyone

 

GDS DESIGN PRINCIPLE

 

Universal Access

Government Services for Everyone

As with every government service, accessibility is a legal requirement for digital products. The GDS philosophy on accessibility states “If we have to sacrifice elegance – so be it. We’re building for needs, not audiences. We’re designing for the whole country, not just the ones who are used to using the web.”

Designs were required to conform to the highest international accessibility specifications & were evaluated to such.

This experience  was fantastic exposure to how it is possible to deliver such a high level of accessibility at scale, through a fragmented & silo-ed organisation such as government.

Be consistent, not uniform

 

GDS DESIGN PRINCIPLE

 

GOV.UK Design System

WOrking with Styles, Components, Patterns

Digital Services (GDS) framework defines a set of patterns & tools that allow designers working on public services all over the world to share best practices, both inside and outside of government.
Designs were restricted to a limited set of design patterns to ensure consistency. An example of such a pattern is the requirement for no more than 1 action per page. Although a challenging limitation for my role as designer, it was an enjoyable challenge to come up with creative solutions.

Agile Approach

Working At Speed In Changing Rules

Government digital service production needs to be able to respond quickly to policy changes and the needs of the public.  To do this, an agile approach is used in design & development of digital services throughout government. Agile development involves building a core digital service quickly & then continually improving it to make it better.

The stages are defined as: Discovery, Alpha & Beta. These are not dissimilar from a traditional user experience design process, but with a focus on delivering a built solution driven from an intensive user needs discovery process investigated in the Discovery phase. Once released services are continually developed to improve by releasing frequent updates.

Within the design process for existing products where new features & functionality are being developed, prototypes of these new features & functionality are quickly designed, prototypes built, user tested & iterated to improve if required, before being released to the live product.

Continuing the agile mindset, ways of working are continually refined, with sprints lengths varying as ways of working through departments are refined. Techniques like scrum, Kanban, stand-ups, & show & tells are used to promote communication & to make sure all parties are kept up to date and informed across all departments.

Do the hard work to make it simple

 

GDS DESIGN PRINCIPLE

 

Service Design

Making Things Simple

Public sector itself is complex, & its role is to deal with complex problems. The National Apprenticeships Service system that I worked on was no different.
The system was responsible for processing several millions of pounds of apprenticeship funding each month, with multiple employers managing over a thousand apprentices each month.
As with any financial product, with high volume, comes high risk. Even a minor issue in functionality had the potential to have catastrophic effects.
We used a service design approach driven by user needs to help create solutions focused on user needs over organisational needs.

Start with user needs

 

GDS DESIGN PRINCIPLE

 

USER RESEARCH

EXAMINING THE DATA

To reduce potential risk, we needed to know the needs of our users intimately.
I worked with a dedicated user researcher & encapsulated insights in a comprehensive set of personas.  Personas were updated as the audience of the product broadened & as functionality increased.
We conducted weekly user testing sessions, testing every design before build & release.
A part of the challenge was to engage the wider team with this user focus so we summarised versions of the personas & presented them along with findings from the user testing sessions.

Understand context

 

GDS DESIGN PRINCIPLE

 

Sketching

Rapid Design

Within the design process, hypothesises for potential design are formed based on user needs. Often sketching is used as a technique for early design iteration, to quickly visualise requirements from specifications, bringing them alive to visually illustrate what the descriptions may actually means in practice.

With a design process operating in a high pressure, fast paced agile environment needing to respond quickly to policy changes & the needs of the public, sketching was a great way to bring together policy requirements, user needs & development restrictions.

Using whiteboards & paper sketching allowed me to quickly collaborate on ideas, to turn around design hypothesises quickly, adapting based on new information & feedback.

Iterate. Then iterate again

 

GDS DESIGN PRINCIPLE

 

Rapid prototyping

Designing For All

Designs were finally output in the form of HTML type prototypes using the GOV.UK Design System and GOV.UK Prototype Kit.
Although initially complex to learn, using a comprehensive library of set styles, UI components, Nunjucks macro & Heroku publishing format, the prototyping kit enabled designs to be quickly prototyped, user tested & iterated to improve if required, before being released to the live product.
Code developed was not intended to be used in production, so speed often took precedence over quality of code.
Some of the challenges I faced along with other cross organisation designers, were learning the system with little support, versioning of design hypothesis whilst maintaining a record of previous design versions, & maintaining a quality of code over the speed of output required from teams.
The prototypes enabled a schedule of rolling user testing each week, with every design testing before build.

GOVERNMENT DIGITAL SERVICES

GOVERNMENT DIGITAL SERVICES

Valuable perspectives for the designer

Working within the public sector is not without its challenges, but it can also offer designers valuable exposure to some design processes & resources not readily available in the commercial sector.

It is a lesson in scaling a system of delivery of design across an often fragmented & silo-ed organisation, as well as offering the unique design challenge of targeting an audience en mass, in often complex subjects, to include a high level of usability & accessibility for all users.

And for such a task, it includes budgets rarely seen outside the public sector, so it is an opportunity to gain exposure to user centred design resources for a truly user centred design practice.

My experience was a nice contrast to the commercial sector & I gained valuable perspective to working in both, further illuminating my understanding of the various cultural challenges of the role of the designer.