“We are what they grow beyond. That is the true burden of all masters.”
— Yoda, The Last Jedi
I've been hearing the term product engineering thrown around quite a bit lately. More so now that AI is finding its way into our design processes. And at work, as we explore the next evolution of how our product and design teams operate, it's becoming part of the conversation. And naturally, being the curious content designer that I am, I started digging.
In simple terms, product engineering brings software engineering, product thinking, design, and user empathy closer together. The idea is that an engineer can take greater ownership of the product experience, from identifying problems and understanding users to building, shipping and improving solutions — sounds interesting.
Although, part of me couldn't help thinking that many product designers I've worked with have been doing elements of this for years. They've been involved in research, influenced roadmaps, shaped requirements and worked alongside engineers to bring products to life.
I guess, the difference now is perhaps how much of that work one person can do, particularly with AI helping to accelerate the process. But something stood out to me.
As our individual capabilities grow, what happens to collaboration?
I love collaborating with other designers, researchers, engineers and product managers. Not because I need someone to validate my thinking, but because they challenge it. They bring different perspectives, spot things I've missed and help shape ideas that are stronger than anything I could have come up with alone.
And to be clear, product engineering doesn't mean working in isolation. Good product engineers collaborate just as much as good designers. But I do wonder whether, as AI makes it easier for one person to take on more responsibilities, we'll start confusing the ability to do something with the ability to do it well — there's a difference.
Anyway, I'm getting distracted. This isn't a blog about product engineering. It's about something that popped into my head while exploring it.
If product designers are expanding their capabilities towards engineering, should content designers be exploring the same thing?
And, more importantly, am I already doing it without knowing?
Hold on, content engineering is already a thing?
Before anyone throws a dictionary at my head, yes, content engineering already exists. I'm not claiming to have discovered a new discipline. Although that would have made for a rather lovely LinkedIn announcement.
Content engineering is broadly the practice of designing, structuring and managing content so it can work as part of a scalable technical system, rather than treating every piece of content as an individual output.
It's the work that connects content strategy to technical execution. Think content models, structured information, metadata, reusable components, automation, APIs and governance. And this is important: content engineering didn't suddenly appear because someone gave ChatGPT a prompt.
The discipline has been around for years, particularly in organisations managing complex content ecosystems across different channels, platforms and services. It helps teams structure information so it can be reused, maintained, delivered and improved without having to rebuild everything from scratch.
That's quite a different challenge from writing a page of content. And it's also different from content operations, which focuses more on the people, processes and workflows that keep content moving.
To simplify things:
Content strategy helps define what content is needed, why it exists and how it supports users and the organisation.
Content design shapes information and experiences around people's needs, using research, structure, language and interaction design.
Content engineering helps create the technical structures and systems that allow content to work consistently at scale.
Content operations helps make the work repeatable and sustainable through processes, governance and coordination.
Of course, the reality is messier than four neat definitions. These disciplines overlap, and organisations approach them differently. But that overlap is what caught my attention. Because the more I explored content engineering, the more I started recognising elements of the work I've been doing.
I've always believed that content design is a design discipline, not simply a job title. And within that discipline, we have different roles and specialisms. UX writers, content designers, conversational designers, content strategists and people specialising in AI behaviour and prompt design.
We share principles, but the problems we're solving and the outputs we're producing can be very different. I've explored this in my previous writing about the evolution of content design. And working with AI has only strengthened that belief.
Perhaps content engineering isn't replacing content design. Perhaps it's another direction our discipline can grow into.
Then I started looking at my own work
At Moneybox, I'm the only content designer within our Product Design team. That comes with some interesting challenges. I work across traditional product content, user journeys, conversational design, and AI. And, if I'm being completely fair, I rather enjoy having my fingers in several pies.
One of the biggest opportunities has been working on Aurora, our AI-powered financial guidance experience. When I first started exploring conversational design, I thought I'd be spending a lot of time thinking about how an AI should speak. Its personality. Its tone of voice. How it asks questions. How it responds - and I have.
But what surprised me was how quickly that work moved beyond words. I wasn't just designing what Aurora said. I was helping define the system that determines how Aurora should behave.
We started by exploring Aurora's identity through workshops, bringing colleagues together to understand its personality, its relationship with customers and the boundaries it should operate within.
We explored what it means to be empowering without being patronising. Reassuring without offering false comfort. Knowledgeable without sounding like an overconfident financial influencer.
Those conversations helped me develop an archetype for Aurora, positioning it as a guide rather than an authority making decisions for customers. I've written about why AI needs an archetype before it needs a prompt, because I believe you need to understand the relationship you're designing before you start telling a system how to behave.
But an archetype on its own isn't particularly useful if the AI has absolutely no idea what to do with it. So I had to translate those principles into something more practical.
That meant developing a system prompt document that defines how Aurora communicates, structures responses, adapts its tone, handles different customer intentions and understands where its responsibilities end.
For example, we developed personality principles such as:
Helpful, but never vague.
Aurora should give customers clear, relevant information and help them understand their next steps.Inquisitive, but never invasive.
Aurora can ask questions to understand someone's circumstances, but those questions need a purpose.Knowledgeable, but never overconfident.
Aurora should explain financial concepts clearly without making unsupported claims or presenting guidance as personalised financial advice.
These aren't simply tone of voice guidelines. They're behavioural rules that need to influence how the system responds across different situations. And suddenly, content wasn't just something being placed into an interface. Content was helping shape how the interface worked.
The research that changed how I thought about the system
One of the biggest lessons came from our early user research. We tested the guidance experience with participants, and some interpreted parts of the experience as though a human Moneybox expert had created their financial plan. That was quite a significant finding.
We'd used language about financial expertise to build confidence. But some customers understood that language differently from how we'd intended. And in financial services, that distinction matters.
My first instinct as a content designer might once have been to rewrite the problematic copy. Make the disclaimer clearer. Change the headline. Remove language that implies a human expert has reviewed the plan. All sensible changes, and changes I worked on.
But as I started thinking about how the experience could evolve into a conversational interface, I realised changing the visible words wasn't enough. What happens when a customer asks Aurora whether they should buy a particular investment? What happens when they're distressed about losing money? What if they misunderstand the guidance and ask the AI to make a decision for them?
A disclaimer on the opening screen doesn't solve those problems. We needed to think about how the system responds throughout the entire interaction. This led me to work on a set of conversational rules and boundaries, covering how Aurora should:
Distinguish between objective guidance and regulated financial advice.
Acknowledge uncertainty rather than invent an answer.
Adapt its tone based on the customer's intent and situation.
Avoid language that implies inappropriate human expertise or authority.
Respect customer decisions rather than push them towards a particular outcome.
Recognise when a conversation needs to move beyond what the AI can safely provide.
Take tone of voice, for example. In traditional content design, I might define a principle such as be reassuring. That sounds reasonable. But what does reassuring actually mean to an AI?
Does it tell someone not to worry when their investments have fallen? Does it say everything will be fine? Does it give them a motivational pep talk? None of those is necessarily appropriate. So the principle needs to become something more specific.
Explain what is known. Be clear about uncertainty and risk. Avoid making promises about outcomes. Help the customer understand their options without making the decision for them.
That's something we can start translating into system instructions, conversation patterns and evaluation criteria. And those instructions need to be supported by technical safeguards and testing. A well-written prompt doesn't guarantee safe behaviour.
One thing I've learnt is that AI forces us to turn abstract content principles into decisions a system can actually follow and that a team can test.
That's where I started seeing the connection to content engineering more clearly.
Designing the conversation is only half the work
There's another part of the Aurora work that's changed my thinking. When designing traditional journeys, we're often working with a relatively predictable sequence of screens.
We can plan the content, map the interactions and anticipate where someone might struggle. But conversational design is a little different.
A customer might start by asking about buying their first home, suddenly switch to pension contributions, then ask whether they should withdraw their savings. They don't necessarily follow the beautiful journey we've spent three weeks mapping in Figma.
So I've been exploring how to design reusable conversational patterns rather than treating every potential exchange as a separate script. For Aurora, this has meant thinking about the structure of a conversation.
How does it introduce itself and explain what it can help with? How does it ask for information? When should it play back what the customer has said? How does it check information against the rules of the experience? What happens when the customer changes direction?
For example, we've explored an emergency fund journey where Aurora helps a customer understand their goal, consider their current circumstances, organise existing savings and think about future contributions.
But the interesting design challenge isn't just the emergency fund conversation. It's recognising which elements of that experience could be reused across other financial ambitions.
The introductory explanation. The customer profiling questions. The playback of information. The clarification patterns. The way the system explains a calculation or presents a next step. These become building blocks for a more consistent conversational experience. They're not quite the same as the structured content models or technical pipelines a content engineer might develop.
But they're starting to apply a similar way of thinking.
Rather than designing every piece of content separately, I'm thinking about the structures, rules and reusable patterns that allow the experience to work across different situations.
And that's a shift I find particularly interesting.
But does that actually make me a content engineer?
Here's where I need to challenge my own excitement. Because there's a difference between doing work that overlaps with content engineering and actually being a content engineer.
Traditional content engineering can involve building content schemas, defining metadata structures, integrating APIs, developing publishing pipelines and automating complex content workflows.
I'm not suddenly doing all of that because I've written a system prompt. Nor am I claiming that designing AI behaviour and engineering the technical system behind it are the same thing - they're not. But I do think they're getting closer together.
When I define reusable conversational patterns, I'm thinking about consistency and scalability. When I establish rules for Aurora's responses, I'm helping design governance. When I explore intent-based routing, I'm thinking about how customer needs influence the behaviour and flow of the experience. When we use research findings to refine the system, we're building a feedback loop between design decisions and real customer understanding.
These are all areas where content design, conversational design and content engineering can meet. And while I'm not building every technical component myself, I'm increasingly having to understand how those components work so I can make better design decisions.
Which brings me back to collaboration. The engineers understand what's technically possible and how to implement safeguards that a prompt alone cannot provide. Researchers help us understand whether customers interpret the experience as intended. Product designers shape the wider interaction and visual experience. Legal and compliance colleagues help us understand the boundaries within which the experience must operate. And content design helps connect these different perspectives into an experience that people can understand and use.
The opportunity isn't to become a one-person design department. It's to become a designer who can contribute more meaningfully across the entire product experience.
For me, that's a much more interesting direction than simply collecting another job title.
Maybe this is what content design maturity looks like
I've spent a fair bit of my career thinking about content design maturity. How we embed the practice into organisations. How we move beyond being brought in at the end to tidy up the words. How we demonstrate the value of content design through the problems we solve, rather than the volume of content we produce.
I've also been fortunate enough to work across content, UX, product and design leadership. And one thing I've learnt is that maturity isn't simply about having a bigger team, a shiny content design system or a very impressive set of guidelines - those things can help. But maturity is also about the responsibility we're trusted to take on, the decisions we influence and how effectively our work contributes to the product.
Working on Aurora has made me rethink what that could look like. Because my contribution isn't limited to writing the words in the chat interface. I'm involved in shaping its identity, defining behavioural boundaries, developing interaction patterns, exploring the system prompt and working with others to understand how the experience should evolve.
I'm moving between strategy and execution. And I love that.
In previous leadership roles, as my responsibilities grew, I naturally spent less time doing the practical design work. Something I genuinely missed. Now, with conversational design and AI, I'm finding opportunities to bring those worlds closer together again.
I can help shape the direction of an experience, translate that direction into practical design rules, collaborate on how they become part of the system and use research to understand whether they're working.
It's not always straightforward. I'm still learning. There are plenty of technical areas I want to understand better. But that's part of what makes it enjoyable. And I think there's a wider lesson here for our practice.
Content design maturity shouldn't only be about getting better at what we've always done. It should also be about recognising where our skills need to grow.
AI is making that need more visible. It's exposing the importance of structured information, clear governance, reusable patterns, reliable knowledge and carefully designed boundaries. All things that content designers can help shape.
But it also means we need to understand more about how our content interacts with technology. Not necessarily to become engineers ourselves, but to make sure we're contributing to the decisions that determine how these experiences actually work.
So, am I a content engineer?
Maybe partly. I'm certainly doing work that overlaps with content engineering. And the more I explore it, the more interested I become in developing those capabilities.
What matters more to me is that I'm growing beyond the boundaries of what I once understood a content designer to be. I'm learning to design not only the words customers see, but the structures, relationships and rules that influence what those words become. And I think that's an important direction for content design.
Not because every content designer needs to become a content engineer. Not because AI will somehow make all our existing skills redundant. But because the products we're designing are changing, and the way we contribute to them needs to evolve too.
We don't have to abandon content design to evolve it. We need to recognise that our discipline has the potential to shape much more than content itself.
Perhaps that's what Yoda meant about growing beyond what came before. Although, knowing content designers, we'll probably spend another six months debating what to call ourselves.
Some things really are timeless.
