Jakob Nielsen's Alertbox, March 7, 1999:

Trust or Bust: Communicating Trustworthiness in Web Design

It is getting hard to trust any website to deliver long-term service without getting very explicit guarantees up front. As the New York Times recently wrote, trusting a website "is like following a helpful stranger in Morocco who offers to take you to the best rug store."

The current climate on the Web is one of disregard for customers who are traded like sheep. Companies buy each other, not to create better products or services, but to take over locked-in users and create more "stickiness." The advice in the Information Rules book is good as far as it goes: Switching costs are indeed an important element in design strategy. But the book can as easily be read as consumer advice: beware of lock-in unless you get sufficient up-front benefits to compensate for the later difficulties.

I am a perfect fit for the new eFax service to receive faxes by email. And yet I don't sign up. Why? Lack of trust. It would be nice to throw out my old fax machine and get my faxes by email (since I only get faxes when communicating with dinosaurs). But as soon as I put their phone number on my business cards (and thus in thousands of rolodexes), I will be at the mercy of any degradation in service, spam faxing, and who knows what else in the future. I am not accusing eFax of doing anything bad or of having nefarious plans: they are just an example of a useful service that is perceived as scary because of the current trust-impaired environment on the Web. Unfortunately the decent sites suffer from the actions of the devious sites.

History shows that high-trust societies fare better than low-trust societies. Right now, the Web is turning into a low-trust society, and as long as the main business models rely on advertising and eyeball herding, the situation will only get worse.

Trust Builds From the Customer Experience

Studio Archetype and Cheskin Research recently completed a user study of Web trust. The methodology has a few weaknesses (most quotes are from super-users, not regular folks; users were asked to check out sites rather than use them for real) but the main results are credible and match earlier studies.

The key finding is that trust is a long-term proposition that builds slowly as people use a site, get good results, and don't feel let down or cheated. In other words, true trust comes from a company's actual behavior towards customers experienced over an extended set of encounters. It's hard to build and easy to lose: a single violation of trust can destroy years of slowly accumulated credibility.

This is why it is important to have contingency plans in effect to immediately mitigate any trust-reducing blunders or scandals.

In the long term, treating customers honestly is the only way to build true, deep trust, but how does one get started on this path? The study found several ways to communicate initial trustworthiness, including some traditional ones like seals of approval (TRUSTe, etc.) and brand reputation

Appropriate use of technology from encryption to download speed also matters: users feel that a professionally run server can be trusted more than one that feels like it could break at any time. When customers encounter technical difficulties at a previously preferred site, their reactions are:

Communicate Trustworthiness

The design itself can communicate trustworthiness in four ways:

Sensitive Use of E-Mail

Users are extremely reluctant to give out their email address because they fear getting endless spam. In self-defense, many users have established secondary email addresses (on services like HotMail) that they can give to less trustworthy companies.

Any time you have a need for capturing a user's email address, it is necessary to provide full disclosure of what will the address be used for. It is also necessary to give users the ability to control how much email they will be getting. For example, it should be possible for a user to place an order and be assured that the only email he or she will receive would be clarifications or confirmations of the order.


See reader comments on this Alertbox.


Previous: February 21, 1999: Details in study methodology can make results irrelevant
Next: March 21, 1999: URL as UI

See Also: List of other Alertbox columns