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

[sanjaypoyzer]

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.