└── docs ├── CHANGELOG.md ├── CODE_OF_CONDUCT.md ├── CONTRIBUTING.md ├── CRITERIA.md ├── DESIGN_SYSTEM_CONTENT_PATTERN.md ├── ISSUE_TEMPLATE.md ├── README.md ├── WORKING_GROUP.md ├── contribution_and_assurance ├── Design System working group decision log.md ├── Design System working group principles and ways of working.md ├── How to organise and run a design system working group review session.md ├── How to support a contributor.md ├── Individual contribution acceptance criteria template.md └── Working group email templates.md └── images ├── caroline-jarrett.jpg └── george-sheldrake.png /docs/CHANGELOG.md: -------------------------------------------------------------------------------- 1 | # GOV.UK Design System Backlog 2 | 3 | This file documents any significant changes we make to the way we organise and run this backlog. 4 | 5 | It is not a record of all the changes made to the contents of the backlog. 6 | 7 | 8 | # How we started 9 | 10 | One of our goals is to create a GOV.UK Design System which represents the needs of cross government teams. The process of building a backlog should be co-created by people in different departments to reflect those needs. So to start with something that could help facilitate those conversations we created a master list of components and patterns which live in Service Manual, Elements, GOV.UK and in other departmental pattern libraries: https://docs.google.com/spreadsheets/d/1HlywOGUPuAOzeI2aeevHGNOOiO1dH5LF_HB1VrmT2sY/edit#gid=1882864638 11 | 12 | We have been talking to representatives of different departments, both designers and developers to get their feedback on what we have on the Design System backlog, identifying what is missing, and spotting where there is overlap in work in different departments. 13 | 14 | Current user pain points from our research: 15 | - Lack of awareness of the available design resources 16 | - Teams developing new things when someone´s already solved the problem 17 | - Duplication of effort and inconsistently designed services 18 | - Useful patterns and components are missing 19 | - A lack of clarity regarding the official status of some patterns 20 | - Design resources feels like they're owned by GDS 21 | 22 | The idea was that this place could host and help raise visibility on what people are working on, while something in not available in the GOV.UK Design System. We want to encourage collaboration and avoid duplication by making work visible to others 23 | 24 | ## Cross- Government Design System workshop 25 | 26 | On 11 December 2017, 18 designers from across government (HO, MOJ, DWP, DVLA, HMRC, Land Registry, Environment Agency) took part in a workshop to: 27 | 28 | * agree a list of components and patterns that are needed in government
 29 | * generate ideas for cross-gov collaboration and contribution
 30 | * review 2 new components to decide if they should be added to the GOV.UK Design System 31 | 32 | See the results and iteration to the Standard and the backlog from the workshop here: https://docs.google.com/presentation/d/15kcx5cBw_PzYW7mmnTbYL5XilmG0yrvhCzA-1M_O4TE/edit#slide=id.g2fafd40fca_0_0 
 33 | -------------------------------------------------------------------------------- /docs/CODE_OF_CONDUCT.md: -------------------------------------------------------------------------------- 1 | # Code of conduct for `alphagov` 2 | 3 | Contributors to repositories hosted in `alphagov` are expected to 4 | follow the Contributor Covenant Code of 5 | Conduct, and those working within Government are also expected to follow the Civil Service Code 6 | 7 | ## Civil Service Code 8 | 9 | The [Civil Service Code](https://www.gov.uk/government/publications/civil-service-code/the-civil-service-code) 10 | 11 | ## Contributor Covenant Code of Conduct 12 | 13 | > Note: 14 | > * where the code of conduct says "project" we mean GDS, `alphagov` and all repositories hosted within it. 15 | > * where the code of conduct says "maintainer" we mean `alphagov` organisation owners 16 | > * where the code of conduct says "leadership" we mean both `alphagov` organisation owners, line managers, and other leadership within GDS 17 | 18 | ### Our Pledge 19 | 20 | In the interest of fostering an open and welcoming environment, we as 21 | contributors and maintainers pledge to making participation in our project and 22 | our community a harassment-free experience for everyone, regardless of age, body 23 | size, disability, ethnicity, gender identity and expression, level of experience, 24 | nationality, personal appearance, race, religion, or sexual identity and 25 | orientation. 26 | 27 | ### Our Standards 28 | 29 | Examples of behavior that contributes to creating a positive environment 30 | include: 31 | 32 | * Using welcoming and inclusive language 33 | * Being respectful of differing viewpoints and experiences 34 | * Gracefully accepting constructive criticism 35 | * Focusing on what is best for the community 36 | * Showing empathy towards other community members 37 | 38 | Examples of unacceptable behavior by participants include: 39 | 40 | * The use of sexualized language or imagery and unwelcome sexual attention or 41 | advances 42 | * Trolling, insulting/derogatory comments, and personal or political attacks 43 | * Public or private harassment 44 | * Publishing others' private information, such as a physical or electronic 45 | address, without explicit permission 46 | * Other conduct which could reasonably be considered inappropriate in a 47 | professional setting 48 | 49 | ### Our Responsibilities 50 | 51 | Project maintainers are responsible for clarifying the standards of acceptable 52 | behavior and are expected to take appropriate and fair corrective action in 53 | response to any instances of unacceptable behavior. 54 | 55 | Project maintainers have the right and responsibility to remove, edit, or 56 | reject comments, commits, code, wiki edits, issues, and other contributions 57 | that are not aligned to this Code of Conduct, or to ban temporarily or 58 | permanently any contributor for other behaviors that they deem inappropriate, 59 | threatening, offensive, or harmful. 60 | 61 | ### Scope 62 | 63 | This Code of Conduct applies both within project spaces and in public spaces 64 | when an individual is representing the project or its community. Examples of 65 | representing a project or community include using an official project e-mail 66 | address, posting via an official social media account, or acting as an appointed 67 | representative at an online or offline event. Representation of a project may be 68 | further defined and clarified by project maintainers. 69 | 70 | ### Enforcement 71 | 72 | Instances of abusive, harassing, or otherwise unacceptable behavior may be 73 | reported by contacting the project team at alphagov-code-of-conduct@digital.cabinet-office.gov.uk. All 74 | complaints will be reviewed and investigated and will result in a response that 75 | is deemed necessary and appropriate to the circumstances. The project team is 76 | obligated to maintain confidentiality with regard to the reporter of an incident. 77 | Further details of specific enforcement policies may be posted separately. 78 | 79 | Project maintainers who do not follow or enforce the Code of Conduct in good 80 | faith may face temporary or permanent repercussions as determined by other 81 | members of the project's leadership. 82 | 83 | ### Attribution 84 | 85 | This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4, 86 | available at https://www.contributor-covenant.org/version/1/4/code-of-conduct.html 87 | 88 | [homepage]: https://www.contributor-covenant.org 89 | -------------------------------------------------------------------------------- /docs/CONTRIBUTING.md: -------------------------------------------------------------------------------- 1 | # How you can contribute 2 | 3 | The [GOV.UK Design System](https://design-system.service.gov.uk) is for everyone, with a strong community sitting behind it. It brings together the latest research, design and development from across government to make sure it’s representative and relevant for its users. 4 | 5 | ## Discussing styles, components and patterns 6 | 7 | You can discuss the existing styles, components and patterns in the Design System, or ones being developed, by commenting on issues in the [community backlog](https://github.com/alphagov/govuk-design-system-backlog/projects/1). Alternatively, you can email govuk-design-system-support@digital.cabinet-office.gov.uk. 8 | 9 | For example, you can: 10 | 11 | - ask questions about a style, component or pattern 12 | - answer questions from other contributors 13 | - share examples or demos of a component or pattern 14 | - share research relating to a style, component or pattern 15 | 16 | ## Propose a new component or pattern 17 | 18 | Anyone can propose a new component or pattern for the GOV.UK Design System. 19 | 20 | To be successful, proposals need to show that the component or pattern being suggested would be [useful and unique](CRITERIA.md). 21 | 22 | Follow 3 steps to propose a component or pattern for the Design System. 23 | 24 | ### 1. Check the community backlog 25 | 26 | Check if someone else has already suggested your idea or something similar on the [community backlog](https://github.com/alphagov/govuk-design-system-backlog/projects/1). 27 | 28 | If your idea is on the backlog and marked as proposed, follow the link and comment on the issue. Say you need the component or pattern and share any examples or evidence you have to support the proposal. 29 | 30 | If it’s marked to-do and you would like to work on it, read [how to develop a components or pattern](#develop-a-component-or-pattern). 31 | 32 | ### 2. Raise an issue 33 | 34 | If your idea is not on the backlog, [raise an issue using the template](https://github.com/alphagov/govuk-design-system-backlog/issues/new). A member of the Design System team will get in touch to discuss your proposal. 35 | 36 | At this stage, you just need to present your idea and evidence of the user needs. You can include screenshots or links to versions of the component or pattern in use, but avoid spending time working on a specific design or writing code. 37 | 38 | ### 3. Send your proposal for review 39 | 40 | The Design System team will help you prepare your proposal and share it with the [Design System working group](WORKING_GROUP.md) to review. 41 | 42 | When your proposal is ready, the Design System team will send it to the working group one week before their next monthly meeting. 43 | 44 | At the meeting, the working group will review your proposal and decide if it is useful and unique. This review helps people avoid spending time and effort on something that’s not needed. 45 | 46 | After the meeting, the Design System team will let you know the decision and recommendations, if there are any. 47 | 48 | If the working group agrees your proposal is useful and unique, the Design System team will mark it as to-do on the [community backlog](https://github.com/alphagov/govuk-design-system-backlog/projects/1). 49 | 50 | At this point, you can either start to develop the component or pattern or leave it for someone else to work on. 51 | 52 | ## Develop a component or pattern 53 | 54 | ### Plan your work with the Design System team 55 | 56 | After you’ve emailed them, a member of the Design System team will get in touch to arrange a kick-off meeting. 57 | 58 | During the meeting, the team will help you to: 59 | 60 | - agree the scope of your contribution 61 | - plan what design, content, code and guidance needs working on 62 | - agree timings 63 | - discuss any support you might need 64 | - identify a contact for you to work with in the Design System team 65 | 66 | If you’re happy to go ahead, the team will assign you to the issue as a contributor. 67 | 68 | ### Research and develop your contribution 69 | 70 | While you’re working on your contribution, the Design System team will arrange a weekly catch up to find out how you’re getting on and if you need any help. 71 | 72 | Find examples of the component or pattern already in use. The best way to do this is to ask the government design community. Use the [Design Slack channel](https://ukgovernmentdigital.slack.com/messages/C062GAGLW/) and the [digital service designers mailing list](https://groups.google.com/a/digital.cabinet-office.gov.uk/forum/?hl=en-GB#!forum/digital-service-designers). 73 | 74 | Examples and research from government services are usually most relevant. But look at how other organisations solve the problem too. 75 | 76 | Involve people from the [government design community](https://www.gov.uk/service-manual/communities/design-community) in any work you’re doing. This makes it less likely that you’ll spend time doing work or research that’s already been done. 77 | 78 | By finding people who are working on similar solutions, you can benefit from progress they’ve made and relevant research they’ve done. 79 | 80 | Once you have collected some examples and research findings, you should start designing a specific implementation of the component or pattern to research with. 81 | 82 | Ideally you’ll research as part of an actual service, but it’s possible to test using prototypes as long as they are realistic. Work with your own team or find a team to work with through the design community. 83 | 84 | Once you have researched the component or pattern and shown it works for users, the [Design System working group](WORKING_GROUP.md) will review it. 85 | 86 | ### Send your contribution for review 87 | 88 | All components and patterns must meet the [contribution criteria](CRITERIA.md) before they can be published. The Design System working group will use the criteria to review your contribution. 89 | 90 | To arrange a review, tell the Design System team your contribution is ready. The team will check your work before letting the working group know it’s ready to review. 91 | 92 | The working group will vote if it can be published: 93 | 94 | - as it is with no recommendations 95 | - as it is with some recommendations to consider when possible 96 | - only after you have addressed certain recommendations 97 | 98 | The Design System team will invite you to meet with them and discuss the decision. 99 | 100 | During the meeting, you’ll be able to ask questions, hear recommendations and talk through any queries or concerns. 101 | 102 | ### Get ready to publish 103 | 104 | If the working group recommended some changes to make before publishing, the Design System team will help you work on them. 105 | 106 | If the working group agree your contribution meets the criteria, the Design System team will help you get ready to publish. This includes organising any final checks or updates to the design, content, code and guidance. 107 | 108 | Most new components and patterns will be published as experimental at first. The Design System team will remove the experimental status once research proves the component or pattern meets user needs. The research must be from different services and with different types of users. 109 | 110 | -------------------------------------------------------------------------------- /docs/CRITERIA.md: -------------------------------------------------------------------------------- 1 | # GOV.UK Design System criteria 2 | 3 | The contents of the GOV.UK Design System are high quality and meet user needs. To guarantee this, all components and patterns must meet certain criteria. 4 | 5 |
