ClearScore · Digital protection
ClearScore Protect: making digital protection clearer and more actionable
Consumer digital protection · Free and paid experience
ClearScore Protect combines monitoring, breach information and routes to support. Customers needed a clearer understanding of what the service monitored, what an exposure meant and what they could do next. As sole designer, I owned the core experience redesign from discovery through delivery. My scope included the main product surfaces, breach flows and paywall, working with Product, Engineering, Research, Content and specialists. The core redesign reached full rollout on 29 June 2026 across five markets and Web, iOS and Android.
Role
Product Designer · Sole designer from discovery through delivery
Scope
Core experience, monitoring information, breach flows and paywall
Timeline
H1 2026

Protect V2 overview from the H1 2026 design review.
01 /
Challenge
Make protection understandable and useful
Protect had fallen behind the wider ClearScore experience. Its value, the information it monitored and the distinction between Free and paid were difficult to understand.
Repeated breach information added complexity without always providing useful guidance. The experience needed to communicate risk with proportionate urgency while giving customers a practical understanding of the service.
I worked within Protect’s existing breach-data and service capabilities. The design challenge was to make those capabilities clearer across different customer states, markets and platforms.

Previous and redesigned Protect overviews, showing changes to hierarchy and the presentation of monitoring and breach information.
02 /
Research
Establish what customers value
I started by tearing down the existing product and mapping its key journeys. This helped me identify where information was missing, where the experience became repetitive and where customers needed more guidance.
I used those initial pain points to focus user research and testing on how people understood Protect; what they believed the service was doing, what they thought it covered and how they interpreted its alerts.
Together, the teardown, journey mapping and research identified five problems the redesign needed to address:
Activity: Is Protect doing anything?
Timing: When is scanning happening?
Coverage: What is currently being monitored?
Priority: Which alerts are important?
Differentiation: Why do all the alerts look the same?
These problems pointed to a gap between the service’s capabilities and what the interface communicated. Monitoring activity was difficult to see, coverage was unclear, and alerts gave people too little help deciding where to direct their attention.
That became the focus of the redesign: make the service’s activity visible, show what it covered and give updates a clearer sense of significance.
03 /
Design decisions
Make monitoring visible
Expose the monitoring scope
To address uncertainty about whether Protect was working and when scanning happened, I made the last and next scan times visible in the overview design.
This gave customers a concrete indication of activity and a reference for when the next check would happen.
I also brought primary and additional email addresses into one section. Customers could inspect the information included in monitoring from a single place.
Together, these changes connected three questions - whether Protect was active, when it scanned and what it monitored - to information people could find in the interface.

Primary and additional email addresses grouped in one section, making the scope of monitoring available to inspect.
Group related exposures, preserve context
The research also highlighted how difficult it was to distinguish between alerts that looked similar.
I considered a full event feed, a hybrid preview and an aggregated model. I chose aggregation to organise repeated exposures into grouped updates.
Repeated exposures increased the grouped update’s count, while sources and context remained available in the detail view.
The tradeoff was deliberate: less event history was visible at a glance, in exchange for a more manageable overview and a scalable route towards useful next steps.
Grouping simplified the overview while preserving the detail needed to understand what sat behind an update.

Repeated exposures grouped into an update, with sources and context retained in the detail view.
Make urgency proportionate
Helping customers identify important alerts required a clearer expression of priority.
I designed around team rules combining potential financial impact and recency. Those rules informed how urgency was communicated, giving updates a more meaningful hierarchy.
The aim was to help people understand which information deserved their attention while reducing repetitive alarm around similar exposures.
04 /
Delivery
Carry the decisions through the complete experience
I carried these decisions through the core product surfaces, breach flows and paywall, partnering with Product, Engineering, Research, Content and specialists. The work connected monitoring activity, coverage, grouped updates and next steps across the Free and paid experience, spanning five markets and three platforms.
05 /
Outcomes
Core rollout and early commercial signals
The core redesign reached full rollout on 29 June 2026 across the UK, Canada, Australia, South Africa and New Zealand, on Web, iOS and Android.
Programme reporting also showed positive early commercial signals.
+8.7%
MRR
+39%
Monthly subscriptions
+9%
M1 retention
These figures reflect programme-level performance.
The early retention cohorts were still maturing. Longer follow-up was needed to understand whether the encouraging signals translated into sustained performance.
06 /
Reflections
Test entry conditions as part of the experience
The verified-email issue made the delivery lesson concrete: a coherent experience depends on the relationship between a message, the customer’s state and the action available to them.
In a future redesign, I would map those conditions earlier—particularly verification status, Free versus paid access, and breach versus no-breach states.
Reviewing those conditions alongside the screens would make it easier to identify journeys that appear complete visually but break when a customer tries to act.