After 2 years in a hybrid role as a UX writer and Localizer embedded in the R&D department of an engineering-driven company with no UX Team, I made the switch to become a full-time UX Writer. I chose Doctolib, a digital health company and France’s largest unicorn, to hone my UX skills and learn from experienced UX Writers and Product Designers.

When moving to a new role with entirely new references and methodologies, things can get messy at first. This is especially true if one is working fully remotely like I was (and still am), since communication with teammates can be harder to establish in the early stages.

In my first 90 days, I focused on:

1. Building trust with teammates
2. Making my first contributions impactful
3. Building a sustainable work process

🧘‍♀️ 0–30 days: Observing

I tried to be patient and take time to observe while I let all the new information soak in. Here are a few things that helped me at this stage.

Identifying partners

During my first few weeks at Doctolib, I had the opportunity to meet most of the people I would come to collaborate with over informal coffees. But meeting people is only the first step.

I made a conscious effort to identify who my allies could be within the Product team, by taking notes of who had strong opinions on copy, who was interested in learning more about UX Writing best practices.

To start building a relationship, asking for help is usually a great idea. I asked teammates questions about the new tools I was learning to use, or if they could explain how a specific feature works, or who they thought I could contact about a given question I had. I was mindful not to overload the same person with questions, and tried to distribute my questions to the relevant teammates.

Asking naive questions

Having a good understanding of existing features or ongoing projects is essential for UX Writers to contribute to the design process. A big part of your job is about asking every possible question, especially the ones that might have unintentionally been left out. When you’re new, it may be hard to ask questions because you’re unsure if they’ll appear stupid to the others in the room. But framing you questions as naive ones holds a lot of benefits. It can help everyone align by uncovering disagreements on unspoken information or implications.

Naive questions help everyone align by uncovering disagreements on unspoken information or implications

Asking questions show you care about a topic, and that you want to make sure you are on the same page as everyone else. Naive questions show the rigour in your thinking, and are respectful. I typically frame my questions like this:

• Is there a reason why you decided to…?
• I’m not sure I understand why…, can you explain?
• I might not have all the context here: can you tell me why…?

🕵️‍♀️ 30–60 days: Making sense of things

Building trust through collaboration

Even though I felt like I couldn’t help my teammates much during the first weeks on the job, I realized I could bring something they may be missing: a fresh eye to help everyone take a step back and get a new perspective on existing features and work processes, through the lens of UX Writing.

To make sure I explored the product and became more familiar with it, I conducted a UX Writing audit and presented it to Product Managers and Product Designers of one of the product areas or “domains” I worked on. This was a chance to show others how I could contribute to improving our user’s experiences through content, and to remind everyone of UX Writing best practices already included in Oxygen, our design system, so they could hopefully apply them themselves in the future. I structured my presentation around 3 main areas where I thought teams could improve, and made sure all my feedback on our product was expressed respectfully.

This presentation turned out to be a good ground for conversations during the session and afterwards. Product Managers and Product Designers would later refer back to it as we worked together on projects.

Building confidence

Because I work fully remotely, it felt harder at first to get feedback from my teammates on how I was doing. I decided full transparency with my manager was how I wanted to create a space for honest communication, that would later ensure I received the support I needed.

Over my first months, I used face-to-face conversation over video calls as much as possible, and asked for frequent feedback from my manager and teammates. Oftentimes, I over-communicated on my impressions, my own understanding of situations and my doubts, as well as on how I felt in the role.

Building a routine

As a UX Writer, I first commit to supporting the feature teams of my domains in crafting product microcopy. But I also contribute to building more visibility and more tools for the UX Writing discipline through our glossary and design system guidelines. To reflect this, I structured my agenda with time blocks and routines to make sure I got proper focus time for each type of task.

⛵ ️60–90 days and beyond: Finding a cruising speed, and iterating

As I was starting to settle in my new role, I had more visibility and clarity to step back and assess the situation. I focused on 2 things.

Less projects, more quality

My workflow had largely been influenced by others at this stage, as I was mostly reacting to requests from Product Designers and running from one project to the next. I realized I was struggling to prioritize the right projects and not doing a great job at following up on tasks and bringing transparency to stakeholders on the status of my work on copy in projects. I’d jump on a project, help out, then jump on another project, and pretty much forget about the other one until someone pinged me again. I knew I could have more impact by actively deciding which projects and priorities to focus on, and better communicating on my current workload and capacity.

To do that, I leant on the Owner|Partner|Consultant framework our team was starting to establish.

In Owner projects, the UX Writer takes full ownership of writing the source copy from the project kick-off. In Partner projects, the UX Writer collaborates with the Product Designer and PM to write the source copy once the designs are in low-def. In Consultant projects, the UX Writer provides support by reviewing the source copy if requested by the Product Designer or PM.

I asked to prioritize projects with Lead Product Managers for each of my domains. We sat down with my manager and the lead Product Managers at the start of the next quarter to make sure we had a clear overview of the projects for the months to come, and decide together which should be prioritized as owner, partner or consultant projects. This meant I was more confident explaining to Product Designers why I wouldn’t be able to dedicate more than a 1h meeting to a project I wasn’t only consulting on. It was also easier to explain why I needed to be invited to important meetings with both Product Managers and Product Designers on Owner and Partner projects. Lastly, this framework meant I could be more consistent in how I prioritized tasks, since it provided 3 levels of priority depending on the role I had on each project.

I prioritized meetings to make time for better focus time. For teams where I was working on Owner projects, I started attending the feature team weekly meetings, because that was where concrete design decisions were taken. For other teams where I mostly worked on Consultant projects, it was enough to catch up on the key info shared during both the domain and feature team weeklies asynchronously or during my 1:1 with the Product Designer.

Expressing my needs and making adjustments

I realized I needed other people to make adjustments in their way of working to adapt to my own needs.

Here are some of the things I needed:

• Clearer briefs: before jumping to the mockups in Figma, I wanted to have more time to understand the problem at hand, and what decisions had already been taken, consciously or not. This was especially true for Partner and Consultant projects where I was joining projects already well underway. When Product Designers contacted me about new projects over Slack (for some, our 1:1 only occurred every 2 weeks), I started asking the same list of questions to gather basic project context, following my team’s Asana task template. We figured that key points that needed to appear in the ‘Details’ section could be shared asynchronously before discussing the project in more depth in a meeting.

• More actionable feedback from Product Managers, and a clearer, more streamlined validation process. A Product Designer from one of my domains felt the same need, and suggested to create a dedicated Slack channel to help us get the type of feedback we needed, at the right time. This helped centralize conversations around design validation with all relevant participants, which meant we were able to implement feedback quicker, and everyone could refer to a single channel if they needed to go back to the decisions that had lead to updates in the design.

For more actionable tips on how to improve UX Writer’s collaboration with Product Designers and Product Managers, read my former colleague Chiara Angori’s article.

If you’re about to start a new position as a UX Writer, consider taking the time to observe and use your fresh eye, investing in relationships with new teammates first, and aiming for a sustainable work process, not the perfect one.

Thank you to Flavie Journet for the lovely illustration, and to Chiara Angori, Hannah Sheeran and Michael Winnington for reviewing this article.