The project is ready to launch. Designers are ready to design, developers ready to develop, and...who is going to write the copy? Project owners firmly believe that it's up to the project team, software developers wonder why they're even considered to do that, and UI/UX designers shrug. There was nothing about such a thing in the project plan.
When starting a project such as a new website from scratch, chances are that the copy is not yet laid out for the team. The project owner usually has a few keywords in mind, such as innovative, cutting-edge or state of the art, but not structured content. The briefing that the team gets is, for instance, to build a disruptive blockchain fintech business website, and they should work everything else from there.
In order to understand who should write the copy, and given the current popularity of experiences with multiple endings, let's work on a few possible scenarios with different endings.
For this hypothetical scenario, we'll assume that hiring a professional copywriter is not possible, due to common limitations regarding budget or project size, for instance. That would be, in any other case, the best option by far, since the value that a copywriter can bring to the table largely exceeds any outcome of the following possibilities.
Bearing all of this in mind, who's going to do it?
Option 1: The project owner writes the copy
There's always that one obvious choice that, given its nature, people just don't feel comfortable in picking. And there's a good reason for that. However, since project owners come up with the ideas, it would make sense that they should be responsible for all the copy, right? Wrong, at least in most cases.
It doesn't mean that project owners can't write great copy, but usually they are not the best pick. The way in which a project owner views the product is different from the view of a potential user, and that mindset is sometimes hard to change. Tasks such as defining if the copy should be shorter or longer, and picking the tone of voice and style, will be much more focused on the product, and not on the user.
This scenario leads to a product that will like itself way too much. Further down the road, as the importance of engaging with users and providing a great experience sinks in, someone else will have to improve the copy by completely re-writing it. What was intended to be a time-saving measure will cost much more than time in the end.
Option 2: The designer writes the copy
Designers are the first ones to get their hands dirty, and as they deal with the product's visuals, they may also be tempted to manage the copy. The main reason is that it will be easier to create an interface if you know that you can freely adjust the copy to the design.
This is the best way to ensure that the product looks great, as designers have total freedom over the creative process at this stage. However, copy will be seen as an accessory in the bigger picture, and the time spent in it will be minimum. Consequently, users get a wonderful experience through abstract screens that display poetic and/or vague phrases, meaning to change the way in which everyone perceives that particular product or industry.
The designer community may love it, but users won't even stop to think what's all of that about. The website will be like a beautiful painted canvas that everyone praises without ever thinking about what it represents. It may even score a spot in the best of 20XX designs articles at the end of the year, but won't fulfill any of the product owner's goals. Eventually, someone will have to change its approach as the wow-factor fades out.
Option 3: The developer writes the copy
If by the time the design is completed there's still no copy, you have a problem already. It's a problem that has to be dealt with, nonetheless. Developers are the next in line, and probably the ones who want the least to write anything besides code, but is there any option by now?
It's irrelevant if developers are up for writing the copy themselves or not, since delaying the issue to this stage will always be problematic. The time to write will be very limited and, since the design is already done, it'll have to adjust to the existing interfaces. Variables become unavoidable circumstances and the decisions will be very limited.
Everything will get quickly done in a pragmatic way, and the end result will be close to what one could expect to achieve through AI. There's nothing wrong with objectivity, but the product may be seen as blunt and uninteresting through the eyes of users. It'll get shipped with a few flaws already to be pointed out, and a second version will soon follow.
Option 4: Everyone writes the copy
Gather everyone around the table and start discussing ideas. You'll soon see that what begins as a fun experience will turn into frustration, as the about page is still being discussed weeks deep into the project. Later, the team decides that it's better that each one write a bit and in the end, everything comes together. Because that always works out, right?
In this case, the copy becomes an inconsistent mass of anger and doubt. The product may still get shipped, but with no clear message to speak to anyone. Users may get to know it, and with some luck even figure what the product is all about and enjoy it. It's up to chance, since the copy isn't really pushing in any direction.
Nothing good comes from leaving anything up to chance, and it'll be very difficult to stand out from the competition. Further down the road, the product owner will have to fix the mess that was created. What tells this option apart from the others is that the product may not be able to survive long enough to make the needed changes.
Option 5: No one writes the copy
We are used to establishing a causality effect between success and bold moves, but that's because we only get to know about the bold moves that succeed.
In this scenario, what's more likely to happen is that the product gets designed, developed and shipped. The apparently inspiring trend of shipping a product with no explanation of what it is puzzles the users and it gets shared all across social media. After the buzz, it will disappear, as no one was really using it.
The company closes doors and the blame is to be shared between everyone involved in the project. No one is happy with that.
Who should do it, then?
In this hypothetical scenario in which the ideal option of hiring a professional writer is not a possibility, the answer, as unlikely as it may seem, is: any of the first three options. What makes the difference in copywriting is the approach, and not the person who ends up doing it. Even if it is not usually seen as important as design or development, copy matters. What happens most of the time, however, is that it is just piled up on top of the other tasks and gets rushed out in the end.
The common mistake that was highlighted in the options above is that copy is seen as a burden and an accessory task that'll eventually get done. However, copy is a crucial point that must be contemplated in the project plan right from the start. Anyone can do it, but it's no easy task.
Business knowledge and a good understanding of user experience are both important, but to write compelling copy, one must make a much more thorough research. A process such as the Persona method is ideal to understand to whom the project is aimed for, and to create the ideal dialogue with users. It takes time and resources, but there's no way to work around it.
The consequences of bad copy may not always be as tragic as the ones mentioned here, but it's a mistake to believe that there are no consequences at all. Copy represents the story that you want to tell, and that's what stays on the users' minds after they use a product for the first time. No matter how great it may be.
Found this article interesting? You might like these ones too!