Proposing a component or pattern
To be successful, proposals need to show that the component or pattern being suggested would be useful and unique.
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.
It does not replicate something already in the Design System. If it’s intended to replace an existing component or pattern, there is evidence to show that it’s better than the existing version.
Proposals that meet the criteria will then be marked ‘to do’, ready to be worked on.
Developing a component or pattern
Before a new component or pattern is published the working group reviews the implementation to make sure it is usable, consistent and versatile.
It has been tested 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.
It reuses existing styles and components in the Design System where relevant. Both the guidance and any content included in examples must follow the Hopin Styleguide. If there is code, it follows the Hopin coding guidelines and is ready to merge in Hopin Frontend.
The implementation is versatile enough that the 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 browser and assistive technology