12 things I'd tell my younger UX writer self

I've worked as a UX writer and content designer for roughly four years now.

Around two as a contractor, around two as a full-time employee. Both in Italian and English, mostly for startups and scaleups.

I've moved from food safety and customer service to social commerce and now to LLMs and business intelligence for regulated sectors.

During this time, I've learned a few lessons I wish my younger self had known from day one.

Different teams, different needs

Company size will shape your day-to-day work.

A startup may operate with a consultant-style approach and prioritize client development. The pace is fast and you're in closer contact with leadership, but there's a lot of uncertainty and priorities change often.

Large businesses focus more heavily on product development. Roles are clearer, everything is process-driven, but decisions take longer and it's harder to show the impact you're making.

Pick your poison.

Your customer is the business

You're that UX writer who always keeps the end user's interests front and center.

Before your solutions ever reach users, though, you'll need to convince a few other stakeholders: the business you work for and its investors.

In other words, the people who pay you — and the people who pay them.

Secure their buy-in first, then deliver what they expect to increase your chances of serving users.

Coordination is where it's at

Because they're not writers or designers, your colleagues from other teams may not know what you know.

And since you've worked so diligently to craft the experience, you'll want to make sure the right teams have all the information they need.

You'll likely spend a good amount of time:

• Reviewing requirements and checking technical feasibility with backend;
• Going over user flows and specs with frontend;
• Confirming desired behaviors with QA engineers;
• Explaining processes, concepts and new terms to support, marketing and delivery teams. This helps them know what to expect and share realistic updates with customers.

Coordination is as important as the writing itself. Talking with other teams is essential for the writing to happen and, once it has happened, for the content to leave your circles and get out into the world.

Spot the HiPPO

You've barely wrapped up your newest proposal when that manager who's been around forever appears out of the blue and randomly changes a few words here and there.

This is especially common in writing. Just because it seems like anyone can write doesn't mean someone with no prior context can jump in and pull it off.

But this someone is the highest-paid person in the room. They think they can definitely do that, and they will. You just observed a HiPPO in their natural habitat.

This won't necessarily happen at your company, and not all the time anyway. It's a matter of company culture and UX maturity. But if it does, there's not much you can do about it.

Join forces with your team lead. Form a united front with colleagues you trust. Come prepared with a strong rationale you can convey in simple words, and let go of the rest.

Get creative with research

As many UX writers have seen firsthand, not getting access to user metrics is surprisingly common.

But testing with actual data is crucial for measuring your content's impact and linking your work to tangible results.

If you can't work with KPIs, you'll need to find other ways to get the information you need. For example, you can tap into your internal network of seasoned, customer-facing colleagues for both qualitative and quantitative research.

Think sales, marketing, product management, customer success and delivery teams. They all have valuable insights you can use to validate hypotheses and support your design and writing choices, too.

Don't wait around for permission

I hear a lot of UX writers complain about not being included in this or that meeting, or not being invited to view this or that Figma file.

But think about other roles. A senior engineer isn't waiting for you to tell them what to do. A staff developer isn't assigning tasks to you. Right?

If they have something on their plate you can help with, they'll come ask you, or explain what they're working on, or share what they expect the result to look like.

You should do the same.

If you're not hearing from others, reach out to them.

Send that message. Request access. Schedule the meeting yourself.

Let them know you're the go-to person in your discipline.

When you show up consistently, others will understand it's you they need to talk to. And they'll start coming to you, rather than the other way around.

Stay zen

Once you claim your space and responsibilities, it's easier to stay calm under pressure.

Don't engage in drama. Don't feed any trolls.

Never take comments on your writing personally. Listen to feedback, but don't react to it right away — instead, sit with it for a while and decide whether it's worth acting on.

Be ready to explain the same thing over and over again as you onboard different stakeholders.

It's all part of the game.

Don't die on that hill

Don't marry your words and ideas. Fall in love with frameworks that solve your specific problem efficiently and can scale.

If it makes sense in context, is technically feasible and holds up under testing, then you're on to something.

Be flexible and open in your approach. Closing yourself off and insisting on your point just for the sake of it can slow your team down and get in the way of your career in the long run.

Touch grass

I mean, both literally and metaphorically.

Look away from the screen every now and then. Stretch and look out the window. Take breaks and get your steps in. In general, spend more time outdoors.

Also, take as many days off as your contract allows (unless you have unlimited PTO!).

In most cases, your job won't involve saving lives. You shouldn't operate in emergency mode. When it's time to clock out, close your laptop and let the workday go.

Don't let the storm simmer

Deal with small problems before they get bigger.

If you have a problem with a colleague and don't know how to approach it, talk to your team lead. And if you have a problem with your team lead, talk to an experienced colleague you trust, possibly from a different team.

Most smaller issues can be addressed and sorted out this way. If it's more serious, consider talking to another team lead before escalating to HR.

Learn to let go

You've realized just how hard this one is at your own expense, after a burnout that had been years in the making.

And even then, you almost fell into the same trap again before you could learn the lesson.

Things change fast. Products are fluid; one day you're ready to integrate the latest feature, the next there's a shift in the industry and you need to pivot.

You scramble to keep up with the pace.

There's this sense that if you don't showcase this demo today, if you don't release this update before noon, competitors will get ahead and it'll be over.

This is the nature of product teams.

As much as you can, don't let the inevitable urgency filter into your life.

Sure, keep doing your best. Be dependable. Take work seriously. But even if you enjoy your job and are excited about the vision, your needs, goals and interests are not your employer's.

You know it, they know it. You just need to politely but firmly restate that boundary.

Leave a trail of good behind you

Throughout your career, the teams you work with may fail to meet their targets. This can happen for a ton of different reasons, most of them out of your control.

As unfair as it is, the blame might still fall on individuals, without considering all the complexity that led to the outcome.

If you think that's happening to you now, take it as an opportunity to show who you truly are. Don't stop showing up.

As a wise frontend developer once said in a retrospective, what matters is always delivering your best work.

Your team lead will thank you. Your colleagues will remember you fondly. And your next employer or client will value you more for that.

Read more from me:

I'm Elisa, an Italian content designer with a background in localization and customer service. This is where I document my life in UX and writing.

Read more