6 | 7 | ## New proposals 8 | 9 | To be successful, proposals need to show that the component or pattern being suggested would be useful and unique. 10 | 11 | | Criteria | Description | 12 | | :------- | :---------- | 13 | | Useful | There is evidence that this component or pattern would be useful for many teams or services.

Evidence could be screenshots or links to versions of it being used in different services. | 14 | | Unique | It doesn’t duplicate something which already exists in the GOV.UK Design System, unless it’s intended to replace it. | 15 | 16 | The Design System [working group](WORKING_GROUP.md) reviews proposals in the [community backlog](https://github.com/alphagov/govuk-design-system-backlog/projects/1) to check they meet these criteria. Proposals that meet the criteria will then be moved into the 'To do' column, ready to be worked on. 17 | 18 |
19 | 20 | ## Before a component or pattern is published 21 | 22 | The working group reviews the implementation to make sure it is usable, consistent and versatile. 23 | 24 | | Criteria | Description | 25 | | :----------- | :---------- | 26 | | Usable | It has been tried in user research and shown to work with a representative sample of users, including those with disabilities.

Components and patterns which are not proven usable can be published as experimental. But they must be clearly based on relevant user research from other organisations and best practice, and meet the other criteria. | 27 | | Consistent | It reuses existing styles and components in the GOV.UK Design System where possible.

Both the guidance and any content included in examples must follow the [GOV.UK content style guide](https://www.gov.uk/guidance/style-guide/a-to-z-of-gov-uk-style).

Any code follows the [GOV.UK Frontend coding standards](https://github.com/alphagov/govuk-frontend/tree/master/docs/contributing/coding-standards) and is ready to merge into GOV.UK Frontend. | 28 | | Versatile | The implementation is versatile enough that component or pattern can be used in a range of different services that may need it.

For example, a versatile date input component could be set up to ask for a year only, a month and year only, a precise date, or any other combination you may need.

The component or pattern must also have been tested and shown to work with a range of browsers, assistive technologies and devices. | 29 | 30 | To find out more, read the GOV.UK Design System [contribution guidelines](CONTRIBUTING.md). 31 | -------------------------------------------------------------------------------- /docs/DESIGN_SYSTEM_CONTENT_PATTERN.md: -------------------------------------------------------------------------------- 1 | All design patterns and components in the GOV.UK Design System should follow the below content pattern. If you’re working on a pattern or component page for the Design System, you should use this as a template. 2 | 3 | (Don’t edit, copy and paste the content into a new doc) 4 | 5 | # Title 6 | 7 | [Overview] 8 | 9 | If the component/pattern is experimental, include this line: 10 | 11 | This [component/pattern] is currently experimental because [more research](link to research section below) is needed to validate it. 12 | 13 | Then, use this overview section to: 14 | 15 | - explain, in one line, how the component/pattern helps users 16 | - show a live example - if this is not possible because the component/pattern is bigger than one screen (eg Confirm an email address), you can use an appropriate illustration or screenshot and/or link to a prototyped example. 17 | 18 | ## When to use this [component/pattern] 19 | 20 | Describe when to use this component/pattern. When is it appropriate to use and what need does it help you meet? 21 | 22 | If necessary, include an additional H2 titled ‘When not to use this pattern’. Use this section to highlight any exceptions or known scenarios where the pattern does not work. If you include this section, explain what to use instead (with a relevant link if we’re suggesting an alternative pattern or component). 23 | 24 | ## How it works 25 | 26 | Use this section to explain how the pattern works. 27 | 28 | This should include: 29 | 30 | - (if the component/pattern is too complex to have been fully described in the overview) a full description of how the pattern works (for users) 31 | - rules/instructions on how to implement it 32 | - steps to follow 33 | 34 | It can also include: 35 | 36 | - coded examples 37 | - things to avoid 38 | - why it works 39 | 40 | If this section is quite long, break it into smaller sections with H3s. 41 | 42 | ## Research on this [component/pattern] 43 | [Research summary - no H3] 44 | 45 | Use this section to summarise the research that supports this component or pattern. If the component or pattern is experimental, summarise the research it’s based on. 46 | 47 | Describe: 48 | 49 | the research context, for example, whether it was tested in isolation, or as part of a prototype or a live service 50 | types of users tested with, for example, users with disabilities, users with low digital literacy 51 | 52 | If possible, finish this section with a link to more detailed research notes. It must be documented somewhere that’s open and publicly-accessible, ideally a blog post. 53 | 54 | ### Known issues and gaps 55 | 56 | Use this section to describe any known issues with the component or pattern, or any gaps in the research. 57 | 58 | ### Services using this [component/pattern] 59 | 60 | Use this section to provide up to 5 examples of services using the component or pattern. If there are more than 5 services using it, you should choose the top 5 most popular, using this list https://www.gov.uk/api/search.json?filter_content_store_document_type=transaction 61 | 62 | For very common components, like text inputs, use this content: 63 | 64 | This [component/pattern] is commonly used across GOV.UK. You can see examples of it being used in the following services. 65 | 66 | List of services in following format: 67 | 68 | #### Department/organisation name 69 | Service name 70 | 71 | For other components and patterns, use this content: 72 | 73 | This [component/pattern] has been used in a number of services, including the following. 74 | 75 | List of services in following format: 76 | 77 | #### Department/organisation name 78 | Service name 79 | 80 | ### Next steps 81 | 82 | If applicable, include this section and use it describe outstanding research or work to be done or questions to answer. 83 | 84 | 85 | -------------------------------------------------------------------------------- /docs/ISSUE_TEMPLATE.md: -------------------------------------------------------------------------------- 1 | 6 | 7 | ## What 8 | > Give a brief description of the style, component or pattern you want to propose. 9 | 10 | ## Why 11 | > Explain why you think this should be added to the GOV.UK Design System. 12 | > 13 | > - What evidence do you have that it's needed by multiple services across government? 14 | > - What evidence do you have that it meets the needs of the users of those services? 15 | > - Have you checked that it doesn't already exist in the GOV.UK Design System? 16 | 17 | ## Anything else 18 | > Include links to any examples, research or code to support your proposal, if available. 19 | -------------------------------------------------------------------------------- /docs/README.md: -------------------------------------------------------------------------------- 1 | # GOV.UK Design System: Discuss styles, components and patterns 2 | 3 | ## About this repo 4 | 5 | This is a place for the UK government community to discuss potential new components and patterns for the [GOV.UK Design System](https://design-system.service.gov.uk/). 6 | 7 | --- 8 | 9 | ### **[View and discuss styles, components and patterns](https://github.com/orgs/alphagov/projects/43)** 10 | 11 | --- 12 | 13 | ## Support 14 | 15 | If you have any questions about this repository you can comment on the issues, email the [Design System Team](mailto:govuk-design-system-support@digital.cabinet-office.gov.uk) or use the [#govuk-design-system](https://ukgovernmentdigital.slack.com/messages/govuk-design-system) channel on cross-government Slack. 16 | 17 | 18 | ## Contributing 19 | 20 | [Check our upcoming components and patterns](https://design-system.service.gov.uk/community/upcoming-components-patterns/) to see what's most needed and how to contribute. 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | -------------------------------------------------------------------------------- /docs/WORKING_GROUP.md: -------------------------------------------------------------------------------- 1 | # Design System working group 2 | 3 | The Design System working group is a multi-disciplinary panel of representatives from across government. It makes sure that all components and patterns published in the GOV.UK Design System are of a high quality and meet user needs. 4 | 5 | The working group: 6 | 7 | reviews proposals and contributions against the [contribution criteria](CRITERIA.md) 8 | makes recommendations to help contributors improve their work 9 | advocates for the needs of colleagues across government 10 | ## Why the working group exists 11 | By including representatives from a mixture of disciplines and departments, the working group helps to ensure that the Design System represents its users. 12 | 13 | It means that decisions made are fair and unbiased, and that the Design System reflects the experiences of the whole of government not just one department. 14 | 15 | ## How to join the working group 16 | 17 | The GOV.UK Design System team is looking into the best way of helping people to join the working group. 18 | 19 | In the meantime if you are interested in joining the working group email the Design System team at govuk-design-system-support@digital.cabinet-office.gov.uk 20 | -------------------------------------------------------------------------------- /docs/contribution_and_assurance/Design System working group decision log.md: -------------------------------------------------------------------------------- 1 | # Decision log for GOV.UK Design System working group review session 2 | [INSERT DATE] 3 | 4 | Reviewers: 5 | 6 | - [NAME] [DEPARTMENT] 7 | - [NAME] [DEPARTMENT] 8 | - [NAME] [DEPARTMENT] 9 | - [NAME] [DEPARTMENT] 10 | 11 | Facilitator: [NAME] 12 | Note takers: [NAME] 13 | 14 | ## Summary 15 | 16 | [Section to publish in GitHub - to write after the review session] 17 | [see an example here](https://github.com/alphagov/govuk-design-system-backlog/issues/10#issuecomment-564633356) 18 | 19 | This summary of the review session will be published in the [Design System community backlog](https://github.com/alphagov/govuk-design-system-backlog/projects/1). The contributor will also have access to the detailed session notes at the end of this document. 20 | 21 | ## [INSERT NAME OF COMPONENT / PATTERN] 22 | 23 | The panel agreed that: 24 | 25 | [The contribution can be published as it is] or [The contribution cannot be published until some recommendations have been made] 26 | 27 | The panel also made the following recommendations. 28 | 29 | ### Design 30 | 31 | [Group the comments under relevant headings, for example: guidance, design, code, etc.] 32 | 33 | [Summarise the recommendations as short and concise points. Make sure you only record genuine recommendations from the working group representatives not your own, the team’s, or an interpretation of a general comment] 34 | 35 | ### Guidance 36 | 37 | [Summarise the recommendations as short and concise points. Make sure you only record genuine recommendations from the working group representatives not your own, the team’s, or an interpretation of a general comment] 38 | 39 | ## [NAME OF CONTRIBUTION] 40 | 41 | [ADD LINK TO GITHUB ISSUE IN THE COMMUNITY BACKLOG] 42 | 43 | ### [NAME OF WORKING GROUP REPRESENTATIVE 1] 44 | 45 | **Decision:** 46 | 47 | [The contribution meets the criteria and can be published] 48 | or [The contribution does not meet the criteria and certain actions must be taken before it can be published] 49 | 50 | **Actions needed/comments:** 51 | 52 | [add recommendations sent by working group prior to the session] 53 | 54 | **Session notes:** 55 | 56 | [add notes from the session and the contributor’s comments] 57 | 58 | ### [NAME OF WORKING GROUP REPRESENTATIVE 2] 59 | 60 | **Decision:** 61 | 62 | [The contribution meets the criteria and can be published] 63 | or [The contribution does not meet the criteria and certain actions must be taken before it can be published] 64 | 65 | **Actions needed/comments:** 66 | 67 | [add recommendations sent by working group prior to the session] 68 | 69 | **Session notes:** 70 | 71 | [add notes from the session and the contributor’s comments] 72 | 73 | ### [NAME OF WORKING GROUP REPRESENTATIVE 2] 74 | 75 | **Decision:** 76 | 77 | [The contribution meets the criteria and can be published] 78 | or [The contribution does not meet the criteria and certain actions must be taken before it can be published] 79 | 80 | **Actions needed/comments:** 81 | 82 | [add recommendations sent by working group prior to the session] 83 | 84 | **Session notes:** 85 | 86 | [add notes from the session and the contributor’s comments] 87 | 88 | ### [ETC...] 89 | 90 | 91 | 92 | 93 | 94 | -------------------------------------------------------------------------------- /docs/contribution_and_assurance/Design System working group principles and ways of working.md: -------------------------------------------------------------------------------- 1 | # GOV.UK Design System working group principles and ways of working 2 | 3 | This guidance explains what the GOV.UK Design System working group is, why it exists and how it works. 4 | These guidelines have been co-created with working group representatives. 5 | 6 | **The GOV.UK Design System team and the working group will be piloting some changes to reviewing contributions from January to July 2019. If this is successful, this guidance will be updated to reflect the changes.** 7 | 8 | ## Overview 9 | 10 | 1. Introduction 11 | 2. Purpose of the working group 12 | 3. Roles and responsibilities of the working group 13 | 4. Reviewing proposals and contributions 14 | 15 | ## 1. Introduction 16 | 17 | As part of the [Government Transformation Strategy](https://www.gov.uk/government/publications/government-transformation-strategy-2017-to-2020/government-transformation-strategy#vision-and-objectives) the Government has committed to “build services that run seamlessly across government”. 18 | 19 | To achieve this, teams need to work as efficiently as possible when designing and building government services. 20 | 21 | They also need access to interaction and content design resources based on best practice from across government. 22 | 23 | ### GOV.UK Design System 24 | 25 | To support this work, the Design System team at the Government Digital Service (GDS) has created the [GOV.UK Design System](https://design-system.service.gov.uk/). It contains guidance, examples, code and research that teams can use to help them prototype and build services. 26 | 27 | Anyone can propose or develop new a component or pattern for the Design System. 28 | 29 | Enabling people from across government to contribute will ensure the Design System: 30 | 31 | - represents user needs 32 | - showcases best practice in government 33 | - reduces duplication of effort 34 | 35 | ### Design System working group 36 | 37 | The Design System team set up a working group. 38 | 39 | The working group is a group of representatives from different disciplines and departments across government. 40 | 41 | The working group ensures components and patterns published in the Design System are of a high quality and meet user needs. 42 | 43 | ### Benefits of joining the working group 44 | 45 | Working group representatives contribute to the wider community by getting user-centred best practice into the Design System. 46 | 47 | Supporting contribution to the Design System promotes collaboration across departments and supports the Digital Transformation Strategy. 48 | 49 | For these reasons, joining the working group can be discussed as a community or corporate objective. This may help representatives to get the time and permission they need to participate. 50 | 51 | ## 2. Purpose of the working group 52 | 53 | The working group supports contributions to the Design System by ensuring that components and patterns reflect the needs of: 54 | 55 | - government service users 56 | - the wider government community 57 | 58 | ### Principles of the working group 59 | 60 | These principles were co-created with working group representatives in a workshop on 19 June 2018. 61 | 62 | #### Open by default 63 | 64 | The working group is open, honest and transparent by default. 65 | 66 | Working in the open and making honest recommendations help users understand past decisions and helps contributors improve their work. 67 | 68 | #### Representative 69 | 70 | Everybody has value to add. 71 | 72 | The working group must be as representative as possible to help it: 73 | 74 | - advocate for a range of user needs 75 | - use the knowledge and experience of different disciplines and government departments 76 | 77 | #### Community driven 78 | 79 | The Design System can only meet the needs of the whole community if it’s built by the whole community. 80 | 81 | The working group ensures that it’s community led, not GDS led. 82 | 83 | #### Enablers, not blockers 84 | 85 | The working group values getting contributions into the Design System over keeping them out. 86 | 87 | They make constructive recommendations to help contributors improve their work. 88 | 89 | ## 3. Roles and responsibilities of the working group 90 | 91 | Representatives of the working group are initially invited to participate for 6 months. 92 | 93 | ### Responsibilities of the working group 94 | 95 | By joining the working group, representatives commit to support the Design System and help achieve its aims. They: 96 | 97 | - review proposals and contributions against the Design System contribution criteria 98 | - collect input and feedback from their colleagues across government to inform their decisions 99 | - ask contributors any questions they need to inform their decisions 100 | - send their decisions on contributions to the Design System team before each review session 101 | - attend a 1 hour long review session each month to discuss their decisions with contributors and the other representatives 102 | - agree to have review session notes shared publicly, though they will not be named individually 103 | 104 | ### Responsibilities of the Design System team at GDS 105 | 106 | The Design System team at GDS commits to support contributors and the working group. They: 107 | 108 | - work with contributors to ensure their contribution is in the best shape possible before the working group reviews it 109 | - ensure that any code meets GOV.UK Frontend Coding Standards 110 | - organise and facilitate review sessions and make sure everyone gets a fair chance to speak 111 | - record decisions publicly 112 | - work with contributors to get components and patterns published in a timely manner after review sessions 113 | - have ultimate responsibility to ensure the contents in the Design System adhere to relevant GOV.UK standards 114 | 115 | Neither the Design System team nor the working group will overrule the other. If there is a disagreement, there will be processes in place to collect concerns and ensure a fair decision. 116 | 117 | ### Leaving the working group 118 | 119 | After 6 months, representatives of the working group will be asked if they wish to continue for another 6 months, or leave. 120 | 121 | Some continuity and consistency in the working group helps things to run smoothly. Before joining, prospective representatives should consider if they can realistically commit to 6 months. 122 | 123 | However, circumstances can change unexpectedly and absolutely no one will be made to feel bad if they have to leave before the end of 6 months. 124 | 125 | Anyone wanting to leave should contact the Design System team who will organise a replacement. 126 | 127 | ## 4. Reviewing proposals and contributions 128 | 129 | ### Review sessions 130 | 131 | Each month, the working group meets for 1 hour on Google Hangouts to discuss new proposals or contributions for the GOV.UK Design System. Contributors are invited to join the call. 132 | 133 | The purpose of the session is for representatives to share their decisions and discuss questions, concerns or recommendations with each other and the contributors. 134 | 135 | These sessions are booked a month in advance by the Design System team. The invitation to the session includes a link to join the Google Hangout as well as other important details. 136 | 137 | Representatives who know they cannot attend a session should let the Design System team know as early as possible and send their decision and recommendations regardless. 138 | 139 | During the review session, there will be note takers from the Design System team to record discussions, recommendations and decisions. 140 | 141 | The Design System team will share these notes with the working group to check after each session. 142 | 143 | To help Design System users understand how past decisions were made, the Design System team will publish a summary of the notes in GitHub. These will not mention individuals’ names. 144 | 145 | ### Reviewing new proposals 146 | 147 | Representatives review each proposal against the [contribution criteria](https://design-system.service.gov.uk/community/contribution-criteria/), and vote on if it is useful and unique. 148 | 149 | At this stage, representatives should base their decision on the idea for the component or pattern in question, not a possible implementation or any examples shown. 150 | 151 | Proposals that meet these criteria canmove into the ‘To-do’ column in the [community backlog](https://github.com/alphagov/govuk-design-system-backlog/projects/1), ready to be worked on and contributed. 152 | 153 | When they have been fully researched and developed, contributions will be sent to the working group for a second review focusing on the implementation. 154 | 155 | ### Reviewing contributions before they are published 156 | 157 | The Design System team will share contributions to review with the working group 2 weeks before each review session. 158 | 159 | Representatives then have one week to review each contribution against the [contribution criteria for before a component or pattern is published](https://design-system.service.gov.uk/community/contribution-criteria/#before-a-component-or-pattern-is-published). 160 | 161 | They should consult with colleagues from their department and the wider community to inform their decision. As part of this, they should consider if there are any security, ethical or political implications for publishing the component or pattern. 162 | 163 | Representatives can also use this time to ask the contributors any questions that will help them to reach a decision. 164 | 165 | Based on this, they should decide if: 166 | 167 | - the contribution can be published as it is 168 | - the contribution cannot be published until certain recommendations have been addressed 169 | 170 | Representatives should respond with their decisions one week before the review session. 171 | 172 | During the review session, the facilitator will introduce each contribution and confirm the outcome of the vote. They will then go round each of the representatives one-by-one and ask them to talk through their decision. 173 | 174 | Representatives will have the opportunity to ask the contributor any questions and the contributor will be able to respond and ask any questions in return. 175 | 176 | At the end of the discussion, representatives will be asked if they’d like to change their initial answer, and the facilitator will confirm the final outcome. 177 | 178 | ### Publishing contributions 179 | 180 | After the review session, the Design System team will work with the contributor to address any recommendations and get the contributions ready to publish. 181 | 182 | Depending on the amount of work needed, it may take a few weeks to complete these steps. 183 | 184 | If, during the course of addressing the working group’s recommendations, there are significant changes to the original contribution, it may be brought back to a future session for another review. 185 | 186 | Once published, the Design System team will move the issue from ‘In progress’ to ‘Published’ in the community backlog, and will notify the working group. 187 | -------------------------------------------------------------------------------- /docs/contribution_and_assurance/How to organise and run a design system working group review session.md: -------------------------------------------------------------------------------- 1 | # How to run and organise a working group review session 2 | 3 | This guidance is used by the GOV.UK Design System team, but if you are running a design system, you are welcome to reuse it. 4 | 5 | It explains how to organise and facilitate a Design System working group review session, week-by-week. 6 | 7 | The GOV.UK Design System holds working group review sessions on the last Thursday of every month. Week 1 starts 3 weeks before the review session. 8 | 9 | ## Week 1 - Prepare 10 | 11 | - The calendar invitation for the session will be already in place and sent out to the working group. Check the date and time, and book reminders into your diary as needed. 12 | - Book a room to facilitate the review session. The sessions are run remotely, but you'll want a quiet space to join from. 13 | - Check with the team which contributions are booked into the session you’re running. 14 | - Check with the people who are supporting those contributions that they are on track and will be ready to send them round the following week. 15 | 16 | ## Week 2 - Send contributions 17 | 18 | - Once you have confirmation that the contributions are ready to send, create a Google form to collect the working group’s responses. Make a copy of [this form template](https://docs.google.com/a/digital.cabinet-office.gov.uk/forms/d/12AiHubZO4zP3zuIsl6pG4pHsum-yoZgBLn1y7Nx4RSQ/edit?usp=sharing) and update it with details of the contributions you’re going to send. Remember to change the permissions so that people outside of Cabinet Office can use the form 19 | - Email the working group using the [Email template for sending contributions](https://github.com/alphagov/govuk-design-system-backlog/blob/master/docs/contribution_and_assurance/Working%20group%20email%20templates.md). 20 | - The template reminds representatives that if they cannot attend the session, they should tell us in advance by email or by responding to the calendar invitation. If any of the representatives cannot attend, ask them to provide their recommendations and decisions anyway and say that you can read the response out on their behalf in the session. 21 | - Monitor responses as they come in. Copy and paste the feedback into the [decision log](https://github.com/alphagov/govuk-design-system-backlog/blob/master/docs/contribution_and_assurance/Design%20System%20working%20group%20decision%20log.md). 22 | 23 | ## Week 3 - Collect responses 24 | 25 | - Chase any outstanding responses from working group representatives. 26 | - When all of the responses are in, let the contribution supporters know so that they can discuss it with the contributors. 27 | - Prepare a facilitator’s discussion guide as necessary for the session. 28 | 29 | ## Week 4 - Run session 30 | 31 | - Make sure every representative of the working group has confirmed their attendance. If not, email them individually to confirm. 32 | - Run session using the facilitator’s discussion guide. Make sure you always have at least one, ideally 2 note takers to record the discussion and recommendations using the decision log. 33 | - While running the session, remember to read out the decisions and recommendations from people who could not attend. 34 | 35 | ## Week 5 - Share outcomes 36 | 37 | - Share session notes with the people in the team who are supporting the contributions that were reviewed. They should go through the notes, and write a summary to send to the working group within one week. 38 | - Once you have received the summaries, email the working group to confirm the outcomes and ask for their feedback on the process. 39 | - Some departments cannot access Google docs, so attach a PDF including the detailed review session notes including a summary of decisions and recommendations (to publish in GitHub). 40 | - If there are no more changes, publish the recommendations in the first comment of the Github thread for the contribution in the [Community backlog](https://github.com/alphagov/govuk-design-system-backlog/projects/1). 41 | -------------------------------------------------------------------------------- /docs/contribution_and_assurance/How to support a contributor.md: -------------------------------------------------------------------------------- 1 | # How to support a contributor of a new component or pattern 2 | 3 | This guidance is for the GOV.UK Design System team. It explains how to support a contributor. 4 | 5 | If you are running a design system, you are welcome to reuse it. 6 | 7 | ## Overview 8 | 9 | This guidance explains the steps involved in supporting a contributor. It starts at the point when you pick up a contribution to support and finishes when the contribution is published. 10 | 11 | 1. Organise a kick-off session 12 | 2. Book into a review session 13 | 3. Develop the contribution 14 | 4. Working group review session 15 | 5. Prepare to publish the contribution 16 | 6. Publish the contribution 17 | 18 | ## 1. Organise a kick-off session 19 | 20 | Invite the contributor to a kick off session to discuss the contribution in detail. Kick-off sessions can be held in person or remotely, depending on the contributor’s preference. 21 | 22 | ### Before the session 23 | 24 | Before the session, create a folder in the team's Contribution and assurance folder with the name of the contribution. Find out the following information and record it in a document, saved in that folder. 25 | 26 | - Is the contribution already in the backog? Is it in the ‘proposed’ or ‘to-do’ column? 27 | - How much work has been done? 28 | - Is there a clear user need? 29 | - Who from the team needs to attend the kick-off session? You must invite at least one interaction designer, one content designer and one frontend developer. 30 | - Is the Design System the right place for that contribution? For example, the [Service Manual](gov.uk/service-manual) might be more appropriate for very high-level guidance. 31 | - Where in the Design System would this contribution live? Is it a component or a pattern? How might it affect or relate to other content in the Design System? 32 | - What dependencies might the contribution have, for example on Frontend? 33 | - Are there any obvious challenges or questions that need to be discussed with the contributor up front? 34 | 35 | ### During the session 36 | 37 | Agree who will take notes during the meeting. Copy and paste the following agenda into a shared Google doc and use it to make notes. 38 | 39 | --- 40 | 41 | ### Contribution kick-off meeting agenda 42 | 43 | #### 1. Overview of contribution process 44 | 45 | - Working group 46 | - Review sessions 47 | - Timings 48 | - Support 49 | 50 | #### 2. Agree acceptance criteria 51 | 52 | Make a copy of the [acceptance criteria template](https://github.com/alphagov/govuk-design-system-backlog/blob/master/docs/contribution_and_assurance/Individual%20contribution%20acceptance%20criteria%20template.md) and update it to document what needs to be done for the contribution to be ready. 53 | 54 | #### 3. Identify support needs 55 | 56 | Note: the Design System team is there to support the contributor. Design, guidance, code and research are ultimately the responsibility of the contributor. If they need a lot of support, make sure the contributor understands that it will take longer to develop. 57 | 58 | #### 4. Next steps 59 | 60 | If the contributor still wants to proceed, check if they’re happy to be named publicly as the contributor (for example, in Slack announcements and in GitHub issues). 61 | 62 | Assign them to the relevant issue in the [Design System backlog](https://github.com/alphagov/govuk-design-system-backlog/projects/1) to confirm that they are working on it. 63 | 64 | Estimate how much time the contribution will take to develop. 65 | 66 | Agree how the work will be developed, for example, in branches of GOV.UK Frontend and GOV.UK Design System, in the Prototype Kit, in the contributor’s own repo or in a Google Doc. 67 | 68 | Book in a weekly slot to catch up, identifying any annual leave or busy weeks that need to be taken into consideration. 69 | 70 | --- 71 | 72 | ### After the kick-off session 73 | 74 | Share the acceptance criteria agreed in the kick-off session with the contributor to check. 75 | 76 | Once they’ve confirmed they’re happy with the acceptance criteria, publish it in the GitHub issue. 77 | 78 | You can refine it later but the basics should not change. 79 | 80 | ## 2. Book into a review session 81 | 82 | The [Design System working group](https://design-system.service.gov.uk/community/design-system-working-group/) is a multidisciplinary panel of representatives from across government. Each month, representatives review new contributions and decide whether they are ready to be publish. 83 | 84 | Based on the agreed acceptance criteria and the amount of support needed, agree with the contributor which review session you’ll aim to have it ready for. 85 | 86 | Contributions are sent round to the working group 2 weeks before each review session. Therefore, the deadline for your work is 2 weeks before the review session you book into. 87 | 88 | The best way to agree a date is to email the contributor with a list of the upcoming review session dates and contribution deadlines. You can check review session dates in the Design System Team Events calendar. 89 | 90 | Suggest a timescale that you think seems realistic, and check if it sounds OK to them. 91 | 92 | Once they’ve confirmed a date, let the facilitator for that session know. 93 | 94 | ## 3. Develop the contribution 95 | 96 | While the contribution is being developed, you should be having weekly catch-up meetings with the contributor. In these meetings, record progress against each of the acceptance criteria, and note down what still needs to be done. 97 | 98 | Follow each meeting with an email summarising the progress and next steps. 99 | 100 | Create cards on [our sprint board](https://github.com/orgs/alphagov/projects/4) to represent any work you agree. This will help you keep track of the work you are doing and make it visible for the rest of the team. 101 | 102 | ### Prepare the contribution for review 103 | 104 | At least 3 weeks before the next working group review session, confirm to the person who’s facilitating it that the contribution will be ready. 105 | 106 | **If the contribution will not be ready in time, you should tell the facilitator as soon as possible.** 107 | 108 | Ask the contributor if they can make a branch and open a draft pull request for adding the contribution to the Design System. The Netlify preview it generates is what the working group uses to review the contribution. 109 | 110 | If they are not familiar with GitHub or not confident enough, offer to help them, or create the pull request yourself. 111 | 112 | At this point, arrange to have a ‘Pre-mortem’ with the contributor. This is a session where you brainstorm the reasons the contribution might not get approved for publication, and decide what you can do to address any risks you identify. 113 | 114 | Involve other members of the Design System team in this session, if you can. 115 | 116 | ### Send the contribution 117 | 118 | When it’s ready to review (this must be at least 2 weeks before the working group review session), you should share a link to the contribution preview with the review session facilitator. 119 | 120 | The facilitator will collect decisions and recommendations for the contribution and share these with you to discuss with the contributor before the review session. 121 | 122 | ## 4. Working group review session 123 | 124 | The working group review session is a chance for the working group representatives to discuss their decisions and recommendations with each other and with contributors. 125 | 126 | ### Before the session 127 | 128 | 1. Check the date and time of the review session 129 | 130 | The review session invitation is sent to the whole team, so it should be in your calendar. 131 | 132 | 2. Invite the contributor to the session. 133 | 134 | Contributors do not have to attend sessions if they don’t feel comfortable doing so. However, feedback from previous contributors and from the working group shows it’s useful for understanding the context of decisions and recommendations, and to have an opportunity to respond. 135 | 136 | If they are willing and able to attend, send them the calendar invite. 137 | 138 | Likewise, you can choose to attend the review session or not, but for similar reasons, it’s recommended that you do. 139 | 140 | 3. Go through the decisions and recommendations. 141 | 142 | The facilitator will send you the decisions and recommendations from the working group 1 week before the review session. You should book in some time to discuss these with the contributor. 143 | 144 | Check that they understand the feedback they’ve been given, and help them prepare any responses they might need or want to give during the session. 145 | 146 | ### During the session 147 | 148 | The facilitator will ask each representative to confirm their decision and talk through any recommendations they have made. 149 | 150 | Although decisions and recommendations are sent ahead of the session, representatives can change their decision based on comments from other representatives, or the contributor, if they want to. 151 | 152 | If both you and the contributor attend the session, let them speak for themselves as much as possible. If they are struggling, or it’s clear that they’ve forgotten something important, you can jump in, but ultimately you’re there to observe and support them, not to speak on their behalf. 153 | 154 | ### After the session 155 | 156 | Summarise recommendations 157 | 158 | Go through the session notes and write a summary of the recommendations. Do this by bullet-noting the recommendations under themed headings, for example, ‘Design’, ‘Code’, ‘Guidance’, ‘Research’. 159 | 160 | 1. Agree pre-publication steps 161 | 162 | Book a meeting to discuss these with the Design System team and decide what work should be done before publication. 163 | 164 | If the working group voted that the contribution can be published as it is, it’s up to you to decide which, if any, of the recommendations should be addressed before publication. 165 | 166 | If the group agreed that the contribution cannot be published until certain recommendations have been addressed, blocking recommendations must be dealt with before publication. 167 | 168 | After the meeting, sort the recommendations in your summary into ‘pre-publication’ and ‘post-publication’ and send to the facilitator within 1 week of the review session. 169 | 170 | ### Example summary 171 | --- 172 | 173 | Payment card details 174 | 175 | #### Guidance 176 | 177 | 178 | **Pre-publication:** 179 | 180 | - explain that the card logos help users trust the service 181 | - explain that showing all the logos helps users understand which cards are supported 182 | - describe the behaviour of the card lookup feature when JavaScript is not available 183 | 184 | **Post-publication:** 185 | 186 | - add information about the range of users, browsers and assistive technology that the pattern has been tested with 187 | - add accessibility criteria for the pattern 188 | - explain when and how to to let browsers autofill a user’s card details 189 | 190 | #### Design 191 | 192 | 193 | **Post-publication:** 194 | 195 | - consider more obvious ways of highlighting the chosen card logo 196 | - provide the card logo images to help people implement the pattern 197 | 198 | --- 199 | 200 | 2. Plan next steps with the contributor 201 | 202 | Share the recommendations with the contributor. Ask how much time can they dedicate to the work and where can we help out. 203 | 204 | Create issues on our sprint board to represent the work and incorporate it into sprint planning. 205 | 206 | ## 5. Prepare to publish the contribution 207 | 208 | Do the pre-publication work you’ve agreed. This might include some back and forth with the contributor. 209 | 210 | Contributions involving new or iterated styles or components will need a pull request on the GOV.UK Frontend repo. 211 | 212 | Contributions involving patterns or updated guidance will need a pull request on the Design System repo. Some contributions will need both. 213 | 214 | Ask the contributor to raise draft pull requests if they haven’t yet. If they are not comfortable in doing this, ask for permission to do it yourself (make sure you also ask if they would like to be named or anonymised). 215 | 216 | ## 6. Publish contribution 217 | 218 | When the contribution is ready, take the pull request out of draft and request a review from someone in the team who has not worked with the contributor. 219 | 220 | Once everyone's happy, you can merge the pull request. 221 | 222 | You might have to have to do a release to GOV.UK Frontend and then one to the GOV.UK Design System to publish the contribution. Keep the contributor updated while this is happening, and let them know as soon as it’s published. 223 | 224 | ### Let the community know 225 | 226 | Post an announcement in the #govuk-design-system channel on Cross Government Slack and #govuk-design-system channel on GDS Slack about the new contribution. 227 | 228 | For example, “We have a new contribution to the GOV.UK Design System! [NAME OF CONTRIBUTION] was contributed by [CONTRIBUTOR’S NAME] on [DATE], many thanks!”. 229 | -------------------------------------------------------------------------------- /docs/contribution_and_assurance/Individual contribution acceptance criteria template.md: -------------------------------------------------------------------------------- 1 | # Contribution acceptance criteria template 2 | 3 | This template is for the GOV.UK Design System team and contributors to record acceptance criteria for specific contributions. 4 | If you are running a design system, you are welcome to reuse it. 5 | 6 | You should adapt it to each contribution. 7 | 8 | ## Detailed criteria for [INSERT NAME OF CONTRIBUTION] 9 | 10 | All contributions to the Design System must meet the [Contribution criteria](https://design-system.service.gov.uk/community/contribution-criteria/). 11 | This document sets out the detailed acceptance criteria for [INSERT NAME OF CONTRIBUTION], to ensure it meets the overall contribution criteria. 12 | 13 | ### Code criteria 14 | 15 | The [INSERT NAME OF CONTRIBUTION] must: 16 | 17 | - be built using [GOV.UK Frontend](https://github.com/alphagov/govuk-frontend) 18 | - follow the [GOV.UK Frontend coding standards](https://github.com/alphagov/govuk-frontend/blob/master/CONTRIBUTING.md) 19 | - be tested with [these browsers](https://www.gov.uk/service-manual/technology/designing-for-different-browsers-and-devices#browsers-to-test-in) 20 | - be tested with [these assistive technologies](https://www.gov.uk/service-manual/technology/testing-with-assistive-technologies#what-to-test) 21 | 22 | You can develop a new component either in a fork of GOV.UK Frontend, or by using the [GOV.UK Prototype Kit](https://govuk-prototype-kit-beta.herokuapp.com/docs). 23 | 24 | ### Design criteria 25 | 26 | The [INSERT NAME OF CONTRIBUTION] must: 27 | 28 | - where possible, reuse elements from the [Design System](https://design-system.service.gov.uk/) 29 | - be operable with a keyboard 30 | - be usable on a small screen sizes 31 | - degrade gracefully if JavaScript is not available 32 | - handle cases where the user changes their default colours or font sizes 33 | 34 | ### Guidance criteria 35 | 36 | The [INSERT NAME OF CONTRIBUTION] guidance must: 37 | 38 | - follow the [GOV.UK Design System content pattern](https://github.com/alphagov/govuk-design-system-backlog/blob/master/docs/DESIGN_SYSTEM_CONTENT_PATTERN.md) 39 | - provide examples of common use cases 40 | - describe what research has been done and what still needs to be done 41 | - follow the [GOV.UK style guide](https://www.gov.uk/guidance/style-guide/a-to-z-of-gov-uk-style) 42 | 43 | ### Research criteria 44 | 45 | The contribution must have: 46 | 47 | - at least 3 different examples of the [INSERT NAME OF CONTRIBUTION] being used in services on GOV.UK 48 | - been tested with a representative range of users, including those with disabilities, in a prototype or live service 49 | 50 | -------------------------------------------------------------------------------- /docs/contribution_and_assurance/Working group email templates.md: -------------------------------------------------------------------------------- 1 | # Email templates for sending new proposals and contributions to the working group 2 | 3 | These templates are for the GOV.UK Design System team to send new proposals and contributions to the [Design System working group](https://design-system.service.gov.uk/community/design-system-working-group/), ahead of the monthly review sessions. 4 | 5 | If you are running a design system, you are welcome to reuse them. 6 | 7 | You should email new proposals and contributions to the working group one week before each review session. 8 | 9 | ## Email template for sending new proposals 10 | 11 | **Subject line: GOV.UK Design System proposal for review by [INSERT DEADLINE (this is one week before the review session)]** 12 | 13 | Hi everyone 14 | 15 | There are [X] new proposals to review ahead of the next review session on **[INSERT DATE]**. 16 | 17 | ## What to do now 18 | 19 | **Step 1:** 20 | 21 | Review each proposal in turn and decide if they are [useful and unique](https://design-system.service.gov.uk/community/contribution-criteria/#new-proposals). 22 | 23 | To help with your decision, speak to colleagues in your department and the wider government community. 24 | 25 | **Step 2:** 26 | 27 | Join the review session on **** to discuss your decisions with the other working group representatives. 28 | 29 | If you are unable to make the session, please let us know as soon as possible so we can arrange to get your response in advance. 30 | 31 | **Proposal #1 - [INSERT NAME OF PROPOSAL]** 32 | 33 | [INSERT NAME OF CONTRIBUTOR AND THEIR DEPARTMENT] has proposed a new [component / pattern], [INSERT NAME OF PROPOSAL AND LINK TO ISSUE]. 34 | 35 | **Proposal #2 - [INSERT NAME OF PROPOSAL]** 36 | 37 | [INSERT NAME OF CONTRIBUTOR AND THEIR DEPARTMENT] has proposed a new [component / pattern], [INSERT NAME OF PROPOSAL AND LINK TO ISSUE]. 38 | 39 | Best wishes, 40 | 41 | [INSERT YOUR NAME] 42 | 43 | GOV.UK Design System team 44 | 45 | ## Email template for sending contributions 46 | 47 | **Subject line: GOV.UK Design System contribution for review by [INSERT DEADLINE (this is one week before the review session)]** 48 | 49 | Hi everyone, 50 | 51 | Here is this month’s contribution to review ahead of the next review session on **[INSERT DATE]**. 52 | 53 | ### What to do now 54 | 55 | **Step 1:** 56 | 57 | Review the contribution and decide if it is usable, consistent and versatile as per the contribution criteria under '[Before a component or pattern is published](https://design-system.service.gov.uk/community/contribution-criteria/#before-a-component-or-pattern-is-published)'. 58 | 59 | To help with your decision, speak to colleagues in your department and the wider government community. 60 | 61 | **Step 2:** 62 | 63 | Send your decision and recommendations using this Google form. Make sure you send it by **[INSERT DEADLINE (this is one week before the review session)]**. 64 | 65 | **Step 3:** 66 | 67 | Join the review session on **[INSERT DATE]** to discuss your decisions with the other working group representatives and with the contributors. 68 | 69 | You’ll have the chance to revise your decision at the end of the session. 70 | 71 | If you are unable to make the session, please let us know as soon as possible. 72 | 73 | ### Contribution: 74 | 75 | [INSERT NAME OF CONTRIBUTOR AND THEIR DEPARTMENT] has contributed a new [component/pattern], [INSERT NAME OF PROPOSAL AND LINK TO THE PATTERN PREVIEW] (you can preview the pattern in the Design System from the link in the issue). 76 | 77 | _Include any additional information about the component or pattern that will help the working group representatives to review it here. If there are any aspects of the pattern that cannot be changed (for example, for legal reasons) state them here. Likewise, if there’s anything you’d particularly like feedback on, you can call it out here._ 78 | 79 | Best wishes, 80 | 81 | [INSERT YOUR NAME] 82 | GOV.UK Design System team 83 | -------------------------------------------------------------------------------- /docs/images/caroline-jarrett.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/alphagov/govuk-design-system-backlog/4a6d4b4754ceda3696938465badb1a72a5849d57/docs/images/caroline-jarrett.jpg -------------------------------------------------------------------------------- /docs/images/george-sheldrake.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/alphagov/govuk-design-system-backlog/4a6d4b4754ceda3696938465badb1a72a5849d57/docs/images/george-sheldrake.png --------------------------------------------------------------------------------