A design response to a research finding
Designing a warning people can obey
A study of how technical people talk about security warnings found that most click-throughs are not careless. The warning has no answer anyone can give. This is the redesign: seven principles traced to that evidence, five situations the browser can already tell apart, a component built to ship, and the study that would show whether it works.
- Research synthesis
- Interaction design
- UX writing
- Front-end build
- Accessibility
- Evaluation design
01 · The finding
The warning has one meaning. The situation has another.
In clicked-through I coded 76 items from Hacker News threads about security warnings. I expected people who understood the risk and proceeded anyway. That was the smallest thing in the corpus. What dominated was people meeting a warning that could not be obeyed.
A browser says a certificate can't be trusted while you are connecting to a printer on your own network. There is no certificate that printer could get that the browser would accept. The only answer the warning allows is to go back, and going back means not doing your job. So people proceed, every day, and learn that the warning means nothing. The one time it does mean something, it looks exactly the same.
your users will inevitably learn to ignore certificate errorsitem 36507168 · habituation-by-design
The study stopped at the finding. This project asks what the interface should do instead.
02 · Where attention goes
Stop is kept for the case that means it
Today every one of these situations gets the same full-page stop. The browser already knows enough to tell them apart: whether the address is private, whether you've been here before, whether the certificate changed, who issued it. The redesign uses that to spend attention where it carries information. It is quieter in five of these eight states. Where a trusted certificate has changed it stays a stop and loses the proceed button, because that is the moment an attack would look like. And for phishing it moves the warning from the click to the password.
| Situation | Today | Redesign | Why |
|---|
Generated from classify.js running on the scenario fixtures, so this table can't disagree with the prototypes.
03 · Side by side
Same situation, two warnings
These are the live component, not screenshots. Every button works, and the full interactive versions with every state are in the prototypes.
04 · Principles
Seven principles, each resting on coded evidence
Each principle cites the items it comes from. A script checks that every cited item exists, carries the code claimed, and contains the quoted words verbatim, so a principle can't quietly outgrow its evidence.
05 · Decisions
What I chose, and what I rejected
- Rejected
Adding friction to the proceed link. It is the usual response to click-through, and the corpus records what it produces: when the compliant path doesn't exist, people build structural workarounds that are worse than clicking through.
- Chose
Friction only where it carries information. After a trusted certificate changes, the way forward asks for four characters printed on the device itself. It is a check only someone with the device in front of them can pass.
- Chose
Remembering trust per certificate, not per host. That is what makes silence on later visits safe rather than merely quiet.
- Rejected
Quietening renewals the browser can't distinguish from an attack. A server that makes a new key every six months still stops people. The report to its owner says why, because the fix is theirs.
- Chose
Never the word “secure”. A device you trusted by hand shows “Trusted by you on 3 March”, never a padlock, so making the indicator go away can't become the goal.
06 · Built to ship
One component, one function that decides
Most of this design is behaviour across visits: what happens the second time, what happens after a change. A static frame can't show that, so the design medium is code. The logic lives in one pure function, classify(), where every branch names the principle it implements, and the tests are the specification.
The <trust-warning> component carries severity in shape, label and words as well as colour, moves focus to the heading on every change of view, and never lets Escape mean proceed. It has no dependencies, no build step and makes no network requests.
- Prototypes
Five situations, every state
Today and the redesign, step by step, with the principle behind each state.
- Component
<trust-warning> docs
Anatomy, severity, states, API, copy rules and accessibility notes.
- UX writing
Every word, in one file
The copy and the rules it is held to. Tests fail if a string says “secure”.
07 · How it would be tested
The study, designed and not yet run
Instrument built · no participants yet
Nothing here is evidence that the redesign works. The test harness runs a counterbalanced comparison in the browser: four tasks, each shown as today or the redesign, recording the decision, time to decide, confidence, and an answer to “what do you think is happening?”. Data stays in the browser until exported.
The hypothesis I most want held to account is the one that could embarrass the design. For the printer, the redesign should not lower the rate at which people proceed. It is meant to make a reasonable decision easy, not to deter it. If it lowers that rate, it is working as friction, and the whole argument above says friction is the wrong tool.
08 · Limits
What this doesn't claim
The evidence comes from one technical, English-speaking forum, and the redesign makes no claim about non-technical users. The changed-certificate case is the design's strongest move and its thinnest evidence: the corpus argues for it but never shows someone meeting it. Recognising inspection products needs a maintained list nobody has built here. Public sites with invalid certificates are deliberately left exactly as they are.