Try before you buy, by Jeffrey Veen

Try before you buy

Crutchfield.com

Earlier today at the IA Summit, Jared Spool discussed the importance of confidence in ecommerce. That is, people are more inclined to buy if they are sure they're making the right choice. My characterization may make the idea seem trivial. It wasn't. Few of us honestly know how to design for confidence.

One example Jared showed was from Crutchfield.com. Among the many effective things the company does is provide PDF versions of the manuals for the products they sell. He explained:

Our subjects would download these PDFs and read through them right then. Because they knew that if they could understand the manual, they'd be able to use the camera.

This reminds me of the work I did with Macromedia a few years ago. Through user research, we found that most visitors to their site came with the goal of finding software that solved a specific problem -- "I need something that lets me edit HTML." And while the macromedia.com web site was filled with marketing content extolling the features of each product, most people just downloaded a demo version. So in the course of about 3 minutes, potential customers became users. And all the users we talked to explained that their decision to buy was made ... in the support forums.

These two examples suggest that today's ecommerce customers are making product judgments based on content that has historically been an afterthought. Pair that with how organizations develop these different kinds of content. I've not seen many organizations that have an integrated content strategy that develops both pre-purchase material and post-sale support. Yet increasingly, it's the support docs that give people the confidence to click the elusive "Add To Cart" button.

In all of this, maybe we'll finally see tech writers getting the support and credit they've long been due.

This entry was written by Jeffrey Veen and posted 5 March 2005 at 11:34 AM. It was filed under Web Design. | View blog reactions

Comments

1. On 5 March 2005 at 5:41 PM Meitar Moscovitz wrote:

“In all of this, maybe we'll finally see tech writers getting the support and credit they've long been due.”

Oh, I hope so! I hope so! Too few people actually realize how difficult it sometimes is to write clear, instructional documentation that is actually helpful.

And to the programmers out there: No, merely commenting ambiguous lines of your code doesn't quite cut it.

2. On 9 March 2005 at 12:57 AM Gordon wrote:

Guess which technical author is forwarding THIS round his development group today!

3. On 9 March 2005 at 12:29 PM Bronwyn wrote:

I know that I often hunt through product pages and manuals to find out if the Acme Whizbang I'm thinking about getting will do the precise thing I want. Maybe this is more common than I thought!

4. On 25 March 2005 at 7:23 AM wrote:

"I've not seen many organizations that have an integrated content strategy that develops both pre-purchase material and post-sale support." Truer words have not been spoken. It is heartening to read Jared's point about customers making decisions based on well put together/usable documentation. Strategically integrating the logical content points between release notes, web support, forums, spec sheets. et al to truly serve the customer is still the holy grail for tech writers/content developers. But the lack of vision here usually seems to reside in the organization, too myopic to see the forrest through the trees.

5. On 25 March 2005 at 11:33 AM Sam wrote:

"I've not seen many organizations that have an integrated content strategy that develops both pre-purchase material and post-sale support."

Most organizations lack the commitment to do this and it becomes the root cause of ineffective, disparte customer communications. Tech doc is seen only as a necessary evil; not as a true purchasing accelorator. Hopefully, product teams can begin to view the value in cross-discipline fucntionality; tech writers, coders, marketers, product managers shouldn't operate in silos. Because the results will almost always be disjointed and low on usability