Human-Centered Context Engineering

I'm Thomas Immich, on first-name terms with almost everyone even in business — and at home in UX and human-centered IT for close to 25 years. I got here through the video game industry: I started at around 15 and later paid my way through university writing games. I was always taken with the combination of design, graphics, aesthetics, experience, gamification and software engineering. I had to port "Wormsblast" to the Mac, for instance, which was anything but a picnic. I had three months, and back then everything still had to be built without AI. Claude Code would probably need three days for it today.

But I noticed early on: coding interests me, sure, but what interests me far, far more is the end result and how it lands with the people using it. So I moved away from pure implementation a little and toward UX/UI. After only two years as an employee in the industry, I founded Centigrade as a UX company 21 years ago. Back then we still called it "UI design" — we gave interfaces a coat of paint, you could say, made old banking software look pretty.

But all of that changed: at some point user research came along, we hired psychologists, we grew, we made the jump from WPF to HTML and, because we work so closely with industry, we even did VR projects in Unity 3D — so we added a great deal on the technical side. And now we're even a training and consulting company for other UX people, which makes me particularly proud: that we're a bit ahead of the curve on the question of where UX is actually headed, now that AI is suddenly plastered across every banner.

And now: why does LeanScope exist in the first place? Our project business always ran along similar lines: first we have to understand what the user wants, what the client wants, and how we can build it in as few moves as possible — so that what stands at the end is the best experience, and not for us, but for the actual target audience. At some point at a conference, UX London, I came across Jeff Gothelf and sat in his Lean UX workshop. That workshop completely blew me away. I came out of it, flew home and then walked around Centigrade saying: "We have to switch everything over to Lean UX!" To do that we made do with Excel sheets at first — business model canvases, persona profiles, usage scenarios, assumption backlogs and plenty more.

Then at some point Clemens Poblotzki joined us as a new hire. He wasn't assigned to a project right away and so had some time left over to experiment. So we said: why don't you pour all these Excel sheets into one central web app. After a month I was already thinking: what he's built there is wild — without AI, by hand back then, with TypeScript and Angular. All I could think was: "Okay, this is seriously cool, we have to turn it into a product." That's how LeanScope came about eight years ago, as a prototype at first. We then gradually rebuilt the prototype into a training tool people could use in production, so we'd have our first license customers. That was a strategic decision, because a training tool is of course allowed to crash now and then and we get direct user feedback! So we could sharpen it, stabilize it and let it mature in a safe harbor. And now AI enters the picture: we took some of the many personas we had built up over the years in client projects, backed them with AI and turned them into living conversation partners in our projects. That drove LeanScope's success so hard that we spun the product out into a company of its own. So LeanScope isn't a subsidiary of Centigrade, it's its own GmbH with its own customers, its own strategies, its own goals. But the cooperation between the two companies is extremely close, because Centigrade, as a license holder, still uses LeanScope on every project — that's where we come from, after all. And the other way round, LeanScope now has plenty of customers Centigrade doesn't have, for example because they come more from the marketing side.

Seen purely technically, the context in context engineering is often derived from the code: I'm in Claude, it looks at my code and knows what to do next on that basis. But if I look at the domain experts instead of the software engineers, they tend to use their "knowledge" context — a wiki, in other words, made up of information ultimately derived from manuals, tickets or other sources of knowledge.

And when I talk about human-centered context engineering, I mean the combination of code and knowledge, but a very particular kind of knowledge! What's at stake here is the knowledge built up about the person the product ultimately has to please: the user. And what we notice is that there's often very little of it to begin with, hardly any LLM wiki that could report on what the audience actually wants. Only a few pioneering companies have their own UX department and people who have explicitly written that kind of knowledge down in Confluence, Jira or similar places. And making that knowledge usable for the AI, even once it has been written down, is the next challenge on top of that. LeanScope simplifies both worlds.

First: building knowledge that isn't there yet — by making it easy to load user research results in. Second: making that knowledge usable through knowledge graphs, RAGs and everything else in the modern retrieval toolkit: not just as markdown files, but as a graph-based database, fast and token-efficient. That, for me, is human-centered context engineering — I know immediately how my users would react to one of my product or design decisions.

