AI doesn’t always live up to the hype, but it’s undeniable that access to these new tools is blurring the line between design and code and changing how we all shape our products. Suddenly, teams are realizing the need for structured content systems, because AI can’t function properly without them. Content designers are going from asking how to get a seat at the table to asking what more we can do with our seat, now that we have one. 

Content design has never been just about writing — it’s always been about design, with language as our primary medium. But in practice, the role can be misunderstood by our peers. Who hasn’t been brought in to do the words after the layout is already fixed? 

Even small changes, like correcting a typo, felt expensive and time-consuming when they were dependent on engineering. Changing language in the user interface meant opening a Jira ticket, waiting days or weeks for it to move through a backlog, and hoping it would eventually get prioritized. Our autonomy was limited, as content needs were constantly being weighed against the roadmap.

That friction shaped how I worked. There was a lot of pressure to get things exactly right the first time. I’d agonize over individual words and phrases, because I knew it would be tough to change them later. I was spending more time generating and refining copy than on the design parts of content design — embracing ambiguity, experimentation, and iteration over time.

For years, I’ve been wishing we had an easy way to manage user-facing strings (individual pieces of text that people see in the product). But whether we went with a third-party tool or built one ourselves, setup would have been a huge investment of time and money to solve a problem just for our little team. I was never able to make an effective business case for a content management system (CMS) or even a basic strings manager. 

All of that is still true. It doesn’t make sense for internal engineering teams to build us tools that don’t have an obvious value for the business. It also doesn’t make sense for engineers to pause work on complex code problems to fix typos. 

What’s different now is that we don’t need to wait for engineers to do it for us. That movement from dependency to agency is what I’ve been the most excited about as I continue to explore the possibilities that come with AI.

A small experiment

A few months ago, a member of our Customer Service team alerted us to some inconsistent language. She had found capitalization errors and misplaced apostrophes in content about workers’ compensation insurance. In the past, we would have added the correct spelling to a Jira ticket and waited for it to get updated by engineering. I decided to try something different this time.

I cloned a local copy of our repository and asked Claude to search for the incorrect strings. In the past, we had to do those searches in GitHub, which can be challenging if you don’t know exactly where to look or how to structure your query. Searching for strings has been a bottleneck for us, so even this much was a huge step forward.

Using Claude Code, I was able to update the strings, push my code changes to GitHub, and open a pull request. With Claude’s help, it still took over an hour to update all of the related lines of code. Even though one hour is faster than not doing it at all, it’s still not a great use of anyone’s time. But it did help me learn more about how our system handles content.

Hidden complexities

We store user-facing strings in locale files, with one for each language we support. Each locale file is a long list of key/string pairs that look something like this: 

• “this_is_the_key” : “This is the string that shows up in the UI”
• “here_is_another_key” : “Another user-facing string here”

The key is what we use in other code files to tell the interface which string to display. In theory, if you change the string, the text is automatically updated everywhere the key is used. That should make it simple to update strings, but the reality is a bit more challenging.

The keys we use are always the same as the English version of the string, so they show up in our locale files more like this:

If we update the English string, then we need to update the key to match, which means we need to update the key in every locale file and in any other files where that key is referenced. And that key could be referenced in multiple files, in multiple repositories, so even a simple copy update can easily become a more complex project.

That complexity used to feel out of reach, in the domain of engineers alone. But working directly with it made it feel like something I could not only understand, but also participate in.

Building something new

With a deeper understanding of how strings are handled and which repos contain them, I teamed up with a product designer to finally build the strings manager I never thought I could have. 

Our tool makes it easy to search and edit strings. It uses AI to read through our code and provide context about where and how individual strings show up, so we don’t make edits that inadvertently break the experience. We can search through multiple repositories at once, and it opens pull requests for us with a single click.

The tool even runs an AI-powered check based on our style guide and glossary to prevent errors before they get to production. It’s one of the ways we’re transforming our static documentation into a dynamic part of our design system.

I’ve used it to update global errors that haven’t been touched in years and didn’t match our brand voice. I’ve used it for swapping out specific words when our glossary was updated. And I’ve used it to proactively search for inconsistencies before they get flagged by customers or our internal teams. 

Before having a tool like this, we weren’t able to do meaningful content audits without the help of an engineer, and changes like these typically gathered dust in a backlog.

So what now?

Less than three years ago, there wasn’t a widely recognized organizational need for systems to manage our content. Now we have a strings manager, and we’re working on structuring our knowledge content so we can implement a CMS too. And with these tools, I’m less worried about getting things exactly right the first time, and more focused on thoughtful iteration. I’m even looking forward to doing my next content audit.

Talking about a strings manager — a tool for searching and editing words — may seem ironic when we know that content design has never been just about words. But it’s one example of how we’ve been replacing dependencies with new possibilities. The strategic part of our discipline — the design process — is not dead. It hasn’t even really changed at all.

What is changing is how things show up on the surface in our industry. And as our industry evolves around us, we should all be asking what the future of content design looks like. If everyone can use AI to write “good enough” copy, and the lines between roles are blurring, where do content designers add value? I don’t think anyone has a definitive answer yet, but for me, it’s about getting closer to the structure and logic that determines how content behaves.

Now is the time to experiment and discover what it means to be a content designer in this new era. We can push boundaries and try new things — things we’ve always wanted to do that weren’t previously possible, and things we’ve never even considered before.

Should every content designer build their own strings manager? Of course not, but the point is that they can. We can all be using this moment to grow further beyond being “the words person” than we ever have before.