How Allied Solutions Built a UX Team That Earned Influence

"How are we going to earn trust and gain influence throughout the organization so that we can help solve some of Allied's biggest digital problems?"

That was the real question Ben Hewett's team had to answer, not the one they expected.

When Allied Solutions started building its UX practice in 2018, Ben assumed the hard part would be redesigning a mountain of legacy software for the finance and insurance industry. He was wrong. The software problems were solvable. The harder problem was organisational: how do you get a company with more than twenty software products and around a hundred lines of business to actually listen to a small UX team?

Eight years later, that team looks completely different. Ben's UXDX talk is the story of how it got there.

Where it started

In the beginning, it was one researcher, one designer and a UX leader, working out of a windowless room decorated with a homemade poster reading, "Pay attention to what users do, not just what they say." The team had limited scope and limited influence. They were working on one software product out of more than twenty, within one line of business out of around a hundred, without much visibility into the rest of the organisation.

It was a project mentality at a time when much of the industry was already moving towards product thinking. A researcher and designer would attach themselves to a project, ship it and then figure out what came next. There was no larger strategy connecting the dots. Just talent applied one problem at a time.

For a while, that was enough. The team started improving satisfaction scores and reducing time on task, and word got around. Clients touring the office would peek through the door and say, "This is the UX team. They start to make things look pretty." That captured how the organisation still perceived the team. People were starting to notice the work, but they were not yet treating UX as strategic.

When demand outran the team

Success created its own problem. Requests piled up faster than the team could handle them, and projects that could not get scheduled simply moved on without UX. Debt accumulated behind them and the walls started to close in.

That was the moment Ben's team stopped waiting to be rescued and turned their own methodology on themselves. "We know how to do this," he remembers thinking. "Let's UX ourselves." If they knew how to design an iterative process for a product, there was no reason they could not apply the same thinking to their own team.

Treating the team as a design problem

This is where the talk becomes particularly useful for anyone trying to scale a design function from the inside. Ben's team wrote down its core values early and barely touched them again. Only one word changed in eight years.

They value outcomes over outputs. They are collaborators, advocates and advisors, not order takers. Not every problem is worth solving, but the ones that are should be solved well.

They also built a vision statement. What Ben is most proud of is not the wording itself, but that every single word was scrutinised by the team before it was finalised. That is where the buy-in came from. A shared vision gave the team something to rally around and a way to decide where it would play, where it would not, and how it fitted alongside the rest of the organisation.

Alongside that, they deliberately created a culture of learning. Skill maps help people see where they were a year ago and where they want to develop next. Researchers can try low-fidelity wireframes. UX engineers can participate in interviews. New hires receive onboarding material before their first day so expectations and culture are clear from the beginning.

None of this is radical on its own. What is notable is how deliberately Allied treated its own team structure as something to be designed, tested and revised, rather than something that simply accumulated over time.

Learning to speak the business's language

The second major shift was learning to demonstrate value in terms the wider business cared about. UX teams often report in the wrong currency: screens designed, sprint goals completed, features released or velocity achieved.

Ben's point is that those numbers mean very little to a business stakeholder unless they connect to value. "You had 100 releases last week," he says. "That doesn't mean anything to me, especially if we're not increasing revenue or we're not decreasing costs."

The case study he uses is myinsuranceinfo.com, a site with one main job: helping people submit proof of insurance. Only 54% of visitors were completing that task, despite the site receiving roughly two million visits a year. Failed submissions were also contributing to call-centre volume, creating additional cost for the business.

The team's goal was to improve completion by around 6% and reduce call volume by 5,000 calls a month. Instead, completion improved by 24%, and the projected reduction in calls reached 17,000 a month. A redesign that previously might have taken around 18 months was delivered in four and a half.

Numbers like that travel through an organisation in a way that a nicer interface never will. Once people could connect the redesign to measurable business value, the conversation about UX changed. It stopped being primarily about whether something looked better and started becoming about what the work was worth.

Ben is also candid about the limits of proving design's contribution. Sometimes there is no straight-line relationship between a redesign and a business result because the rest of the organisation does not stand still while the work is being done. The team's approach has been to frame potential value before starting and increasingly use analytics afterwards. Embedded product managers now help define the goals before work starts, while analytics help the team measure what happened afterwards.

Earning advocates one conversation at a time

Even with results in hand, influence did not arrive through a single executive sponsor. Ben describes a winding process of taking case studies on roadshows across the organisation, talking to product managers, operational leaders and other stakeholders, only to repeatedly be told there was someone else they needed to speak to.

One of the clearest examples came from Allied's sales organisation. Because Allied works with large financial institutions, sales teams understandably guarded access to clients closely. Rather than trying to route around them, the UX team invited salespeople into the process. They showed previous work, asked for introductions to a small number of clients, and invited the salesperson to sit in on the research conversation.

Once that trust was established, future access became much easier.

Advocacy is not granted. It is built function by function, often by inviting the person who controls access to become a co-owner of the win rather than a gatekeeper to route around.

What still isn't solved

The evolution is still unfinished. In the Q&A, Ben was candid about several problems the team has not fully solved yet.

On UX debt, he admits they probably do not have as good a system for tracking it as they need.

On AI, Allied has not yet faced major pressure from leadership to justify UX headcount because AI can do more of the work, but Ben expects that conversation to come. The team is already exploring whether AI could help them scale the amount of work and value they provide without assuming that every new value stream requires another person one-for-one. His example is whether one researcher might eventually be able to support two value streams rather than one.

Even prioritisation stays messy. Rather than saying no outright, the team often says "maybe not yet", although Ben admits that sometimes means stakeholders simply move forward without them.

That honesty matters. The story is not about Allied discovering a perfect operating model. It is about becoming better at evolving the model as the organisation changes.

Where the team is headed next

Allied's UX practice has already gone through one major structural shift, moving from isolated project pairs towards embedded product teams where researchers and designers work alongside engineering and product management.

Now the team is realigning around business value streams rather than individual software products. Because Allied does not sell the software itself, a single business value stream can span several products at once. That means the team structure needs to reflect the business objectives rather than simply mirror the software portfolio.

Ben frames all of this as ongoing, not finished. If the next structure does not work, they will iterate again.

His closing challenge is simple: prioritise vision before structure, adaptability before velocity and safety before scale. Ask honestly whether your team is built for agility and influence, or only for speed.

"Growth isn't a project, it's a practice."

The team that got this far is not done evolving. Ben does not expect it ever will be.

Want to watch the full talk?

You can find the full talk here:
https://uxdx.com/session/never-done-evolving-ux-teams-who-earn-influence/

Or explore all the insights in the UXDX USA 2026 Post Show Report:
https://uxdx.com/post-show-report/