Stop Rewriting My UX Copy
How to address chronic copy meddlers
You’re cooking dinner for a friend. You looked up a good recipe, found a delicious jambalaya, shopped for the ingredients, spent time prepping and cooking. Now your friend takes a few bites. They then get up, walk out, and a little while later come back with a take-out meal.
Many a UX writer, content designer, or content strategist knows this story. They write, rewrite, or edit something. Then a client, stakeholder, or product owner — instead of giving feedback — says “Here are some other options.” They think it’s helpful. Maybe they think it’s time saving.
It’s neither of those things.
Why does this happen?
I see three main reasons for rewriting in lieu of good feedback: misunderstanding the UX writer role, people taking shortcuts to good feedback, and problems in the process (or a mix of any of these three).
1. People don’t understand or respect the UX writer’s work
You might find yourself on a team that understands the unique challenge of UX writing. But chances are, you’re on a team that doesn’t get your role and may not appreciate it. This may be especially true of people like clients and stakeholders.
People react and judge prematurely what they don’t understand. How can they engage work with respect when don’t fully respect the writer’s expertise?
Perhaps you work with a team or client that’s used to working with traditional creative agencies. They’re used to copywriters. You might be the first or only UX writer on your team. If people aren’t familiar with your discipline, there’s more room for misunderstanding. There’s a greater temptation to meddle in place of feedback and dialogue.
2. People don’t understand what good feedback is
Let’s recap the three types of feedback: reactive, directive, and critique (also described as reactive, prescriptive, and descriptive). I believe they roughly correspond to the three levels of processing discussed in Don Norman’s “Design of Everyday Things” (55-56):
Feedback Type | Emotional Processing Level | Examples |
---|---|---|
Reactive (negative or positive) | Visceral | “I don’t like that headline.” or “This body copy is fantastic!” |
Prescriptive (or Directive) | Behavioral | “Strike that body copy and write the following…” |
Descriptive (or Critique) | Reflective | “Since the goal of this feature is to reach a younger audience, words like ‘logistical’ and ‘requirement’ don’t seem like the best fit.” |
People may struggle with feedback for a couple of reasons. In addition to not understanding what good feedback is, you may find the following are true:
They don’t understand what they don’t like. They just react. They might think, “That’s not it” and instead of articulating why the copy isn’t working for them, they just write what they like or ask someone else to write what they want. This is one form of reactive feedback. Other forms of reactive feedback include statements like “Can we just make the headline different?” or “I hate that body copy.”
They understand what they want, but can’t explain why the copy didn’t meet their expectations. Again, rather than work to articulate why the copy didn’t work, they just rewrote it or submitted something else. This is a form of prescriptive feedback. They don’t speak to why the copy is not working, and offer a different what — new copy.
3. Teams need to improve processes
The other main reason why clients and teammates may rewrite copy is because processes need to be improved.
A writer is working with a client, they email a design with new copy; the client forwards it to a third party – someone who’s normally not part of design reviews. The third party replies back with alternative options.
That third party may not be very well-versed in UX design processes, proper feedback practices, or creative feedback in general. So they rewrote the copy, probably in no small part because of their inability to name what they thought should be improved.
Most product owners might know to avoid this, and teams might know this isn’t productive, but an outside contributor might not be aware.
Whether or not the rewriter is a coworker, a client, on the client’s team, or a third party, how does a UX writer handle someone taking the reins on the UX copy?
How to handle someone rewriting UX copy
Keep in mind the following, regardless of your situation (whether it’s a role respect issue, feedback quality issue, a team dynamic issue, or some of each):
- Anticipate this problem. At the beginning of a job or client relationship, feel out where they’re at with feedback. Are they seasoned feedback givers? Does it seem like they might need some coaching? Coach them if necessary, but definitely set ground rules for feedback. Talk about modes (in-person as preferable to asynchronous, how to handle online feedback) and what type of feedback is wanted (“I’m looking for feedback on the length/tone/accuracy”).
- Make sure everyone has access to brand guidelines and style guides. Also make sure they understand how these guides work and are applied. Applying those guidelines properly takes a particular set of skills.
- Check the ego. No writer’s words are always perfect. It’s jarring when people rewrite UX copy, but they may have legitimate reasons for feedback. Writers should assume good intentions.
- Clarify the feedback. Hopefully the approver sends a timely response with their feedback so the writer has time to probe further and improve. Probing or clarifying may look like this:
“I see you sent some other options for the waffle maker landing page section titles. Thanks for that. Could you also share what about the original options wasn’t working for you? Was there a specific word or phrase? Did it feel like the wrong tone? Was there something in particular you wanted to see to fulfill the goal of selling more waffle makers for the holiday sale?”
When there is a lack of respect for the UX writer role
You’re not alone if you feel like people don’t value your work fully. Other awesome people have written great pieces explaining the UX writer role and how to get a seat at the table, so briefly, here are a few ways to address this:
- Introduce yourself and onboard teammates. Beyond hellos, explain your role and how you’re involved. Explain the difference between a copywriter or technical writer and a UX writer (or related role).
- Give a short presentation about your work. Use internal critique time or segments of design reviews to give a mini-workshop on what you do, how your work integrates into design. Share your knowledge with your own team and with your clients.
- Explain your process. It might help to explain how you think or work. What are your goals, what are some best practices that you keep in mind, and what are your challenges? While it’s difficult to “show the work” on the synthesis that is making the complex simple, it may help to discuss the goals, challenges, constraints, and guidelines you’re working with.
- Get in meetings. Make it known that you want to be in meetings; tell people which meetings you want to attend. Remind people and track down the logistics to help make it happen. Enlist your product owner and team members’ help in advocating for invites.
- Present in design meetings. Different agencies have different practices. If you’re not presenting your work, give this a go. This allows you to drive the presentation rather than sitting in the back seat. You’re taking the lead because you’re the expert. You can show your work, your rationale, and ask for specific types of feedback just like another member of the design team (because you are a designer).
When the problem is poor feedback habits
Tapping into expectations, style guides, checking your ego, and clarifying the feedback will go a long way toward improving the feedback culture with your team. But it may take even more effort to correct crappy feedback:
- Try pair writing. One way to create clarity, improve communication, and promote respect for the UX writing process is to do it together. This works best when the writer works directly with their teammates or client, rather than when they’re on an agency team that works with a client-side product owner. Working together will also help the writing partner feel heard and will let the writer show how they apply the brand guidelines and style guides.
- Address the issue one on one. After getting clarification on intended feedback, the conversation could go something like this:
“Thanks for further clarification on the waffle maker section titles. That was helpful.However, I noticed that in your initial response, you rewrote the copy rather than giving feedback about what you liked or didn’t like, why, and how it did or didn’t meet our objectives.
I’m sure your intention was to be helpful, but as a writer this actually isn’t helpful for a couple reasons:
1. It wastes your time. It takes time to write copy, and sometimes the shorter the copy, the longer it takes to come up with alternates.
2. It wastes my time. Sometimes UX writing seems easy because there’s often so little copy, but there are so many factors at play. So when people rewrite the copy in lieu of giving feedback, it often means we need to clarify the intentions behind that new copy and clean that copy up a bit. Depending on how much is rewritten, it can be time consuming to rewrite the rewrite.
3. Rewriting in lieu of giving feedback robs you of using the skill of giving genuine and good feedback. Good feedback is something that needs to be practiced. And I stand to become a better writer by receiving thoughtful feedback instead of rewrites.”
When copy rewrites are due to a process issue
Assuming that the person rewriting copy and giving feedback is a vital stakeholder (i.e., their opinion matters significantly), I recommend the following:
Address the process issue with your design team or have an advocate help.
- The proper order and chain of this depends on the team makeup. On an in-house team, the UX writer can talk to a teammate and/or the direct supervisor, like a product owner or UX Principal. With client teams, the product owner can talk with the client product owner to alert them of a trend with certain people so that they can send the proper message on their end, as well as watch for it again proactively. (In some cases, it might be a small enough company or team where the writer can approach the third party directly.)
- For someone coming into the feedback process midstream, talk with your product owner. Maybe some sort of contextual introduction for those parachuting in would provide clarity on their sudden input? Often someone gets brought in for feedback at a certain point and they’ve not seen the seven versions before the current one. Maybe it’s a simple verbal onboarding, like “This is where we’ve been, this is where we’re at, and this is the type of feedback we’re looking for.” Maybe a written mini-brief. I’ve seen a designer who made an artboard scrapbook of all previous versions. Anytime someone dropped in (or was there but didn’t remember previous feedback) and said what about doing X, the designer would pull up the version artboard and say, “Yup, we did that in version 16.”
- Consider who the decision makers are. It’s important to establish with the key stakeholders at kickoff: what are the problems we’re trying to solve, what are the goals, and who are the decision makers? In a room full of opinion givers, who are the real decision makers? It might be the case that the rewriter and their feedback are lower priority, or really aren’t aligned with the feature goals.
- Consider the personal rewriter’s perspective. Are they in marketing? Are they a business analyst? They may not have the same perspective, so you may have to negotiate those differences of perspective. You might say, “In this part of the feature, it’s important to explain in plain terms what’s happening, and this isn’t a place to ‘sell’ them on the company.”
Address the process issues in retros.
If the writer works in-house, they can get everyone on the same page by calling this bad habit out and discussing it. If they work with a client team, they can bring this up in client retros, refreshing everyone on good, proper critique and keeping them alert for this habit in their peers, both on the regular design team and the third parties they consult. This should never be presented as a personal criticism, but as a professional proposal for team improvement.
Design and writing must be as collaborative as possible. This goes for personal interactions as well as the team’s processes.
A writer wouldn’t attempt to change someone’s visual design without expertise in that area (nor should the designer redesign simply to satisfy critique). The same should be said for anyone working with UX writers – respect the skillset, offer clarifying feedback, ask questions if you aren’t sure what’s being required of you.
Every UX writer, content designer, or content strategist has had someone bring their own meal to dinner. It happens. Be patient, generous, proactive, and collaborative; these moments can be opportunities for the whole team to improve. That means better content, better experiences, better services, and better products.