Growing a UX Writing Practice

You can push forward your culture without waiting for someone to be responsible full-time. These are some of the strategies that worked for us!
Jay Mahabal
 — 
Frontend Engineer

You can push forward your culture without waiting for someone to be responsible full-time. These are some of the strategies that worked for us!

In early 2020, Lattice had just over 100 employees and there was little consistency in our application copy. We had ambitious plans to grow (we’re now over 400 people!) and knew that we needed our writing to be clear, anxiety-reducing, and accessible. 

At many companies, product managers or dedicated content writers determine what user-facing text appears in the product. At Lattice, engineers, PMs, and designers share ownership over what we build and are encouraged to continually push for improvement in the spirit of “Clear Eyes.”

To better serve our users, Amy Luo (Design) and I (Engineering) started building a UX Writing style guide and growing a UX Writing culture so that we could:

  • Reduce the cognitive burden on users by using consistent language
  • Make it easy for our teammates to do their work by providing clear copy guidelines 

This article shares some of the lessons we learned, even as we iterate and evolve our own process. Hopefully, it helps you build a strong UX writing culture in your organization.

Integrate into existing loops

It’s tough to create a brand new process, especially when people are used to their current workflow and are rightfully hesitant about anything that could slow down their shipping velocity. One way to account for this is to integrate it into existing workflows. 

Initially, most of our teammates weren’t referencing the style guide as they worked, even though we included links to it in our onboarding materials, pull request templates, and sent out regular updates on our progress. 

One thing that was to call out fixes during an already-established review period like design critique or a pull request. Giving feedback at an expected time ensures that it's taken in the best possible way and immediately actionable.

In addition, piggybacking off of an existing process prevented us from becoming a bottleneck and made it so that others felt comfortable contributing. Seeing public comments on a pull request resulted in other engineers picking up on what to improve and suggesting changes on other PRs in turn. This is the positive feedback loop we want to encourage! 🔁

Screenshot of a Figma comment asking for copy guidance

One way we tried to reduce the nit-picking nature of our feedback was to call out not just what was wrong, but to provide an alternate solution. This makes it easy for our teammates to incorporate the suggestion without slowing down the project.

Screenshot of a Github comment providing alternative copy suggestions


That said, one behavior that we wouldn’t recommend is to lurk on every pull request and fix every issue. You can’t fix every sentence and even if some less-than-ideal copy gets into production, your time would be more impactful elsewhere. Staying the course and building a strong culture is more important than individual fixes. 

Dig the “pit of success”

We want to make the easiest approach that people take the most correct approach. We call this digging the "Pit of Success." It's more effective to spend time helping others instead of fixing problems one-by-one yourself. You don’t want to become a bottleneck for progress as people await your feedback. This especially applies to Lattice because we’re growing so fast; scaling our impact will be the key to our success 🔑.

To mimic what our CTO Eric Koslow has said about our codebase, “Our efforts to improve the next million words we write will be vastly more impactful than our efforts spent trying to improve the current ten thousand”.

If possible, invest in tooling that can automate some of these checks. For example, we’ve leveraged custom ESLint rules to find opportunities for better link text. These errors could be automatically fixed and forgotten, but we made sure to use the opportunity to teach developers about the context and the “why” behind them as well.


Screenshot of VSCode with an error for not having descriptive-enough link text

Evolve your process

In addition to providing a style guide, Amy and I also wanted to be available to answer any questions in person. At first, we met once a month for an hour and allowed people to add agenda items before the meeting. This meeting ended up being too big to be useful as we found ourselves cancelling often since we couldn’t commit to staying the entire time, even if we had an item on the agenda.

We iterated and now have a half-hour meeting every two weeks. The meeting is framed as an “office hours” where people can drop by with their questions. This made it much more casual and much more effective at what we’re trying to achieve. At the end of each session, we make sure to share what we talked about. This helps people understand what kind of support they’ll receive if they come to office hours.


Screenshot of a Slack message recapping what happened during Office Hours

Of course, people can also ask questions asynchronously in that same Slack channel if they can’t make office hours. This is great for those in different time zones or with busy schedules. 

Another lesson we learned is that sometimes it’s not worth it to prematurely formalize your work or create unnecessary processes.

For one of our first projects we created Jira bugs for the relevant teams who owned those sections of the codebase, but the tickets sat deprioritized in those teams’ backlogs. These super-easy and low-risk bugs didn’t need to have this level of process associated with them when we could fix them in the same amount of time it took to make the ticket.

There’s definitely value in submitting a bug to the team that owns it, both for visibility and helping the team build their muscles. In terms of getting things done, it’s unlikely to be effective. Returning to the concept of the pit of success, we should be making things easier for teams and not adding to their backlogs.

Establish guidelines

A clear set of guidelines can help you work through problems with no immediate obvious solutions. 

For example, we recently ran into a problem when deciding how to frame the many-to-many relationships between employees and compensation bands. Do we assign employees to bands or do we assign bands to employees? Both are technically correct!

Ultimately, we landed on framing this as assigning bands to employees. One of our guidelines is to be human-centric and the latter framing fits that better.

Another guideline that's been helpful has been to be “clear and descriptive, but not excessive.” We tend to avoid punctuation at the ends of sentences unless it's a part of a larger paragraph or the sentence is complex enough to warrant it.

Because we’ve stripped away the unnecessary punctuation in most places, when we do include punctuation, it stands out and adds pop to the copy. This allows us to intentionally inject personality, while keeping the rest of the product buttoned-down.


An empty state with the title, “Quick, while it’s still fresh!”

Find an executive sponsor 🌟

Institutional support has been key in pushing forward — and maintaining — this culture of clear and effective UX writing.

Amy and I were lucky to have the support of Jared Erondu, VP of Design, from Day 1. One of the most effective ways he showed his support was by giving us public praise in Lattice. This had two main benefits. First, it raised the visibility of our work and made it easy for us to broadcast what we had been working on. Second, the recognition signaled to the rest of our colleagues that our work was valuable to the company.

Having a senior leader appreciate our efforts also helped us navigate imposter syndrome. Neither Amy nor I are UX writers and this isn't something that's a part of our primary jobs. How could we dictate to others the “right” way if we weren't ourselves confident? Jared helped us overcome our doubts and realize that we didn't need to wait for an official UX Writer on the team.

“Anything you do will be an improvement on what was there before, because you care about it and are trying to be thoughtful. You shouldn’t let perfection get in the way of progress and since no one has ownership over this area, it’s better to have someone who is interested in owning it take it on than continue to have no one.” — Jared

Thanks, Jared!

What’s Next 🔭

We’ve started having a quarterly sync with leaders from the Customer Success and Marketing teams. This gives us an opportunity to ensure we aren’t duplicating work and lets us align on how we approach site-wide conventions.

We’ve also started to measure the value of our processes in quantitative terms. We’ve run bi-annual surveys for the organization and are excited to take the feedback and get better 💪.

If you’re interested in creating impact through writing and making work meaningful, join us at Lattice.

Special thanks to John Saito who joined us recently and has already had a major impact on our writing.


more articles