How to measure the success of UX writing freelance projects

When you’re a freelance UX writer, clients come to you to solve problems.

And there’s pressure behind the word “solve.”

It means ya gotta find a path to success. Or your freelance UX writing client will be disappointed, and the whole thing will be bad news bears.

There’s an easy solution: Deciding early how you’re gonna measure success.

Why defining the success of freelance UX writing matters

Your UX writing freelance project will only be set up for success if you define what success looks like.

There’s a very likely chance you’re gonna be the OG UX writer to touch your client’s product.

You’re starting from ground zero, and ya gotta make sure you’re set up to define what level one of success and good UX writing looks like.

If you don’t, you’re going to be set up for subjective opinions, and that’s just a box of unknowns.

Makes sense, but how do you measure UX writing?

Digital products and mobile apps are made up of much more than just the words.

There are visuals, hierarchies, architectures, flow orderings, and much more.

UX writing is just a piece of the user journey and experience. It’s hard to measure just the impact of UX writing, if other things are being tested at the same time.

You have to A/B test UX writing in isolation.

That means pinning the original version against only what you change as a UX writer.

To truly know the impact of UX writing, there can’t be any changes to the visual or UX design or any other factors.

You have to fly solo and only A/B test your UX writing work if you want to know the difference UX writing can make.

What about collaboration?

As a freelance UX writer, you’re gonna work on lots of different kinds of projects.

In some, you’ll work with an entire product design team, product managers, and UX research to move metrics collectively. In this case, you aren’t measuring the impact of just UX writing. It’s a team effort and a team analysis.

But in other projects, you’ll fly solo. Clients hire UX writers to work independently all the time. And since the spotlight is on UX writing in this case, measuring the UX writing alone is imperative.

An actual case study from a UX writing job

When I freelanced for Virgil, a mental health care startup, they asked me to improve their booking flow (aka how the people signed up for online therapy.) Virgil didn’t come with a specific set of success metrics, so we worked together to define them.

This was a bit tricky, because Virgil’s booking flow has two purposes:

1. To get people to schedule a consultation call
2. To disqualify people who aren’t candidates for online therapy

Based on those two criteria, people successfully reaching the end of the booking flow wouldn’t work as a measurement of success, since it mattered if those people were qualified online therapy candidates.

We pinpointed a worthy success metric to be the difference in the number of qualified candidates speaking to a Care Coordinator. That worked, because the Care Coordinators double-checked a candidate's qualifications before hopping into care.

With that success metric defined, I got to work optimizing the booking flow. I worked on improving the microcopy and flow ordering (or story) only.

By focusing on changes only from a UX writer’s perspective, we could conduct an A/B test to understand if there’d be a lift in qualified candidates speaking with a Care Coordinator.

The A/B test pinned the original flow against my revised version. 50% of people saw the original version, and 50% of people saw my revised version. After a period of time, we compared the results, and deemed it a “winner.”

My revised version led to a 42% increase in qualified candidates speaking with a Care Coordinator. And we were only able to isolate this as the impact because I, the UX writer, was the only one who made changes.

What if I lose the A/B test?

The value isn’t always in winning – it’s in learning.

If your A/B test flops, you still gave your client tremendous learnings about what doesn’t work. And learning what doesn’t work is just as valuable as learning what does work.

Set expectations with your client before the project kicks off that the goal isn’t to win the A/B test, it’s to learn from it.

If your client gets fussy about that, run. They’re a bad apple, and your project won’t be set up to succeed.

How to deal with subjective opinions

Having clear goals combats subjective opinions.

When you have a crystal-clear measurement of success, your client can’t argue if something works or not — the users will answer that question.

If a client is questioning your work before you launch into an A/B test, ya gotta back it up.

First off, your choices shouldn’t be based in subjective opinions.

Every word and move you make on a user experience should be based on your expertise in an industry, insights you’ve read or learned about the product’s users, or learnings from your previous experience.

When you have reasoning for why you’re doing something a certain way, it’s hard to argue with an expert.

For example, a client once challenged why I chose to use the term “account balance” instead of “account” when describing what the user would be linking from their bank account to the client’s product.

I said, based on my 3+ years improving fintech products, I know linking your bank account to a new product is scary for people. If we use “account balance”, we’re implying we’re only pulling a specific piece of data from their bank account, not linking their entire “account.”

And it’s also immediately clear to the user that piece of data contributes to the problem we’re solving for the user, vs. they’d question why we need access to their entire “account.”

Leaning on my expertise and experience convinced this CTO to move forward with “account balance.”

That said, founders can be opinionated, and at the end of the day, it’s someone else’s product.

Sometimes you’ll need to bend. But definitely back up your decisions first.

Happy UX writing 🖖