In this case, speaking about writing, it not only involves web copy, but project documentation and user manuals (for web tools and internal company applications) too.
Let’s get things clear first.
Saying negatives mean speaking about what your product “can’t do or doesn’t cover”. Let’s face it, this is never a good way to sell and idea. And speaking with negatives can sabotage our work in different ways depending on what the text will be used for.
Users don’t react positively to encountering a list of flaws when they’re browsing for something on the web. Anything. That’s why, in e-commerce sites, the link reads ‘Features‘ and not ‘Deficiencies‘.
Of course, not all negatives are that obvious. Take for example a phrase such as “the [product] doesn’t include [feature], but it includes [other feature]”. Is it really necessary to write that? The user can just consider the features it does include instead.
Stakeholders are a lot less tolerant to negative statements than the average user, considering they are probably going to invest a lot more money. A project presentation is a very delicate matter that should never emphasize anything negative.
Not only stakeholders, but future team members, current team members and ourselves will be recurrently reading a document resulting from the development of a project. Positivity is a very important part of team motivation, but it also avoids confusion. Clarity comes from not having to ask ourselves constantly “Then is actually working right?”.
Clarity is a lot more obviously important when it comes to text that focuses on describing functionality. It needs to be brief, clear, and, by design, positive. Just what the application o tool is able to do for you, and how it does it.
Positivity also helps you fight the change resistance that comes obligued with any new redesign or implementation. Don’t make it harder by being negative yourself.