Back to
UX & Content Design
team

First content designer on the team: do’s, don’ts, and survival tips

I’ve been the first (and for a while, the only) UX writer at two companies where I built processes from scratch. So, I decided to gather the lessons I’ve learned. There are tons of articles on this topic, so there are no claims to game-changing insights here — just sharing personal experience. Let’s dive in!

Sometimes, I review drafts and suggest removing explanations altogether by restructuring elements. We shouldn’t be afraid to cut down text — instead, we should focus on information architecture and let the interface speak for itself.

If you’re new to content design or UX writing, here’s a quick rundown.

💡 The textbook definition

A Content Designer is someone who writes interface copy to help users navigate a product. The goal? Make interactions effortless and intuitive.

🛠 The real job

Writing is actually the last step. First, you:

  • Dig into the product, audience, and competitors. Figure out what the business is trying to solve.
  • Get involved early, working with designers on logic and information architecture — so users don’t need to read too much. Good UX writing is invisible.
  • Write the first draft.
  • Bonus point: Test it with real users and iterate based on insights. But let’s be honest — startups move fast. Sometimes, your test is just watching metrics and hoping for the best.
  • Gather feedback from product managers, designers, and analysts — polish, refine, and ship.
When I need to explain what I do, I compare it to making a salad. First, you buy ingredients, chop vegetables, prepare croutons — and finally, add the sauce.

After that, compliance, localization, and release notes kick in. But this is the foundation.

If you want a deeper dive into UX writing, plenty of folks have written about it. For now, let’s get to the fun part.

How to join a team and be useful

Short answer? You won’t be. At least, not instantly.

I’ve been the first UX writer in two teams, and my task was not just to plug into a well-oiled machine and quickly write a style guide. While this is important, the real work lies beneath the surface — moving too fast can backfire.

What to do instead

✅ Start with the product managers. Most people run straight to designers (which is fine), but PMs are where the gold is. They’re the bridge between the team and the business. They know why things are the way they are, what’s working, and what’s broken.

✅ Go through the product like a user. Seems obvious, but too many people jump straight into Figma or the backlog. First, experience the product. Where does it break? Where do you get confused? What wording feels off?

✅ Figure out how the team actually works.

  • How are features built?
  • How many teams are there?
  • Where do texts live?
  • Who wrote them before?

✅ Map out existing pain points. Before suggesting significant changes, gather insights. What problems have already been flagged? Where do users struggle? Then, present your findings — this instantly shifts how the team sees you. You’re not just here to “fix some words.” You’re here to improve the product.

✅ Propose a workflow. In that same presentation, set expectations:

  • When should you be involved?
  • Who should you work closely with?
  • Where should text live?
  • How should reviews happen?

This saves you from sitting around waiting to be looped in (or, worse, being forgotten).

I always strive to use popular metaphors, like the Power of Three from the ’90s TV series Charmed. Imagine a UX team where each member has a unique power, but together, they unlock a superpower — creating not just a great but the best user experience.

What not to do

❌ Jump into writing right away. Without context, you’re just guessing.

❌ Kick down the door with your rulebook. You might have strong opinions (which is great), but first, listen. Understand what’s possible to change and what will just frustrate the team.

❌ Try to work with every team at once. Been there, crashed, burned. It’s tempting to prove your value ASAP, but taking things one step at a time is smarter. For example, at QIC, there was a clear divide between web and mobile when I joined. I focused on mobile first, then gradually expanded to the web. Much smoother.

TL;DR

  • Learn the product first and write second.
  • Understand how the team works, where content lives, and what’s already broken.
  • Present insights and solutions — not just text tweaks. Bonus points if you tie them to metrics.
  • Take it one step at a time. Trying to do everything will burn you out fast.

Surviving as the first content designer is a marathon, not a sprint. Pace yourself, pick your battles, and take it step by step.

‍