Exactly — I'm talking about domain knowledge, but from the users' perspective. Because domain knowledge is already there at most companies; what isn't there is domain knowledge from the users' perspective, and certainly not aligned with their mental models. And a user's mental model is often completely different from the company's domain model, because of course everyone inside the company is wearing those famous glasses that make them blind to other perspectives. Those are the glasses we want to take off, and put on a different pair. That's why LeanScope's claim is: "See the world through your audience's eyes."

Exactly right, that's how it is. Of course there are also customers who have never once run a piece of user research. With them it's always a bit awkward to say: "Okay, just use LeanScope to learn more about your users." Because if I don't even know how to run a user research interview, or how to set up a user research repository in the first place, then I really am still a bit early for LeanScope. Eliciting context knowledge is still to a large degree a human act, and so it's something you have to be able to do. At that point we tend to help out with our professional user research staff at Centigrade instead of offloading everything onto the tool.

That was a really fascinating journey, especially since we ventured into the AI topic very early, right after ChatGPT 3.5 appeared. It started with our bot P.F.U.X. for my podcast at the time, "Prompts for UX." The basic idea was to create an AI-driven creature that could answer UX-specific questions and was able to write better user stories. To do that my colleague Catharina and I naturally had to dig deep into prompt engineering, and we learned a lot. To make the creature more approachable, I built a Lego figure back then that even opened and closed its mouth while it spoke. So we played around a lot with storytelling and character design. And I noticed: a well-made character does something to me, does something to people — that this isn't just text, but a personality delivering that text. Then the idea came almost by itself: let's build more of these funny characters and have more fun using AI.

T0-N1 for instance, our voice-and-tone bot, is extremely funny; he insists on a proper greeting, among other things. If I just barge in and say "Give me a spell check on that text there," he'll say: "How about a nice hello first?" What was interesting and important for us was that not every bot answers the same way — each brings a personality of its own, which raises the motivation to use them.

The risk we didn't quite see at the beginning was of course that people might feel replaced to some degree once the AI has not only impressive abilities but a personality of its own on top. So there was indeed a discussion at Centigrade, and entirely rightly so, about whether our bots belonged on the team page or not — are they even "team members"? But because we did it with a wink right from the start and also made it clear — "Hey, these are obviously just funny characters, but without their human godparents they're nothing at all, because all they do is reflect the humor of the people who prompted them" — the discussion resolved itself amicably in the end. But it was important that the handwriting of the human godparent is recognizable in the bot, so that this person can say: without me this character wouldn't exist at all!

Back then there weren't the great tools we have today — you really just wrote a prompt into the GPT chat. For the sake of reusability, our godfathers and godmothers built these prompt templates up front and then maintained them. Whenever someone on the team said "I thought that bot's answer was rubbish," the godparent adjusted the prompt and brought it up to date again. A bit like a small software engineering change management process among non-software-engineers, if you like.

Yes, in GitHub it would be the developer and/or maintainer — but we deliberately called the role "godparent." Precisely to make the point: "Look, you're the role model." The pecking order is unmistakable: the godfather is the Godfather, the godmother the Godmother. After that nobody feels subordinate to the AI anymore.

As I said, at first we risked people feeling replaced, or Centigrade coming across completely wrong, along the lines of: "Oh look, there's a human-centered AI company that can do without humans." That risk is always there when you use AI. And that's why we deliberately work against it. On our new website, in line with our philosophy, "People" is therefore the top menu item; the AI topic comes relatively far down. Where you might now say: "Ah, but AI has to go right at the front!" Yes, AI is important, but we believe there always has to be an enabler to get complex digital systems out the door at an exceptional level of quality, and that enabler is the people on our team.

First of all: teams that already don't talk to real people, sadly won't do it in the future either. That's roughly my experience. And the other way round: teams that were already doing it will keep doing it, because they have simply felt the real value of it.

Which is why, in my view, the risk of using LeanScope is actually highest with the teams that have never applied any user research method at all. Why? Because they're the most likely to take everything the persona says at face value. When purely technically it can't possibly be that. What the persona says is always a sum of insights a human gathered beforehand, and then a sum of probabilities that move an LLM toward an answer. But: a persona doesn't represent one person — a persona represents the sum of the characteristics of similar people. So for one thing, I can never trace back to a single individual who said what, which is already an important foundation from a GDPR point of view.

