The role of an engineer at a startup is a tangled web: as well as writing code, you have to be your own product manager, QA tester, customer support and designer. But thereâs another hat that you have to wear which you might not have thought about: copywriter.
All products have copy, from welcome messages to text on a submit button. At incident.io, we have to put on our copywriting hats every time we add a new feature.
Some of the kinds of questions I find myself asking daily range from âshould this button say Save, OK or Submit?â to âDoes this label accurately but concisely explain what this box is for?â. Labels on forms, page headings, Slack bot messages: itâs all copywriting.
Many companies hire designers and writers to do this kind of thing, but if youâre a small team you all probably pick up a bit of everything. That doesnât mean you should give it any less thought, though: good copy can be the difference between a decent product and a great one.
The incident.io product operates across multiple platforms â Slack and web â which is a challenge when it comes to a visually recognisable product identity.
We donât have much control over how things look on the Slack side - we tell Slack what to render inside modals and posts, but the design is all determined by Slack.
A consistent tone of voice allows us to add the incident.io stamp on everything we write, across Slack and our web dashboard. Our tone-of-voice guidelines include small things like:
Early stage companies donât necessarily need a fully-fledged charter, but itâs worth having at least a bulleted list of things to aim for and things to avoid when writing copy for the product.
There are some fantastic examples of tone of voice out there - itâd be remiss of me not to call out Monzoâs guide as a shining example. Part of my onboarding at Monzo involved a session called âWriting Slightly Betterlyâ, which explained the tone of voice in an engaging and entertaining way with plenty of examples.
Consider including product writing guidelines in your onboarding processes, to get your team writing clearly from the outset.
Your job is to put out fires when incidents happen, and our job is to make that as easy as possible. In the heat of the moment, the last thing you want to do is comb through a lengthy docs page to figure out how to update the status page or add someone to an incident. Thatâs why itâs really important to keep all the copy really simple and to-the-point, with appropriate and timely guide text on the user interface.
Good writing is a core part of user experience (UX): a nice design will only get you so far if your users have to decode a cryptic message before they can use a feature. Similarly, if youâre in a stressful situation, the last thing you want to do is click a button and find it does something totally unexpected or publishes something private to the whole world.
Clear, friendly language has benefits beyond the incident context, of course. We have plenty of users for whom English isnât their first language, and as our customer base grows, that proportion is only going to increase. Non-native English speakers and non-British native speakers might struggle with idiomatic terms specific to British English (commonly called Anglicisms), so we avoid those.
Users might have reading difficulties such as dyslexia, or processing disorders which make it hard to parse large amounts of text. Keeping sentences and paragraphs short is really key here, preferring simpler, shorter words over their more complicated equivalents. As a bonus, this makes your copy easier for everyone to read.
That doesnât mean we have to be really serious and boring, though. Injecting a bit of lightness into our writing helps to keep spirits up at what can be a stressful time. A bit of personality in the copywriting makes using the product more enjoyable. When Iâm writing copy, I approach it as if Iâm literally talking to someone. For example, by incorporating contractions such as âweâllâ and âyouâreâ, it comes across friendlier and more accessible.
A conversational tone of voice might not be appropriate for every situation, but itâs more applicable than you might think. Companies like Farewill and Monzo have a very approachable, friendly tone of voice in industries that have historically been very formal, full of legal documents and jargon.
In the incident.io interactive tutorial flow, we guide the user through a simulated incident where a cat is stuck up a tree. We keep it light and engaging, and explain each step clearly.
While good copy is key to great user experience, too much writing can have the opposite effect. Overly long messages and explanatory text clutter up the user interface, taking up valuable screen real estate and distracting the user from whatâs actually important on the screen.
When writing or reviewing copy for incident.io, I go over it several times to remove as much as I can. Itâs amazing how often we repeat ourselves or pad out sentences without thinking.
Get someone who hasnât been involved in building the feature to try and use it. Whatâs the smallest amount of instruction you can give them so they know what they need to do? Have you used any engineering-specific jargon that your users wonât be familiar with?
Consider: Does this copy add anything to the context itâs displayed in? Can you say the same thing using fewer words?
In the words of Kevin from The Office, âwhy waste time say lot word when few word do trick?â.
An example of where we trimmed something down recently was the âExport to Jira/Linear/GitHubâ dialog:
As a user I already know that this is going to create a new issue in Jira - the tab says so, and I clicked the button because I wanted to export the action to Jira. We donât need to say it again.
The emoji doesnât add anything, either. We tend not to use emoji quite so much on the web dashboard as they take up space - they are more contextually appropriate in Slack, where emoji are everywhere already.
The only bit of the explanatory text we kept was the information that changes would be synced automatically.
We also made sure everything was sentence case for consistency, and changed the text on the submit button to reflect what was actually happening.
âOKâ is better suited to a confirmation dialog. We chose âCreateâ here as weâre creating a brand new issue, and the verb matches up with the highlighted âCreate newâ tab in the dialog. If you were to select âConnect to existingâ, the button text changes to âConnectâ.
Good, clear writing takes practice, but the good news is it becomes second nature the more you do it. There are a few things you can start doing now:
Weâre tidying copy as we go, but there are still parts of the product we havenât tackled yet. The incident.io Community is a great place to feed back about copy in the product, and let us know about any areas for improvement.
We created a dedicated page for Anthropic to showcase our incident management platform, complete with a custom game called PagerTron, which we built using Claude Code. This project showcases how AI tools like Claude are revolutionizing marketing by enabling teams to focus on creative ways to reach potential customers.
We examine both companies' comparison pages and find some significant discrepancies between PagerDuty's claims and reality. Learn how our different origins shape our approaches to incident management.
The EU AI Act introduces new incident reporting rules for high-risk AI systems. This post breaks down what Article 73 actually mandates, why it's not as scary as it sounds, and how good incident management makes compliance a breeze.
Ready for modern incident management? Book a call with one our of our experts today.