23 February to 8 March 2020 Weeknotes: Salesforce, support and completion reports

Completion reports

Both Jack and Jamie, our user researchers have opened the can of worms that is Completion Reports. They have both been working on paving the road for our content and interaction designers for when they finish the work on payment in arrears in the near future. This work includes finding out what we do know and what we don’t know about completion reports as well as locating the pain points within the completion reports journey.

With this said, our user researchers are starting the process of speaking to both our internal and external users to gain an understating of what the experience of completing a completion report is like.

This is a very exciting time to be working on completion reports as the Digital Service Design team has nearly completed designing and developing the MVP IMS service and the completion report functionality is one of the last steps for our end-to-end funding journey.

Support ticket Work

On an exciting note we think the recent change to the legal agreement journey implemented by the Digital Service Design team has reduced the number of support tickets received this month.

At the beginning of February, our team was hard at work ideating solutions to help reduce our support ticket load. A huge amount of support tickets we were receiving were requests from Grantees to change their legal signatories. With this considered, the team decided to change where we asked our Grantees to submit their legal signatories in the legal agreement journey which is later in the project life cycle.

Since the change went live on the 8th of February 2022, we have seen a large reduction in the number of Grantees asking to change their legal signatories. However, it is important to note that although we have made this change and that there are less legal signatories changes coming in, however, there are still a small number of requests being submitted.

A reduction of requests from external users to change their legal signatories over a 7 month period

Salesforce Design System Prototyping

We have been expanding our ways of working to introduce more input from the full Digital Service Design Team on the Salesforce side of the IMS solution. Specifically, some members of our User-Centred Design (UCD) Team, Service Designer Rosa, Interaction Designer Kas and our Content Designer Abbie, have all been expanding the input they provide on the Salesforce design.

One of the barriers to their input has been the lack of a prototyping tool for Salesforce. This has meant that feedback has in the past been provided based on live mock ups of potential designs completed by the developers in a Salesforce Sandbox. Alternatively, the UCD team has built mock-up designs that show the preferred solution at a high level without being able to fully prototype interfaces that imitate the Salesforce user interface.

To bridge this gap, our Service Designer Rosa has worked with our Senior Developer Alicia to work out which key elements of the Salesforce user interface are commonly used to completed features for IMS. With this knowledge, Rosa has created a prototyping kit for Salesforce. Each element identified has been recreated in our design app Miro. This will allow all members of the UCD team to create prototypes which more accurately reflect the Salesforce interface. Such designs can then be the basis for:

  • wider discussion within the team,
  • allow the User Researchers within our team to get feedback from staff,
  • and finally, as a tool for the developers to use when completing the build.

Here is an example of one of the commonly used components within the Salesforce user interface:

One of the most commonly used components used within Salesforce
One of the most commonly used salesforce components

Knowledge of the Salesforce platform and the Salesforce configuration tools available has been actively shared for many months to allow for more constructive conversations between designers and developers. This is another very important step towards ensuring the Salesforce side of IMS gets the same high level of collaborative input that we currently give to the design and build of the FFE website our applicants and grantees use. Full input from all disciplines in the team will help us put our users first, which we strive to as a User-Centred-Design-Team, primarily putting Heritage Fund staff first when designing for Salesforce.

Salesforce Arrears Database Planning

The IMS system includes both the Heritage Fund applications and grants as well as applications and grants from Memorial Fund. This adds some complexity to the Salesforce side of the build. The Salesforce database that supports the arrears payments journey has already been partially built for the Memorial Fund grants. As such careful consideration is needed to ensure that both grant types can co-exist in the IMS together. Ideally, both grant types will follow the same journey for arrears payments.

During the last sprint, our Senior Developer Alicia explored the options available for the supporting database in Salesforce. To aid this work, our Product Manager Jamie helped to outline the process that is currently in place for arrears payments. Specific emphasis was put on identifying any relevant approval steps and any expected deviation fromthe normal process.

The following areas were identified:

  • Bank details check and approval
  • With Finance stage
  • Project Costs will need to be flexible and may be amended by IM.
  • Spend submitted by grantee will be reviewed and may be modified by IM.
  • No more payments can be submitted while a request for payment is in place.

These factors will impact the build of the Salesforce database. For example, the figures in the Spend to Date table (which will show a summary of previous payment requests) must be static and not dynamically pull through the Project Cost info as this may change between requests.

The expected object model was then mapped out and compared with the functionality of the Memorial Fund projects to check for compatibility.

One other significant outcome of this exploration and planning was to discover that the Heritage Fund is lacking policy on project budgets. Specifically, we do not have a consistent approach as to whether:

  1. a project budget should be viewed as flexible within a Cost Heading,
  2. or whether each project cost submitted by the grantee should be viewed as a budget for each project cost.
A collection of all the different costs related to a project submitted by a user as part of the arrears payment journey.
Collection of project costs under different cost headings

Using the above example, can all the project costs reported under New Staff be added together to create an overall budget for New Staff or should the grantee account specifically for each cost, such as the £6,014 allocation to a Volunteer Coordinator.

This question has been raised as a Decision Record for Project Board to resolve.

Uncovering this unknown around project budgets and unpacking the known approvals and expected changes to figures is great groundwork for the build in Salesforce.

Funding Front End (FFE)Arrears Build

Our developers have been completing phase one of the FFE website build for grantees to request arrears payments or provide project updates. This phase is to complete the full pathway through the website to each page that forms part of the arrears payment journey. This does not include any integration with Salesforce and the final content for each page may not be complete.

Updates to the home page to allow grantees to access the journey to request a payment or provide a project update are now available in the FFE developer version:

The start of the arrears payment journey for an external user.
The start of the arrears payment journey for an external user
Two choices presented to an external user as part of the arrears payment journey.
A choice presented to a user as part of the arrears payment journey

Once the appropriate journey is selected by the grantee, the pages that form the request for payment or to submit an update have started to be created and connected.

A start page pattern signifies to a user that this is the start of their arrears payment journey.
A start page pattern used as part of the arrears payment journey

This is a great start for the arrears build.

--

--