The new basics: questions content designers should be able to answer in 2026

As the year heads into its final quarter (ack), it feels like a good time to take stock of where we are as an industry. 

This year’s Button conference was a good piece of inspiration. The case studies people share there are great examples of how increasingly complex and technical work is becoming just part of everyday content design jobs.

Our recent AI survey supported this: most content designers say their jobs are becoming more technical.

Now, the job of content has always involved more than writing interface copy. But the range of systems a content designer might need to understand is getting wider. You may be asked to shape an AI assistant’s behavior, define language rules for a component, or work on establishing content rules that apply across a range of different states.

One example I keep going back to is Ademola Adepoju’s job ads analysis from earlier this year. He pointed out that 87 out of 100 job ads requested systems thinking skills, 65 asked for technical skills, and 52 asked for AI skills.

LinkedIn isn’t real life (thank goodness) but there are a range of posts from people like Christopher Greer, Adedayo Agarau, Laura Costantino, Ayelet Kessel, Jody Allard, and others who share a wealth of information about their jobs and how they’re changing. 

All of these signals point in a clear direction: the “floor” for content skills is changing. 

So we thought we’d put together a key list in 4 key areas we believe content designers need to focus. Of course, this is on top of all the basic skills you’d expect for a UX writer, like the ability to understand how content works within components, strategy, etc. 

You don’t need to know everything in them, but can you explain how each one affects a decision you might face at work? If not, it might suggest there’s something for you to learn.

How models behave

Content designers have always shaped how products communicate. We have to think about what information the product uses, what it does when information is missing, and how we know whether its answers are good enough. All that good stuff. 

Now, however, more roles demand basic abilities to guide how models behave.

You can see that shift in job ads. New roles describe working with prompts, training data, and the model itself. 

Say your team is building an assistant that answers questions about a financial product. Someone asks you to make its answers more reassuring. Then a user asks, “Am I guaranteed to qualify?”

The assistant needs to know the eligibility rules and whether it has enough information to apply them. It needs to avoid promising an outcome it can’t confirm. It may need to ask a follow-up question or direct the user to a person. A warmer tone won’t solve any of those problems.

If the answer is wrong, where would you look? The assistant may have received the wrong source material, failed to use the material it received, or followed an instruction that pushes it to answer when it should say it doesn’t know. 

This is all fairly simple stuff, but it isn’t easy. Understanding model behavior is about balancing a model itself, system instructions, and other data. It might even involve working with engineers to fine-tune a model for a specific purpose using purpose-built benchmarks. 

This is also where evaluation comes in. You could test the assistant with questions from eligible customers, ineligible customers, and people who leave out a crucial detail. You would check whether it gives the right next step without making an unsupported claim. You would also read the answers as a content designer: an answer can be technically correct and still leave someone confused.

Want to stay up to date? Ask yourself:

• Do you know how an LLM produces text?
• Do you know why different models produce different answers to the same prompt?
• Do you know what a system prompt is?
• Do you know what a context window is and what happens when it fills up?
• Do you know the difference between a model, a product built on a model, and an agent?
• Can you express voice and tone as instructions a model will follow?
• Do you know what an eval is, and how to write them?

Building with AI

Using AI to draft or edit your own work is useful. But a growing part of content design is building something that helps other people work better: a tool, a set of reusable instructions, or a workflow that solves a recurring problem.

Jody Allard recently described a content designer who had built two such tools while doing his regular product work. One helped product designers draft against his team’s voice, tone, and terminology standards before bringing the work to content design for review. The other tracked terminology decisions across Figma and the company’s chat tool.

We’re seeing this more and more. In our AI Accelerator classes, we’ve seen several different content designers create tools for tracking and checking whether content is applying to specific styles and rules. Christopher Greer’s work on Dante at Stripe is a good example of this.

Of course, merely building artifacts sits on a spectrum. It’s very easy to ask AI to build you something, but whether that “something” actually is robust, and works appropriately, is a different matter.

That’s the skill that matters more than just “building with AI.” You need to describe a problem clearly, give the tool reliable material to work from, test it against edge cases, and work out who will maintain it. A prototype that impresses people for a week is very, very different from a tool the team can depend on long-term.

