Five tips for success as a solo UX writer

I transitioned from marketing to design at Codecademy—an ed-tech company committed to empowering inspiring careers in tech through interactive, online coding education.

I’m the first UX writer on a team of product designers, working across seven different product squads. There’s no shortage of variety in the types of projects I get to work on. There’s always a new and exciting puzzle to solve—and I’m loving it.

But as the first and only UX writer on a team, things can get overwhelming. You’re building out a whole new discipline from scratch. Plus, you’re fielding writing requests from designers, PMs, and engineers. And you’re probably also spending a good deal of time explaining to people what UX writing even is. It’s essential to take the time upfront to set yourself up for success.

Five tips for setting yourself up as a solo UX writer

I’m still new to this. But a few things, in particular, have helped me in my first eight months as a new UX writer at Codecademy. I’ve rounded them up here, along with some resources I found helpful.

Tip #1: Get to know the team

UX writing is a very cross-functional and collaborative job. You’ll likely be working with designers, product managers, engineers, and even marketers. To set yourself up for successful collaboration, it’s so so so important to start with getting to know the team.

During my first few weeks on the design team at Codecademy, I set up a series of info-gathering sessions. I met with groups of designers by business unit. Plus, I scheduled one-on-ones with design team members working across product squads. This included UX research, design systems, and communication design.

My goal was to get to know the team, their existing pain points, and opportunities related to UX writing. This information would inform my process work. Plus, it would help me determine priority UX writing projects to make a quick impact.

In the group sessions, I asked the following questions:

Past experience

• Have you worked with a UX writer before?
• If yes, how and when did you involve them in your projects?
• Were there any helpful resources they provided you with?

Current state

• How have you dealt with UX copy for your projects without a UX writer on the team? Reflect on process, stakeholders, approval, or anything else that comes to mind.
• What things do you like about UX writing? What’s gone well?
• What are the biggest challenges you’ve faced with UX writing?

Opportunities and future projects

• Are there any existing problems or points of confusion for our users that you’ve come across that you believe UX writing can help solve?
• What upcoming projects are on your team’s roadmap that could benefit from UX writing support?

In the one-on-one sessions, I asked a few additional questions related to process and collaboration:

Process

• What processes do you currently have in place for requests and for working with designers and/or product teams?
• What has worked well?
• What areas are you working to improve?

Collaboration

• How might we work together?
• Are there any areas in your world that you think might benefit from UX writing?

I created a FigJam file to facilitate the sessions. I gave the team time to add stickies to answer the different questions. Then we discussed the answers as a group. After all the sessions were complete, I did an affinity mapping exercise.

Three major themes emerged. One was an opportunity for more consistency. Another was the need for education on how to work with UX writing. The last was the desire for guidance and documented writing best practices. These themes shaped the foundational work I did to set up UX writing at Codecademy.

Interested in running a similar session? I turned my FigJam file into a template. Feel free to duplicate the template from the Figma community!

Tip #2: Document your intake process

As the only UX writer on a team of designers, product managers, and engineers, things can get hectic fast. Taking time early on to create and document your intake process can help you stay organized.

A streamlined process that everyone can use to make requests will save you time (and anguish). Plus, it’ll help you establish UX writing as an official new discipline in your org.

Your initial intake process likely won’t be perfect—and it doesn’t have to be. You can (and should) iterate and improve as you test things out. My initial process started with a simple Google form for requests.

In addition to asking for general details about the project, I asked for:

• Relevant links, including product briefs and applicable research
• A requested completion date
• The product squad the request came from (for tracking purposes)
• Relevant business KPIs (for prioritization)

Once a request came through, I added it to a UX writing board in Notion. I like Notion because the Kanban board view works well for tracking progress on tasks. Plus, each task has its own individual page where you can save links, screenshots, and other documentation for future reference. I’ve since upgraded from a Google Form to JIRA, but I still maintain my board in Notion for documentation purposes.

Process is personal. So you may come up with something completely different than I did based on how you work (and what you learned from your own info-gathering sessions). But whatever process you land on, you’ll want to make sure your team is aware of it.

Host the details in a central location where they’re easily accessible. And don’t be afraid to remind the team of your process. I keep my new JIRA requests link handy so I can share it when I get requests via Slack or other channels.

Tip #3: Show the team how to work with you

Odds are that at least some of the designers, product managers, and engineers you’re working with have never worked with a UX writer before. So it’s also important, as part of your process, to help them understand how they can work with you.

My Notion hub includes documentation on how to work with UX writing (that I also link out to from my request form). It includes information about how people can collaborate with me (for example, I can be used as a consultant for projects that don’t require extensive writing but should be a partner for projects that require new language or information architecture). Plus, it includes some guidelines on when to bring me into the process based on the type of project.

When you’re just starting out, you may be left out of some conversations or brought into the process later than you believe is necessary. While it may be frustrating, it’s totally normal. Remember that the team is learning to work with you just as much as you’re working with them. And as you work together to solve complex problems, they’ll start to better understand the value you can provide and when and where to bring you into the conversation.

Tip #4: Equip the team to write better UI copy on their own

Once the requests start rolling in, you’ll quickly realize that as the only UX writer on the team, you won’t be able to do it all. But that’s ok! You can set the team up for success writing on their own by documenting and sharing best practices.

I started documenting best practices as requests came in. I got a request for a tooltip—I did a deep dive on best practices for writing tooltips and documented it. I got a request for an error message update—I documented best practices along with it. I did the same for confirmation dialogs, alerts, buttons and links, and more.

At first, I collected the guidelines in Notion, where they were easy for the team to find—and easy for me to share. Now, they live alongside our design system documentation too. A writing section in Gamut, Codecademy’s design system, includes UX writing best practices specific to our components, an accessibility checklist and guidance, and tips for writing useful UI copy.

In addition to sharing best practices, you can also share tools with the team to help them write more effective copy. One of my favorites is the Hemingway app—a staple for checking the readability of copy.

Similar to your intake process, you’ll want to make sure the team knows this guidance exists. Share guidelines in design critiques as you work on them. Create optional team training sessions. The more ways you can find to share your knowledge, the broader the impact you’ll have across your organization.

Tip #5: Learn from the community

You may be the lone UX writer on the team, but you aren’t alone. There’s a thriving (and very welcoming) community of content designers and UX writers out there. They’ve shared advice in books, they host inspiring conferences and events, and they connect over various Slack communities.

I recently rounded up the resources that were helpful for me during my transition to UX writing at Codecademy last year. Here are a few that stand out in particular if you’re the first UX writer on a team:

• UX Writing Fundamentals course from UX Content Collective: In the weeks leading up to my transition from marketing to design, I was dealing with some serious imposter syndrome. The course material helped me feel prepared to work on a design team.
• Strategic Writing for UX by Torrey Podmajersky: The 30/60/90 day plan at the end of Torrey’s book was instrumental in my approach to starting out at Codecademy. If you haven’t read this book, it’s a must.
• Writing Is Designing by Michael J. Metts & Andy Welfle: This book does a phenomenal job of outlining UX writing as a design discipline and shedding light on how UX writers and product designers should collaborate. It serves as super helpful context for explaining the role of UX writing to colleagues that may be less familiar.
• Content + UX community on Slack: This community of UX writers and content designers is thriving. The advice, frameworks, and experience that members of this space have shared with me have been priceless.

Being the first UX writer on a team can be a challenge. But it’s also a ton of fun. I love learning from my teammates—and from the content design community.

Megan O’Neill is a UX writer at Codecademy. Connect on LinkedIn.