Digital Service Design Weeknotes — 2nd February — 15th February
This week our weeknotes are brought to you by Jo, our user researcher, Rosa, our new service designer, and Em, our delivery manager. Rosa joined the team in January and has been working on understanding the work we’ve done so far and creating maps of the service.
Mapping the service
The core of our work is based on designing and delivering an “end to end” service that allows users to achieve their goal and the Fund to carry out all the necessary internal processes to deliver an excellent service experience. For that purpose, we use different Service Design tools to understand the current state of the service, uncover “pain points” (problems), and envision the future state of the service. These tools include Journey Maps and Service Blueprints.
Our new Service Designer in the team, Rosa, has started her role by designing a new model, or template, that integrates all the elements needed to create more accurate maps of our service. She merged the main elements of the Journey Map, that visualises the experience of a user with a service as a sequence over time, with the elements of the Service Blueprint, that connect the user experience with the staff processes and activities to support and deliver the service. Then she defined the scope of our mapping, as both tools can be used to represent a “high-level” or end-to-end service, or concrete steps of a higher-level journey. She has zoomed in the payment stage as it was the sprint focus.
As a result, we have mapped a detailed payment journey for every programme (small, medium and large) to help the team and other colleagues in the Fund to have a clear and common understanding of our service with the user experience in mind.
Here are some basic elements, descriptions, and examples of what’s in the journey map model:
- User actions: every step and experience that the user has with the service. In the payment stage, for staff users this might be “scheduling the payments”, for example.
- Pain-points: Problems and difficulties that the user has while using and interacting with the service. These have been identified in our research with users, staff, and/or other quantitative data research. For example, this includes users struggling to read the guidance when preparing for Permission to Start.
- Channels: Any medium for communication or delivery involved in a specific step of the journey. Our users at this step could use the application portal (TopLevel), email, telephone, website or even a visit to a local office.
- Touchpoints: All interactions a user has with the Fund, which makes up the total experience of using a service. A touchpoint is defined by a user need and a channel. E.g.: editing and submitting Permission to Start through the portal; notifying to the Fund of some changes needed in the Approved Purposes.
- Frontstage actions: This shows all the activities of frontline employees that are visible to the customer for every step in the journey. It can be one or multiple staff actions for every step. E.g.: Checking all the documents submitted by the user in the Permission to Start.
- Backstage actions: These are the activities by frontline staff that are not visible to the customer. E.g.: checking fraud.
Designing an equality data monitoring survey
As a public sector funder, we have a duty to gather data about who our funding is reaching. This is something we currently collect on a project level, which can mean that the data we get is unreliable. The data is currently stored in PDFs which means it’s very hard for us to accurately report on who’s applying for funding, who’s successful and which groups are less successful. We currently collect the data when someone applies for funding and then again after the project is finished. This means that we ask too early, when applicants and grantees don’t always know who’s going to be involved with their project, or we ask too late in the project, when people have left. It’s difficult for grantees to inform us accurately.
We think that if we change this monitoring survey from a project level to an individual level, we’ll get more accurate data that we can access more easily. It will also mean we can ask more regularly instead of at two fixed points.
Kerry, Jo and Abbie have been working to design a way for people to self-report on their demographic data. They’ve based the new content on some desk research we did in the summer about how to ask for demographics, our experience with the research panel, and conversations with our data and insight team and our inclusion policy expert.
Designing how staff will see a pre-application form
The service we’re building needs to work for applicants, grantees and members of staff. This sprint, Paul Smith has spent some time looking at how staff in our Engagement teams will be able to access and respond to our pre-application forms. For the private beta, we aren’t making huge changes to this process. It’s currently all offline and off system, so the major change for the beta is that we’re bringing key bits of it into the digital service.
The pre-application forms are often a way for first time applicants to get advice and support, while starting to build a relationship with their local team. This means it’s important that staff can see information about the project idea, but also can see contact details and preferred contact methods for the person who submitted the form.
Paul has based his designs both on user research we did with Engagement teams in May last year and on how this process works now.
Building payments
Last sprint, we designed the last few steps of the payment journey where grantees can request a portion of their grant. The rules vary depending on the size of the grant, so we need to get data from the Salesforce system and to use that to determine the pages grantees are shown.
Stu and Paul T have been working on this, as well as building out the front-end pages that grantees will use and making sure Salesforce can take in the data from the grantee and present it to staff in a useful way.
