Digital Service Design Weeknotes 19 January — 1 February
This week the weeknotes are written by Abbie Foxton, our Business Support Manager and Emily Fuller, our *inhale for long title* Grants and Investment Systems Support Manager *exhale*. They share the work the team have done to plan how payments can be made through the Investment Management Service (IMS), an update on the data migration from GEMS (our legacy system), and work on improving the accessibility of the system.
Migrating data and documents from GEMS to the new service
This sprint, we have started delving into all the fields that make up GEMS and have begun making decisions about whether the information should be migrated to the new IMS. Abbie and Emily have looked at which fields appear for which programmes and identified patterns, and Emily has looked into all questions and answers stored in the back end of GEMS. For each, they have suggested either decisions on migration or further work to enable a decision to be made.
This then feeds into a bigger project Jamie and Emily are undertaking, of going through each field granularly and suggesting whether to migrate. This work will continue into the new sprint and then links to the work our Data Architect, Mohammad, is doing on creating a data model for IMS. He’s ensuring that everything we need to take with us from GEMS has a home in the IMS.
In exciting news, we have also begun migrating all documents off the existing applicant and grantee portal and into our own document storage. We’re already over a third of the way there, having mapped 612,000 of 1.6m documents! These are all the application forms, payment requests, progress reports etc. that make up a project.
Building the IMS
This sprint the goal has been to design the end-to-end payment journey, think about how this can be achieved technically and get it ready to be built into the code of the service in the next sprint. The team started with a flow mapping session to map out how payments work now and think about how we can improve this process in the IMS. Using Miro, we were able to plot out what was needed for each payment type and the commonalities they shared. There are currently multiple processes for requesting grant payments so this was an opportunity to investigate where we could simplify before building.
Caption: Screengrab showing the minimum actions users go through in the payment part of the service to enter bank details and get a grant payment
To help reach the sprint goal, the team have also been visualising and designing:
1. How users will request payments on funding front-end.
Paul S, Kerry and Rosa have been visualising the flow of the payment request journey and mapping what we need to do and when to get a payment out. Paul S and Kerry have designed some prototypes of what the pages and content might look like for a grantee in the new IMS service. These can then be built into the code by Stuart and Paul T.
Caption: Screengrab of a page in a low-fidelity prototype showing how grantees might add evidence of grant spend
2. How users can tell us about the progress of their project.
Kerry has been designing what the progress report will look like by identifying the purposes and important information from the progress report. Kerry has then sketched potential content for how grantees can tell us about recruitment and acknowledgement of their grant.
Caption: Sketches to show a mini flow in the progress report, so that grantees can tell us about staff recruitment and add evidence
3. How finance can make payments through Salesforce.
Paul T, Stuart, Jo and Jamie have been thinking about the functionality of Salesforce; page layouts for how staff will pick up payments and what has already been built into Salesforce to enable Finance to make payments. They have also been factoring in if there are any changes or additions that will need to be built and planning how much work will need to be done to get Salesforce ready for payments.
4. How users are notified when their payment request is submitted and how they are notified when a payment is made.
Abbie has been content designing the notification emails grantees receive at different points of their payment journey. By thinking about what users need to know at different points, we can help grantees know what to expect and provide reassurance through the process.
Auditing web accessibility
We’ve worked with UX design agency, Nomensa, to carry out an accessibility audit of the funding front end service and the accessibility of the service overall. Working with a professional external agency means we gain a deeper and more thorough understanding of where we can make improvements to make sure the experience of the service is as inclusive as it can be.
The front-end pages reviewed were:
- Legal signatories — where applicants tell us about who their organisation’s legal signatories are.
- Wider range of people — where applicants tell us about how their project will meet our mandatory outcome for involving a wider range of people.
- Other outcomes — where applicants can select if their project will meet any other outcomes.
- Cash contributions — how applicants tell us about money they are putting towards the project.
- Your grant request — how we show applicants what their grant request is, based on costs they enter in the application.
- Check your answers — where applicants are shown their answers and are given the option to edit.
- Confirm declaration — where applicants confirm they agree to the declaration before submitting an application.
- Upload governing document — where applicants use an uploading feature to attach their governing document to the application.
While the audited IMS pages got a good review for accessibility and best practice, Nomensa were able to make suggestions for improvements and fixes. Paul Smith has been able to factor these changes into the ‘requesting a payment’ journey page designs. This included improving the location of additional support options like ‘help answering this question’ from the bottom of the page to before the user’s text box. This format is more meaningful for someone using a screen reader because the help available is offered when it is needed.
Caption: screengrab of text box on a page in the service Nomensa audited. The ‘help answering this question’ button is highlighted in its old location at the bottom of the page, below the ‘save and continue’ button.
The team are always considering accessibility when designing and building so this audit gives a good base for making continuous improvements.
Working with National Heritage Memorial Fund
Jamie has been working closely with Suzanne and Vanessa in the National Heritage Memorial Fund team to help refine their monitoring forms which already use Salesforce. This included reviewing the:
1. Permission to Start form — the form people complete to start their awarded project.
2. Payment form — the form people use to tell us about what they have spent and request grant money.
3. Progress Report form — the form people use to tell us about how their project is going.
4. Completion Report and Final Payment Request form — the form people use to tell us about the end of their project and what else they have spent.
After reviewing, they planned what updates or changes were needed to improve the functionality or performance of the forms. Once changes had been agreed, Jamie was able to create updated templates and send these to Methods who then built the changes into Salesforce side of the service.
Links we think you might like:
At a time where there’s a lot going on and some tight deadlines, this article explains the idea of your self-care battery, and a template to help replenish its charge.
This article explains what moving away from a legacy system entails. It’s the rationale of our whole project wrapped up in an easy-to-digest 4-minute read.
Our own Jo Arthur has written on the topic of accessibility and we’d also suggest reading this article on how to make your online content accessible for further context of the work we’re doing.