But for another, it also means: there is no one truth, there is a healthy mix of perspectives that gives you a solid tendency to decide in a particular direction. And that degree of accuracy is entirely sufficient for product development. So LeanScope is more of a compass that points you to the north star: should I go left or right? This compass rarely shows hard to port or hard to starboard. In the end it still takes human instinct plus the technical and organizational room to maneuver to actually take a given path.

There's what we call assumption tracking in LeanScope. All through the process, user researchers keep making small annotations whenever they're unsure whether what they're dealing with is the truth or not. When they're sitting in a workshop, say, and three people are arguing to the last — you know how it goes, suddenly everyone is right. I found it really inspiring, for instance, that Jeff Gothelf just said something like: "Let them talk! Simply write down that what each of them has is an assumption. All three are wrong, because nobody knows it or can prove it." So we write down: we're missing evidence here — and then we go and collect that evidence afterwards. Simply being able to say: we're not going to argue this out now, we'll only note that we still need evidence here — that can be so relaxing.

And writing that piece of evidence down and then delivering it — someone has to do that! People, namely, who notice in discussions: oh, there's no consensus here right now. That alertness to the situation is something I can expect from professional user researchers. They then make small, quick annotations in LeanScope in the form of a question mark emoji — and from that alone the AI already knows: "This sentence here is somehow uncertain. Maybe we should flag it for the next round of user research: please verify this assumption and deliver either a confirmation or a contradiction."

And that's so powerful because it can be played out over a longer stretch of time. There's no binary "ah, it was a proto-persona, now it's a verified persona." The persona gets better with every new insight, and that's why the user researchers are a permanent part of the process.

Oh, that happens rather often. That's the funny thing about our workshop approach at Centigrade. We go into an initial scoping workshop with the stakeholders and take up their perspective. We write down contexts of use, we develop proto-personas — but honestly, at that point it's still a guessing game. The "best guess" of everyone involved. And plenty of them are convinced: "We've been doing this for 40 years, we know exactly how the users tick."

But then we go into the first round of user research, do our in-depth interviews and come back with the result — and suddenly everything is covered in annotations with red X's saying: "That's not how it is." And then everyone looks rather sheepish. But: that's an enormous learning effect outside the comfort zone. You can't help noticing: "Oh look, the world isn't the way I thought it was." That's the moment when we've brought the client one step closer to understanding their users — that's user research at its best.

You can definitely see it as a conflict of interest. I don't quite see it that way, though, and I can explain why. I believe that very often it's precisely the small and mid-sized companies that do no user research at all and can't do it either — they simply don't have the money for it. But they still have to hold their own against the big SaaS companies that have their own UX department with gold-standard maturity. How are they supposed to stay competitive, especially now that we all know: UX makes you competitive. That's why I think it's a good thing that we're making this access cheaper.

But — and this is crucial — it never replaces dealing with real people. It can only complement it.

And even so, we very often find that certain target groups just aren't reachable. I can't recruit the people I would need to interview in time, let alone interview them and analyze the whole thing. But if I have to make my decision today — then AI personas like these can help me complete my picture cheaply and quickly. But those AI personas couldn't exist in the first place if real people hadn't been interviewed beforehand. Which is why, from the point of view of our two companies, there is no conflict of interest at all — quite the opposite, there's a sensible cooperation: TestingTime does exactly what LeanScope can't — recruiting real people so we can run real interviews with them. And we only do what TestingTime doesn't — creating lifelike AI personas on the basis of interview results.

That question is really important, because with some inquiries I have felt a twinge of unease: sometimes people reach for personas for the wrong reasons and the mindset simply isn't there that we still need real humans to succeed. Then I hear things like "synthetic data" — a use case, in other words, where even the data foundation is generated by the AI. With something like that I always ask myself: isn't that a really dumb circular argument? Maybe I'm missing something, but I have been at this for a while now...

