Proving a testimonial without asking anyone to trust me

The problem

A published testimonial is worth exactly what its verification is worth, and most sites verify nothing. A quote with a name and a job title under it is indistinguishable from a quote I wrote myself, and a reader has no way to tell the difference. That is a problem for the reader, but it is a worse problem for a genuine referee, whose real words are devalued by sitting next to unverifiable ones.

Why it mattered

This is a one-person consultancy. Almost everything a prospective client can check about it is something I have said about myself. Testimonials are one of the few places where somebody else speaks, so they are exactly where an unverifiable claim does the most damage: if the reader concludes the quotes might be invented, they reasonably extend that doubt to the rest of the site.

What I looked at

The obvious framing is "add a verified tick", and the obvious framing is where this goes wrong. Once you start designing it, the question stops being how to confirm an identity and becomes what a confirmed identity is allowed to mean.

Two things happen to a submitted testimonial. Someone confirms they are who they say they are, and someone decides whether the testimonial gets published. Those are different decisions, made by different people, for different reasons. A referee confirming their identity has not approved anything; a moderator approving a testimonial has not verified anyone.

The options

• Publish unverified, with a disclaimer. Honest and cheap. Rejected because a disclaimer transfers the problem to the reader rather than solving it, and nobody reads it.
• One verification state, driving publication. Verified testimonials go live; unverified ones do not. Simple, and wrong: it makes identity confirmation into an editorial decision, so a referee who signs in has effectively published themselves, and a moderator's judgement disappears.
• Two independent records: verification and moderation. More storage and more states to reason about, and it means the moderation view has to show both without implying either follows from the other.

What I chose, and why

Two records, kept separate, with neither able to imply the other. Verification never approves, never publishes and never changes moderation state. It is recorded against the testimonial as its own fact, and the moderator still decides.

There are two levels, and only one of them is public. An email link confirms the referee received a message at an address, which is a real internal signal and a weak public one, so it earns no badge. A provider sign-in confirms an identity against a third party, and that is what a public badge is allowed to mean. Showing a badge for the weaker signal would be the same failure as the disclaimer: technically defensible, practically misleading.

Where it got to

In production. The badge, duplicate detection and the moderation view all read from the verification records rather than from a flag on the testimonial, so there is one answer to "is this verified" rather than one per feature.

The referee journey is live at Share Experience, and the provider work is written up separately as three identity providers, one flow.

What I would do differently

I would have written the storage design before the first provider rather than after it. The first implementation recorded verification in columns named after the provider that happened to be built first, which worked perfectly until there was a second one and then quietly recorded it as the first. That is the subject of Three identity providers, one flow, and the branch that was not allowed to exist, and it was avoidable: the shape of the problem was visible from the beginning and I optimised for getting one provider working.

I would also have been slower to describe levels as "level 1" and "level 2" internally. Numbered levels invite the assumption that more is better and that the numbers are comparable, when the real distinction is what each one entitles you to say in public.

Related

If this is your problem too

Deciding what a system is allowed to assert, and keeping two decisions from collapsing into one, is usually the hard part of an identity feature. Consultancy covers that kind of diagnosis, and integration work covers the plumbing.