I recently completed a user experience (UX) review on a digital service in Beta. When a digital service is in Beta, it is close to launching to the public. In the review I found the team had added a new link and it opened a PDF. The content in the PDF seemed important and helpful to people who would use the digital service. I found myself re-reading it a few times and it was a bit hard to understand. I could tell it might not meet the government's reading grade standard which is for online content to be between grade 6 to 9.
I ran the PDF text though a tool we use to assess the reading grade and complexity levels. I found the reading grade level was grade 13 and 7/13 sentences were rated as "very hard to read" and "hard to read." There were 212 words and the estimated time to read the page was 51 seconds.
As part of my report for the team I included 3 recommendations for the PDF.
- Remove the PDF. It was only a 1/2 page of content and would be better suited as a web page.
- Rewrite the content to meet the reading grade standard.
- Build and publish a webpage with the new content.
Does PDF content count as real content?
When I meet with project teams to go over the UX review report, they often have questions and we work together to figure out how to meet the government's Digital Service Standards.
As we looked at my recommendations for the PDF, the team's initial response was to ask, "Does PDF content count as real content?" And if it is not, "Does it have to meet the reading grade level standard?"
PDF content is real online content!
I had to break the news that yes, content in PDFs published online is "real" content. It must meet the reading grade level, other online writing standards and additional standards like accessibility. In this instance there was a small amount of content in the PDF. It would be straight-forward to rewrite it and publish it to a webpage.
Can the team implement the UX recommendations for the PDF?
In our discussion the team identified a variety of potential barriers to implementing my recommendations. These boiled down to the timeline to launch the service and the processes they needed to follow.
1. Could they implement the recommendations before launch?
An important consideration in the team's decision-making was that the recommendations were one of many the team were actively working on. It wasn't that they didn't see it as important - they all recognized it was. Compared to other work, this might be less of a priority to complete before launch. It wasn't stopping people from using the overall service.
The team had around 2-weeks before their planned launch date. They were not confident they had time to rewrite the content, get it routed through their department approvals and get it translated before launch.
Rewriting the content
The subject matter experts on the team were not content specialists and being faced with rewriting content can be a daunting task. I ran an test so I could give them an estimate of how long it would take.
It took me under 20 minutes to rewrite and reformat a first draft. I was able to make the following imrprovements:
- Reading grade: Improved 5 grade levels. From grade 13 to grade 8.
- Sentence complexity: In the previous version, 54% (7/13) of the sentences were ranked as "very hard to read" and "hard to read." In the updated version 0% (0/30) sentences were flagged with this ranking.
- Word count: Reduced the word count by 53 words. The initial version had 212 words and the updated version had 159.
- Estimated reading time: Improved the time by 13 seconds. The initial version was 51 seconds and the new version was 38 seconds.
All of these improvements combined mean the information is much easier for people to use and understand.
I shared this with the team and they were concerned re-writing the content meant they were potentially changing the meaning. I employed the following techniques to ensure this did not happen.
- Removed duplicate content. One the 1/2 page of content, a few lines were repeated in each paragraph. I added them 1 time in the order I thought the user would need the information.
- Organize the information into logical groupings. Thinking about the message the content conveyed and the order people would consume it in, I created groupings I thought would make sense for users. This also helped me identify and remove duplicate content.
- Use bullets to break up complex sentences. By reformatting the content with bullets I was able to make the page easier to scan and highlight important points.
- Use clear headings. The initial version was a wall of text and there were no headings to help people see what information they'd find in each section.
- Used shorter sentences. This aided in making the content scannable and made it easier to understand. Sentences in the previous version combined more than one idea. This made it harder to follow and understand.
At 20 minutes to rewrite and an estimated 30-minutes to remove the PDF, build the web page and publish it with the new content - implementing my recommendations seemed possible.
Routing updated content through department approvals
They did not feel like there was time to get rewritten content through their department approvals process. Every department is different and this department had a more involved process.
When I conduct UX reviews of digital services, I want to catch these things as early as possible to give teams as much time as possible to implement my recommendations. Catching this addition in Beta meant the team might not have time to implement them before launch. They had estimated it could take 2 weeks to do this.
I always recommend project teams loop their communications lead in at the start of a project to ensure they meet all of the content requirements. This also allows teams an opportunity to update timelines for their mandatory reviews. In this case the link was added as one of the last content updates and they were not aware it should be a webpage.
Getting the updated content translated into French
This team already had the PDF content translated in French because it was on Yukon.ca. FLSD had already completed their translation for the digital service and the team were not confident they could get the new content through this process before launch.
Determining where the webpage would live
The team own the Yukon.ca content and the digital service. They were not sure the best place for it to reside moving forward. They wanted to check in with their communications team to figure out where the content should live. This could take some time.
Did the team implement the recommendations before they launched the digital service?
Unfortunately the team was not able to complete this work before their launch date. This was the only call they could make given the number of tickets they had to work through before the service launched.
Instead, they opted to:
- remove the link from the digital service; and
- made a plan to work with their communications team to complete the work once the digital service launches and the dust settles.
Working with this team inspired me to learn more about the reasons why staff still publish online content in PDF rather than an HTML webpage.