You can do it, of course — but then you should be aware of the dangers. So if a client comes along and says: "I know that's a danger, but I'm taking the risk!" — I'm completely fine with that. But if someone comes along and says: "I think this is the silver bullet and there's no risk!" — then I'd say: better go and look at what user research and market research actually are and how the professionals work. Everything there is highly methodical and systematic. You have to have understood that discipline before you set out to use it. Even the supposedly simple act of asking a question can backfire badly at the first leading question. Building a good interview guide isn't that easy either.

In what are called ethics committees, definitely. We're fortunate to have been able to run a few research projects, funded by what was then the BMBF — today's BMFTR, the German Federal Ministry of Research, Technology and Space. Without that LeanScope couldn't have come about either, which is maybe worth emphasizing at this point.

Every funded research project now has to have an ethics committee. You're not allowed to work at all without engaging with the ethics question. Incidentally, you're also no longer allowed to work in research projects without user research. So you can't just blast the project out among engineers and researchers, you need UX, you need ethics. Good thing!

And it was precisely in those research projects that I really became aware of how important the topic is. In public discussion, by contrast, it gets too little airtime. But once you have an ethics board looking over everything, you notice: ah, right, okay, I hadn't thought about that at all — makes total sense.

Yes — I wouldn't call it strictly scientific, but strictly systematic, certainly. In the end it doesn't matter whether you cite "design thinking," the "double diamond" or the human-centered design process. It doesn't matter whether you do Lean UX, Scrum or SAFe. At the end of the day it's about the same recurring patterns that underlie all these processes equally. There's no point, for instance, in talking about visual design when you don't even know what the company's concept or brand is. And I can say that right now, I don't need AI for it. On the contrary, the AI might say: fine, since you're asking, I'll go ahead and generate you a nice icon, because I'm so good at building icons. As a human I'd say: don't do it, even though you can. Don't start thinking about visual design yet, it's too early! And that's where I still very much see us humans, with our experience, having the move. But we also have to be allowed to gather that experience — otherwise we simply won't have it when we need it!

Let's define a little first: what even is a mental model? That's really hard to grasp — having a mental model of a mental model isn't exactly easy, to put it on the meta level for a moment ☺ But here's how I see it: every person has a different access to their own knowledge, to their own experience. When I think of a bicycle, I think of a two-wheeled contraption with a thing to sit on that goes by the name of saddle. But if someone rides a recumbent, they might think more of a kind of seat, not a saddle. For them a bicycle isn't something you sit upright on, it's something you sit lying down on. Two people, one word — and still two different mental models.

And that's exactly where the difficulty lies for us as UX professionals. We design software with the mental model of the UX person (when things go well); when things go badly, we design it with the mental model of a software engineer. And that's usually a completely different mental model from the users' — and then we have a clash. And: every single user's mental model is different. Which means we have thousands of different mental models — so there are basically a thousand "user experiences." Because UX is what I experience before, during and after I use something. Strictly speaking you can't design UX at all — how am I supposed to design something that arises differently inside every single person's head?

So that means: I can only see mental models as a simplification of reality. If three out of four people think about a term in a similar way, that's enough for me to build a mental model out of it. That's reserved for me as the human modeler. So it's also a strategic decision how far I want to go here.

What you mustn't confuse it with: this is not a universally valid ontology that the company stores as a universal knowledge base, say. If I describe a bicycle in my ontology as a bike repair shop, then of course the bicycle will have wheels (1 to 3) and something to sit on (saddle or seat). But whether I then actually call it saddle or seat in the UI depends on which users I'm addressing or which bicycle I'm looking at specifically. And if I also want to reach recumbent riders, then the word "seat" has to return hits in my web shop search as well. Designing perspective-taking properly — this is exactly where I think mental models are extremely underrated. And personas along with them, because they represent precisely these mental models at a level of detail that becomes directly usable in user interface design.

I think the new tools will get us part of the way there. There's Google's Open Knowledge Format (OKF), for example, basically an LLM wiki. It's about standardizing the way we update knowledge and store it in graph form. I find that a really interesting approach, because we're moving away from monolithic documents toward fine-grained entities and their relationships. And one small but neat detail: in OKF every term always has what are called "aliases," that is, synonyms. So a bicycle could also be called a "boneshaker" and still be understood semantically as a bicycle — older readers will surely still know the word. That's a nice development, because we can see: knowledge isn't absolute, knowledge depends on the context. And I'd add: knowledge above all depends on the context of use — and that always includes the user with their needs.

