Contact a service (Get help)

[michaelcattell]

This pattern is now published at https://design-system.dwp.gov.uk/patterns/contact-a-service

Hello, we'd like to use this open discussion on the use of the Ask for help / Get help pattern:

Some discussion points to get things going:
Have you used or know where this component has been used?
Do you know if there's been any research or testing done on it or around it?
Do you agree with the user need?
Things we don’t know enough?

Why
For users that are having difficulty completing a service it signposts where they can go for help

Community backlog link: https://github.com/dwp/design-system-community-backlog/issues/23
It has a pattern existing on the MoJ design system https://moj-design-system.herokuapp.com/patterns/get-help

Examples we have so far (Budgeting Loans):

[ladine-cook]

We recently tested this is in New Style Employment and Support Allowance. We started with "Get help with your application" but during user research people expected to see help specific to the page they were on or FAQs. We've changed the link text to "Ask for help with your application" but this hasn't been tested yet.

We decided to show it at the bottom of the page rather than to the right hand side because:

• people zooming into the screen often miss anything on the right
• people naturally read right down and across
• most people using our service use a mobile, so it would have to move to the bottom anyway

We used the "details component" as not everyone will need the content. We also felt that it was a lot of content to show on the bottom of every screen.

We chose to show it on most screens except things like:

• check your answers
• complete
• error pages like 500's and 404s (these usually already have a number)
• feedback
• cookies
• accessibility statement

[cristina-agramunt]

Hi, I am currently working on the Apply for a National Insurance Number and we display the "Get help" as part of the footer section and also on the service's information/start page.

We decided to place it in the footer so its less disruptive on the screen and with the thought that after the user locates it at the footer, they will already expect/know where to look for wherever they are in the application.

To minimise the need for the user to "Get help" we have also added the "Details" component to the most complex screens giving further information that relates only to the question on the page itself.

We find that most users are actually using the Get help info after the application has been sent - So mainly for status updates and address changes on the application.

I am happy to have a chat if you would like any further information.

[martinwake]

At a content designers' show and tell session on 25 October I asked for people's experiences with showing help in a service, for any research they were aware of and for their comments on the various examples we've collected.

We also collected another example from Child Maintenance which presents help as another option in a radio button list. This was aimed at helping more people to make the appropriate choice for their own circumstances from the other two options:

Comments on examples

Details component

Do we know the success rate of this pattern?
Could this get unwieldy if there is lots of content to show?
Should there be more than one onward contact option - will people avoid calling if they have tried to do that before?

Help in footer (either link or contact details)

How well does this work with assisted digital / accessibility needs?
Some experience that footer text is generally missed / ignored

Ideas and questions

• Is it possible to dynamically include gov.uk content if that is the authoritative source?
• Could the same content be reused across services?
• Should the treatment of help content depend on where the user is in the service?
• Check the DfE research repository for relevant research
• What is the right thing to do if linking out to help logs users out of a service?

[rachel-robson-dwp]

Hi there,

As I've recently moved around other government departments, and in my experience as an assessor and design lead, I'm seeing this pop up more and more as a way to offer assisted digital support within a digital service.

Adding contact details directly into a service is not something I would ever do as an interaction designer, or recommend that anyone else ever do as a lead, so thought I would throw in my feedback and reasoning as to why, in case it's helpful.

Based on my previous experience of managing services that have moved to a Live support team, I think there should be guidance added to this pattern about only using it if there is a process established with the operational areas to receive updates when these details change.

Actual numbers don't change very often, but I have seen an example of a service where both the telephone and textphone numbers had been out of date for over 2 years before it was discovered, because the digital service manager/owner had not been made aware these contact details had changed.

It doesn't help that the way we work in digital services across teams means that services are constantly changing hands between delivery teams, maintenance teams, and different owners/responsible people, as people move around, in and out of the departments.

It's important to keep in mind that even though the contact details themselves might not change much, opening hours for these helplines fluctuate across the year, due to different KBEs and prioritisation/availability of the call centre agent teams.

This became especially apparent during the COVID lockdown periods, where changes were made to opening hours without any way established of informing digital services, and multiple services info was out of date very suddenly, without anyone realising.

As a response to this, within Live Services at HMRC, we made a conscious effort to remove contact details from all services we maintained, as there was no reliable broadcast loop in place for us to be informed of changes, nor was it something any business area was interested in working to establish.

We therefore made sure that these services all had direct links out to the GOV.UK contact pages for the service put in place of the details, as these pages are always, by their very existence, the most up to date source of contact information.

If we end up with incorrect contact details embedded in a service, then we aren't really helping the people they've been added there to help, which could be some of our most vulnerable citizens.

Directing out to the GOV.UK contact page for a service should, based on the examples I've seen and mentioned here, always be the first port of call when needing to offer offline support to a user, as there is a robust process in place for operational areas to raise a ticket with the GOV.UK team and request changes which are prioritised and turned around within the day.

I believe the GOV.UK contact pages should be covered within this pattern as the initial source of truth for service designers to look at linking out to first, especially for new designers starting out who may not be aware they even exist. This approach avoids any unnecessary overheads of updating the service in future.

If it is completely unavoidable and contact details have to be added into service pages, then as I mentioned earlier, the service team should make efforts to establish a process where they can be immediately informed of changes required, and try to make it as robust as possible, avoiding a single point of contact failure if their contact or their own team were to move onto another project.

Happy to discuss any of this feedback if it's helpful.

Thanks.

[martinwake]

Thanks @rachel-robson-dwp - as discussed, we'll consider adding guidance about the importance of a robust update process when we next review this pattern.