That's how it started. Five product teams, one user group, one massive problem nobody noticed at first. We thought building better UX for one product would naturally improve the overall experience. Spoiler: it didn't work that way at all. A user had to log in to Tool A, manually re-enter their schedule details into Tool B, then do it all again in Tool C. Every single day. The moment we realised this was happening, everything changed about how we thought about our job.

We weren't actually designing for users. We were designing for our own team's convenience, with users paying the price in wasted time and cognitive load.

The Journey From Team-Level to Domain-Level Thinking

Moving to a domain-level UX structure meant hiring another designer, setting up working agreements with product teams, and completely rethinking how we allocated our time and attention. Some teams wanted us to own all the details and hand over finished work. Others wanted us to be consultants, working alongside their people whilst they handled implementation details. No two teams worked the same way, and that complexity became both our biggest challenge and our greatest teacher.

We settled on quarterly roadmap planning sessions with each team and their product owners. It sounds straightforward until you're actually in the room trying to explain why you can't do everything at once, or why a problem in one team might actually be solved better by looking at how another team is handling something similar. That's when the real conversations started happening.

Learning One: Context Loss and Unexpected Clarity

The catch-22 of being a domain-level UX team hit us fast. Moving from Team A to Team C meant losing the thread we'd spent weeks building. We'd nail something for one product, dive deep into their problems, understand their constraints, then switch contexts and suddenly we're starting from scratch somewhere else. The mental load was exhausting.

But here's what we didn't expect: by stepping back from any single team's bubble, we could suddenly see patterns. "Wait, Team B is solving the exact same problem that Team A asked about last month." "Oh, the friction users are experiencing in Product C is because Product A isn't feeding them the data they need." We started connecting dots that nobody within their individual silos could see.

The benefit of losing context was gaining perspective. Yes, we couldn't be the deep experts within every single team anymore, but we became something more valuable, the people who remembered what everyone forgot, who could see the bigger picture and push back when a solution was too narrowly focused on one team's needs instead of what the user actually required.

This is what strategic design leadership actually means. It's not about being the cleverest person in the room. It's about holding enough context to ask good questions, even when you're not the expert on that particular product.

Learning Two: Resource Scarcity as a Design Tool

We couldn't say yes to everything. We didn't have the capacity, and frankly, we didn't need to. What we needed was better conversations about what mattered most.

So we built a quarterly ritual. Each product owner pitches their epic for the next quarter. We talk through priorities together, not in isolation where everyone's just fighting for their slice. We give everything a t-shirt size S, M, L, XL. Then we agree on what doesn't happen. This last bit is crucial. Most teams are used to arguing for more resources. They're not used to actively deciding what to not do, and that shift in thinking changed everything.

The magic happened when we started bringing all the teams together to think about t-shirt sizing collectively. Suddenly a PO would see that what they thought was an XL epic was actually the same size as three other team requests. They'd ask, "Wait, is this really that big compared to what Team C needs?" Instead of fighting for their own slice, they started thinking about the whole domain. They became advocates for good prioritisation rather than just their own backlog.

We also set aside time for ad-hoc support because reality doesn't follow quarterly plans. Critical issues pop up. A user group suddenly needs something urgent. That flexibility matters. Some quarters the structure works beautifully. Some quarters it bends under the weight of everything happening at once. We've learned to see that not as failure but as signal. It tells us where the real pressure points are.

Learning Three: Better Integration Means Better Collaboration

Once we realised the core problem was that users had to manually re-enter data across products, merging those tools became inevitable. But this decision forced a harder conversation. How do we integrate? By syncing data? By embedding one product inside another? By sharing components? Suddenly design and engineering had to have stronger opinions about technical architecture.

This was a turning point, though not in the way we expected. When your frontend teams have to actually collaborate on integration instead of building in their own corners, something shifts. They stop reinventing components that already exist in another product. They notice when one team solved a problem elegantly that could help another team. They start caring about the user's journey across the whole ecosystem, not just their corner of it.