That's a very deep question, one I first have to try to think through to the end. Let me try it by associating outward from the campfire: television essentially replaced the campfire first, long before software played any role at all. Where a few decades ago we were still talking about "Wetten, dass..?", we now talk about reels on Instagram. So something similar has already happened here: we broke the central, shared campfire called "TV" into many small individual campfires called "Instagram content stream."

And that's both a curse and a blessing. On the positive side: new small communities form that previously had no idea their members even existed. On the negative side: it also means more and more fragmented communities.

If you carry that over to software, the question is: does it have any deeper value that I can talk about Figma and everyone at my campfire knows what Figma is, because the name and behavior of the software are familiar? Or is it perhaps worth more to talk about what you achieved with Figma: "Thanks to a prototype I put together quickly that looked incredibly real, my users gave us great feedback on our product ideas." Does it matter which software I built it with, or does it matter more that we talk about the outcome of the software, which in this case moved a few people forward? So is the software the campfire — or is it our goals and the experiences we managed to create? Software could of course also take on a new campfire value as an object of nostalgia in the future... along the lines of: "Remember back when we pulled skins over the UIs in WinAmp?" It may not do anything anymore at that point, but it has become a story, and that makes it absolutely campfire-worthy!

Exactly, and that is a danger. Which is why I say: a blessing and a curse. I still grew up with linear television and only three channels. Back then, even one single additional channel would have been absolute paradise for me.

If you take that further and say: at some point we'll have as many channels as there are human interests, and everyone only watches their own channels but no longer wants to talk to anyone about what's on them — then as humanity we'll also have lost our core. Because what marks us out is that we want to exchange with one another, that we inspire each other, that we want to tell and hear stories. And really it isn't the campfire itself that this is about — it's the stories told around the campfire, whatever decentralized form that campfire may have taken by now. And that we have to preserve, with everything we hold dear. If we only ever experience things inside ourselves and for ourselves, that will be a very sad future. Honestly, though, I don't believe it will come to that. Walking through the world with unshared experiences simply isn't any fun.

Yes, I do believe there's a point at which people say: "Nope, I don't actually want this." That's my hope, at least. But unfortunately we also see signs that I could be wrong — we see people who only stare at their phones and are absent, teenagers who take their own lives because of social media. And we have to take that very, very seriously. So I believe we have to do something proactively to steer against it. I think it's good, for example, that we're discussing whether there should be a social media ban for teenagers. That gets the debate going. I don't think a ban alone will achieve anything, though; we need to start educating people much earlier. We have to start explaining in schools, early, how an AI actually works, how social media algorithms work and how they pull you under their dark spell. We also have to dare to try approaches where we tell children: "Yes, you're allowed to use AI here, but tell me how you went about it — and tell me where the AI got it wrong."

Yes, definitely. In my view, human beings are built to be self-determined; so I believe people can basically make good decisions. But you can dazzle them with misinformation, echo chambers, promises of salvation and, of course, money, and send them down the wrong track so thoroughly that you'd almost have to say: "They couldn't help it!" Of course they can help it, if they want to be treated as capable adults! But they can't help misinformation and disinformation that has sneaked its way to them unnoticed. And it is exactly at the border to the "invisible" that we have to mobilize our "defenses": disinformation we have to recognize! Deliberate manufacturing of dependency we have to recognize! Ideological echo chambers with no openness to the outside we have to recognize! We have to recognize when people are deliberately pulled into somewhere they can't find their way out of without help, and we have to put a stop to it!

The answer is almost too simple: "If everyone always agrees with you, you're already in the echo chamber." No, seriously: I actually surround myself with friends who don't always share my opinion. On LinkedIn I always follow people from both ends of the spectrum on the AI topic: someone who is completely against it, and someone who is unreservedly for it. In between I have to form my own opinion.

