Communicating with users
Follow the Design System communications charter
Responding to users
If someone asks a question or reports a problem you should respond to acknowledge their questions. Being able to take part in team meetings takes priority over support.
When you respond you should consider:
- discussing the query with another person on the team if complex
- if there is something in the Design System or Frontend that can help this person?
- if we don’t have something but it lives in the community backlog, share the specific issue and say that people across government have shared work in progress that might help them
- whether you or someone in the team can help this person?
- if not, identify who is best placed from GDS to refer to
Just because you’re on support doesn’t necessarily mean you’re the right person to respond to a particular query. Your role is to identify the right person and liaise.
In addition to this, if you are not on support but feel best placed to answer a particular query, please discuss it with the designated support volunteers before replying.
Then:
- if the Design System does not contain guidance, but we want to give an opinion, we need to make it clear that it’s a personal opinion and not a representation of GDS.
- if it’s something that someone else in the team can help with get them involved (only in the case if the issue is preventing the user from being able to use the products)
- If it’s a bug, ask if it’s possible for them to raise an issue in the corresponding repository (unless that is how the support request comes in). Say “if you are not able, I can do this for you” Make sure you ask them if we can mention their name or prefer it to be anonymous.
- If you think the user might be able to fix the bug themselves (for example, if they provide a ‘suggested fix’), ask them if they would be willing to do so, encouraging them to raise a pull request.
- Otherwise, if the bug is something that is easy to fix, and you are able to fix it, you can do so, following our usual development practises.
- if they are requesting something new or a regression from the old products, thank them for raising, explain that it doesn’t exist and encourage them to raise a PR
- If you need more information from them to answer their query, ask for it. If the query is via Zendesk and you don’t hear back within a week, you can close the issue - but send a message explaining why. If you need to open the issue at a later date, you’ll need to create a Follow up ticket
If a question is a broader one that cannot be solved at the moment but should be captured (eg. a discussion about whether it’s useful to add “or” between radio button options), try to nudge the conversation towards the backlog by saying that the feedback is really valuable and we don’t want it to get lost from Slack.
Use this guide to identify if a query is a feature or a bug.