How might we best demonstrate our level of confidence in new or adapted components within MTS and the DVSA design system?
We know that some components may be best replaced by more recent GDS components with a greater weight of research and breadth of use. Also, there are a number of components where we have a degree of confidence that they are serving a genuine user need that could not be wholly fulfilled by an existing component within the GDS design system. This confidence will vary depending on the research we have carried out, and their ubiquity of use elsewhere (other GDS services, de facto standards elsewhere on the internet).
In all cases, it would be useful to be able to illustrate and track that confidence in order that we can more efficiently target future research and/or feed back to the GDS community backlog.
There are a few thoughts about how to achieve this; largely within the design system itself. I would suggest that each custom MTS component or pattern should have an issue against it where we can share findings and discussion; also enabling it to be open to the wider community.
What are your thoughts? @rafaldrewnowski @MartinDM @campbellm104
Examples:
Recent blog post by Eliot Hill (https://hodigital.blog.gov.uk/2018/09/07/documenting-design/)
HMCTS labels e.g. [Experimental]: (http://hmcts-design-system.herokuapp.com/components/timeline)
HMCTS backlog: (https://github.com/hmcts/design-system-backlog/issues)
How might we best demonstrate our level of confidence in new or adapted components within MTS and the DVSA design system?
We know that some components may be best replaced by more recent GDS components with a greater weight of research and breadth of use. Also, there are a number of components where we have a degree of confidence that they are serving a genuine user need that could not be wholly fulfilled by an existing component within the GDS design system. This confidence will vary depending on the research we have carried out, and their ubiquity of use elsewhere (other GDS services, de facto standards elsewhere on the internet).
In all cases, it would be useful to be able to illustrate and track that confidence in order that we can more efficiently target future research and/or feed back to the GDS community backlog.
There are a few thoughts about how to achieve this; largely within the design system itself. I would suggest that each custom MTS component or pattern should have an issue against it where we can share findings and discussion; also enabling it to be open to the wider community.
What are your thoughts? @rafaldrewnowski @MartinDM @campbellm104
Examples:
Recent blog post by Eliot Hill (https://hodigital.blog.gov.uk/2018/09/07/documenting-design/)
HMCTS labels e.g. [Experimental]: (http://hmcts-design-system.herokuapp.com/components/timeline)
HMCTS backlog: (https://github.com/hmcts/design-system-backlog/issues)