Ask yourself:

• Do you know the difference between using AI to do a task and building something that does the task for other people?
• Do you know how to turn a task you repeat into reusable instructions a model can follow?
• Do you know how to give a model reference material, like your style guide or terminology list, so it works from your standards?
• Can you describe a problem clearly enough that a model can build a working solution?
• Do you know what AI coding tools can build for you, and where you still need an engineer?
• Do you know how to share what you’ve built so your team can use it?

How content gets into the product

A lot of content work still happens in Figma, but Figma is really only one stop on the way to the product. It’s not the product itself. 

Now, yes, content designers will have varying levels of access to code repositories. But understanding where your content lives, how it’s managed, how it’s reviewed, and so on, can give you an enormous amount of power and influence that you didn’t previously have.

Just as Figma made it easier for UX writers to work directly in design rather than using copy docs, LLMs are making it easier for us to work in code. You can ask a tool to find where a message lives, explain how it’s used, and help propose a change. Yes, GitHub might sound and look pretty scary at first glance, but it actually unclocks a huge amount of power. 

The list of job ads we linked to earlier found that 57 of the 100 postings mentioned working with engineers. It does make one wonder how much better that work could be if we knew our way around a repo: where product strings are stored, what else uses them, and how a proposed change gets reviewed.

This leads to even more impactful conversations, like discussing whether your strings might be better suited to key-value pairs – which could unlock even more flexibility.

We don’t really have an excuse anymore. Understanding how repos work is now easier than ever, and LLM-based tools make it easier for content designers to own the content end-to-end. The question isn’t why would we learn this…given the amount of influence available, why wouldn’t we?

Ask yourself:

• Do you know how your words travel from Figma into shipped code?
• Do you know the difference between hardcoded text and key-value strings?
• Do you know how variables and plurals work in a string?
• Do you know what a repo is?
• Do you know what a branch, a pull request and a code review are?

Structured content and systems

We’ve been talking about systems thinking in content design for years. But what does it actually mean when the content itself has to work as part of a system?

Think about how often the same information appears across a product. A subscription plan might have a name, a price, a short description, a list of features, and eligibility rules. Those details could show up on a comparison page, at checkout, in an email, and in an answer from a support assistant.

This work is showing up quite explicitly. Earlier this year Netflix published a job ad that asked for someone who can connect language standards to things like a JSON schema, metadata pipeline, or product component. That’s a specialist role, of course. But the underlying question applies to plenty of less specialized jobs: how do you make a content decision hold up when dozens of people and systems use it?

It can be hard to describe what “systems thinking” actually means, but essentially it’s just about understanding how content is stored and moves across a product. 

And AI makes those decisions more pressing. If an assistant draws on your product information, will it find the current eligibility rules? Can it tell an approved fact from an old piece of marketing copy? Giving it access to more content won’t help much if that content contradicts itself.

So when someone asks you to “think in systems,” ask where the information comes from, how it’s structured, who owns it, and how a change makes its way through the product.

Ask yourself:

• Can you break content into patterns and parts, like a title, summary and body, that different screens can reuse?
• Can you read a JSON file or a schema?
• Do you know how a design system component sets rules for its text, like length limits and required fields?
• Do you know what design tokens are, and how terminology can be stored as data?
• Do you know what a taxonomy and metadata do in a product?
• Do you know how conditional or personalized content is built with logic?

Where to start

Looking at this list, you might feel like you need to learn five new disciplines at once. You don’t. Start with the part of your job where you keep running into a wall.

Pick a single problem, and see it through to the end. Ask where the information comes from, how the product uses it, and who can change it. When you reach a point you can’t explain, you know where to start!

/**
* UXCC: “The new basics” self-check widget.
* Use it in any post or page with the shortcode [uxcc_new_basics]
* Settings: run on the site front-end only.
* The widget is plain HTML and CSS (no JavaScript). Edit the questions or links below.
*/
add_shortcode( ‘uxcc_new_basics’, function () {
return <<<'UXCC_NB_HTML'