The standards are there to set minimum requirements to help schools and colleges make more informed decisions on technology. We have already published 8 standards on the GOV.UK website.
With every standard put through user research, we received feedback on the format of the standards.
The trouble was, we needed time to sit down and understand where people were struggling with the format, and to look at how we could help them. And we really needed everyone present to agree on ideas to test.
So, along came Manchester and our team away day – this was our time to tackle the formatting beast.
The format of the live standards
If we look at one of the cyber security standards as an example, you will be able to see the headings we currently have live. These are:
- the importance of meeting the standard
- how to meet the standard
- technical requirements to the standard
- dependencies to the standard
- when to meet the standard
Why we wanted to change the format and understand the content
The project has been running since March 2022 but, as a content team, we are fairly new. We have recently begun the process of writing some of the newer standards. And, while looking back through the format and content of the standards that were written before us, and how they have evolved since the start, we wondered how we could improve them for the future.
This needed to be a little lighter touch than just throwing the whole format in the bin and starting from scratch. This was down to timing and impending deadlines to write more standards.
User research on the standard format
During research interviews, we found some reoccurring comments that we knew we needed to address.
- The importance of meeting the standard: research suggested that users felt this section was often repetitious and too long, however they liked it when we included risks and some benefits – including risks and benefits was not a standard practice and had been done in some standards, but not others
- How to meet the standard: users were sometimes confused about the difference between this section and ‘technical requirements’
- Technical requirements to the standard: the heading was sometimes misleading because it did not always contain technical details, but was instead perceived as an extension to ‘how to meet this standard’
- Dependencies to the standard: this was often confusing due to the word ‘dependencies’ – the standards referenced within this section were often just ‘related’ and the user did not understand the relationship between them
- When to meet the standard: we received overwhelming feedback that users did not like it when we used the phrase ‘as soon as possible’ – this felt unachievable and was unhelpful
Running a content workshop to gather information and knowledge
Along with the learnings from user research, we needed to understand the views of both policy and subject matter experts.
The aim of the workshop
We wanted to walk away from the workshop with:
- an understanding of new headings we needed to test
- a new content guidebook for what needed to be included under each of those headings
- acceptance criteria that helped the content designers focus on achieving both policy, user and SME needs for each section of the content
Getting the right people in the room
We needed the whole team to attend the workshop. Within our team we had:
- user researchers – to hold space for the user’s needs
- policy – to tell us the policy intentions and limitations and what needed to be covered to create change
- subject matter experts (SMEs) – to input their expertise in the subject area and tell us what needed to be included
- delivery managers – to plan for us to make changes and agree actions
- content designers – to take all of the above and create a new template that worked for everyone
The format of the workshop
We spent the first part of our workshop figuring out what makes a standard – talk about opening a can of worms! You can read more about this fun existential standards crisis on our other design history post called ‘what makes a standard...a standard’.
After that minefield, it was on to unpicking the headings and content that we had always worked with.
We started with the headings and looked at what:
- information people would expect to find under the current heading
- user research we had that suggested the heading worked or did not work
- alternative heading suggestions we could come up with that would better suit what we were trying to cover
Next up, after deciding on what to call these new headings, we ran through the content that should sit under each section. We also needed to create rules and guidance about what needed to be under each heading.
We started with a blank page with just the new headings at the top. We then asked everyone to go around the room and place sticky notes under each section. We wanted them to cover:
- what content needed to be under each heading
- what rules would apply to the content under those headings
- the acceptance criteria of the content
Outcomes from the format and content workshop
With lots of feedback on the walls and on our Lucid board (for those that joined online), it started some great discussions around the room about how we could work together to improve standards and the things we’d all struggled with.
We then gathered all of the feedback together and placed it on one board. After gathering the key points, we pitched this to the team to make sure they agreed, before setting a template that detailed:
- the new headings
- the content
- what acceptance criteria was to be placed on it
Headings
We set new headings to test with users to see if they would help to make the content clearer and more focused. For example, we added a new section titled ‘Who needs to be involved’ - feedback suggested that users needed to understand what roles are responsible for certain standards so that they can assign the right people to the job.
Content
We set rules in place that would give the content designers a steer on what information they would need for each section. For example, the content under ‘when to meet this standard’, would need to include:
- clear next steps – to be explicit and explain why they need to meet the standard in the timeframe
- an explanation to follow the words ‘as soon as possible’, so that people know why we have asked this (legal reasons or compliance)
- specific enough to provide guidance and reassurance, but not to cause panic
Acceptance criteria
We set acceptance criteria to each heading so that when we write, we know which keywords we are measuring against. Details of this part of the session can be found in our other blog post labelled ‘what makes a standard...a standard?’.
What’s next for the standards format and content?
You can never know if the assumptions that you make are correct without testing them first. So, to follow the work that the content designers have done, our wonderful user research team will:
- send the proposed new format template to previous research participants to get their feedback
- collate the feedback and play this back to our team for discussion
The content team will then:
- take the feedback on board
- implement any changes to the template
- run this by the team
- start using this on all new standards
Along with all of this work, we know that we are still not quite there. We have some key pieces of the puzzle missing that we need to look at. These include:
- testing the live standards and making content iterations based on feedback, so that we can keep evolving our work
- understanding the relationship between each standard topic to help us identify which standards are dependent on one another and if there is an order to them – this will help our users know where to start and keep track of the standards they have read
- setting clear success criteria against each topic and the standards within them as they are published