The Power of Proximity: Embedded Teams in High-Stakes Systems
Embedded teams learn the mission, not just the requirements. When UX and dev build alongside their users, “contractor” turns into “partner,” and great tools become inevitable.
In public-sector and critical-operations software, the creation of specialized applications and tech is often handed off and outsourced to other teams. These teams get labeled with a big dirty word in our industry.
The C-word.
You know it.
Contractors.*
These contractors sweep in with the technical skill and ability to program stuff, but they’re often miles away from the day-to-day realities of the people who’ll actually use The Thing.
Contrast this with commercial work, where designers and developers often build for products they already use—or at least understand intuitively. It’s much easier to empathize with a shopper, a traveler, or someone trying to stream content.
But what happens when your users have highly specialized jobs that no one outside their field has even heard of?
Your “user” might be someone managing federal grants and tossing around form numbers like it’s water-cooler chit-chat:
“They submitted the SF-424B, not the SF-424D?! What a headache!”
Or a cybersecurity analyst citing MITRE ATT&CK TTPs like you’re both fluent in threat taxonomy:
“Classic spearphishing, amIright?”
You nod politely, pretending to understand—until you realize: this is the language of the mission. And if you want to design for it, you’ve got to speak it.
That’s why I advocate for embedded teams. Not just UX—the whole freakin’ team.
Anyway, let’s get to it! Here are ten reasons I believe in embedded teams. Yes, TEN! So many!
1. Domain fluency
Designers and developers working side by side pick up the specialized jargon, workflows, and edge cases of the domain. This is huge in nuanced contexts. Less explaining—more solving.
2. Continuous knowledge transfer
Knowing the terminology is a start—but it’s not enough. Sitting with your users gives you something far more valuable: context. You start to see how their world actually works, and that insight flows straight into your designs.
When you can iterate side by side with subject matter experts, complex topics click faster. You can sketch, prototype, and workshop ideas on the fly—testing your assumptions in real time instead of designing in isolation, waiting for feedback, and reworking later.
Being embedded means the flow of feedback is constant.
3. Less confusion and talking past each other
Knowing the user is step one. Making sure your dev team knows them too—that’s step two.
How many times have you met with users, tried to explain their challenges to the dev team, only to field a new round of questions—and end up going back to the user for clarification all over again?
With embedded teams, that cycle shrinks. You’re no longer the go-between. Engineers are right there in the room (or the chat), hearing the pain points firsthand and seeing the mission impact alongside you.
That frees everyone up to do what they do best—you focus on translating problems into design solutions, and they focus on building the scaffolding that makes those solutions real.
4. Faster iteration & feedback loops
Speaking of which—just like with users, feedback between UX and development becomes constant. Prototypes and wireframes can be validated directly with engineers, speeding up feasibility checks and cutting down rework.
5. User Experience is the North Star
When UX sits embedded with the team, we’re that tiny angel on the shoulder—the voice whispering, “Do the right thing… for the user!”
It’s not that engineers get lost in technical weeds. But every so often I’ll hear, “Can we get away with doing it this way?”
Translation: “That way involves a lot of work. Is this really that bad?”
And my answer, almost every time: “If you have to ask, then yeah—probably.”
But that’s where the fun problem-solving challenges come in: Can we do right by the user given all the technical constraints, policies, and ticking clocks?
When you’re all wrestling with those tradeoffs together—balancing user needs, policy, and feasibility—that’s when real ownership starts to form.
6. Increased investment in success
This is where the real payoff happens: investment.
I’ve always advocated for embedding UX within development teams—because honestly, why wouldn’t you? When designers and engineers build side by side, they naturally care more about the outcome.
But when that same crew works directly with their users, that investment goes through the roof. Everyone’s hearing the same pain points, seeing the same friction, and solving it together.
And when developers help shape the solution—not just code it—they’re that much more excited to see it succeed.
7. Stronger trust with end users
That shared investment doesn’t just stay within the team—it spills outward. When users see that same collaboration and care, trust starts to build.
Embedded teams working alongside analysts, case workers, or clinicians show that the builders actually get it. They understand the work, the pressure, the why behind the what. And when users feel understood, they lean in instead of resist.
Plus, proximity does something softer but just as powerful—it builds relationships. You stop being “the dev team” or “the UX people” and start being… friends. 🥹
And we all like to do nice things for our friends.
8. Improved resilience under pressure
That kind of trust pays off when things get tough. When the mission shifts or the timeline tightens, everyone’s already on the same side.
Embedded teams respond faster and panic less (okay—sometimes we panic). But compared to the old feedback → design → develop → review loop, they’re simply more fluid. Adaptability isn’t a process for them—it’s a habit.
9. Cross-disciplinary empathy
When you work shoulder to shoulder every day, you start to see what’s hard for everyone else. Designers learn what’s tough to build. Engineers learn what’s tough to use.
That shared empathy leads to pragmatic solutions—the kind that balance technical reality with human need. It's not the perfect-on-paper kind, but the kind that actually works.
10. A culture of continuous improvement
We’re the CI/CD of UX and development, baby—that’s how everything gets built!
Small improvements stack up. Feedback flows naturally. The line between “designing” and “building” blurs until it’s just one team, constantly tuning for better.
And with all those tiny, incremental changes, you don’t always notice how far the product has come—only that users are a little happier every time you check in.
Wrapping up
At the end of the day, embedded teams are how great mission work actually happens. When UX, engineering, and domain experts huddle together, the work stops being about deliverables and starts being about outcomes.
You get better tools, smarter decisions, and a team that genuinely cares about the people they’re building for. Everyone learns more. Everyone invests more. Everyone wins.
Maybe “contractor” started as a dirty word. But when you’re embedded, invested, and aligned with the mission, it starts to sound a lot more like partner.
Turns out the C-word isn’t so bad when it stands for caring. 🥹
*Also “consultants,” if your company feels fancy—but most of the time, it’s the same thing.
