|
| 1 | +--- |
| 2 | +title: Breast screening - our first prototype |
| 3 | +description: Exploring the first design of our user interface |
| 4 | +date: 2025-06-11 |
| 5 | +author: Kieron Bradshaw |
| 6 | +tags: |
| 7 | + - prototype |
| 8 | + - alpha |
| 9 | + - cohort manager breast screening |
| 10 | +--- |
| 11 | + |
| 12 | +Cohort manager is being developed to help identify, receive and correct the demographic details for eligible participants of a screening service, so they are correctly selected for invitation. It's initially being built for use with the breast screening programme, with the intent that it will be available for use by any screening programme in the future. |
| 13 | + |
| 14 | +Please note that this post provides the early design of our user interface. We'll be sharing updated versions soon and exploring how it has been developed to align with changes in our user group and the tasks they will complete. |
| 15 | + |
| 16 | +## Improving the quality of screening data |
| 17 | + |
| 18 | +To begin, imagine a person whose NHS record has been selected as being eligible for routine breast screening. |
| 19 | + |
| 20 | +If their record contains even small errors or missing information, a data exception will be generated, meaning their screening invitation could be delayed while staff work hard to manually investigate and fix the problem. |
| 21 | + |
| 22 | +To support this process and ensure that errors are picked up early and quickly resolved, cohort manager will apply a series of validation rules to each record entering the screening pathway. |
| 23 | + |
| 24 | +It automatically identifies invalid or missing information (data exceptions) and can resolve many data issues, such as transformations, without staff intervention. |
| 25 | + |
| 26 | +For cases that need manual intervention by staff, the system provides an interface that visualises the data exception and enables users to quickly direct it to the appropriate team for resolution. |
| 27 | + |
| 28 | +## Our first design of the user interface |
| 29 | + |
| 30 | +Our first prototype was based on our understanding of the work of participant index (PI) bureau colleagues. This is the team that manages data quality for routine breast screening cohorts in existing live systems. |
| 31 | + |
| 32 | +Although the specific staff group using the interface has changed since this first design, its purpose was the same: to enable users to view any data exceptions that require manual intervention. |
| 33 | + |
| 34 | +The long-term ambition is for cohort manager to raise all exceptions with the appropriate teams automatically. As the user interface is only intended to be an interim solution, decisions made around meeting each user need have been balanced against the time and resource it would take to build functionality. |
| 35 | + |
| 36 | +Throughout this section we'll explore each screen of our initial prototype. |
| 37 | + |
| 38 | +### Overview screen |
| 39 | + |
| 40 | + |
| 41 | + |
| 42 | +This is the first screen that a user sees when they log into cohort manager. It uses the [card component](https://service-manual.nhs.uk/design-system/components/card) to provide a simple overview of data exceptions that require manual intervention. |
| 43 | + |
| 44 | +Our hope was that this component would provide structure for the landing page whilst also serving as a dashboard. Each card is configured to display the number of outstanding exceptions for a particular category and provides users with a snapshot of tasks to help prioritise their workload. The user can click each one to navigate to more detail. |
| 45 | + |
| 46 | +### Summary screen |
| 47 | + |
| 48 | + |
| 49 | + |
| 50 | +Depending on which card the user clicks on the previous screen, they will be taken to a summary screen that provides a quick view of all open exceptions for that category. |
| 51 | + |
| 52 | +The intention is that by presenting the information in a [basic table](https://service-manual.nhs.uk/design-system/components/table), it's easier for users to compare and scan the data when prioritising their tasks. |
| 53 | + |
| 54 | +Other key design components included on the summary page are: |
| 55 | + |
| 56 | +#### Snapshots of key information for each exception |
| 57 | + |
| 58 | +From our research with users, we knew that information they looked for to help prioritise and carry out their tasks effectively were: |
| 59 | + |
| 60 | +* the participant's NHS number |
| 61 | +* the date the exception was created |
| 62 | +* a short description of the problem |
| 63 | + |
| 64 | +#### Unique identifier for each exception |
| 65 | + |
| 66 | +Each exception has a unique ID. We used this as the point of navigation for the user to find more detail about an exception. |
| 67 | + |
| 68 | +### Participant details screen |
| 69 | + |
| 70 | +Please note: the data shown in the image below is for demonstration purposes and is not a real person. |
| 71 | + |
| 72 | + |
| 73 | + |
| 74 | +This is our final screen, where we provide more detail about each data exception. |
| 75 | + |
| 76 | +In our initial design, this information intended to support the participant index (PI) bureau user to understand the problem with the record, whilst providing enough data about the participant to support any investigation needed to correct it. |
| 77 | + |
| 78 | +The level of detail included was based on our research with this user group. We needed to find the right balance between: |
| 79 | + |
| 80 | +* ensuring the user had enough detail to carry out their task |
| 81 | +* avoiding overloading them with information |
| 82 | +* preventing information governance issues that may arise from revealing more personal data than is needed for a task |
| 83 | + |
| 84 | +To keep the layout simple, we used a summary list to pair related information and used [tabs](https://service-manual.nhs.uk/design-system/components/tabs) to separate the participant data from the details of the exception that has occurred. Our intention was to structure the information in a way that places the least strain possible on the user. |
| 85 | + |
| 86 | +## Next steps |
| 87 | + |
| 88 | +Our prototype is constantly improving as we test it with users, and we will highlight other useful information about the development of the interface in future posts. |
0 commit comments