Help users to contact a department or service team

[govuk-design-system]

What

Help users contact you on their preferred channel.

Why

Anything else

• HMRC has a version of this Sign post: HMRC design patterns

[suryanaga]

Is this the same as "Switch channel from online to phone" ?

[mikeash82]

@gavinwye commented on 24 May 2017

This pattern is used when there is a problem with a users account and they need to contact HMRC

Example

@matthewjbarker commented on 24 May 2017

@gavinwye commented on 24 May 2017
@matthewjbarker could you provide some details about why this exists and what problem it solves for users, please?

@stevenaproctor commented on 24 May 2017
@gavinwye @matthewjbarker We are supposed to say sign in and sign out, not log in and log out. I would also wonder why it says "MCI error". That will mean nothing to someone signing in.

[ignaciaorellana]

I am looking for more best practice on helping users get support in different scenarios. For example in a transactional service, in a mainstream content guidance page, a Whitehall guidance page, etc.

I found this today in the cross gov slack channel http://hmcts-design-system.herokuapp.com/patterns/get-support so I'm adding it here as an example, which seams to be in the context of a transactional service using the details component

Also, the import and export step by step on gov.uk provide contact details as step at the end of the journey. It takes you to a "contact" type page

[Nadiahuq]

Example from the Home Office: https://eforms.homeoffice.gov.uk/outreach/lcs-application.ofml

right to rent check - contact example.png

[amyhupe]

Design System working group review session 28/11

The GOV.UK Design System working group met on Thursday 28 November to review the Help users to contact a department or service team pattern

The working group agreed that the pattern can be published as experimental in the GOV.UK Design System.

Design

• Consider including information about call charges directly on the page rather than linking out, if there is a concise way of explaining them
• Consider adding the tag around the example address

Guidance

• Add guidance explaining that the order in which the contact channels are listed should be based on a balance of users’ needs and organisation’s needs.
• Include a link to the GOV.UK linking policy to explain why we recommend not linking to social media channels
• Explain that it’s best to avoid using the details component to hide contact details if there’s only a small amount of content - in which case it’s better to just include it in the body of the page
• Add guidance on displaying response times for channels when the times are dynamic (like webchat) and what to display when the channel is temporarily unavailable
• Change the wording of the first sentence in the Social media section to be more direct and explicit: ‘Include social media channels if users can contact you via these channels’
• Find out if there is guidance (in the Service Manual, for example) that covers providing appropriate channels for disabled or assistive tech users and - if there is - link to it
• Consider adding explicit guidance to say that the pattern does not show where to put contact information in a page or service, and that this decision should be made based on contextual user needs

Examples

• Include an example showing how to present a social media channel (using @HMGovernment)
• Update expanding contact details example to include more content, as this is a more appropriate use case - if there’s little content, it’s better to just include it in the body of the page
• Consider making link text in expanding contact information example more specific, for example, ‘If you need help completing this form’ rather than simply ‘if you need help’.
• Include or update an example to show how to include information about things a user might need when they contact you, like reference numbers

Research

• Carry out research to understand how this pattern works for users with access needs
• Consider carrying out research to learn when to put contact information inside the details component versus when to put them in the body of the page

Other Design System updates

• Create a separate Pull Request to update the Service unavailable pages, and There is a problem with the service pages so that they’re consistent with this pattern.
• Consider clarifying guidance on using ordered lists versus unordered lists in the typography page, as this cause some confusion as whether the contact channels list should be a <ul> or an <ol>
• Consider adding guidance that warns against putting important information (like contact details) beneath the main call to action on a page as it may be missed by people using screen readers or screen magnifiers

Next steps

The GOV.UK Design System team will work with the contributor to address as many of these recommendations as possible before publishing the pattern.

[jeanesims]

Are there any thoughts on including guidance for service teams on this pattern to help them know when to link to contact details pages published on GOV.UK for those using services and when they should create their own page with contact details within their service?

One example might be where a user is using a service and there is an unhappy path. For example, if the service can't find the user's details, and to continue the user might need to contact the department to finish the task. Typically, the user will be shown a page telling them there is a problem and that they need to do XYZ, or contact the department, etc. In these cases, service teams would typically put the contact details on the page for the user as it's another click for the user if the team puts a text link to the GOV.UK page with the relevant contact details. If the link text on the service page 'opens in a new tab' the user can still stay in the service.

I'm not sure putting contact details on this type of 'unhappy path' page in services is the best option for the user as it means that they might not be shown the full details that are often on the GOV.UK contact pages. The GOV.UK contact details pages typically have all the channels a user can use, times they can call, call costs, how to get additional help if they need it, etc.

Also, as the pages in services are typically hard coded, so a developer would probably need to make a change to the content details on a service page. This creates a maintenance burden for service teams and typically means the user doesn't get shown the full details and contact options, etc, and there may be lag in the details being updated in both places (within a service and on GOV.UK).

Would there be any merit in adding in a few sentences to advise on the best approach for service teams? If it's the better option to link to GOV.UK contact pages service teams would need to be made aware of this and having guidance in the GOV.UK Design System would help with this.

This is the list of pages with contact details for HMRC's services on GOV.UK
https://www.gov.uk/government/organisations/hm-revenue-customs/contact

I've just picked one at random and I think it shows the user a lot of helpful details - https://www.gov.uk/government/organisations/hm-revenue-customs/contact/help-to-save-scheme

So, should service teams be linking to these GOV.UK contact pages rather than creating their own? If so, I'm not aware of any guidance on this? I know you can't take a one size fits all approach so there would definitely be exceptions.

[paulwelsh1]

Is there any guidance or UR around having something on this type of page that calls out a best time to call or time to avoid for phone lines? I've seen HMRC have something along those lines on https://www.gov.uk/government/organisations/hm-revenue-customs/contact/income-tax-enquiries-for-individuals-pensioners-and-employees

[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 an 'established' 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.

[stevenjmesser]

Thanks for those thoughts, @rachel-robson-dwp. Our guidance encourages teams to place contact details wherever their research tells them is most helpful. However, your point about updating contact details, opening times, etc. whenever those change is a good one. That feels like something that would be covered by the Service Manual's guidance on setting up and managing user support, but adding a bit more detail on how to keep a tight loop between operational and digital functions?

[rachel-robson-dwp]

Thanks for your reply @stevenjmesser
Information about ensuring process for updating could certainly sit in that service manual section, but I still feel it would be beneficial to mention it in the pattern guidance too. My main reasoning for this is that in my experience (8 years across many different services in GOV), the user support contact channels already exist when a designer starts on a project, so they may never read that service manual guide.

[abbott567]

With the introduction of WCAG 2.2, there is a new criterion for AA compliance, 3.2.6 Consistent Help.

The guidance in the design system already states that contact information should be in the same order everywhere it is shown, but with this new criterion it will also need to be in the same place.

I think if you update the guidance to highlight this it could help teams avoid accessibility failures against this new criterion during the design phase, rather than during an audit.

[stevenjmesser]

We have removed the 'Experimental' tag from components, patterns, and guidance in the Design System. 😌

The tag was being used on the Contact a department or service team pattern to raise awareness that more research is needed to validate it. However, we recently published new guidance on how to share findings from users which we hope will make it easier to collect more information about how the Design System is being used across services.

If your team has used this component please let us know. 💪

[romaricpascal]

Recent user feedback on support mentioned a lack of guidance regarding the design of contact forms as a way to get in touch with departments and services. It was particularly pointing how limiting the number of characters that users can enter when contacting governments may prevent users from entering enough details about what they want to reach the department or service about.