3 strategies I use to collaborate better with colleagues as a UX writer
There were many instances at work where I’ve thought to myself, “This would’ve been done so much more quicker if I didn’t have to collaborate with so many people…”. That may be true, but working with people from different expertise is also one my favourite things about being a UX writer in a big tech company.
While UX writers do collaborate with product managers, designers, or developers, we must see them as individuals first, then function second. Every teammate is a unique individual. So while we have the same goals and objectives, we each have different ideas on how to go about doing it. To achieve the team’s goal, we need to lower barriers to collaboration.
Before we even start to think about writing, there has to be multiple rounds of discussions and decisions with others. Good writing skills will only get a writer to a certain level. I’ve seen many writers struggle with the role because they realise that writing is just one part of the job. To have a successful career, or simply enjoy working as a UX writer, one’s got to work well with others.
I wished there was a standard process, but collaboration is a messy, organic affair that differs from company to company, and person to person. But there are 3 broad strategies that I use to create good partnerships at the workplace.
Practise active listening
As an introvert, I prefer listening to speaking. I also tend to ask more questions as opposed to tell others about myself. When I’m interacting with my colleagues, I don’t just listen to what they say, but how they say it. This gives me clues about what aspects of work they enjoy, what stresses them out, and what their pet peeves are. These clues help me understand their perspective and empathise with them, which makes working and getting along with them easier.
Empathy for others is crucial, especially in high-stress environments where people may say or do things without much thought. Each one of us has a different style of communication, so what you interpret of a message may not always be what the sender intended. When someone throws out a rude comment, I try to clarify things by saying “Do you mean…”. Most of the time, it’s not as bad as it sounds. It’s better to take a step back first instead of jumping too quickly into conclusions.
Not reacting immediately to negativity is a really difficult thing to do. But while I working in a really demanding role with even more demanding people when I was younger, I picked up meditation to deal with the stress. Through hours of guided meditation (big thanks to the Calm app), I learnt that taking deep breaths and observing my thoughts and emotions rather than having knee jerk reactions to them helped me to stay calm in difficult situations.
In meetings, I try to be as present as possible even if I’m not expected to contribute to the agenda. There’s always a good reason why I chose to attend the meeting, so I tend to listen to every meeting carefully and try and suss out if whatever’s being discussed will affect the user experience. Even if I’m new to the project and might not be able to ask deeper questions, I will take notes and summarise what’s being said in order to make sure that my understanding of the topic is accurate. I will also ask general UX-related questions like what’s expected of UX, deadlines for UX deliveries, names of key stakeholders, or documentation for you to do preliminary research. This will communicate to others that I’m not only actively listening, but also ready to start collaborating.
2. Understand and adapt to your team
When I’m new to a team, I like to spend the first few weeks observing things like a fly on the wall. By actively listening in on team meetings and observing group chats, I’m able to understand the team dynamics and see how people like working with each other. In the interest of setting a good foundation for future collaboration, I position myself as a colleague who can solve issues that the team is currently facing. It’s more about ‘let’s see how we can do this together’ rather than a ‘this is how UX should to be done’ mentality for me. For example, if the team prefers to have some copy written without any research, I can either 1) kick up a fuss and lecture the team about how this is not a good UX best practice or 2) write the copy and mention that we should strive to have research in place in future. Choosing the second path shows the team that you’re a team player.
Change scares people. So even if I’m used to working a different way, I’ll try and adapt to the company and team’s way of working before getting them to learn how to work with me. Nobody likes new joiners who come in and think they can change everything. Establishing trust is my priority for the first few months with the team. Only after trust has been established that I move on to educate them about my value.
I also enjoy sending out good vibes by calling out work that has genuingly left an impression on me. Because… who doesn’t like a compliment? It doesn’t take any effort at all to hand out praises, and it creates an open and encouraging atmosphere that can only aid collaboration.
It’s probably my Asian upbringing, but I’m usually also quite all right with compromising a little to maintain team harmony. Perhaps there are people in the team who don’t understand fully what a UX writer does. Or perhaps the team is about to launch a product that never had any UX inputs. As there’s always room for UX improvement for every project, I always pick my battles. If a stakeholder vehemently insists that I should use a word that I don’t 100% agree with, I’ll communicate my professional opinion as to why I’m against it, but still agree to go ahead and change it (if it’s a low priority project).
Give them an inch, but never let them take a mile. Some writers get really upset when non-writers tell them what to write, but I prefer not to sweat the small stuff and focus my energy on high-priority projects.
While it’s important to be a good team player, that doesn’t mean that I’m saying ‘yes’ all the time. There’s a fine line between being easy to work with and being a pushover. I never hesitate to speak up if someone makes me feel slighted, or if the workload gets too overwhelming. I often have to remind younger writers this, as they lack the experience and confidence to manage their work. Although people generally don’t like hearing ‘no’ for an answer, saying ‘yes’ all the time for the sake of getting along with colleagues is also not the way to go.
3. Managing stakeholder feedback
Years of presenting my work to stakeholders for copy review has definitely taught me a few things. As my work is never just about the words in itself, I make sure that any work I share out has a writeup of its context and copy rationale. By explaining how and why I’ve written something, I’m helping the stakeholders understand why the team has made certain UX decisions. This usually greatly reduces the amount of comments and copy suggestions that are made out of context.
I also never take any feedback personally, as I know that whatever I present is often a collaborative effort. So all the feedback I get on the artefact — even if it’s about the choice of words — is actually a feedback to everyone who’s worked on the project.
I value feedback because it gives me a good idea as to whether people understand my words. I’m seldom precious about my initial word choices because language can be interpreted in so many ways. I’m more keen to refine my words into something that my audience will understand.
If I don’t agree with some feedback, it’s better to dig deeper into the opposing perspective than to start defending the work immediately. I will defend my work if needed, especially when I’ve got hard facts to back my UX choices up. I will then use my UX writing expertise to explain why I disagree with a comment. For example, a professional reply like “We’ve decided not to use this term as users found it misleading during our previous usability research, .” is much better than “This term is used in other pages too”. Most of the time, stakeholders appreciate that I’ve taken the time to consider their comment, and are happy to learn more about how UX writers think and work.
The feedback process is not a platform for others to criticise my work. I see it as a necessary step to improve the product’s user experience — if people working on the project are unclear about the experience, how can you expect your end users to understand it? It’s also a great opportunity to educate colleagues on the value of what UX does and how to collaborate with UX professionals.
Main takeaways
Practise active listening in order to understand and empathise with your teammates.
By actively listening in meetings, you can suss out if whatever’s being discussed will affect the user experience.
Having a ‘let’s see how we can do this together’ rather than a ‘this is how UX should to be done’ mentality can create a better environment for collaboration.
Establish trust before trying to change any thing.
It’s OK to compromise a little now and then to make collaboration easier. But never be a pushover.
During the copy review process, having clear writeups that explain the rationale behind UX decisions does wonders. Your colleagues get some UX 101 lessons, and you'll be able to position yourself as the UX expert.
Be open to all feedback and if defend your work using professional UX expertise rather than emotionally-charged language.