You're absolutely right, that's comfort. Incidentally, it's one of the human weaknesses that batters us the most. Take the climate crisis: it's been known about for a long time. Climate impact research predicted everything that's happening right now, this summer in particular. And then the Rhine somewhere near Koblenz is down to 16 centimeters at the edge and 1.29 meters in the shipping channel. So you can practically stroll across the Rhine and keep your head dry. And what's the idea for solving the problem? We'll just run more trucks! But then the next problem arrives: the bridges, left to rot out of comfort, won't carry those trucks in the long run. Onto the railway, then — except the railway doesn't work either, thanks to the comfort of the past few years! So time and again we've given in to our comfort and always taken the path that was easier in the short term. And then suddenly, and apparently out of nowhere, a mountain of problems comes at us and you might think: "The world has conspired against us." It hasn't — we just always made the most comfortable decision and piled up a mountain of accountability debt.

And that's why I believe comfort is exactly the point where we have to start. It's also why I'm so taken with gamification. Fitness, too, is "against comfort": why should I go running in the morning? Most of the time it's no fun at all. But once you've done it a few times, after a while you can't do without it. That has to do with coaching and habituation, with gamification, with motivation techniques. And I think to myself: if we can bring ourselves to jog at 5 a.m. in the rain, then maybe we can also manage to think a little more deeply about one opinion or another. That doesn't yet mean we have to adopt the other person's view as our own. But listening, letting it sink in and imagining that other perspective for a moment... that would be a start, wouldn't it.

If I give that away now, I've squandered my unique selling point. So I'll probably take the first question instead. It's highly relevant to me because even now I think: some of what I did a year ago is worth nothing anymore, because AI is currently clearing out the field from behind at a tremendous pace. Claude, for example, is already far better at working out the context than it used to be. In part you no longer even have to write prompts as good as you once did, because the LLMs are getting better and asking ever smarter follow-up questions.

But then again I think: if you want to do it sparingly, with smaller models, if you maybe also want to do it in a more European way, with GDPR in mind — then it all comes back and rather less works "out of the box" than you first thought. And here we're back to comfort: I can always use the most advanced technology going, but then I'm usually also dependent on a global player who is the only one offering it (see Palantir, for example). But if I take a step back and say, "even though there is a vendor who can do what I'm looking for, I'll do it differently," then I'm freer and more self-determined for it, I can change tack more nimbly and may even be more competitive in the long run. So I wouldn't take as my yardstick the thousand things that will be possible in the future and aren't yet. The question is rather: at what price was making them possible bought? Maybe you can achieve a similar result by another route that is far cheaper and that nobody has discovered yet. Those potential possibilities are ultimately why I became an entrepreneur!

Over time we're guaranteed to lose the odd patch of ground, because yet another release has made something obsolete. And then we get — how do they put it: Sherlocked. Let me explain: there used to be a search tool for Mac OS called Watson. And at some point Apple itself came around the corner with exactly such a search, named "Sherlock," and nobody needed Watson anymore. That's where the term comes from: "They got Sherlocked." It's the same here: we build something, then someone comes around the corner and pulls the floor out from under us. But for us it would only ever be part of the floor. We are a platform, after all; LeanScope is more than a small app. Whatever ground washes out from under us in the short term, we rebuild somewhere else by being smart. I can't tell you what it will be — but I can tell you: it will happen.

First of all, and this matters: I won't recognize it by patting myself on the back, but by seeing the light in users' eyes — that's what matters to me personally. I still find it so fulfilling when a LeanScope customer tells me: "Oh, I was at a conference, I showed LeanScope there and their eyes went wide." Then I think to myself: "Yes, that's exactly why we do this."

But I also know we're on the right journey when the team finds it motivating to work with and for LeanScope. When the team says: I believe in what we're doing. And in the end I have to believe in it too! That's always a thing in entrepreneurship: you do go through dry spells. I haven't spent 21 years saying: yeah, we always do the right thing, I'm 100 percent up for this. As an entrepreneur there are days when you're just not up for it and you think: what are we actually doing here? But out of those crises, and out of crises of meaning in particular, a new and sharper sense of purpose or a new belief has always emerged — and that transforms the entrepreneur and the company along with its team alike. So I'd say: success for us is always the good match between our values, our beliefs, our purpose and the good work that is reflected back to us by our customers and users. It's a fine line, I admit — but that's what I strive for.