|
| 1 | +--- |
| 2 | +title: Rule library version 2 |
| 3 | +description: Improving our rule library to make it easier to add rules |
| 4 | +date: 2025-11-12 |
| 5 | +tags: |
| 6 | + - users |
| 7 | + - service design |
| 8 | + - rules |
| 9 | + - user research |
| 10 | +--- |
| 11 | + |
| 12 | +Our initial way to add rules was through a rule builder form, which required a high degree of technical understanding. Our first version of [rule library](/select-people-for-invitation/2025/03/rule-library/) was a way of pre-populating that form with certain values to make the process easier for users. |
| 13 | + |
| 14 | +Our [research](/add-link/) showed this was a big step forward in making it easier for users to add commonly used rules, however there was still a lot of scope for improvement. We anticipated this might be the case as the first rule library implementation was very much a minimum viable product approach - we wanted to add value quickly and learn more about the way users interact with the system. |
| 15 | + |
| 16 | +## The problems we wanted to fix |
| 17 | + |
| 18 | +- Having some parts of the form pre-populated was useful, but where values needed to be changed it was still fiddly to use |
| 19 | +- There was some risk of not updating the right parts |
| 20 | +- Users still didn't feel that the form was as simple or intuitive as it could be |
| 21 | + |
| 22 | +## Our approach |
| 23 | + |
| 24 | +- We reviewed the list of rules that were in the library and categorised them |
| 25 | +- They fell broadly into 4 types of rule: |
| 26 | + - **Text:** Rules that require a parameter configuring as text e.g. exclude people under a certain age (age is the text parameter) |
| 27 | + - **Text and date:** Rules that require a text parameter and a date parameter, e.g. exclude people under a certain ago on a particular date |
| 28 | + - **Pick list:** Rules that require one or more parameters to be selected from a list of options, e.g. exclude people who are not registered to a GP within certain ICBs |
| 29 | + - **Radios** Rules that require a single selection from a group of options, e.g. exclude people living in care homes (yes / no) |
| 30 | + |
| 31 | +We designed a template for each type of rule, which means the user interface is tailored to the rule type. Therefore the interaction is much simpler, quicker and safer for users. |
| 32 | + |
| 33 | +This image shows the old screen for excluding care home residents |
| 34 | + |
| 35 | +[](rule-library2.png) |
| 36 | + |
| 37 | +This image shows the new screen, which as can be seen is very much simpler to use and easier to understand. |
| 38 | + |
| 39 | +[](rule-library3.png) |
| 40 | + |
| 41 | +## Feedback |
| 42 | + |
| 43 | +Initial user feedback has been very positive. Users find these new tailored rule pages much simpler and easier to use than the old way of all rules using the same generic form. |
| 44 | + |
| 45 | +## Next steps |
| 46 | + |
| 47 | +The dev work to roll this out is ongoing and we're continuing to review the types of rules that are being used in live campaigns. The library caters for the commonly used rules, but for more unusual ones the old rule builder form is still required. We've begun to refer to this as the "custom rule builder" and made the rule library the default way to add rules. Access to the "custom rule builder" is restricted to a certain user role, so if we onboard new users to SPI we can prevent them adding any type of rule which isn't in the library - which makes the service a bit safer for new users. |
| 48 | + |
| 49 | + |
| 50 | +A note on the technical implementation: every rule which follows the same template uses the same underlying code, but configured through customised parameters. Meaning we ensure a consistent approach and we don't have to maintain many versions of a radio button rule page for each individual rule which uses that pattern. |
| 51 | + |
| 52 | + |
| 53 | + |
| 54 | + |
| 55 | + |
| 56 | + |
0 commit comments