I'm Rishi Sharma, Lead Content Designer at Birdeye. I've been doing this job for eight years across SaaS, event tech, and AI products. In that time I've worked with PMs who got it immediately, engineers who assumed I was there to fix typos, and recruiters who listed "strong copywriting skills" as a requirement for a content design role.
All three groups had the same question underneath: what does this person actually do all day?
This post is the answer I wish I'd had written down years ago.
What is content design?
Content design is the practice of deciding what information a user needs at a specific moment, in what form they need it, and what it should let them do next.
That last part is the one people miss. It's not about information for its own sake. It's about what the information enables. A good error message doesn't just describe what went wrong. It tells the user what to do next, in the time it takes to read one sentence.
The discipline was formalized at GOV.UK around 2012. Sarah Richards, who built the content design practice there, defined it simply: designing content to meet user needs. But that definition is easy to misread as "write content that users like." It's not. It means questioning what content should exist at all, and in what format, before you write a single word.
A content designer working on a form isn't just labeling the fields. They're asking whether the form needs all those fields. Whether the order makes sense to the user or just to the database. Whether a tooltip is the right way to explain something, or whether the explanation signals a deeper design problem that copy can't fix.
What does a content designer do day to day?
Honestly, it varies by company. But across eight years, these are the things I've done consistently.
Sitting in design reviews before the wireframes are locked. This is the most important one. If I see a flow for the first time when it's already in Figma with real copy placeholders, I'm reacting to decisions someone else made. I can improve the words. I can't fix the structure. Getting in earlier means I can ask why a step exists, whether two screens should be one, and what the user is actually trying to do at this point in the flow.
Writing and rewriting microcopy. Button labels, error messages, empty states, tooltips, confirmation dialogs, onboarding prompts. This is the part most people associate with the job. It's real and it matters. A poorly written error message generates support tickets. A well-written one doesn't.
Here's a real example from my time at Cvent. We had a notification that read:
Your virtual vendor card request for GBP 400 has been submitted. Once approved, Mastercard will share the card details with abc@vendor.com via a secure email.
Your virtual vendor card request for GBP 400 has been submitted. You will receive your card details at abc@vendor.com upon approval.
The before version buries what the user actually needs: when will I get the card details, and where. The after version leads with that. Shorter, clearer, no passive voice, no unnecessary actor (why does the user need to know it's Mastercard sending the email?).
Building content systems. This is the part that scales. At Birdeye, I built the language system for Search AI from the ground up. That meant defining what terminology the product would use across every surface, documenting the rules, and making sure the dashboard, the landing page, and the onboarding emails all sounded like one product. Without that system, you get three teams writing slightly different versions of the same concept, and users who wonder if they're looking at the same data.
Running content audits. Going through an existing product and scoring every piece of copy against a set of criteria: clarity, accuracy, consistency, readability, action quality. At Cvent I built a full audit framework using Flesch-Kincaid scoring alongside a ten-dimension model. The point wasn't to criticize what existed. It was to make content quality something you could measure and track over time, not just a subjective call in a design review.
Pushing back. This one doesn't show up in job descriptions, but it's constant. A PM drafts banner copy that buries the key message in jargon. An engineer names a feature after an internal code name and assumes it'll make sense to users. A designer adds a tooltip to explain something that shouldn't need explaining. Part of the job is catching those things early and explaining why they matter, in a way that doesn't make people feel criticised.
What does content design own that other roles don't?
The structural decisions about content. Not just the words, but the logic underneath them.
Should this be one page or two? Does this feature need a label, or does the interaction make it obvious? Is this an error message problem or a flow problem? What information does the user need at this exact point, and what can we defer until later?
These aren't questions a visual designer is primarily trained to ask. They're not questions a PM always has time to ask. Content designers ask them by default, because the answers directly affect the words, and the words are what the user actually reads.
One way I explain it to new colleagues: visual design asks what this should look like. Product asks what this should do. Content design asks what this should say, and whether it needs to say anything at all.
How do you know if content design is working?
When I redesigned the Workflow Hub at Cvent in 2024, the goal was to reduce the confusion that was driving support tickets. We consolidated scattered workflow components, renamed features from internal shorthand to user language, and added a workflow map so admins could see how settings affected each other.
Support cases dropped 40%. Navigation clicks dropped 35%. SUS score went up 12 points.
None of those numbers came from writing better sentences. They came from making structural decisions earlier, questioning the information architecture, and getting content into the process before the design was locked.
That's what content design looks like when it's working. Not polished copy. Fewer support tickets.
If you're a PM reading this: bring your content designer in at the problem definition stage, not the copy review stage. You'll spend less time in revision cycles later.
If you're a junior UX writer figuring out whether to move toward content design: the difference is mostly about where you sit in the process. Start asking structural questions, not just copy questions. That's the shift.
And if you're hiring: the job description probably says "strong writing skills." That's necessary but not sufficient. What you actually want is someone who asks why the content exists before they ask what it should say.