All work
Product conceptAI agentCybersecurity2026

Guardian — from security alerts to resolved problems

An AI security agent that doesn't stop at the alert. It explains the risk, guides the fix and verifies the result.

Open the prototype

My role Product & UX/UI designer, concept to prototype
Team Solo, self-initiated concept (all prototype data is fictional)
Timeline 1 week, 2026
Platform Desktop, mobile and browser extension

At a glance

01 Problem

Security tools detect problems well, then leave people alone with the warning

GoalMove people from "I got an alert" to "it is fixed and I can see it".

Challenge

How do you turn a stream of technical security alerts into something an ordinary person understands, acts on and trusts, without fear tactics and without the system taking control away from them?

Outcome

Designed and clickable end to end: alert, explanation, guided fix, verified result. Real-world effect is not measured yet; the validation plan defines how.

Business Protection is invisible when nothing goes wrong, so people ask at renewal what they are paying for
Usability Alerts use jargon and leave people to work out the fix across several apps and sites
Engineering Signals live in separate products, so five protection layers must collapse into one status

Security products detect problems well, but each signal lives in a separate product with its own alerts and language. Users are told something is wrong, then work out the fix alone across several apps. Even when protection works, its value stays invisible.

02 Users

Built for ordinary people who get a breach alert and don't know what to do next.

E
Everyday user Gets a breach alert and doesn't know what to do next.
Business Wants proof the subscription is worth keeping
Usability Needs plain words and one next step, not a technical notice
Tech Uses several devices and apps, with passwords reused across accounts
H
Household helper The family member who ends up fixing everyone's security.
Business one person sees and helps with the household
Usability Wants a household overview and a way to help remotely
Tech Later phase; not part of the MVP
P
Partner product team A security, password or fraud product that already has the signals.
Business Retention at renewal, cross-sell and engagement
Usability A layer inside the existing app, not another app
Tech Reuses signals the company already detects

Deliberately out of scope New detection technology, silent changes to accounts, and any paywall in front of a warning.

03 Research

Starting from three assumptions, to be tested with real people.

Public product review Business need Accessibility review User needs

Desk research and public product information, plus an accessibility review. User interviews, a prototype test and a pilot are planned, not yet run.

  1. Assumption: alerts end where the work begins People get a warning but no guidance on fixing it across apps
  2. Assumption: panic produces bad decisions Urgency must come from hierarchy and plain language, not red screens
  3. Assumption: invisible protection is not renewed Showing what improved gives a reason to keep paying

04 Process

One product model: detect, explain, fix, verify, prevent.

01 Product model 1 day
02 MVP & information architecture 1 day
03 Interaction & visual design 3 days
04 Prototype & accessibility review 3 days
05 Pitch deck 1 day
Product & strategy me, Ai-assisted UX & UI design me Prototype me, AI-assisted Pitch me
Today: from alert to fix
5 steps
  1. 01 Alert arrives GoalKnow something is wrong FrictionTechnical wording, no explanation
  2. 02 Work out what it means GoalUnderstand the risk FrictionJargon, so people search the web
  3. 03 Find the right place GoalReach the change-password page FrictionSeveral apps and websites
  4. 04 Fix it alone GoalChange the password FrictionReused passwords stay unchanged
  5. 05 No confirmation GoalKnow it worked FrictionThe value of protection stays invisible

Detection works. Everything after it is left to the user.

With Guardian
5 steps
  1. 01 Open GoalScore is 78, three issues need attention
  2. 02 Alert GoalAdobe credentials were exposed in a breach
  3. 03 Understand GoalGuardian explains why reuse makes it risky
  4. 04 Resolve GoalNew password, reused ones replaced, 2FA on
  5. 05 Result GoalVerified, and the score rises to 91

The user confirms every change.

Guided fix
5 steps
  1. 01 Generate GoalA strong, unique password is created
  2. 02 Open GoalGuardian opens the exact change-password page
  3. 03 Fill GoalThe browser extension fills in old and new passwords
  4. 04 Confirm GoalYou press Save. Nothing changes without you
  5. 05 Verify GoalGuardian checks the password is unique and not breached

Confirm is the one step Guardian never does for you.

Product model
Product model The loop every incident goes through, from detection to prevention.
Signal map
Signal map Five protection layers collapse into one score.
Trust model
Trust model What Guardian does alone, what it asks first, what it always logs.
Information architecture
Information architecture Five sections and a persistent Ask Guardian entry point; mobile keeps the same structure.
MVP scope
MVP scope One complete journey first; the rest is phased.

05 Decisions

Trust came first: nothing changes without the user.

  • Nothing changes without the user Silent account changes break trust, and trust is the product CostSlower than full automation: one extra tap
  • The warning is never behind a paywall Someone whose password leaked must learn it for free CostLess revenue from alerts; paid value moves to resolution
  • A layer inside an existing app, not a new app A separate app would add to the fragmentation it exists to reduce CostDepends on a host product to launch
  • Five layers, one score, one next step Nobody acts on five dashboards CostDetail moves one level down (Feed, Identity)

06 Solution

One score, one next step, and a visible result.

  • Calm, not alarming: urgency through hierarchy and plain language, not red
  • screens
  • Human language first: say what it means, not the jargon
  • Action over information: one obvious next step per screen
  • Visible progress: show what changed after the user acts
  • Permission clarity: the user confirms every change
scroll
Alerts end where the work begins
An alert that explains itself

Instead of a breach notice, Guardian says what was exposed, why it matters (the same password protects two other accounts) and what fixing it involves, before asking for anything.

scroll
The user stays in control
Incident

A strong, unique password is generated and the change is prepared, but the user presses Save. Every account reusing the password is listed and updated one by one.

scroll
Invisible protection is not renewed
The result is visible

The score rises from 78 to 91 and every change is listed, so the user knows exactly what improved.

scroll
Panic produces bad decisions
Prioritised and transparent

A feed ordered by impact instead of a list of alerts, and a log of everything Guardian did and why, so nothing happens off the record.

scroll
Prevent
Stopping the next incident

The browser extension steps in before credentials are typed. It shows the expected and visited domain side by side and highlights the single swapped letter.

Before
After
Before After

Home before and after one guided fix: score 78 to 91 (prototype scenario).

07 Results

A complete journey, designed and clickable; real numbers come from the pilot.

78 → 91 Safety score after one guided fix prototype scenario, fictional data
3 surfaces Desktop, mobile and browser extension all clickable
What I learned
  • Trust belongs in the product, not in a settings page: the permission model is part of the interface.
  • A product that exists to reduce fragmentation cannot be another standalone app.