Learning home made copywriting
So you two startuppers have technical skills, a great idea, maybe even a nice logo, and have the means to survive without sales for six months. So you have all you need to create your product and launch your startup?
This is what we believed, and it has been a long journey to realize how wrong we were. In your startup you will need a lot more skills or “hats” to succeed. For example, you need to do SEO on your product presentation site, you need to write license agreements for your software, you need to create and maintain a consistent design, you need to present your plans to potential funders, you need to interview and select workers, you need to have a way to test the application both functionally and on end users, and so on.
A review of the range of activities needed can be found in The Web Startup Success Guide, which I also reviewed here. I have been focusing recently on a skill that underlies many of the needed “hats”: this skill which your startup absolutely needs is
copywriting
usually referred to simply by “copy”. Wikipedia defines copywriting as
Now, there is an apparently simple way for a startup to compensate the lack of internal skills: hire consultants. What is sometimes missed in this “solution” is that most of the needs listed before are not the problems of a day: you have to create copy material almost every day of your startup activity. Also consider that the value of your product may be in details that get added day by day, and there must be a close collaboration between production and copywriting to communicate effectively to the users / visitors / buyers. Considering also that as startuppers you are likely a group of creative people, you may opt for creating contents yourselves! Many – most? – successful startups do that, cultivating a blog, site, tweets and more. And I suspect that spelling out in clear writing the benefits of your product may also help the development of it.
I took notes while studying the literature and introductions to copy, and extracted from there some notes in the form of blog posts. I hope that can be of help to others that are trying to learn copy for their startup.
A note about the “startup” term: I use “startup” more to mean an attitude, or even state of mind, that even software houses which strictly speaking are not startups may assume. In particular in the European Union, creating a new software product and creating new companies may be activities that do not coincide, given the complexity of setting up a company.
These two posts are directly about writing:
Improving the writing style of technical blog posts (part one)
A checklist for improving the writing style of technical blog posts (part two)
and I will talk about this theme at the forthcoming Developers in Florence 01 meeting.
This is about home page composition:
Get visitors to read and remember your home page – the principles
Get visitors to read and remember your home page – applications
and as I will talk about the latest two at the forthcoming Better Software conference, I am expanding the information there with new experiences – will publish an update blog post.
Good luck with your copywriting!
A checklist for improving the writing style of technical blog posts (part two)
This blog post is the second part of a previous post, Improving the writing style of technical blog posts. Read the first part before proceeding.
As you survived reading up to here, now you get a reward: a simple checklist which you can use to verify your posts before publishing them. The checklist does not contain anything about the core quality of your contents: being a technical writer / worker, it is simply assumed that you have something of value to say, but don’t know exactly how.
Checklist
(Get attention)
-
There is an effort to capture reader’s attention in the title and very first sentence
Copy is never too long, just too boring.
-
Benefits for the reader are immediately clear – instead of features
I woke up this morning thinking: I really need …
-
At least in the first paragraph, every sentence somehow leads to the next one.
-
The post contains a (short) story
“For sale: Baby shoes. Never used.” Ernest Hemingway
(Authority)
-
Substitute opinions with descriptions
-
Your assertions are backed up with specific proof
-
You establish authority somewhere, somehow
-
You kept the initial promise through which you got attention
(Style & format)
-
Can you make it shorter? Where in doubt, cut it out
“To be or not to be?”
-
You kept the language simple and clear.
No one will ever complain that your writing is too easy to understand. -
You sum the contents up at the end of the post.
(Review)
-
You’ve printed the draft on paper and re-read it
A way to get a new perspective, a bit like giving it to someone else to read it.
-
You read it loudly
A way to become sensitive to the rhythm of your writing.
-
Immediately before publishing it you did spell check it not just on some online spell checker but on Microsoft Word.
This is it. Shouldn’t be too hard. Download here the checklist in PDF format.
One could add to this list, with a slight change of focus, “Did you insert meaningful SEO words?” in your writings – but this opens up further considerations, maybe I will discuss them in a following blog post.
Using these techniques
Am I using this checklist? Well, I am. Consider for example this recent blog post I published in one of the most boring blogs on the web, the one where we announce Teamwork’s releases:
There were once two brothers and a sister, and they were managers at three companies.
The first brother was called Micro Manager, and he picked the most complex […]. And after a week everybody hated the system, and then they hated Micro Manager, and everybody was unhappy.
The second brother was called Over Simplify, and he didn’t want any kind of management apart from to-do lists […]. And then they hated Over Simplify, and everybody was unhappy.
Their sister was called Reasonable Modesty, and she had minimal goals, had always clear that what matters is how people work and interact, and that software is always secondary, and should be flexible, not do too much, and not get in the way. She started evaluating Teamwork.
Teamwork’s blog usually has posts like “Teamwork 4.3.12323 released”, followed by say a series of bug fixes which make sense only for Teamwork administrators, and can be made more interesting (and popular) using the techniques just described. In fact many people liked this last one.
Another example, this very blog post: this is a bit particular as it is half way between a guide and a blog post, some call it a “blogzine” entry. I did review it (several times) according to its own criteria, and made many changes (improvements, I hope).
A well-written blog post can have several “usages”:
-
It can be used as a base for a talk for a conference – or for proposing one
-
It can become a chapter of an e-book
-
It can be the base for building the contents of a dedicated micro-site
-
It can be transformed in a project – for example as done at the Startuptodo service
Again, all contents of good quality have a positive SEO effect: it is a side effect, but it can be great.
Exercise: review your latest blog post with this checklist. Is there anything that could be improved?
Conclusion
So we started from examining the writing and narrational style of some popular technical blogs, and then isolated a few techniques in a checklist which you can use to refine your own blog posts. This is just a start, you can find references and more material to study in the next section.
Further reading
I would like to thank Mr. Brian Clark for his brilliant site, copyblogger, that I discovered half way through and gave me a host of new ideas. Some advice on how to write blogs is at the end of this podcast:
http://blog.stackoverflow.com/2010/01/podcast-81/
From the notes:
Some tips from Joel and Jeff about why and how (or if) programmers should blog. Set a schedule and stick to it. And don’t be a commodity blogger! It helps to focus on the storytelling aspect of the writing, per Ira Glass. And remember, writing a better article on any topic is usually pretty easy, because so much of the content on the internet is so darn bad.
The Delicious links provide some sources.
This blog’s theme is discussed on Twitter and classified in Delicious under the tag “wellWrittenBlog”. The first part of this blog post, “A checklist for improving the writing style of technical blog posts” can be found here.
Improving the writing style of technical blog posts (part one)
Why few blogs are very popular, and most are practically ignored? You may believe that popularity is simply a question of luck or money. I read many blogs for professional reasons, and some among these are a real pleasure to read. Well, it also happens that the well-written ones are the most popular among the ones I read, and being well written may be what explains their success, at least partially. So in what follows I do some analysis of writing styles and then define a checklist which you may use to analyze your own blog drafts before publishing them, eventually improving your writing.
Most popular blogs are “well written”: by this I don’t (just) mean grammatically correct, I mean well written by looking at them as sort of short stories. Looking at blog posts in this way is a perspective that probably escapes technical writers; it is obvious for anybody who has copywriting experience. A blog can be very well written and not be popular, and there may even be popular blogs that are badly written, but there seems to be enough correlation with “good writing” for blogs that have contents as good as those of many others but stand out in popularity.
Now we will examine three popular blogs, to see some writing techniques in action. Then we will try to define some rules to improve your blog’s writing.
I will not go into why having a popular blog can be important, I just assume that it is so – a discussion would lead us to an entirely different topic. What is here said about writing is contextualized to blogs, but I believe can be a help in any kind of copywriting activity.
Three popular blogs
The blogs I’ve chosen as examples are those of Joel Spolsky, Jeff Atwood and Seth Godin. The first two are about programming, the work of programming and software marketing, the last one about marketing and spreading ideas.
Joel On Software
As an example post from Spolsky’s blog I’ve picked this one: The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!), and here is a short abstract from the blog, the opening paragraphs:
Ever wonder about that mysterious Content-Type tag? You know, the one you’re supposed to put in HTML and you never quite know what it should be?
Did you ever get an email from your friends in Bulgaria with the subject line “???? ?????? ??? ????”?
I’ve been dismayed to discover just how many software developers aren’t really completely up to speed on the mysterious world of character sets, encodings, Unicode, all that stuff. A couple of years ago, a beta tester for FogBUGZ was wondering whether it could handle incoming email in Japanese. Japanese? They have email in Japanese? I had no idea. When I looked closely at the commercial ActiveX control we were using to parse MIME email messages, we discovered it was doing exactly the wrong thing with character sets, so we actually had to write heroic code to undo the wrong conversion it had done and redo it correctly. When I looked into another commercial library, it, too, had a completely broken character code implementation. I corresponded with the developer of that package and he sort of thought they “couldn’t do anything about it.” Like many programmers, he just wished it would all blow over somehow.
Notice how this blog post, which is highly technical, start by asking questions and telling short stories – I’ve underlined the starts. And not only is the beginning like that, it keeps proceeding in such fashion. Why don’t you go now and read it, trying to notice the short stories that pepper this nice post.
Coding Horror
Let’s examine now Atwood’s Coding Horror blog, for example this blog post: The Great Newline Schism. The topic of this post is newline invisible characters, and this post topic is probably on one of the most uninteresting topic ever, but reading it is a pleasure anyway because of the way Atwood evokes old typewriters and nice pictures to lead the reader along; he is not telling a story in a classical sense, but he is indeed engaged in narration:
“The Carriage Return (CR) and Line Feed (LF) terms derive from manual typewriters, and old printers based on typewriter-like mechanisms (typically referred to as “Daisywheel” printers).”
Seth’s blog
Finally, let’s consider the posts from Seth Godin’s blog: these are short (yes, mine aren’t
).
Consider The hidden power of a gift:
“Perhaps we resolve it, as the ancient Native Americans did, by acknowledging the power of the giver … The key is that the gift must be freely and gladly accepted”
and Frightened, clueless or uninformed?
“Comfort the frightened, coach the clueless and teach the uninformed.”
His posts are filled with anthropological observations: he manages to link to the readers’ emotions. He has a talent for finding latent emotional roots in apparently purely commercial / economical interactions. He looks at human beings as emotional chimpanzees – which you may say is exactly what we are – and as shaped by implicit social norms; we are not as logical as we’d like to think we are. Seth explains behavior through micro anthropological narrations, which take little time, and stimulate reflecting on the bases of motivation – hence on marketing.
Design for beauty or readability?
The communication strategy which we are trying to refine here is focused on narration, as this is a way to transmit contents. A different strategy is to use design, but then it will be much harder to communicate a specific content; you will need a different design for every post, and find / invent a graphical metaphor. This is what indeed some talented designers are doing: see
http://line25.com/articles/tips-for-designing-unique-and-attractive-blog-posts
http://www.smashingmagazine.com/the-death-of-the-blog-post/
These are incredible designers that create a different design for each blog post. But as said above, our idea is to excite the reader with narration, not with novel design, as we want the reader to focus on contents. So pick a simple, highly readable, consistent layout for your blog and stick to it. Use very simple typographical tricks to lighten the reading experience, and few pictures. For an example, consider Joel’s clean style. Don’t invent a layout – its non trivial!
The importance of a good start
Blog titles play a crucial role in your posts, similar to that of product / web site’s pitches. What is the purpose of the pitch – in our case, of the title? The purpose of the title is to make the first sentence read. And what is the purpose of the first sentence? The purpose of the first sentence is to make the second sentence read. And so on: if you don’t get the attention of the visitor with the title, your failure is complete.
So make sure you try lists of different titles and starts, and variations on them. Get someone to verify them with you. Do the titles and openings grab attention? Interest?
The words that you are choosing there are important too: these should be inspired by the words used by your potential visitors / customers to describe their wishes, hopes, desires, dissatisfactions, fears, worries in relation to your topic / product.
You should probably dedicate almost half of the total time you dedicate to the post’ writing to experimenting with the title and start. For example, in the case of our Patapage site it took me months to get to a decent pitch. A blog post title is somehow less important than a home page pitch, but still put a significant part of your effort on the opening.
Why telling stories is good idea?
First you should realize that “by default”, nobody is interested in your blog posts, apart from very few people close to you who maybe, maybe, are interested. This is so important to deserve repetition and bold fonts:
nobody is “spontaneously” interested in what you are writing.
This is a “negative” truth. But here comes a “positive” one:
people are hungry for stories.
These two facts can help all along your writing.
As a technician, you are probably the least apt to communicate to the general public, and you also have to communicate the hardest topics. Furthermore, what you are trying to say cannot be trivialized without losing its essence. If you explain your ideas in technical terms, it will be non trivial to keep the attention of the readers. This is why using stories is a good idea: you can begin communicating non trivial ideas building up the readers’ attention.
So tell a story. Now, not a silly story: the point is not telling jokes, the point is to introduce your topic.
The conclusion is: in your post, tell stories, about conflicts, experiences, problems leading to your theme, and you’ll get the reader’s attention.
Hiring a copywriter may not always be the solution
If you are working with a large budget, the simplest way to solve any copywriting problem like writing good blog posts is simply to hire a copy. With the web and social media opening “windows” on companies’ activities, many (most?) companies actually need to create well written, interesting contents every day of work. Now, can you hire a full-time copy? If you can’t, like me, you can do a lot by yourself.
As a startup, there are several occasions where we got perfectly good solutions with a little internal research instead of paying expensive consultants with dubious competencies. The “solution” hire a consultant simply assumes that consultants are competent by default, which is often not the case. Need to write a license? Need a user guide? Need SEO optimization? Hire an expert. We didn’t, and are happy with the results; again, these problems appear continuously, so you need the relative competencies in-house.
In order to write, you need to have some “creative spirit”. It is impossible to learn to be creative: Steve Jobs as quoted in Inside Steve’s Brain says that seeing people trying to become creative is “painful to watch”. Indeed it is. Here I’m just assuming that you are, and that maybe your attention needs to stop a bit on your own writing style.
And now… go to the checklist!
This blog’s theme is discussed on Twitter and classified in Delicious under the tag “wellWrittenBlog”. The second part of this blog post, “A checklist for improving the writing style of technical blog posts” can be found here.
The blurring distinction between graphic design and software development
Since we released the beta versions of Patapage and BugsVoice, I keep receiving enquiries about the graphic design of these applications and their web sites. People ask me “who designed the graphics?”.
Actually, the answer is everyone in Open Lab, and specifically no one. I always found a bit simplistic the idea that the “developer” creates applications by programming, and when the app is working and almost done, he/she asks a designer to create some graphics for it. In this line of reasoning there is a family resemblance with the idea “I first create an application and then market it.”, which I find deeply wrong – but this is another topic. If you are developing web applications aimed at wide markets, design and application development integrate one another at every development step. And this is how we create and design applications in Open Lab.
Like when we have to create a logo, the internal designers, who are also developers, propose candidates in a meeting to which the entire software house takes part; not only design and application integration are considered, but also marketing must be taken into consideration when evaluating design solutions.
Interface design and graphic design are different concepts, but are also related: a usable interface must be pleasant, not confusing, and both skills must be used to get a good result. Today’s users expect applications to be pleasant; and a well designed and pleasant application will more easily elicit a “collaborative” attitude from users in the first steps of evaluation, and even afterwards, if the design is consistent throughout the application. Consider also “wow” effects that designers can create.
The gaming software industry has understood the crucial role of designers long ago. And the boundary between gaming techniques and usability for “serious” software can be crossed proficiently – we did this with good results in our Teamwork software. A great introduction to this theme is Putting the Fun in Functional: Applying Game Mechanics to Functional Software by Amy Jo Kim. In order to use such techniques, good design is essential.
People that have designers take part in development, will notice that they can learn a lot from development, even when they get back to more design-specific tasks. And vice-versa, even more, holds for developers. Usability is often supplying the right metaphor: algorithmic experience often won’t help in such tasks, but the culture of a good designer can.
If you are doing web development, can you draw a strict line between what is done in your CSS for usability and what for esthetic considerations? And with say jQuery JavaScript selectors, their usage is for behavior, layout, design? There is no clear distinction; and you may see this as a problem, but also as an opportunity for interdisciplinary work.
This also evidences that it is a bad idea to use just external occasional collaborations for graphic design; you should find a way to have a consistent and continuous flow of design ideas in your software house. A similar conclusion is reached by Joel Spolski in this podcast: “Joel explains why he no longer believes in outsourcing design.”
So among the hats one startup should include in its first team, there is indeed development and marketing, but also graphic and usability design.
Similar considerations to the one above are valid also in the rest of the industry, not only in software; I was recently in Milan in the Triennale expo about Deepdesign (see a review here), and what they are doing brings together design, industrial prototyping, integration with mass production, and hence the distinction between design and product engineering is blurred.
Another, similar development: with Patapage in Open Lab we are working continuously crossing the boundary between page design and data / contents mashupping, creating a tool that makes the distinction between designing a site and inserting / updating / community contributing its “contents” problematic.
And the answer to“who designed the graphics?” is… the entire Open Lab team.



2 comments