Table of Contents
I have the privilege of meeting every single new UX writer we hire at Wix (we’re currently a team of 65). I get to give them a few tips and tricks that I’ve learned along the way, things that I learned mostly through trial and error. People are always a little surprised to hear that these tips are actually all focused on soft skills, rather than writing itself.
1. Be active in meetings
As the field of UX writing continues to develop, I’m pleased to hear less and less people talk about not having a seat at the table. If you’re lucky enough to get invited to the meetings that matter, don’t squander the opportunity!
Show the other stakeholders that you’re engaged and have something to offer. I know you probably have a lot of work, but typing away through meetings is the fastest way to lose your seat. For many people, inviting a UX writer to meetings early on is still not intuitive. We write the words, the words come last, therefore we’re not needed. You need to prove to them that bringing you in does add value.
That doesn’t mean that you need to talk just for the sake of talking. Start by closing any open work and looking directly at what’s being presented, or the person presenting it. Ask questions whenever you need more clarification, or jot a note to yourself to ask one-on-one if it’s not relevant to everyone in the meeting. Leave some comments in Figma or your content doc so others can see that you were paying attention. (This also benefits you, so you don’t forget what happened in the meeting.)
We’ll discuss active listening further down, but keep in mind that it’s a great tool for meetings too, not just one-on-ones.
2. Question everything
As UX writers, we can’t take any text that we receive from someone else at face value. What’s written there is what that person thinks is the correct message. And maybe they’re right. Then again, maybe they’re wrong. It’s our job to figure out what the correct message is; if you’re not asking enough questions, you’ll never be able to do that part of your job.
Here are some questions to get you started:
- What does the user see before this? What did they click on to get here?
- Why are they seeing this message?
- What action do we want them to take? Why?
- What are the consequences and/or benefits of doing the primary action?
- What happens after they complete the primary action?
- What happens if they choose the secondary action?
- Will anything happen that can’t be undone?
- Are there any ramifications on XYZ earlier/later in the flow?
It’s crucial to ask these questions before writing a single word. If the answer you’re given doesn’t quite make sense, push harder. You might be uncovering something that no one else thought about yet.
3. Hone your active listening skills
Asking all these questions means nothing if you’re not practicing active listening for the answers.
The United States Institute of Peace defines active listening as “a way of listening and responding to another person that improves mutual understanding”. Researchers Jack Zenger and Joe Folkman discovered that “good listening [is] seen as a cooperative conversation”. Mutual understanding and having a cooperative conversation is the goal here, not to prove a point or show up the other person.
Active listening is just that–active. You want to really try and understand what the other person is saying. You can paraphrase, repeat back to them what you understood and check for accuracy, and ask questions to dig deeper. It’s also helpful to empathize and acknowledge the other person’s feelings and thoughts.
Let’s look at some examples, to see the differences when using active listening.
Not using active listening:
- Product manager: “This is missing a ton of stuff that we should be telling the user here.”
- You: “I disagree, I think this is exactly what the user needs to know right now.”
And that’s it, that’s the end of the conversation and no mutual understanding has been reached.
Active listening:
- Product manager: “This is missing a ton of stuff that we should be telling the user here.”
- You: “Okay, tell me what’s missing for you. What do you think they need to know right now? Why do you think they need to know that?”
- Product manager: “We’re not telling them about Feature X, which is super cool. If they know about Feature X, they’ll want to keep going.”
- You: “So you think that Feature X should be mentioned earlier. I think that’s too much info to give the user right now, as we know that users are currently dropping at this stage because they feel overwhelmed. But I agree that we can mention it in step 2 instead of waiting until the end. Do you think that could be the right spot for it?”
By using active listening, you’ve better understood what the product manager is missing and been able to explain why you disagree. You also empathized with them and tried to find a solution that works for all parties.
Not using active listening:
- Designer: “I liked the way I wrote it in the wireframe better.”
- You: “I think mine is better because it tells the user only what they need to know.”
- Designer: “I don’t agree with that.”
Stalemate! Neither of you are feeling positively towards the other, nor are you aligned on the text.
Active listening:
- Designer: “I liked the way I wrote it in the wireframe better.”
- You: “What did you like better in what you wrote? What isn’t working for you in what I wrote?”
- Designer: “I feel like we should be celebrating more here, and what you wrote feels less exciting.”
- You: “Why do you think we should be celebrating more here?”
- Designer: “Because the user just finished adding a product, which should be a happy moment.”
- You: “I understand what you’re saying. We think that this is a happy moment because that’s one of our KPIs, but for the user this is just another part of their work day. They didn’t spend a lot of time on this and they’ll see this message every time they add a product. So I don’t think we want to be really excited here. But I do agree that we should celebrate a truly happy moment. Do you think we could add some kind of notification once they’ve published all their products? That feels like a bigger moment to me.”
Again, you’ve really dug deeper to understand exactly why they liked their version better. You’ve also had an opportunity to explain why you disagree, and are putting the ball back in their court to incorporate what they think is important in a different way.
Active listening is a crucial soft skill for relationship building and can help produce really great products that everyone feels confident in.
4. Save your strength for the things that matter
Small disagreements like the examples above happen all the time, and active listening can help resolve them quickly. But what happens if the other stakeholder doesn’t agree, even after you’ve practiced active listening and explained your side of things?
Then you have to decide if it’s worth fighting for.
In the past, I explained this to writers as “picking your battles.” Recently, though, I’ve tried to move away from using that metaphor. Other stakeholders should be seen as our partners, not our enemies. We all want the same thing: to create a great product for the user.
Partners, of course, do sometimes fight about the best course of action. Not every fight is worth the energy, and if you try to fight people on every little thing, they won’t take you seriously on the big stuff. They won’t be willing to work with you on the things that actually matter.
So how do you decide where to draw that line? How do you decide what’s worth fighting for, and what’s worth letting go?
Here are a few things to ask yourself when deciding if it’s worth your time:
- How likely is the user to read this?
- How prominent is this in the flow?
- Will this impact user trust?
- Could this have an impact on our main KPIs?
- Does this have implications for things later in the flow?
If you do decide to expend your energy, remember to fight fair.
5. Treat other disciplines like you want to be treated
The division between designers, writers, and product managers can get pretty fuzzy. You all have the same goal (to create a great product for the user), you just have different areas of expertise to contribute in getting there. It’s important to respect those areas of expertise, especially when you’re first building that relationship.
I’m not saying you should stick to words and just the words. Instead, treat other disciplines like you want to be treated.
I want the input of designers and product managers about my text, just like I want to be able to give feedback on the design and product behavior. But I don’t want them to tell me that I should use a comma, or a sentence is phrased incorrectly, or that the word “utilize” is better than the word “use.” Nothing makes me ignore other people’s opinions faster than when it crosses the line from feedback to editing.
The same goes for our partners, especially design. If you’re doing a QA, for example, and the design of something looks off, you should absolutely flag that. How you flag it is what matters. Rather than saying something like, “This notification is off by 5 pixels,” you could say, “This notification looks off to me. Can you take a look?”
If you’re working on a draft and find that the design isn’t quite working for you, don’t try to redesign it yourself. Instead, sit with the designer, explain what isn’t working and work with them to design something new. In this way, you’re giving your input and having your voice heard without trying to do their job for them.
Your job as a UX writer is to write great content that guides the user in their journey. As we’ve discussed, though, achieving that goal is just as much about soft skills as it is about words. Building great relationships through engagement, active listening, and mutual respect is the first step to building great products.
Further Reading
What Is UX Writing? A Complete Guide For Beginners
