Building a prototype to test the 'request for support' journey

This is the first time we have built and tested a prototype for users who work at voluntary and community sector (VCS) organisations. The service will allow VCS organisations to receive and respond to requests for support for a family.

The flow we built to test includes:

• a mock up email inbox with an email notification from Notify that there is a new request for support - user clicks on the link
• the sign in screen
• a dashboard showing requests, with requests at different statuses and 2 new - user clicks on the new request
• request details page showing the detailed information and available actions - user clicks to decline
• confirmation screens for declining request
• return to dashboard and request has disappeared as it’s declined - user clicks on next new request
• request details page showing the detailed information and available actions - user clicks to accept
• return to dashboard with status of the request now updated to ‘accepted’

Email

We have written a simple email with the subject and header ‘New request for support.’ The body text says: ‘You have received a new request for support. Sign in to your account to view the request:’ with a link to the service.

We have not included details of the request itself in the email, for data protection reasons.

Questions about email

Questions we have for users include:

• what do you think a ‘request for support’ is?
• is this how you would expect to find out you have a new request for support?
• would you open this straight away?
• who in your organisation would receive and respond to this?

Sign in screen

We have used a simple sign in pattern.

Questions about the sign in screen

Questions we have for users include:

• which sign in details would you use?
• do you think you have an account for this?
• how would you get an account if you didn’t have one?

Dashboard

We assume that users would want an overview of their requests for support - so we have designed a dashboard.

We’ve presented the dashboard in a table format using the table component.

The data shown for a received request is dictated by the data entered in the request form. For this prototype, we have made the fields match the most recent tested version of the form, with a few iterations.

The fields shown in the table on the dashboard are:

• request number - as we assume each request needs to have a unique identifier and this is how users might refer to them
• date received - as we assume there will be a service level agreement for responding to requests so a user would want to know how old a request was and to order them by age
• contact - on the request for support form, this field is called ‘Person in family to contact’ however this is too long a heading for the table
• requester - the professional who requested support for the family- again this is too long for a table heading
• status - which could be ‘new’, ‘viewed’, or ‘accepted’ (declined requests would not be shown)

We’ve used the tag component from the GDS design system to indicate status.

We have added functionality for a user to search by name of contact. We assume this is the primary way users would identify and look for requests.

Questions about the dashboard

Questions we have for users include:

• do you recognise which request is new?
• have you noticed the search function?
• what do you think the different statuses mean?
• are there any other details you’d want to see here?
• are you clear what is shown under ‘Contact’ and ‘Requester’?
• do you know how to open the request to look at it?

Request details page

The heading level 1 is the request number, as this will be a unique header for each request details page.

We’ve added the fields to correspond with how data is collected in the request form. Fields shown in this section includes:

• name of person in family to contact
• email
• phone number
• best time to contact
• details of the request for support

We have added ‘Best time to contact’ as a separate field. This is not currently collected separately on the form, but we know from previous research this is important to request receivers.

On the request form, ‘details of the request for support’ is a free text entry field with a 500 character limit. The hint text advises users to include detail on:

• why the family needs help
• any health conditions or special educational needs and disabilities (SEND)
• times of the day to contact the family

We have created bespoke example requests for each user taking part in user testing. We looked at what type of organisation they are from and tried to write a request to match what they offer. We anticipated that in order to consider the ‘accept’ journey, they would need to see a request that was realistic for them. For the same reason, we have also designed the request for them to decline for a type of service that they do not offer.

The requests we’ve created are deliberately very vague with minimal information. We hope this prompts users to tell us what information they would need to make a decision to accept or decline the request. We already know that different types of services will want different types of information in their requests.

Questions about the request details page

Questions we have for users include:

• are you clear on who needs support and why?
• are you clear on how to contact them?
• what is the minimum information you would want to know in order to make a decision to accept or decline a request?

Anonymisation

We are currently exploring the need to anonymise the name and contact details on the request, until the VCS accepts. Our data protection officer has questioned whether a VCS need access to this personal identifiable information in order to make a decision. If they don’t need the information, we should not show it to them.

We will be meeting with our LA partners and their data protection officers to discuss the needs. We’ll ask about their current processes and whether they anonymise such requests.

In this prototype, we have left the personal identifiable information in. Questions we have for users include:

• do you need to see the name and contact details to make a decision to accept or decline?
• what difference would it make if the details were anonymised?

If a user states that they would want to know information, we should ask whether it is needed for the decision, or is a ‘nice to have’.

Professional who requested support for this family

Details on the professional who has requested support for the family are included as we know that the receiver may want to contact them to discuss the request.

The details included for the requester are:

• name
• email
• phone number
• role
• organisation

Currently the only data collected for a professional when their account is created is their name and email address. We are exploring whether we can collect more data on professionals when their accounts are created. Otherwise professionals will have to enter any additional data each time they complete a request.

For now, we have assumed we can collect and provide a professional’s phone number, role and organisation. We assume this is the minimum information a VCS would need to contact them about a request.

Questions about the requester

Questions we have for users include:

• are you clear who or what the 'requester' is?
• would you contact the requester? (now, before accepting, or once accepted?)
• how would you contact them?
• is there anything else you’d want to know about the them?

Your response

We have used radio buttons for users to respond to the request. We have expanded the text to say:

• ‘Accept - our service will contact this person to offer support
• Decline - our service will not offer support’

We assume the user will need this clarity on what precisely they are agreeing to. They are agreeing to contact the family to discuss support, and not necessarily that they will support them.

We have used the word ‘decline’ as it has more positive connotations than ‘Reject’. Reject is defined as ‘to refuse to accept, submit to, believe or make use of’. Decline is defined as ‘to express polite refusal.’

We have included a free text entry box for users to add details about why they have made the request as a required field.

We have also given the option next to the ‘Send response’ button to ‘Return later’. We assume this will indicate to users that they do not have to submit their response now, and this is something we want to test.

Questions about the response

Questions we have for users include:

• are you clear what accepting and declining means?
• how do you feel about adding a reason you declined?
• what type of reasons might you decline for?
• what would you do if you needed more information to be able to decide?
• who would make this decision - would you need to discuss with others?
• would you action this straight away?

Confirmation pages

For the ‘accept’ journey confirmation page, we have used the confirmation page pattern from the GDS design system.

For the ‘decline’ journey confirmation page we’ve used a simple text page.