Something finally clicked.
Context Engineering and Context Design might be a space where Engineering and Product/UX/Design can join forces on building useful things with AI. Where the different languages (engineer-speak and UX-speak) can meet.
Call it Context Engineering for engineers. Context Design for UX/Design/Product people. We now have something we can talk about.
At Simply Put, we’ve been building AI products for two years now, and with a background in UX and Product, it’s been surprising to see how UX, Design and Product have been largely sidelined in the building of AI-first products.
In large part, that may be because much of the invention, creativity and experimentation of figuring out how to Build Useful Things with this new capability has been happening in the world of engineering.
Most of the ideas and language have come from what I would call engineering-first teams. RAG. Observability. Evaluation. Tool Use. Most of the tooling around this is engineering-first tooling.
And a very large chunk of this ends up being about Context Engineering. In the end, you are simply adding stuff (let’s say text, for now) to the LLM’s context window.
RAG simply adds text to the context window.
Tool Use adds text to the context window.
System Prompts add text to the context window.
Agents are simply LLMs running in a loop, and a lot of what you’re doing is managing the text in the context window.
Memory (say it with me) adds text to the context window.
It has turned out that a large part of building useful AI systems is managing what’s in the LLMs context window. (Another major part of it is doing evals, but we’ll leave that for another article.)
Simon Willison wrote about context engineering recently and the term is quickly overtaking “prompt engineering”, which always felt a bit off.
So if context engineering is what engineers do, then context design can be what non-engineer/design-y people do?
Context Design feels like a natural fit for product people, designers, information architects and researchers. It feels like a good place to be.
What could context design look like?
- Working in Google AI Studio, LangSmith or other tools to test LLMs responses to what’s in their context window.
- Doing content audits to figure out what types of content should be pulled in by a RAG system, and how good the content we have available is.
- Creating qualitative and quantitative research and evaluation plan. When do you know you’re done? (Good eval is the second key component of useful AI systems).
- Reviewing use cases, thinking through what the “best output” for those may look like, and what context the LLM would need for that.
- Working closely with the engineers on improving the relevance of the data in the context window.
- Running evals in Helicone, BrainTrust or others.
I’m honestly not quite sure where this ends up. The one thing I know is that we need better ways to build these things together, with a variety of skillsets, being able to speak the same language.
So say hi to Context Design? Let’s join hands with Context Engineering. It’s a safe space. We can talk there. And hopefully, build Useful Things That Matter.
(If you’d like to discuss these ideas further, set up a meeting to chat. No sales pitch, we just like to talk about this.)
PS 1: This reminds me a bit of the role wireframes played in early web design. Wireframes were a safe space where designers, clients and engineers could have an actual conversation and understand each other.
PS 2: This all hinges on designers, product people and such learning about LLMs, how useful AI systems are built, and why context design and engineering matters. There’s a lot of learning to be done on all sides.