UX writing behind the scenes
The words users see on the screen are the tip of the iceberg when it comes to UX writing. There is so much going on under the surface that the end-user doesn’t know. I am reminded of this time and time again when I see screenshots of microcopy on social media with long threads trashing them as so obviously off the mark, so obviously in violation of basic rules, when there are 101 reasons that the string that ended up in production is actually the very best choice out there. We just don’t know about all of the factors below the surface that pushed that particular string to the UI.
The microcopy we see as the end-user is only the last stop in in a big process
Regulatory requirements
Here’s an example I grapple with almost daily: due to a regulatory requirement, I must use passive voice in places where the writer in me is crying out to use active. I don’t use active though, because that will get my company fined and my ass fired. Any day now I could find a screenshot on Facebook or Twitter, of something I’ve written, with a slew of disses about how passive voice should never be used, how this could so easily have been written better, that it’s sloppy or lazy of proof of lack of talent and investment. And those trolls would be right in a sense: it is indeed generally better to avoid passive voice. But not always.
I work in fintech which is highly regulated, but even product writers who don’t have regulatory constraints have a whole slew of other obstacles to navigate. It’s our job to make sure that whatever we write does not come off as a compromise, though it so often is.
Functionality
UX writing helps the user use the product, it doesn’t define the product. For example, I recently posted an empty state I liked: “No spreadsheets yet / Click + to create a new spreadsheet.”
A well written empty state that uses the opportunity to encourage the user to fill it
Someone responded, “Why not a ‘Create spreadsheet’ button?” I don’t know why there isn’t a button, but there isn’t. My post was about the copy with respect to the existing functionality. I have to assume that more factors went into designing the UX/UI than the effect it would have on the microcopy, and that the decision not to use a button was deliberate, and that the UX writer was asked to write for this element, not propose another.
I have written plenty of fantastic copy that simply wasn’t accurate, that just didn’t describe the actual functionality of the feature. It sounded nice though. But it never went to production. The user saw something that may have been less elegant, but did a better job of getting them to their goal.
Tech investment
I’ve given a number of talks about the ROI of microcopy. As a general rule, it’s important to invest in UX writing because at the end of the day, good copy will make the business money! But on a case-by-case basis, it isn’t always worth it.
For example, a number of times I’ve proposed really specific, customized strings that would create an excellent experience, using lots of variables, taking into consideration things like the specific user’s timezone. But sometimes it turns out that coding a customized experience just isn’t worth it. Something that could take a week to code, wouldn’t move the needle on revenue a smidge. It might improve delight ever so slightly, it might make a pretty addition to my portfolio, but it wouldn’t pay back the investment it took to develop it. The next time you criticize a string, consider that your arguably better solution simply doesn’t make business sense.
Bugs
I’ve also seen a lot of posts where the copy looks bad but it’s not bad copy. Sometimes it’s just a bug. People are trashing a string that was actually never written that way. No UX writer sat down and crafted what you see in the screenshot. A technical bug broke the experience, a variable was pulled in incorrectly, or the backend was never queried at all and the placeholder for the variable remained for all the world to see. That doesn’t make it bad copy. That’s just a bug. Not a good thing, but a whole other thing. Not a microcopy issue.
A bug infested the salutation
My point is not that we should refrain from criticizing copy! Not at all. My point is that we would benefit from taking a nuanced and comprehensive approach. When we see copy that we think we could improve, we might first consider how it ended up this way in the first place. What considerations might there have been behind the scenes when this copy was written? Then ask, what would I have written under those same constraints? Not only is this a more realistic, relevant approach, it’s also more challenging and therefore, more fun :)
