Why I Avoid Text Editors

Working on content for a SaaS Product, I write a fair amount of content that I call ‘Design Copy’ — stuff that is hard-coded and can’t be edited in a CMS.

Be it microcopy, help text or modal windows, I’m responsible for making sure that every word that appears in the application is useful and concise.

Here, design and words are working closely together. They might be signposting a function, removing ambiguity or providing advice. Using words in this way requires a different approach.

Avoiding Text Editors

Just as I encourage designers to work with real content, I encourage writers to work with real designs.

Writing words in the same context that they will be published is important — there is no knowing how the words will work and feel until they are surrounded by that visual design. It also gives you an opportunity to test with users before committing.

To do this I take a few different approaches.

Dev tools

If you’re rewriting something, or just playing around with some microcopy that will eventually be hardcoded, this is a great approach. Create multiple copies, save them, test them, all without bothering a busy developer.

Useful for copy that is already hardcoded or where the design already exists, like a 404 page.

Developers coming up with something in a rush
A more considered approach

Good for: quick changes on single, static pages.

Bad for: anything that relies on dynamic content (e.g. server-side data), since you can’t save the page.


Design tools shouldn’t be limited to visual designers. Sketch has made the whole process super accessible for those that don’t have the time to invest in mastering Photoshop/Illustrator. Get in there, whack together a wireframe — put together some content ideas and discuss it with your designer/developer.

Useful for seeing how titles act in the confines of a mobile menu (concept piece, not commissioned by Met Office)

Good for: putting your ideas on a page, developing layout alongside content.

Bad for: a project where the visual/layout already exists.


Requires some basic coding skills, which I know not all content writers have (or want to have) but worth it if this is within your reach.

Whacking together a quick prototype for testing your content isn’t massively time consuming and can provide you with that flexibility to start playing around with the design — can be quick if you’re using something like Foundation/Bootstrap as a base.

Simple and quick layout using the Foundation’s grid system

Good for: pages where you need something interactive and quick to edit layout.

Bad for: projects where you have access to a developer, if your code skills are slow (but a good way to get them faster!)

Content & Design

Content and design have a lot of cross over, it’s inevitable.

Having a toolset that reflects this benefits me when I’m working on things like microcopy and sales sites, where it’s essential that design and content need to work together.

Ultimately I’ll leave the design to the visual designer and the coding to the developer, but having approaches like these helps us work together, not separately.

I’m interested to hear about how you approach this. Comment below with your thoughts or tweet me at @Rob_McW.

Show your support

Clapping shows how much you appreciated Rob McWhirter’s story.