But there's more to it than just code sharing. We started bringing engineers into user research sessions and usability tests. Not as observers, but as participants. A developer watching a user struggle for five minutes to find something in the interface gets something different than reading a ticket that says "improve navigation." They start suggesting solutions from a place of understanding rather than just spec-following. Their code becomes better because they actually care about the outcome, not just the architecture.

One frontend developer said something that stuck with us: "I used to think my job was to build what the designer handed me. Now I realise I'm building something someone's actually going to use every day, and if I get it wrong, their job gets harder." That shift in mindset changed how they approached decisions. They asked better questions. They suggested improvements because they actually understood the problem.

The Real Win

After all the complexity, the arguments about integration models, the quarterly planning meetings, and the constant context switching ”here's what actually mattered: users stopped re-entering the same data five times. Their cognitive load dropped. They finished tasks faster. They were actually satisfied with their work instead of frustrated.

It's not glamorous. It's not a fancy design pattern or a prestigious award. But it's everything. A planner at a global logistics company doesn't care about your elegant architecture or your thoughtful design system. They care that they can do their job without wasting an hour a day entering information into systems that should've been talking to each other in the first place.

The Unsexy Reality: Everyone Had to Learn

None of this worked until we stopped treating UX as something the design team did to products. We had to drag engineers to user interviews ”they complained about wasted time, then their perspective completely changed. We had to teach product owners about different research methods, over and over, until they stopped seeing UX research as a nice-to-have and started seeing it as the foundation of good decisions. We had to show stakeholders why a merged system was worth the complexity, why slightly increased technical dependency was a worthwhile trade-off for a dramatically better user experience.

Education was honestly 60% of the job. Design was the other 40%. We'd sit in meetings explaining why a particular design direction made sense not just for one team but for the user's entire journey. We'd bring in research findings that surprised people. We'd facilitate workshops where different teams realised they were solving the same problem in three different ways. Every conversation was an opportunity to help people understand that user experience isn't a feature you add it's the outcome of every decision you make.

The turning point came when people started asking us questions instead of waiting for deliverables. When a product manager would say, "I'm thinking about this feature, but I'm wondering if it creates friction somewhere else in the user's day." That's when we knew the culture had shifted. People weren't just tolerating UX anymore. They were thinking like designers.

Being Honest About the Trade-offs

Building a domain-level UX team isn't the "right way" for everyone. It's complicated. You lose the deep expertise you could have developed in a single product. You have resource battles that never fully resolve. You argue about integration models with engineers who have very strong opinions and they're usually right about the technical constraints even when you're right about the user needs.

Context switching is exhausting. Some quarters you feel like you're juggling five different problems with half your attention on each. You can't be the expert in every product anymore, and that's a different kind of professional challenge. There's grief in that loss, even though the gain is bigger.

But if your user's journey actually crosses product boundaries ”if they're wasting time and energy because your products don't talk to each other ”then the pain of maintaining separate silos is probably bigger than the pain of building something better. The question isn't whether this structure is perfect. It's whether the status quo is costing your users more than the complexity of change would.

If You're Thinking About This For Your Own Team

Start by mapping your actual user journey. Not the one you wish they had. The one they actually live through, including all the bits that embarrass you. Where do they waste time? Where do they get confused? Where are they entering the same information twice?

Then find one other person who sees the problem the way you do. Your success won't come from having all the answers. It'll come from having a partner who cares about the whole picture enough to argue about priorities and push back when a quick fix in one team creates problems somewhere else.

Run a small experiment. One quarter. One cross-team initiative. Maybe it's merging two related workflows. Maybe it's getting designers from different teams to share their research. Watch what happens. Some of it will be messy. Some of it will work brilliantly. Both outcomes are useful because they teach you what your actual constraints are.

The biggest wins often come not from having the perfect structure but from giving enough of a damn about the whole picture to try something different. Sometimes that's domain-level UX teams. Sometimes it's something else entirely. But at least you'll be asking the right question: is this working for our users, or is it working for us?