Sean Watson, ServiceNow
November 15, 2020

Integration between UX design and content writing is in the early stages of development at ServiceNow. Because of this, there’s a lot of opportunity to define processes in those relationships. The following are some key takeaways learned for successfully establishing a process that builds strong functional relationships across teams.

Perhaps the most impactful task you perform as a content writer is procuring information. There are several types of information required to perform a task. This information is typically acquired by meeting with a UX designer or a team of UX designers, and possibly a product or project manager.

What information is required to perform this task?

When you’re writing UI content for a feature, subtleties in the UI can influence the phrasing or structure of your writing. As I always say to designers, I prefer to have too much information rather than too little. Before your procurement meeting, obtain any mockups available (Invision, Miro, XD, etc.) that can be reviewed before the meeting. That way your questions in the meeting will guide to the nuances of the feature rather than introductory explanations.

What resources do I need to measure the quality of my product or argue for specific structural style?

UX designers view content writers as expert wordsmiths. My intention is to always reinforce that. I do this by presenting a clear process for completing tasks and supporting my writing with the authority of style guides (for example Microsoft Style Guide and MailChimp). Some features may have company or department-specific style guides. Learning of these can be a good question to ask the UX designer to comply with preset standards.

The UX designer is likely going to look to you to guide the process. Disclosing the process places the responsibility on you to guide the task to completion, which is what I find preferable. My process is to give the UX designer the expectation that I will provide several ways the content can be written. With my initial submission, I provide one sample with text that best incorporates the expectations stakeholders have. Then I include additional bullet points arguing word style, structure, and potential preferences. Ensure that you’re clear in your bullet points if you do this. The expectation is then created with the UX designer that the content can be refined over a couple of rounds according to content from the bullet points.

What are the designer’s and PM’s expectation?

Be sure to include all relevant stakeholders in the procurement meeting to identify expectations for the content you write. You can also make suggestions about the UI if you see design that could potentially improve it. Most likely the UX designer and development team will have already discussed the possibility, but the feedback can shape your writing further. This aids in the discovery of additional expectations.

One example of this is a dialog box that I thought could be a multiple-choice list. The UX designer asked the development team about it and learned that the responses will be used to create a multiple-choice list in the next release. As a result, I saw an additional expectation that the development team had and learned I needed to craft the content to obtain the desired feedback from users.

Content writing is a lot of fun. As technical writers, it provides the opportunity to learn about features you write about from different lenses that can supplement and compliment product documentation. My hope is that these takeaways provide ideas to begin or improve your cross-team experiences.