Theocacao: Writing Modern Copy for Product Pages

Writing Modern Copy for Product Pages

Many Mac developers understand that a high-quality visual design for their web site helps the visitor understand both the company and product, but language design is just as important as layout and screenshots. It's in your best interest to make specific statements about what your software does, and to not talk down to the reader.

Many developers believe in the "start with something simple" philosophy when writing code, but may not immediately realize it works just as well for writing copy. When you sit down to write about what your app does, start with just that — explain what it does.

But by this I don't necessarily mean just list features. A terse explanation can be just as vague as a long explanation. Explain what your product does in practical, specific terms that actually make sense to the reader. Vara Software gets this right with ScreenFlow:

During your screen capture ScreenFlow tracks where your mouse cursor is, when you click and when you press a key. This allows you to add mouse click effects (both visual and audible), an overlay showing your key strokes and even lets you zoom the mouse pointer up & down."

This isn't an interpretation. It's a clear statement about how this feature works. There's no commentary on what your impression is of this feature — that's left up to you to decide. This shows respect for the reader.

Up until recently, conventional wisdom was that you should not use any language that limits what your product does. That is, it was in your best interest to make vague claims about features in order to cast a wide net and get as many users as possible to latch onto the idea.

In practice, this doesn't seem to work as well anymore — at least for the audience that Mac developers are typically targeting. By saying specifically what your app is, you don't waste time, energy, and bandwidth on customers that aren't really customers. I'm not saying sell yourself short, just that you should focus on the people that are actually likely to enjoy what you've made.

Few product web sites get this right all the time, and it's not a matter of good or bad. The point is that I think the closer you can get to this sort of writing, the more likely it is that you'll get the kind of customers that you actually want to make software for.

Writing Modern Copy for Product Pages
Posted Mar 20, 2008 — 11 comments below

Keith Duncan — Mar 20, 08 5673

Speaking of web design, is there anyone in particular you'd recommend?

Dana Spiegel — Mar 20, 08 5674

This is a very important aspect of getting people to understand your software, and its even more important to do this when your software does something that people haven't had experience with before.

When I was developing products for OnForce, we tried to do this as completely as possible. The software is an online marketplace for managing on-site IT service (when you bought a service, like a wireless router installation, from CompUSA, for example, it was an OnForce technician actually doing the work).

You can see some examples of this in our product blog.

One thing we found was that writing clearly, simply, and directly is really hard. It takes a lot of work to express software and process (yes, we made the software as simple as we could) in an easily understandable manner.

Ryan Ballantyne — Mar 21, 08 5676

I hate vague and uninformative marketing copy. I don't know why that was ever considered effective since it drives me away if I can't quickly find information that actually tells me what I want to know. I'm probably atypical, I know, but THANK YOU for helping, even if a little, to dispel that annoying practice.

Cathy — Mar 21, 08 5677

I think careful "language design" should also extend to the copy on the app itself. Things like tool tips, menu item titles and other types of explainatory text on an interface often don't articulate the feature in a clear way. Sometimes it's too vague or sometimes too technical.

In either case (marketing or UI design) it seems like it's worth it to hire a copywriter to go over the text. We hire graphic design professionals, seems reasonable to do the same for language design.

lance — Mar 21, 08 5679

"During your screen capture ScreenFlow tracks where your mouse cursor is, when you click and when you press a key."

I do not know ScreenFlow. When it tracks, what is doing the screen capture? I dislike relying on a comma for a list of things that starts with phrase, there can be too much misinterpretation. In this case it seems like something tracks when you click and press a key, but that is probably not the case.

Perhaps ScreenFlow is a screen capture program, or not, but I can not figure out what is doing the screen capture. Perhaps a [the] main feature was absent from the description? I suppose it would be obvious if one knew what ScreenFlow was, but I think I am lacking some critical information. Perhaps it is a plugin for Ambrosia's SnapZ Pro? Is it even an application? I am sorry, but this description is very condensed sounding.

Scott Stevenson — Mar 21, 08 5680

@lance: Perhaps ScreenFlow is a screen capture program, or not, but I can not figure out what is doing the screen capture

That was just one excerpt from ScreenFlow's product page which describes a specific feature. I chose it because it seemed to be particularly clear. The main page describes the product in detail.

Luis Alejandro Masanti — Mar 21, 08 5681

If we, as programmers, could write a "one paragraph clearly stated definition" of what our software do... before we even we start coding, it would be easy to write the "copy for the product page"!

Bob Peterson — Mar 25, 08 5688

To restate Scott: The product's main page must, in few words and clearly, tell me what the product does. It's the elevator pitch for the Web age, where surfers don't have to wait for the lift to reach the first floor before I leave.

Too many product sites start with a release note list. Or what's new. Or the features or benefits or both. Sometimes it is an exercise in reading akin to reading Delany's deconstructionist works. Screenflow gets it right from the top: ScreenFlow/Professional Screencasting Studio.

Jay Jennings — Apr 06, 08 5706

People don't buy a drill because they want a drill -- they buy a drill because they want a hole.

I see a lot of programmers write their own copy and they focus on features and not enough on why that feature is good to have (the benefit). You know your program inside and out and so it's perfectly obvious why a feature is good to have -- to you.

But to someone coming across your page out of the blue, they may not inherently understand that why flashing widgets will help them. If someone can say, "So?" to one of your features, you might want to also stress the benefit to make sure it's fully grokked.

Jay Jennings

Scott Stevenson — Apr 07, 08 5708

@Jay Jennings: I see a lot of programmers write their own copy and they focus on features and not enough on why that feature is good to have

I agree with this to a point. As long as the explanation of the feature is a true explanation, and not just commentary. It probably depends on the feature.

Tetanus — Jan 03, 09 6582

Poor choice of language was the reason why I resented so strongly the application VisualHub (now defunct).

As a video formats conversion application, it is an application with a lot of complex options, yes, but I didn't think that the developers had to talk users down with dialog boxes that go along the lines of "Don't change any settings in here! You're bound to screw things up!"

Comments Feed