How to work with an engineering team as a UX writer

Some preliminary observations

Engineers nocturnally-inclined creatures with a predisposition for intense focus. So approach them slowly, and make sure you’re not disturbing one of their genius flows with your blinding laptop screen or phone.

Sometimes you will feel like they speak another language than you, and it’s because they do. Engineers, like all professionals, will speak in jargon that you may or may not be familiar with, but eventually it will start to make sense. But not the jokes. The jokes will never make sense.

Working with an engineer will feel different than working with a designer because the two gravitate towards different work flows: designers are more likely to abandon an entire conceptual approach in pursuit of an alternative that may or may not work, whereas engineers working on a developed concept will work in sprints guided by chronology and logic in order to reach an end goal.

No judgement or value assigned to these processes — just know they are different.

Because engineers work extremely hard to complete a product towards the tail-end of a project cycle and need to face deadlines like true heroes, we need to work with them in a way that best suits their processes so that we can all succeed. And because copywriters wear several hats and touch a project throughout the entire project life-cycle, it makes sense that you review copy and overall experience throughout development, and not just at the beginning or end of it.

This means you need to continue to integrate yourself in engineer-speak and culture by using engineering tools. I find using tools like GitHub and Pivotal Tracker help engineers reach out for approval when they need to, and let you tell them something is wrong when they are able to address it. In other words, these tools let them address issues when it’s in context for them, so you’re not bombarding them when they’re working on another feature or coding sprint. Plus these tools are easy enough to use for non-engineers.


What it does

GitHub allows developers to work on separate pieces of code that can be later be merged to form one super code repository (that’s a fun word, “repository”). When engineers need to “merge their branches”, they should seek approval from the designer, copywriter, and another engineer to ensure that their code is accurate and that what they are creating meets design and copy expectations. This is known as creating a “Pull Request” or PR, and you can be set up to be tagged in PRs that are relevant to you.

How to use it

Proper PR etiquette involves

  • Being provided with screenshots so you can see how the copy looks within a context that makes sense
  • Being provided with a build on a test device when providing screenshots is unfeasible

During this QA process, if you have any concerns, the engineers are in the right mindset and workflow to address it. Until you give them that sweet sweet check mark of approval, they won’t merge.

NB: When an engineer asks you to take a look at a PR, do it as soon as possible so that you are not blocking their workflow. They can’t really move on until you do.

What it looks like

You should be set up to get an email when you are tagged in a PR. You can open up the PR in GitHub from your email to see the ticket and associated screenshots. Once you are happy with the copy, give the checkmark.

Keep in mind that after you give that checkmark, you can still make changes. The checkmark simply communicates that at this point in time, you have acknowledged the existence of this product vision. It doesn’t mean this product vision is set in stone.


What it does

At its most basic level, Pivotal Tracker is a communication tool.

Pivotal Tracker, well, tracks the progress of a project. User stories (e.g. As a user, I should be able to log into the app) can be accepted, rejected, or delivered by the QA team until all project stories are eventually delivered and the project is complete.

Pivotal Tracker promotes transparency and allows team members to see who is working on what, how much work is being done, how much work remains, how fast the project is moving, and when to expect completion.

The nature of the tool warrants that when team members report bugs or ask questions about a story through Pivotal, it will eventually be addressed because the story will remain unfinished if it isn’t. So it’s a great way to track and document issues that need consideration. Think of it this way: if the issue isn’t in Pivotal, it doesn’t exist.

How to use it — conceptually

Along with responding to Pull Requests, you should regularly be looking at builds of the product. Sometimes when you see the entire app at play, you may notice something that you didn’t when you weren’t looking at the “big picture.”

If you find a bug, you can create a story in Pivotal Tracker and log it as a ‘bug’ after confirming that QA hasn’t already found and reported it. This way, the engineer can address it when they are ready to by looking up all the bugs that need to be tackled.

If you feel like something needs to change UX-wise, talk to the designer and product manager. If they are in agreeance, you can create a story in Pivotal and log it as a ‘feature’ and the engineer will get to it when they can. Make story descriptions as clear as possible so that they are easy to reproduce and understand.

How to use it — technically

Get a tutorial on using Pivotal from a QA team member or engineer. Teaching Pivotal is beyond the scope of this article, and I ain’t no scope creep.

Final Thought

Use of these tools isn’t meant to replace face-to-face interaction with engineers. If you need to talk to them, talk to them!

Have any other recommendations for working with engineer? Comment below.