17 to 29 November: Design and prototyping for progress report and payment request functionality
This sprint we designed and prototyped different ideas for The Fund’s arrears payments functionality. This work included thinking about different ways grantees can get a grant payment in arrears, submit a project update and what information staff need to be able to assess project updates and process payment requests.
Grantees that have been awarded funding over £100,000 need to be able to ask for the first pot of their money through the service for funds they’ve already spent on their project. We applied service design thinking to explore how we might build this part of the service and how we can make this part of our Minimum Viable Product (MVP).
We also took part in accessibility training with Nomensa, a user experience design agency, and welcomed our new Senior and Junior User Researchers to the team.
Designing progress report and payment request prototypes
We worked in three groups to produce an agreed wireframe and build-approach for capturing arrears payments and project update information in Salesforce. Our goal was to have the plans ready to build this part of the service during the next sprint.
We focussed our prototypes on the main Lottery programmes and split the work into 3 chunks:
- The internal staff overview. This is the information staff need to see to access and process a progress report or payment request,
- The internal business process flows for the payment request and the progress reports. Thinking, what does Salesforce need to do to move this data through a workflow to make a payment, or update on a project,
- The internal top-level history information view. This includes a list of previous payments and progress reports for a project with key information
After initial conversations within our groups, we shared thoughts with each other. This gave the opportunity to ask questions, open conversations about what we liked, or thought might not work, and ensured we were meeting the needs of the MVP.
Service Designer, Rosa, then consolidated these thoughts into a table in advance of a second session, where we addressed each aspect of the designs and assigned a priority and size to the work. This allowed us to separate the essential functionality from that which we considered ‘nice to have’. For example, having the necessary information presented to staff to enable them to assess progress and approve payment is essential; having links between tabs to allow better access to this information received a lower priority, as this is something we would like to deliver but it wasn’t required for MVP.
As we went through, Senior Developer, Alicia, added information about how we might build the functionality for each point in Salesforce. This helped us with allocating a size to each task and therefore a priority. Those points where we may have to undertake further research, such as the idea of adding a timeline of payments and progress updates to the record, received a low priority rating and a medium/large size, which means it’s unlikely we’ll pursue this idea for MVP.
We made cards on our Planning Trello board for each idea. We’ll be bringing through the more complicated cards and spikes for this coming sprint, so that we can scope whether we’ll be able to implement the functionality. This is so that we don’t undertake all the work for the easier tasks to find that we get blocked by something we hadn’t initially scoped.
We agreed as a team that this way of working was productive. It promoted collaboration across disciplines (groups were made up of a mix of design and development staff) and the two huddle sessions allowed us to plan as a team and consider all options. We will likely also be using this method to design and prototype the external user journey in a future sprint.
Accessibility training
The team enjoyed two accessibility training sessions this sprint, led by Nomensa, a user experience design agency. The sessions were made up of an introductory to accessibility workshop, and a longer, more in-depth session that explored the detail of the WCAG2.1 guidelines, and available technology, which can help ensure our service is as accessible as possible. There will also be another workshop during our next sprint, tailored towards development — this will include training and technology specific to our Developers, for them to use as they continue to build our service.
We agreed in our team retro that these sessions had been an invaluable resource to continue accessibility training and have updated our definition of done to include some of the things we learnt.
A big welcome to Team User Research!
We welcomed two new team members this week. Senior User Researcher, Jamie Gibson, joins us from Citizens Advice and Jack Slater, who joins us as our Junior User Researcher. Jack previously spent three months with the team as a Change 100 intern — so it’s more of a ‘welcome back’. We are so happy to have Jack and Jamie on board.
