Get in touch
Log in
Written By: Sowjenya Parthasarathy, Context Designer
Recently, my role at Funnel changed from Technical Writer to Context Designer. But this isn't really a story about a role change. It's a story about something that has always existed in content, but rarely had visibility.
Context.
Let's start with something we all do without noticing. When you read a help article or a tooltip, you automatically fill in the missing pieces. You know what you're trying to accomplish. You understand the product terminology. You can infer meaning from what you've seen before.
The context is invisible because humans are remarkably good at constructing it.
AI isn't.
When an AI system encounters ambiguity, it doesn't politely ask for clarification. It makes an assumption and responds with confidence. Sometimes it's correct. Sometimes it's wrong.
That's what makes context so interesting. We only started paying attention to it when AI exposed how much we relied on it.
Different disciplines have always been designing context
On paper, they looked different. In practice, however, they were solving a similar problem.
A technical writer creates context for understanding.
A content designer creates context for decision-making.
A conversation designer creates context for interaction.
The difference is where that context appears. A technical writer might provide it through a help article. A content designer or UX writer might provide it through a button label or onboarding flow. A conversation designer might provide it through prompts and responses.
The goal is always the same: helping people understand what matters, when it matters, navigate uncertainty and move forward with confidence.
Why this matters to Funnel
Funnel helps our customers clean and organize marketing data and understand it through a semantic layer. We're now investing in a context layer: the goals, knowledge, processes and decisions that help AI reason more effectively.
That's where my role becomes relevant. Product content is part of that context layer.
AI changed the audience and how we build product content
To make content work in an AI-driven product, we have to design for two entirely different directions of system traversal simultaneously: authoring and querying. We have to create conditions that allow this two-directional system to work effectively.
When we author, our role is deliberate and architectural. We start with user intent and systematically build down into the stack, mapping out information architecture, establishing semantic relationships and structuring raw data with strict schema constraints. We are intentionally building reliable ontology.
When a user asks a question, the AI queries the system from the bottom up, pulling raw data chunks, validating them against the schema, processing semantic meaning, filtering the user’s real-time context and using logical inference to assemble a highly personalized interaction surface.
The biggest shift in my work happened when AI became part of the product experience. Our job used to be linear: we authored content top-down and a human reader consumed it top-down. We controlled the entire narrative arc.
But AI has fundamentally broken that paradigm. Today, we aren’t just writing for the human at the end of the journey; we are creating structural assets that an AI can disassemble, retrieve and reconstruct for various user journeys.
So what does context look like?
Context shows up in many places in disguise.
Content governance. Without consistent terminology, style guidelines and ownership, content becomes fragmented. Humans might work around those inconsistencies although it increases the cognitive load and decreases product adoption. AI systems often cannot. We recently ran a survey to understand how customers use our documentation. The biggest complaint wasn't missing content. It was finding content.
That's not a writing problem. That's a context problem.
Information architecture. Metadata, taxonomy, glossary definitions and content relationships determine whether information can be found, understood and reused. This becomes even more important when content needs to support multiple outputs, from traditional documentation to AI-powered experiences.
User journeys. Different users need different types of content. Some need explanations. Some need guidance. Some need reassurance. Others just need a quick answer and want to move on.
Designing for those moments requires understanding not only what information exists, but why someone needs it in the first place.
My deliverables as a Context Designer help create reusable context that can be used by both humans and AI systems.
How is Context Design different from Context Engineering?
On paper, Context Design and Context Engineering have separate paths. However, in practice, they intersect.
I’ve found myself looking at chunking strategies, reading NDCG scores, validating source quality and learning how vector stores influence retrieval. Not because I’m doing an engineer’s job, but because content decisions and system decisions are often intertwined.
If a chunking strategy separates a definition from the examples that explain it, that’s a content problem disguised as a pipeline problem.
Good context design requires understanding both worlds to spot issues that neither discipline would catch alone.
What’s next for context-driven roles?
In organizations where AI is becoming more central, it creates space for us to focus on something machines still struggle with: understanding people.
We can spend more time understanding their language and decisions, how they describe their problems and what information they need at different moments.
This is also why the boundaries between parallel disciplines are starting to blur and Context Design emerges at the converging point. The full scope of what this profession actually involves is diverse. This won’t look the same everywhere, of course.
The tools may change, but the underlying challenge remains the same. Those of us who understand user language, domain and contribute to context, we’re no longer supporting the product from the sidelines. We’re going to be more central to whether it works at all.