19 April 2022 to 3 May 2022 Weeknotes: Arrears payments build, designs take shape and research goes ahead

The weeknotes for this sprint are from Abbie Foxton, Content Designer and Jamie Gibson, Senior User Researcher. We will give an update across 3 areas:

  • Progress of payment in arrears and project update implementation
  • Design work focusing on digital outputs and funding acknowledgement questions
  • Research into completion reports and how to prioritise improvement

Progress of payment in arrears and project update implementation

We start with another update on the ‘payment in arrears’ journey, something we’ve mentioned in the last few weeknotes. This is a process our projects over £100,000 go through to update on progress and claim money for things they’ve paid for.

In the last fortnight the developers were building the pages for people to tell us how much they’ve spent.

We continue to follow the progressive “one task per page” approach that we’ve used in most other parts of the service we’ve built and designed so far. That means we ask for details about each type of cost on separate pages, breaking the process down into smaller steps.

A screenshot of our project update service. People are asked ‘what item of spend do you want to tell us about’, and they can answer spend over £250, spend less than £250, or no spend update.
One of the first pages people see in this journey, allowing them to tailor the reporting to what they actually need to tell us.

We’ve also built this process to adapt to budget information people told us about in their applications. The website checks the database to see what costs the project has in its budget and shows only those options. This means a grantee only sees the options that are relevant to their project, rather than seeing the full list of possible costs that any project could possibly report against. You can see an example in this screenshot: this project only has costs for new staff, so they only need to see the option to tell us about costs for new staff.

A screenshot of our project update service. People are asked what types of spend they want to update us on, and they see one or more options as checklist options. These options are generated from project data stored in our database.
Screenshot of the spend update section. People only see options that are applicable to their project, based on the project data in our database

Next up: we’ll be testing parts of the journey as they are completed.

Design work focusing on digital outputs and funding acknowledgement questions

Getting a grant comes with requirements. Two of those are to acknowledge where the money came from and to make sure all things digital that are paid for by the grant are made available to the public. We needed 2 new pages to make sure we were capturing how people met these requirements.

To understand the needs, we worked closely with colleagues in policy and communications; policy cover digital outputs, and comms cover funding acknowledgment. To brainstorm we worked as a group of 3 designers from different disciplines: content design, interaction design and service design. Through collaboration we were able to focus the designs down to the main requirements and make some mockups to share with policy and comms for feedback.

a mockup in Miro of the funding acknowledgement design. Users can use checkboxes to update on multiple areas or they can choose that they don’t have an update on any yet.
a mockup in Miro of the funding acknowledgement design. Users can use checkboxes to update on multiple areas or they can choose that they don’t have an update on any yet.

After sharing with colleagues, we were able to iterate based on the feedback and finalise the look of the design and where the new pages would go in the journey. This was then fed back to the developers so they could build the pages into the front end.

A lesson we learnt from this experience was that if expectations are managed from the start, working with stakeholders who know more about the requirements makes the process much smoother.

A before and after showing how the digital outputs question used to be asked as Material from our project is available online and how it’s asked in the new design. The new design breaks the question into 2 steps — step 1 asks if they have created digital outputs and if they say yes, they go to step 2. Step 2 gives an input box asking for a brief description of the digital outputs and website links.
A before and after showing how the digital outputs question used to be asked as Material from our project is available online and how it’s asked in the new design. The new design breaks the question into 2 steps — step 1 asks if they have created digital outputs and if they say yes, they go to step 2. Step 2 gives an input box asking for a brief description of the digital outputs and website links.

Research into completion reports and how to prioritise improvement

A couple of weeknotes ago we mentioned that our research into Completion Reports was coming to an end. Over the last couple of sprints we’ve been following the spirit of the ‘double diamond’ design approach (illustrated below). You can read more about the double diamond in this blog post.

A hand drawn sketch illustrating our double diamond approach. There are two diamonds laying on their side, that are joined at the tip. There are four stages: research, ideation, prototyping and implementation. Within those are 10 smaller steps: research planning, research, ideation, grouping, decide scope for prototype, prototype, plan implementation, implement, test and iterate.
A beautiful illustration from our Service Designer Rosa of our adapted double diamond approach to our work on Completion Reports

This means we’ve been:

  • Ideating: coming up with lots of different ideas to solve the problems raised in our research
  • Consolidating: grouping similar ideas together and adding more detail to them
  • Prioritising: choosing a few ideas that we want to take forward.

By the end of this sprint we managed to prioritise our ideas, using a ‘product matrix’. Basically, it’s a graph with two axes:

  • Feasibility: how easy will it be to implement
  • Impact: how much benefit it will provide to people

We assembled our design team, as well as Katherine Wynn and Jo Walker who, as Investment Improvement and Compliance Managers, have great experience of our processes and policies. We discussed our ideas and placed them in this matrix. After the discussion we’ve ended up with seven ideas which are high impact and high feasibility. We will start our design work with these seven.

A screenshot of the product matrix. It’s a graph with 2 axes. Impact is the Y axis (bottom is low impact, top is high impact), and feasibility is the x-axis (left is low feasibility, right is high feasibility). We’ve plotted each of our ideas onto the graph. Through discussion, we worked out which ideas were high impact and feasibility; these are the ones we’ll start designing with.
This is what our product matrix looked like. The ideas in the top right quadrant (high feasibility and high impact) are the ones we’re going to start prototyping for the first version of the completion reports.

Until next time 👋!

--

--