Skip to main content

How to collect feedback from the community

When to ask for feedback

We like to work in the open.

We want to involve the community in decision making so that the Design System continues to reflect what users use, need and want from the Design System.

Asking for community feedback can help you:

  • gain confidence in the decision you are making
  • assess the impact to users
  • collect alternative suggestions for the work you are doing
  • highlight gaps, uses cases you haven’t considered

Asking for feedback is not user research.

Consider where you are at with your work. Do you need the community’s help with decision making, do you want to collect ongoing feedback indefinitely, do you want to co-design with the community or do you want to show them what you’ve done?

Use this guide if you want help with decision making.

If you want to show the community what you’ve done, consider:

  • writing a blog post
  • presenting slides at an internal showcase or community event
  • presenting slides at an external event

If you want to co-design with the community, consider

  • running specific sessions, workshops, design crits, hack-a-thons etc. with the community
  • organising a steering group – forming a group who have an interest or have worked on similar projects to the one you are working on. You can set up a Google group to message them specifically.

Which channels to ask for feedback on

The common channels we use are:

The channel you use will depend on who you want to reach and what type of feedback you need. You may need to use multiple channels and signposts from other channels.

Github discussions

Use Github discussions if you need to

  • gather detailed feedback, you can set a specific timeframe or indefinitely
  • share a lot of context, background information, images or refer to Github issues
  • share the decision making process
  • allow users and the team to build on, ask questions and debate with each other
  • reach all users

Github discussions are good for working in the open, transparency and keeping feedback all in one place. But be aware, you will have limited scope to collect user characteristics. Some users don’t want to or find it difficult to use Github. Github is open to everyone, this can attract irrelevant opinions and will require moderation. You’re more likely to get strong opinions rather than neutral opinions.

Survey

Use a survey if you need to

  • gather detailed feedback at a point in time
  • gather quantitative data
  • gather data about users themselves, for example, characteristics, level of confidence
  • users to respond to specific questions
  • target certain types of user groups (e.g. use screening questions)
  • get private feedback (e.g if responses might include sensitive topics)

Surveys are good for collecting systematic feedback and doing quantitative analysis, however there’s no space for discussions. But be aware you’ll need to send out multiple reminders.

Monthly community chat

Use the monthly community chat if you need to

  • share a lot of context, background information
  • allow users to discuss and surface ideas (e.g breakout room discussion)
  • gather feedback about general topics (e.g community activities, pain points, ideation)

The monthly community chat is open to any Design System users. Attendees’ experience and context can vary widely and feedback you receive will reflect this. In the past, we’ve found it difficult to include a lot of technical folk. The format is timebound and less convenient than asynchronous methods. It’s also harder for users to provide evidence on the spot and more prone to opinions.

Padlet board

Use padlet, if you need to

  • gather anonymous feedback
  • display information and questions in different ways
  • control who you give access to

There are many different formats you can display information and ask for feedback on a padlet board. We have mainly used it to collect feedback as part of community events. It may be an easier platform for some users than Github, it needs further exploration and experimentation.

Email the mailing list

Use email if you need to

  • contact as many of our users as possible
  • ask for a specific thing (e.g. sign up to do user research)

Email is best used to signpost to other channels you’re collecting feedback or telling users about community activities. Be aware that any emails sent to the mailing list must fit in with existing communications that’s already going out to users. Send emails sparingly as it can feel “spammy”. Once emails are sent, they are uneditable.

Slack

Use Slack if you need to:

  • get simple, immediate feedback
  • get feedback from a specific group of users (e.g. port maintainers, steering group)
  • get feedback from a specific person

Slack is best used to signpost to other channels you’re collecting feedback. Users tend not to read or respond to older messages. You will need to transpose feedback somewhere else as we don’t have access to messages older than 90 days.

How to ask for feedback

GitHub Discussions templates

When posting on GitHub discussions, use one of the following templates for Design and Development considerations.

An open-ended discussion

[Title in the title field]

We are working on...

## About this work

<!-- Include relevant GitHub work in progress links, Design System backlog links — write a summary of each link shared to provide context within the discussion -->

## How you can help

You can answer any or all of the following:

<!-- 
Prompts:
* Are you using the style, pattern or component at the moment?
* What are your insights about how people use the style, pattern or component? Try to include:
  * how it helped or hindered users’ journeys, using specific observations
  * any metrics or hypotheses that helped you measure success
  * screenshots of how you implemented it in your service
* How does this change affect your work/service?
* If we shipped this tomorrow, would you be in a position to update? What work might you need to do?
-->

## What we're hoping to achieve

<!-- Help users understand ours goals and constraints so they can focus their discussion -->

## Other ways you can give feedback

## When to give feedback by

<!-- time and date -->

A question and answer

[Title in the title field, in the form of a question]

We are working on...

## About this work

<!-- Include relevant GitHub work in progress links, Design System backlog links — write a summary of each link shared to provide context within the discussion -->

## How you can help

Answer the question, or vote for the best answer that somebody else has submitted.

<!-- Highlight any specific considerations for "good" answers -->

## What we're hoping to find out

<!-- Help users know what we want from their answers, to help them focus their answers -->

## Other ways you can answer this question

## When to answer by

<!-- time and date -->

A poll

[POLL: Title in the title field]

We are working on...

## About this work

<!-- Include relevant GitHub work in progress links, Design System backlog links — write a summary of each link shared to provide context within the discussion -->

## How you can help

Take part in our poll.

<!-- Highlight any specific considerations for users before selecting poll options -->

## What we'll do with the poll results

<!-- Explain how we'll use the poll results -->

## Other ways you can take part

## When the poll will close

<!-- time and date -->

If you’re seeing the same voices engage with the discussion and are looking for new voices consider adding a comment:

If you’ve recently contributed to a discussion, we’d appreciate your help in encouraging new voices within your teams
and departments.

Remind users of the Code of Conduct by adding a comment:

Just a reminder that our GitHub discussions fall under our team's [code of conduct](https://github.com/alphagov/govuk-design-system/discussions/5036#discussion-9237622). Please help us keep these forums a
safe space for all.

If you’re not getting much engagement, consider following up with reminders or prompts that include the following text:

If you’re neutral about [x], your feedback is still valuable.

How to support and promote your request

To sign post users to your request you can:

  • use community events
  • post in internal and x-gov slack
  • share within your social network

Things to think about when considering where to promote your request:

  • the audience
  • the level of feedback you require, for example, can someone contribute without much context?

Try not to alienate who can take part in your request for review. It’s good to aim to have one source of truth for feedback but include methods to support users contributing in other ways, for example, let users email or direct message with their feedback and obtain their consent to post it in the more public forums.

When and how to close a request for feedback

On GitHub Discussions

Include within your post a time and date in which you hope to collect feedback by. Use the ‘When to give feedback by’ heading to communicate these dates.

You should collate all feedback on the discussion thread or backlog issue. If this is not possible for some reason, you could use an internal document, a brief issue, or even a pull request/issue on one of our GitHub repositories if the feedback highlights a small, actionable task.

If you’ve got feedback in a private channel and haven’t already told users how that feedback might be anonymised and made public, ask for permission to do so before adding the feedback to the common location.

Once the date for feedback has passed, summarise the findings either in the original discussion post or as a comment on the discussion thread.

You can then close the discussion thread with a comment thanking folks for contributing, indicating if and how they can still feedback, and reminding folks how the feedback might be used.

When the status of the work changes, it’s useful to update the thread with a comment pointing at that work, so everybody who took part will be notified that there’s been an update.