Designing the first release of the manual

With our bank of user needs we drafted acceptance criteria for each one.

Examples of user needs and acceptance criteria for accessibility and inclusive design

As someone in a service design team,
I need guidance for how to manage accessibility issues when they occur,
So that I can mitigate risk to the department or end user

This is done when the user knows (or can):

• how to prioritise issues
• some examples of category A issues and what to prioritise
• how to contact the accessibility team for prioritisation support
• they have determined which issues to resolve, which could be supported by our accessibility team
• that they need to track issues, where to track them and who needs sight of this
• what disproportionate burden to include in an accessibility statement
• what to include in their accessibility statement

Another example of a user need with acceptance criteria:

As someone in a service design team,
I need guidance for what tools are available, how and when to use them,
so that I know what tools to use and when

This is done when the user knows (or can):

• what accessibility testing tools are available
• why a team would use tools
• what each tool can do
• when to use each tool
• how to use each tool
• if a tool is specifically helpful for a certain profession

Our acceptance criteria will form the structure of all of our accessibility content. Each one helps us to know when each user need is met, and is ready to be tested.

We sketched the information architecture based on high-level themes identified through research

Starting with the 6 higher-level themes we identified through research, we sketched possible designs for the information architecture.

The themes:

1. Leadership and culture.
2. Awareness.
3. Standards and assurance.
4. Training and learning.
5. Tools.
6. Guidance.

For our MVP we considered how we can meet the needs of service teams through content.

We acknowledged that not all needs are best placed to be met by guidance in a manual. Through design workshops, we identified those needs that could be met through guidance, and ones that are best met in different ways.

For example, training and learning will be tackled differently to leadership and culture.

For leadership and culture, we will consider comms, communicating upwards and across leadership the needs of service teams, pain points and how we can address them.

Standards and assurance will overlap with the wider, cross-DfE work around standards for digital delivery.

As well as meeting user needs, we considered our 5 business requirements and things that we know teams just need to do to meet accessibility laws – this all went into the initial information architecture sketching.

We created groups of content as part of the architecture

This is a snapshot of a sketch of things relating to standards that we knew we must include in any accessibility guidance. For example, laws, regulations and legislation.

The following zoomed-out image is the first draft of information architecture for accessibility guidance with user needs and how might wes matched against each section. The how might wes helped us to identify different design ideas to best meet user needs.

This informed design possibilities including guidance content, training, workshops, comms, including cross-government resources.

We took all possibilities relating to guidance from this architecture and used it to create a structure for accessibility and inclusive design guidance.

This sketch shows the high-level structure for the accessibility and inclusive design manual. It includes what we know we can do now, and later. For example, standards, audits, statements, and some training can be part of our MVP. While profession-specific guidance will take longer to design, so will be part of the second release.

We ran a card sorting exercise with communities

With our basic structure in place, we ran a cross-community card sorting exercise.

Our goal was to understand if teams would theme the content in a similar structure to the one we’d sketched.

We’d use the findings to iterate our initial sketch, so that the information architecture worked in a way that people expected.

What happened during the workshop:

• 3 groups looked at the scrambled cards for content within the manual
• each group identified themes and grouped cards together
• as a larger group, we reviewed each of the 3 finalised structures
• we asked people what they would call the manual

The main learning we took away was that service teams expect to see a section on managing accessibility issues as a stand-alone piece of guidance, rather than within a statements section.

We also confirmed that people expect the manual to include inclusive design guidance in conjunction with accessibility guidance, so the working title of Accessibility and inclusive design manual was validated.

We created design principles

Following the workshop, we created 4 design principles for the manual based on feedback, what we’d learned so far and what we believe is in scope:

1. We do not duplicate GOV.UK content.
2. We will create 1 source of truth for digital delivery.
3. We are not focusing on diversity and inclusion work.
4. We are not focusing on tech we use in DfE.

We moved the project to GitHub, for simpler documentation and to manage the content flow

Now we had our information architecture, we moved all user needs, stories, how might wes and acceptance criteria to GitHub. We created a board of content tasks and linked each content page to a user story and acceptance criteria. This became the basic structure and way to document what content we were working on and when.

This image shows an overview of the accessibility manual as a project in GitHub. It shows each page, user needs and a workflow for the content to move through the workflow from being prioritised to review and staging.

Getting ready for release 1

We looked at the structure and confirmed what we could write first, for example, anything to do with law, regulations, statement guidance, tools. And considered what would come later: profession-specific guidance, using test script and ‘done when’ criteria and a triage process for audits. We drafted a roadmap for our first release to be shared with teams at the start of September.

We used the GOV.UK design system and looked across the UK and worldwide governments, as well as the private sector, to see how they talk about accessibility and inclusive design.

We documented page patterns, components and concepts, and sketched ideas in Figma.

We coded in the open and encourage feedback

The manual has been built using node.js and html with all source code published in the open on GitHub. This means anyone can make a pull request and suggest a change. Whether that's improving guidance, creating new content or adding new features.

We have linked to the manual from the DfE design manual, with a feedback loop to encourage feedback from teams and will be looking to understand how teams find it, whether it’s useful, what they think of the content, while we work on the second release during autumn.

We will also be confirming and considering our KPIs, which will include things like how many people take part in online accessibility training, download tools, and receive a green rating for Standard 5 in service assessments.