Most of our developers have a hard time when it comes to writing a good, marketable description for their components. We want to give you a few pointers and general advice on how you can write a good description that conveys the value of your product.
1. Making your description scannable
Site visitors, especially power users, are used to skim quickly through large amounts of text that are not prose. Remember, you are not here to write a novel but to quickly hook a visitor into learning more about your product. When faced with a huge block of text, visitors often give up before even giving your product a chance.
Breaking the description into ‘chapters’, with relevant and concise headings could help them locate the information that is most important to them and understand quickly what topics are covered. Including a bullet-list of features is a sure-fire way to cover the important aspects of your product in an easily digestible manner.
That said, try to provide all the information a person needs in order to make a decision. Don’t worry if your page ends up being very long – if you have headings and bullet points, readers will find exactly what they need.
2. Benefits First
Developers tend to do two mistakes when writing descriptions: focusing on features, and talking about themselves. The right way to do it, is to start with the benefits – what would someone gain from buying your component.
What problem does it solve (THE most important question)? Is it easy to implement? Will it save hours of labor? Is it robust and stable? Start your description by telling your potential users exactly how you’re going to make their life easier by buying your component.
Combining bullet points and benefits is one of the most powerful marketing tricks you can use.
3. Proof
Now it’s time to convince your potential user that your promises of benefits are not empty. There are a lot of ways to do this, and it’s never a bad idea to use any of them that are applicable.
If your component is really easy to implement, consider showing a sample code of how easy it is. My favorite example is the “How to Use” part in this component. It really looks easy to implement, doesn’t it?
If you know people who used your component, ask them for a testimonial. A short quote about how fast it was to implement could go a long way. If you provided support through your issue tracker and left someone a happy camper, ask him to provide a review through his download center. If you don’t have any contacts to people who can give a review, consider sending a few review copies for free so you can get some testimonials.
If you know of websites or apps that use your component, ask them for permission to add their logo or link, and make a “used by…” section in your description.
Pro tip: While “thank you”-type testimonials have a big effect, and should definitely be used, try to use the testimonials to kill two birds with one stone by addressing your main objections with the testimonials (“I Had it up and running in 3 minutes!”)
4. Rub it in
Now the user knows why they should use your component, and hopefully trust that you can deliver on your promises. The next thing you want to do is mention any other reasons for them to buy your component.
List the features – don’t leave anything out, big or small – don’t take anything for granted. You never know what would convince a user to make a purchase, which feature will seal the deal. Often, you will miss out on a sale just because the reader wasn’t sure if you have a feature he needs, and didn’t bother to ask.
Write use-cases – Sometimes users won’t realize how much they need your component unless you put it right in front of them. This is sort of like benefits, but should be more descriptive. Use examples and use-cases to appeal to users who did not realize they could do those things with your component.
We often take use-cases for granted. If you wrote your component to solve a specific problem in a certain situation, don’t forget to cover all the side cases it solves as well.
List any other reason you can think of to buy your component. You never know what will convince a user. The reader at this point, is hopefully excited about finding your solution, and trying to think of reasons why it makes sense to buy from you. Looking at a long list of features and will remind them of the time and effort they will save, and bonus features they are getting which they would probably not bother developing on their own.
5. Solving the problem
Now is the time to tell the story behind the component. Go into more detail about the original problem it was created to solve. What alternatives you tried before resorting to writing it? how is your solution superior to those alternatives? try to make the reader relate, having encountered the same problems themselves.
Tell how hard it was to build it, what problems you ran into while writing the code. While most of us want to sound cool and as if it was a piece of cake, the better idea is to make sure the reader understand how much time, effort and frustration went into the code, because the more time & frustration you went through, the more time and frustration you’re saving your potential customer.
It’s important to keep in mind that you are not writing to get things off your chest. Don’t get your readers bored. This part is about convincing people to use your component rather than coding on their own, and maybe including some use cases and even some keywords for the benefit of search engines. Don’t tell your users more than they need to know, and keep the structure easy to read (bullet points, short paragraphs and the use of headings).
6. Kill Alternatives. Overcome objections
Now the only thing coming between you and a sale, is the user trying to think of reasons to keep their wallet in their pocket. Your job is to step out of your shoes, look through the reader’s eyes and come up with any excuse they could think of not to buy your component.
Here are a few popular objections (and counter-arguments):
“It’s a piece of cake, I can code it myself”
Stress features the user probably won’t bother coding on his own, how robust is your solution, etc. Basically make them understand that they will have to spend hours or days coming up with a solution as good as yours.
“Is it worth the money”
By conveying the effort it took to develop it, and the scope of the problem it solves you’re attacking the “is it worth it” argument. Make sure coding it from scratch sounds like it would cost more than the license, in development time.
“I’m not sure this solves all my problems”
Make sure to list all the features, and provide any information you can think of that the user might want to know, and look out for pre-sale questions in our comment system.
“There’s a cheaper (or free) alternative somewhere else”
Stress the quality of the code. this is where you need to highlight features like robustness, valid code, your testing efforts (cross browser, etc.), elegant code, well-commented, etc. Also, sexify your code.
“I’d rather code it myself and avoid the hassle of learning someone else’s code”
Explain how easy it is to implement this. A good, descriptive documentation to prove your case, and a few usage code examples would make it clear that it’s faster to buy & implement your code than writing it.
Also, repeat the benefits, and use sentences like “in 15 minutes you can have a working example on your app and launch”.
To sum up, if you were selling face to face, you would be able to ask potential buyers what they are looking for and what they are looking for and what bothers them with your solution. When selling online you don’t have that privilege, so you need to make sure every reason to buy is mentioned, and every reason not to gets a good counter-argument. And don’t forget to make all this information easy to find and navigate through!
Author: Adam Tal