8 February 2022 to 22 February 2022 weeknotes: improving Welsh in the service and preparing for arrears payments and progress updates
Welcome to this bumper edition of weeknotes written by Jamie and Abbie — our Sr User Researcher and Content Designer. In this post we’ll be talking about:
- Improving Welsh across the service
- Laying the foundations for arrears payments and progress updates
Improving Welsh across the service
Why we did it
Since 1993, the Welsh Language Act has stated that certain public bodies should provide their services in both English and Welsh. We follow this standard at the National Lottery Heritage Fund. When we build the new service, add new features, and create new notifications we try to work with Liam, the Fund’s Welsh Language Officer to make sure everything we build is available in Welsh.
There are challenges though. The digital service design team works in an agile way, meaning we pick up a goal or a part of the service and focus on that for 2 weeks. Then we move on to the next goal. Anything we didn’t have time to get exactly right becomes ‘debt’ we need to address later. Sometimes that ‘debt’ is an inaccurate Welsh translation from an automated translator or a missed translation on a button and others are enhancements we want to make.
We want to make sure our service is accessible to everyone and consistent so resolving the experience for Welsh speakers is always important to us. Thanks to Liam and colleagues based in the Wales team, we were able to work together to identify potential improvements or gaps in the live service. To do this Liam and the Wales team created a report for us to work with and we visualised where the gaps were across the service.
What we did
We decided that we wanted to focus this sprint on Welsh improvements. We took the report and broke the work up based on size and which discipline had the skills and access needed to make the change. There was a mixture of areas to work on including:
- Updates to current translations
- New translations to be added to emails
- Updates to page furniture like word counters and BETA banners
- Creating bilingual emails
After defining the tasks, we approached the work from three directions:
- content
- front-end development (the bit users see)
- back-end development in Salesforce (the bit staff see)
Example of content changes
One content change was to update answers for buttons.
This example shows:
- ‘Dim’ meaning ‘No’ has been replaced with ‘Neb’ meaning ‘Nobody’
- ‘Amh.’ that Google says means ‘for H’ has been replaced with ‘Amherthnasol’ meaning ‘Not applicable’
While these changes may be small, they improve the quality of the experience for Welsh speakers by increasing the clarity of what we are saying.
Example of front-end development changes
Page furniture is content that sits on a page but is built into the service using code. That means it’s not as simple as going in and swapping the words and expecting the content to behave the same way. In this example, there is text that counts down to tell the user how many words they have left in an answer box. Our component is adapted from the character count from the GOV.UK Design System used across Government Digital Services.
It’s on the Government Digital Services (GDS) roadmap to make a version of this component that can be translated. In the meantime, we’ve worked with Liam to agree on a temporary solution: the sentence is in Welsh but it does not count the words down. It’s a trade-off we’ve had to make due to complexity and to make sure we’re not duplicating work that GDS is already doing. If we built a solution now, we would only be scrapping it later to use the GDS version which would not be an efficient use of time so for now we have a compromise.
You can read more about the work GDS is doing to improve translations on their blog.
Example of back-end development changes
And finally, there are changes to the back-end; the part of the system that our internal users see. When applicants and grantees complete certain actions, we send automated emails confirming the action is complete. We send those emails in English or Welsh depending on the communication preferences they express. Some people express a preference for both, and others don’t express a preference at all. We’ve developed bilingual emails to meet this need, amongst a few other tweaks to refine how this works.
We also tidied up some of the list options that our staff see in our back-end system. In this example, related to cost tables, our staff were seeing drop-down menus that had a mixture of English and Welsh options to choose from. We’ve looked into why this was happening and ensured that people see lists in one language in the future.
Laying the foundations for arrears payments and progress updates
While all that was going on, another part of our team was looking ahead to a feature that allows people that receive medium or large grants to ask us for payment. We’ve been working along two lines, to ensure we had everything in place to start developing in the next sprint.
Interaction design and user journey
Starting from the overview level, Rosa and Kas — our Service Designer and Interaction Designer — spent the last sprint making sure the flow for our grantees was correct. That includes:
- looking for gaps in the process. Where we found them, we discussed them with colleagues in other parts of the organisation to work out what should happen
- finding parts of the flow that didn’t work that well, or where people may get stuck
- thinking about how each individual page will look
Working in Miro, they mapped out all the pages a grantee may have to go through as well as the flow through each page to the end point. They’ve also consulted with various internal teams to make sure the data we’re asking for matches our needs.
Prototyping options for visualising and displaying data
At the same time Alicia, our Salesforce Developer, was investigating options for presenting this data back to internal users who review these update reports and requests for payment. This included reviewing versions of tables we’d implemented before, exploring the in-built options available in Salesforce, and producing some prototypes so the team could assess the layout and functionality.
This was important because we’re trying to build a Minimum Viable Product (MVP), a solution that meets the core needs as simply as possible. It’s the solid foundation from which we can build and improve the whole system. If it was possible to meet our needs with code that’s mostly already written, that would have been a huge help. However, the review suggests we probably do need to build this feature from scratch.
The key issue we found was the limitation in Salesforce, which means we can only configure one related list to use in a table. For this feature to work, we really need to have multiple tables to show different sides of the data side-by-side. The main job for this table to do is to compare costs in a payment request to the agreed amounts in the grant and the amount provided already.
The process of exploring, prototyping, and reviewing options has helped clarify what we think the Minimum Viable level is, helping the work we’ll be doing in the next few sprints.
What’s up next for the team?
In the next few weeks we’ll be:
- Completing research and design tasks to prepare for the next feature we want to build, which is the completion reports grantees submit at the end of the project
- Building the payments and progress updates feature
Until the next weeknotes,
Bye!
