When Amazon Web Services (AWS) sent an email with their blank template—nothing filled in—the Internet laughed. I took notes.
The AWS email included a placeholder image and an inline writing guide. Its contents are as insightful as they are embarrassing. The cloud division makes up half of Amazon’s operating income and this “whoopsie” looks amateurish. The practice of using templates (appropriately modified!) itself is a professional move.
When you create large quantities of content, it helps to follow a model. Especially with many different types of content, created by an expanding team, templates can point contributors in the right direction.
Developer content is especially prone to losing its way. In this post, you’ll see how templates can help and what it takes to implement them yourself. You’ll be able to create your own AWS-like templates. Just make sure you fill it in before you publish.
Why You Should Use Templates
You want to publish original developer content. Huge volumes of low quality posts are unlikely to move the needle. At face value, templates encourage cookie cutter content, the sort of stuff that sends developers running. Instead, the goal of templates is to help you more easily create great content that stands out by following a proven structure.
The many app comparison sites may have tarnished the idea of templates. Take the nearly useless Twitter vs Slack example above. It’s hard to imagine how it helps the reader make a choice between the two products. It’s simply a regurgitation of whatever data the site has available. There’s no context about why you’d make the comparison. And you’ll find countless other generated pages fighting for search results.
Content templates, on the other hand, are filled out by humans. Machines are best at inserting variables. Although AI tries, humans are still best at inserting meaning. Your templates should remind writers what to include in a good headline, what’s needed in introductory paragraphs, and how to select images. It helps you consistently produce good content—the sort that will be appreciated by developers.
Find Your Content’s Natural Structure
In Developer Marketing Does Not Exist there’s an entire chapter dedicated to tutorials. The most important word within it is “structure.” Think about any tutorial you’ve ever read or written. You could probably recite its general bullet points right now. Why not codify that structure? Get it out of your head and into some internal documentation.
For example, this post follows a fairly simple model of mid-form content:
- Headline with advice
- Context-setting section
- Get started section
- Actionable next step section
- Optional call to action mini section
Your template can be as simple as the above outline, or go into details for each section: include your best practices for opening paragraphs, identity where to place screenshots, and encourage bullet points for skimming.
For tutorials, you might show how best to include code snippets and model how best to reference GitHub repos. Maybe even include a note about how the H is always capitalized in GitHub.
Look at your best-performing posts, or even favorites from around the web, and document their skeleton—the basic structure that remains the same from post to post. That becomes version 0.1 of your new developer content template. Over time you’ll improve it and expand to other types. You could have a handful of templates for each different type of content: blog posts, emails, tutorials, guides, and more.
Done well, you’ll be able to use your templates to create better, more consistent content. And you should be able to work faster, whether it’s just you or a whole team of writers.
Embed Your Strategy Within Templates
Armed with your content’s natural structure and desire to make templates, you’ll deconstruct it into a series of “Copy Goes Here” statements, right? Unfortunately, that can have embarrassing effects. You don’t want to make the mistake The Patriot-News published in their Sunday Opinion section.
Even worse than meaningless placeholders becoming permanent is that they probably won’t help you do the right thing. Instead, you want to use meaningful placeholders. As with Amazon’s example, let your template remind you and your team what good looks like.
Rather than “Headline Goes Here,” help craft the right copy with the placeholder. For example:
- Attach an Action-oriented Headline
- Why [Keyword Phrase] Will Help You [Problem/Solution]
- Write a Gripping Headline With Illustrative Word Pictures
- [Verb] Your [Noun] in This Remarkable Headline
- Try Five Headlines and Choose the Best One
Each of these reminds you, within its content, how to create a good headline. You can use similar placeholders for sub-headings, opening paragraphs, calls to action, and anywhere else you want your best copy.
Are you among the hundreds of developer marketers that receive our weekly lessons on developer engagement? If so, this template might look familiar, especially viewed alongside a couple of the recent dispatches:
Each individual email has its own angle, a fresh take within the framework. If I hadn’t pointed out the template, you might never know that I work from it.
Most emails I send are a little longer than the template. Sometimes it doesn’t have an image, or I remove the bullet points. But it always gives me somewhere to start, which is what it takes to publish consistently.
Build Your Own Content Templates
Whether it’s blog posts, community spotlights, or technical tutorials, you can maintain consistent quality with a templated approach. Start with the most common type of content you create, with special attention to its most important elements.
If you want help with your developer content strategy, work with EveryDeveloper to create a repeatable system to reach more developers.