-
Notifications
You must be signed in to change notification settings - Fork 4
Design system user needs
Dave Hunter edited this page Nov 21, 2023
·
1 revision
# | User | Need | |
---|---|---|---|
0.1 | As someone developing an NHS service, I need... | To work efficiently | |
0.2 | To know the best way to solve a design problem | ||
0.3 | To know what standard the design must meet | ||
1.1 | As someone using a design resource, I need... | It to contain the things I need to design the service I’m working on | Styles, components and patterns to be assured so that they meet the need of users |
1.2 | Regular contributions to the design system from the community | ||
1.3 | Regular contributions to the design system from the design system team | ||
2.1 | It to be well maintained and supported | To get helpful, responses to any queries, issues and pull requests I make | |
2.2 | For any bugs or issues to be dealt with promptly | ||
3.1 | It to be easy to implement in my prototype or service | To be able to use the design system with my preferred device, browser or assistive technology | |
3.2 | To see coded examples of the main use cases for each style, component or pattern | ||
3.3 | To be easily able to copy an example straight to my prototype | ||
3.4 | To be able to easily update a prototype or service to the latest version of a style or component | ||
3.5 | To be able to adapt the design system for NHS services that are not on nhs.uk | ||
4.1 | It’d be based on research and best practice | The team to include a dedicated user researcher for developing components and patterns | |
4.2 | Components and patterns to be user tested before being published | ||
4.3 | Components and patterns to be tested across a range of devices, browsers and assistive technology | ||
4.4 | To understand the user needs of the component or pattern | ||
5.1 | To know if any parts are optional or can be changed | To know whether my service should look like an NHS service or not | |
5.2 | To know when I should or should not use a specific style, component or pattern | ||
5.3 | To know under what circumstances I can iterate a style, component or pattern | ||
5.4 | To know how up-to-date the styles, components and patterns in my service need to be | ||
6.1 | To know what exists | To learn about the design system when I start my job (inductions, training…) | |
6.2 | To find out about the design system via work channels I use (Slack, Twitter, email…) | ||
7.1 | To trust it enough to use it | To know what the design system is, who it’s for and what the benefits of using it are for | |
7.2 | To see a summary of the research and testing behind each style, component or pattern | ||
7.3 | To see a history of the change made to a style, component or pattern, and why they were made | ||
7.4 | To see that’s it well maintained, well supported and up-to-date | ||
8.1 | To be allowed to use it | The design system must not be blocked from departmental networks or devices | |
8.2 | I can explain the benefits to users and the nhs of implementing a specific component or pattern | ||
9.1 | To know when something is updated or added to it | To get updates about the design system via the work channels I use (Slack, Twitter, email…) | |
9.2 | To know if a specific style, component or patterns on our backlog and when it might be ready | ||
9.3 | To know when a specific style, component or pattern is added or updated | ||
10.1 | To be able to easily find what I’m looking for in it | To be able to find all the styles, components, patterns and guidance I need in one place | |
10.2 | A consistent taxonomy, optimised for primary users of the design system | ||
10.3 | To be able to search for things using my own terminology | ||
10.4 | To be able to browse the design system by theme and hierarchy |