11 to 24 January: redesigning our beta service based on users feedback
The main work developed in this sprint has been refining the “Accept the grant” stage already developed in our beta new service. After receiving a considerable amount of user feedback about problems when signing the contract, the team considered having a deep review and redesign of this part of the journey. In this sprint, Jamie our Senior User Researcher and Rosa, our Service Designer share how the design process went. They also discuss the work carried out to collaboratively prioritise User research topics for the next few months. During this first sprint of the year, we have also spent time reviewing and discussing two relevant areas to help us work collaboratively and efficiently in the team: MVP planning for the next sprints and the map of roles.
Redesigning how do we capture legal signatories’ information in the service
A key part of the journey is when users “Accept the grant” after receiving the confirmation of the award. This stage allows users to accept the grant and terms and conditions before starting the project. After submitting the signed contract, staff can do all the checks before confirming grantees can start their project, which includes giving instructions about next steps and how to manage the project.
Part of the complexity of this stage is that we ask grantees for two legal signatories: a person who has the authority to enter into legal contracts on behalf of the organisation). At the moment we ask for this information early in the journey, before submitting the application.
Thanks to the data and insights provided by Emily Fuller, our Investment System Support Manager, and Jamie McGarrigle, Product Owner, we discovered the pain points and how is affecting to users and staff. One of the main reasons we’re getting a considerable number of queries about adding or changing legal signatories is that distance between asking for signatories and when we actually need to contact them. By the time these legal signatories are requested to sign, they might not even be associated to the organisation/project anymore or their role has changed!.
Another problem is related to legal signatories not receiving the email with the magic link that allows them to read, download, sign and upload the signed terms and conditions. This feature of sending magic links was taken as a transitional MVP solution before moving to the digital signatures by users in our service. Even though it’s a solution to be refined, we improved the accessibility of the content thanks to the HTML functionality that replaced the old and non-accessible PDF.
The vast majority of the team was involved in reframing the problem and taking some decisions for the refinement of the journey. Then, Kas, Interaction Designer, Rosa, Service Designer, and Abbie, Junior Content Designer, worked on the design of the new journey, flow and content. We checked and agreed some of the changes with the legal team in order to cover the requirements in the new journey. Finally, the key decisions we made are the following:
- Asking for the legal signatories information in the “Accept the grant” stage, instead of earlier in the journey, so that users can provide us with the updated information.
- Associating legal signatories data to a project and not to an organisation.
- Removing the need for main contacts, who aren’t legal signatories, to read terms and conditions.
- Adding instructions by asking users to check their junk/spam folder.
- Adding new content to explain users that legal signatories can sign the contract separately.
The next step is the development and testing of this refinement that we hope will solve most of the problems and will improve the user experience to complete this relevant part of the journey.
Reviewing the gaps in the end-to-end digital service journey
The MVP that our team is designing and developing is a complex service that includes different funding programs and a long sequence of steps. We are now in the last part of launching the end-to-end digital service journey, but… we still have a few challenging sprints to go through this year to achieve our goal. With the objective of prioritising the gaps that we have still to design, deploy and finally launch we needed a collective review of features to be built. Currently, we are running the service combining an old digital system, the new MVP and some manual processes that are filling these gaps until the whole MVP goes live.
Service Designer, Rosa, has consolidated these gaps and tasks in a few visual artifacts that will help the team to have a clear picture about the planning for the next months. These visuals represent in a nutshell the following information:
- Stages developed and launched in the new service for every funding program.
- Stages to develop that are supported by manual processes.
- Estimated number of projects due to require completing the stages that we haven’t developed yet.
- Main risks and problems associated to the gaps.
- Level of complexity to design and develop every gap.
- Work already done (design, prototypes, code…)
- A high-level roadmap with the work to be done in the next sprints for every team (design, development, support and management).
Mapping the roles in the Digital Service Design team
The beginning of the year it is a suitable moment to review and plan the roles and skills needed in the team to achieve the goals for the year and envision new projects. This sprint, Heather, our Head of Investment (interim), has led a process to map and plan the right roles for the Digital Service Design Team at the Heritage Fund.
Through a board in Miro we have collectively identified and discussed the roles we already have and those that we might want to have. We have reviewed the Data and Technology Profession Capability Framework of Gov.uk. to have a clear description of every role. There are also some other roles specific to the Heritage Fund that are key to have within the team. Summarising the map of potential roles discussed, included all that we have or not, and by category are:
- Product and Delivery: Service Owner, Product Manager, Product Owner, Agile Delivery manager, Project Manager and Product Communication officer.
- Operations: Customer Support manager, Customer Support Technician, Business Support Manager.
- User-centred design: User Researcher, Interaction Designer, Service Designer, Content Strategist, Content Designer, Graphic Designer.
- Technical: Technical Architect, Frontend Developer, Salesforce Developer, Salesforce administrator.
Prioritising focus areas for user research
In our last sprint note we discussed our process for prioritising User Research. After testing the process and tools with colleagues before the festive break, we ran our first proper prioritisation session in this sprint. We invited 5 colleagues, covering all the different disciplines in the team, to share their opinions on a few different ideas.
The session went well for a couple of reasons.
- Team Alignment. It was good for different people in the team to exchange their thoughts on what a priority was for them (and why), which coincidentally supported the work reviewing the gaps in the MVP mentioned earlier in this post.
- Scope refinement. Having time to ask colleagues how they’ll benefit from a piece of research, how they’ll use it, and what exactly they need to know, has helped the User Research team tighten up the scope of the work that’s coming up.
The UR team has two priority projects they’ll be working on over the next month or so; we’ll share what we learn in upcoming sprint notes!
Exploring how a panel of subject matter experts might help our team
Over the last few years the Digital Service Design team has used secondments to embed internal users of the system we’re building into our way of working. Having the voice of current and future users in the team to guide every decision has helped the team build better software, and at the same time we’re helping colleagues across the fund gain skills in agile and digital methods and tools.
This year we wanted to try something different to maintain the co-design benefits but to also allow a broader range of internal users to help us with our work. We think that a panel approach, where we ask more people for smaller pieces of advice or support, might be the best approach. We’re discussing the different options with the team over the next few weeks before making a decision.
