The NSW Design System helps people in government build distinctly NSW digital products and services.
Our Community is made up of varying levels of maturity, and anyone is welcome to contribute to our growing library of components. We appreciate all well intended contributions, so if you are unsure about anything, just ask us via the Digital NSW Community.
To be considered for inclusion in the Design System, components and patterns must be:
It addresses a user need that’s shared by multiple services or products.
|Unique||It doesn't duplicate something which already exists in the Design System, unless it's intended to replace it.
Components shouldn't duplicate the functionality of another component. We need to keep the system slim; the more components that are in the system, the harder it is to maintain and the possibility for code-bloat and technical debt is increased.
If a component is similar in function consider extending it rather than duplicating it.
Before new components and patterns are published into the Design System, the team of core contributors will review them to make sure that they are:
We would like NSW Government website users to feel like they are on a NSW Government website, to ensure this is the case all suggested components must be aligned to the distinctly NSW look and feel. Access the latest NSW Design System Figma UI kit.
It’s been tested and shown to work with a representative sample of users, including those with disabilities.
It uses existing styles and components in the design system where relevant.
Components that follow the system are much more themeable and reusable by other teams. New components must follow the system as closely as possible, particularly the specifics of colour, spacing, and typescale in ~/src/global/scss/settings/settings.scss.
It can be easily applied in different contexts.
|Coded||Components are ready to merge in.
Code is for humans: Please look at our coding style and work with it, not against it. We add spacing, and prefer readable code over clever code. Yes, code is actually for computers, but it is humans that need to maintain it.
Code comments: Our stance on commenting code is that we encourage code to be cleanly and logically written to minimize the need to comment. Sensible and clear naming of functions and variables would also help readability without the need for excess comments.
Follow the folder structure: New components should follow the same folder structure as the existing components.
CSS can be dependent on other components, but must use core functions and mixins at a minimum.
PS: Don't forget to remove your debugging! :)
|Tested||It's been tested and shown to work with a range of browsers, assistive technologies and devices.
Accessibility: A component on its own must be accessible to WCAG 2.1 level AA. Some documentation on how this has been checked, tested, or decisions made to support accessibility should be supplied.
Browser and device tested: All components should meet our browser support requirements.
Documentation and rationale have been provided. Include a high-level description for what the pattern is, and what it’s for.
We aim to explain design and code decisions as openly as possible. Explanations about why decisions have been made help others understand the work involved but also help them understand the consequences of overriding.
This Contribution Guide is adapted from: