4 foundational lessons learned in 4 months as a new UX writer

Find success as a new UX writer with these tips

So you’ve finally landed your first role as a UX writer.

You might’ve just started your new gig or you won’t start for a few weeks yet. Either way, you probably want to know what to expect on the job. You might have several questions about how to perform well in your new role. Questions like:

How do you get up to speed with all of your company’s products, voice and tone guidelines AND show people you actually know how to string a decent sentence together?

How do you know when your content is “done, done”?

How do you present your work to product and design stakeholders?

Well, buckle up. As a newbie UX writer myself, I’m just past my 4-month mark in my new role. Coming into the field with limited content design experience and little understanding of my design domain in payments & protections, I’ve learned four fundamental lessons in how to be an effective UX writer.

Today, I want to share those lessons with you.?

You’ve gotta start somewhere

My first week as a UX writer was one of the most painful experiences of my life.

No, my coworkers didn’t boo me out of my first meeting. I wasn’t yelled at by my manager for a simple mistake. Instead, I caught my first bout of COVID-19 less than 24 hours before my start date.

Let me tell you, trying to learn a new job, meet new teammates (virtually of course), and pay attention to Design Town Halls is a near impossible task when your throat feels like sandpaper.

But when you’re new to the content design field, you need to persevere and show that you’re willing to do whatever it takes to learn and get up to speed in your new role.

I spent my first few weeks setting up one-on-ones with other UX and content designers on my team. I learned it was normal to feel an urge to be productive right away. But I also felt reassured that it took my teammates some time to understand their domains and contribute.

As I was meeting my teammates and learning about their processes, I absorbed eBay’s voice & tone, familiarized myself with and contributed to edits of our content style guide, and learned the norms of our content critiques and design team sprint planning.

It was so much to learn and I hadn’t even started an official project yet!

In order to survive your first few weeks on the job, you need to be patient. Take as much time as you can to understand the voice & tone you’ll be writing in. Understand how you can help coworkers and where you can best contribute once you understand things better.

It was these early meetings and study sessions that set me up for success when I began my first project.

Key lesson #1: Take time to understand the people, processes, and goals related to your role.

Wait, is this any good?

You can only go through onboarding materials and intro meetings for so long before you’re expected to complete some meaningful work.

My first project was a feedback survey for sellers that chose not to complete enrollment in a product that allowed them to spend money on our platform instead of having it paid out to their bank account.

We needed to uncover why these sellers didn’t finish enrollment in the program from a variety of hypotheses. It took multiple discussions with the PM, product designers, my boss, and reviewing the enrollment flow of the product for me to have a firm understanding of the possible reasons sellers wouldn’t want to complete enrollment. Even after these discussions, I had a hard time creating survey responses that got to the heart of the problem sellers were facing.

I remember a tense meeting (at least for me) with a PM where he didn’t think the content I’d created for the survey responses had hit the mark.?

My boss pulled me aside after the meeting and spent the next hour with me talking through all the possible reasons a seller wouldn’t have wanted to enroll in the program.

We had data on where sellers were dropping out of the enrollment flow. We’d aligned on the other top reasons we thought a seller may not join. But it was only when my boss and I actually spoke what we wanted the responses to be out loud that I realized where I was going wrong.

Instead of writing the survey responses from a user point-of-view, I was writing them with the company’s goals in mind.

I was more focused on the business goals and less concerned with the user goals.

Speaking about the user’s experience out loud allowed me to create much more focused responses for the next review session with the PM. And instead of showing the content in the design mock-up, I presented the responses one-by-one in a Google Slides presentation, with the proposed content and a short snippet about the rationale and what hypothesis it solves.

The PM and his manager were much more agreeable to my suggestions using this approach, and I worked with my designer to update the experience and hand off to engineering.

Key lesson #2: While a project is only “done” when handed off to engineering, getting a “yes” from your PM is your most essential task.

Can I chime in here?

A big part of working in UX is presenting and getting feedback on your work.

I presented my work and thought process plenty of times during my HR career, but never on a daily or weekly basis. Because UX is such a collaborative field, it takes multiple perspectives and frequent iteration to ensure we’re delivering on a great experience for users.?

I’m still trying to get comfortable with the frequency of feedback I receive on the job.

For my biggest project to date, one of my challenges was naming an in-product seller financing repayment feature for one of our European markets.?

Everyone seemed to hate the existing name we were using for the feature, but because of a bevy of legal restrictions, we were still using it throughout the design. Undeterred, I conducted competitor research, tested out new names with design peers, and built a case for some naming ideas that would make the experience easier to understand for sellers.?

When I was finally ready to share my latest thinking with European legal partners, the lawyer I was working with told me that my favored name wouldn’t work.

While the feedback was valid (the translation of the word had other meanings in both the broader financial industry and in the country we were creating the experience for), that didn’t make the feedback any less painful to swallow.?

Instead, it motivated me to work harder to find more suitable terminology, which we eventually did when we aligned our marketing and in-product terminology. Learning that the feedback from my content, design, legal, and product partners wasn’t about me as a person, but about improving the user experience, made it easier to process.

Key lesson #3: Don’t take feedback personally. The point of UX is to arrive at the best solution possible for a user. Keep your ego out of it.

Show me what you’ve got

Speaking of presenting, expect to do a lot as a UX writer.

Now that you know not to take feedback personally, you can sharpen your storytelling skills to convince stakeholders that your design solution makes life easier for your users. I’ve found my content colleagues are most successful in getting their solutions to stick when they have a thoughtful content strategy to back up their work. The few times I’ve built and presented content strategy have been among my favorite work as a UX writer.?

Here are some pointers to consider when presenting during a content review or strategy session.

1. Provide context

Don’t spend too much time on this (I’m guilty of adding details about a project that PMs and design leads have already heard a dozen times), but it’s important to give people a quick overview of why you’re building what you’re building.

2. Get clear on the business and user goal

Working on this product or feature should solve a pain point or help a user accomplish a key goal. Take every opportunity to reiterate the user goal and how this solution will accomplish it, as well as reiterating how solving this problem will benefit the business.

3. Show your preferred solution

Don’t show your stakeholders every solution you ever considered. Decide on the best option that accomplishes your user and business goal and present that.?

4. Explain why

You should have a point of view on why the solution you’re presenting is the best one. Tell your stakeholders how it makes an experience clearer for your user, how it saves them time, or how they can meet the core needs your product solves faster. Don’t be afraid to discuss how it’s better than other solutions you’ve considered.

5. Allow time for feedback

Once you’ve made your case, allow time for discussion. Others may not agree with what you’ve said and will ask you to consider other options. Sometimes, you’ll hear that everyone loves what you’re proposing and you can start implementing (though don’t expect that to happen too often). Either way, you should have clear next steps.

6. Save the rest for the appendix

You may have killer competitor analysis to share. Perhaps you have a host of other feature names you considered showing in case you received negative stakeholder feedback. Save all of your fun goodies for the end and let everyone read at their leisure if they want. You can always jump to one of these slides as support if you need to.

Key lesson #4: Presenting with a strategy proves the value of content and UX writing. It’s how you go from serving as a “wrist” to a full-fledged design partner.

Final Thoughts?

While there are plenty more lessons I’ve learned as a UX writer, these 4 are key issues I believe affect most of us at the beginning of our content careers.

Give yourself plenty of time to understand your company, your colleagues, and your role. Know who you need to get a “yes” from on your work. Don’t take feedback personally. Have a clear strategy in mind when presenting your work.

If you can nail these skills within your first few months, you’ll be well on your way to a successful UX writing career.

What other pointers do you have for newbie UX writers?