The Translation Problem Nobody Talks About
- Chelsea

- 12 minutes ago
- 2 min read

Most policy communications are not translated into the reality people are navigating.
I saw this up close when a city launched a rental assistance program. Eligibility was defined, funding was in place, and the application process was designed to be simple.
On paper, it worked....then it opened.
Residents weren't sure if they qualified. The application language felt foreign to people who hadn't navigated systems like this before. Community organizations were fielding questions they didn't have answers to. Caseworkers were interpreting requirements differently.
The easy diagnosis was a messaging problem. Just say it clearer.
But the more we sat with what was actually happening, the more that felt off. The information wasn't wrong. It just wasn't landing in a way people could act on, and that's a different problem entirely.
So before anything got rewritten, I started paying attention to three things: what was designed, how it was being implemented, and how people were actually experiencing it. Because the gap almost always lives in the tension between those three.
What I found was this. The language assumed a familiarity with systems that most residents had never navigated before. The process made sense in sequence but not in real time, when someone is sitting at a kitchen table trying to figure out if they qualify before a deadline closes. And the same information was landing differently depending on who was explaining it and in what room.
That told me the issue wasn't the message. It was the distance between how the program was built and how it was being experienced by the people it was built for.
So the work shifted. Instead of rewriting materials from the inside out, we started from where people were actually getting stuck. What questions kept coming up? Where were people dropping off? What felt clear to the team but confusing to everyone else?
From there, the focus became less about explaining the program and more about helping people move through it. That meant building materials around real questions instead of internal assumptions, creating pathways not just explanations, and aligning the teams doing the work so they were describing it consistently across every touchpoint.
Over time you could see the difference. Fewer repeated questions, more completed applications, stronger alignment across the people supporting the work.
The program didn't struggle because it was poorly designed. It struggled because it hadn't been translated into the reality people were navigating.
Before I write anything, I ask three questions. Who has never been in this room before? Where are people actually getting stuck? And what would this need to say for someone to feel like they can take the next step?
Those questions don't make the work simpler. But they do make sure the work is actually reaching the people it was built for.
The information was never the problem. The distance between the system and the people it was built for was.




Comments