Staff safety system
Safety information that changed with responsibility
The organisation needed to surface known risks before staff contact while managing the incidents, approvals and reviews behind each alert. As the sole Product Designer, I designed the connected CRM and case-management experience across roles and carried it through testing and build. Internally, the case-management product was known as the Caution Register.
Role
Period
Design and UAT alongside CRM
Team
Scope
The incident view brought the case, safety context and supporting information together before the next decision.
The situation
One safety process had to support different roles and permissions
The CRM was the system of record for people and addresses. The staff safety system sat alongside it, holding only flagged records and the workflow behind each alert.
Managers submitted incidents, Heads of Service made approval decisions, Directors reviewed appeals, and Directors’ personal assistants supported the process. I worked alongside the Business Analyst and service to translate the operating rules and permissions into a connected product, surfacing gaps as they had to work screen by screen.
Decision 01
Person and address lookup started in the system of record
Out of the box, the staff safety system let staff search directly for a person or address. I removed it. Because the system held only records already flagged, a failed search could look like evidence that no risk existed.
No result was not the same as no risk.
I routed lookup through CRM, where a caution surfaced on the authoritative record. The route was less direct, but the result was safer to interpret.
Direct search was reinstated after pushback because it felt faster. Once I explained how absence from a partial dataset could create false reassurance, the concern was understood and it was removed again. Search by known case or flag reference remained because the user already knew a record existed.
The caution surfaced on the authoritative CRM record, so staff could see the safety signal in context before opening the deeper case.
Decision 02
The workflow followed responsibility, not platform mechanics
The low-code platform exposed its own workflow mechanics: stages in an unintuitive order, progress and regress controls, and system states users had to interpret. I replaced that with a chronological task model showing what had happened, what was pending and what could happen next. When responsibility passed to a Head of Service, the decision action appeared for them; managers could see the same stage without being able to act.
The same principle continued across both products. Frontline staff saw enough safety information to act without access to the underlying case; managers and senior roles could access progressively deeper detail and actions. I translated the permission rules into connected journeys, surfacing edge cases as the screens made them concrete.
Before
After
The redesigned task list exposed sequence, status and responsibility; actions appeared only for the role responsible for the next step.
Decision 03
Competing review models made the policy choices concrete
When cases came up for periodic review, multiple incidents and services created consequential choices: should the decision consider one incident or a wider history, who should own it when several services were involved, and what could legitimately change? I modelled competing approaches in prototypes so stakeholders could see the consequences before choosing between them.
I separated the record of what had happened from the safeguards staff should follow. A review could adjust those safeguards as circumstances changed, but adding a new risk to the record required a new incident. Later work on the review process returned to these prototypes and the logic they contained.
Review model A
Review model B
The prototypes made competing review rules visible, so stakeholders could compare consequences before committing to a model.
Delivery
Role-based testing continued into the build
Nine participants worked through realistic scenarios across four roles: managers, Heads of Service, a Director and two Directors’ personal assistants. Testing changed notifications, labels, default sorting and workflow behaviour.
“You have taken a very complicated process and made it very simple and straightforward.”
Head of Service, during user testing
During UAT I checked the low-code build against the intended interaction model and GDS-based standards. I identified issues in role visibility, state, navigation, interaction behaviour, including regressions. I then retested fixes with the external developer.
UAT · Director role
UAT checked the built product against role, state and interaction logic, not just visual fidelity.
Outcome
The connected model reached live use
The connected CRM and staff safety model was implemented, including cautions surfaced directly on person and property records in CRM, with role-aware workflows behind them.
with an initial frontline team in April 2025
and expanded to more services in December 2025.
View next case study