Advocating for UX in a large product team

On our counsellor workspace project, the first task was to make sure people could do everything in the new system that they could in the old one. That was a reasonable place to start. The existing tools were unreliable, and moving to a new platform was already a substantial piece of work.

But we’d also spent time with counsellors and knew where those tools made their day harder. Copying them would mean carrying some of those problems into the new system. I wanted us to use the move as a chance to fix them.

Making room for that work meant working closely with product, engineering, and clinical teams. We had to explain why a change mattered, understand what it would take to build, and decide what we could realistically deliver. Some of that went well. We also got things wrong, particularly around rollout and expectations.

These are a few things I took from that project and the related work on our booking tools.

Start with something people recognise

It’s hard to have a useful conversation about making software “more intuitive.” It’s much easier to talk about a counsellor opening several tabs just to get ready for an appointment.

Before a session, counsellors had to piece together recent assessments, clinical history, and other client information from different screens. Each move triggered another load. The information was there, but getting to it took too much effort.

That gave us a specific problem to work on together. We brought the information into a pre-session summary, with access to the full records when more detail was needed. It was easier to explain the value of that change because we could show how it fitted into a counsellor’s day.

On the provider booking project, agents told us they sometimes skipped the first pages of appointment results to avoid slots that looked available but failed when they tried to book them. They called these “shadow availabilities.” That workaround said a lot about how little they trusted the tool. It also made the problem much more concrete than a general complaint about search.

For me, this is where research helps with advocacy. It gives the team something specific to understand and respond to.

Find the people who share the problem

The booking work mattered to operations as well as the agents using the software. Our service-level agreements required us to offer care within short time windows. Unreliable availability made it harder for agents to help clients and harder for the business to meet those commitments.

Making that connection helped us build support for more than a like-for-like replacement. We worked with product and operations to make the case for booking foundations that could eventually support other services too.

I think it’s worth making that ambition clear early, while other teams can still help shape it. Operations and clinical leadership understand parts of the service that aren’t obvious from the interface. They can also explain why a problem matters in conversations the design team isn’t part of.

There was a similar connection in the counsellor workspace. The client-facing product was prioritising longer-term mental health support. Bringing clinical notes together across a client’s ongoing care helped counsellors deliver that kind of service. We could explain the change in terms of both their work and the direction of the product.

Work through the constraints with engineering

The counsellor tools were built on Microsoft Dynamics 365. We couldn’t design them as though we had a blank canvas. The navigation had to work with the CRM’s data model, and custom behaviour meant additional engineering effort.

Working with engineering was a big part of getting the improvements made. For example, the original structure put clinical notes under individual appointments. Counsellors needed to read across sessions, so we linked the notes to the record for the client’s ongoing care and showed them as one chronological history.

That was a practical change to how the information was connected, not just how a screen looked.

We didn’t get everything we wanted. On the booking project, I wanted agents to be able to use the tool as a standalone app, keeping their main CRM workspace free. Technical constraints meant it had to be integrated instead. That gave us some benefits, including automatic client context, but less flexibility in how agents could arrange their work.

I don’t think accepting a compromise means you stop advocating for the user. But you do need to be clear about what the compromise makes harder, rather than treating the constraint as if it has made the problem go away.

Be careful about what the vision promises

This is the part we didn’t handle well on the counsellor workspace.

I’d shown clinical leadership a more complete experience that included a care-plan portal and simplified booking. It helped align the team around where we wanted to go. But we hadn’t managed expectations around how quickly we could get there.

We launched an MVP knowing some workflows weren’t yet as usable as the old tools. The plan was to improve them through iteration. Then resources shifted to meet the needs of a large B2B client, and those improvements were delayed.

We didn’t properly reset expectations or reconsider the rollout plan. Counsellors had moved to the new system, but parts of the experience we’d shown them were still missing.

Losing that trust hurt. People had been willing to work through the smaller issues because they felt heard and could see progress. Once that changed, every issue became harder to work through.

Looking back, I’d be much more explicit about what was ready, what was planned, and what wasn’t committed. If capacity changed, I’d want us to revisit the rollout as well as the backlog. People need to know what that change means for the work they’re being asked to do.

Look past the initial response

There were real improvements in the counsellor workspace. Reliability complaints fell, and counsellors reported saving time preparing for sessions. But the initial improvement in satisfaction didn’t last.

We ran satisfaction surveys twice a year and looked at feedback alongside reliability complaints and reported preparation time. Those measures told different parts of the story. A more reliable platform didn’t make the missing workflows or delayed updates less frustrating.

That experience made me more cautious about calling a launch a success too early. I want to know whether people can do their work after they’ve settled into the new system, and whether we’re following through on what we told them.

What I’d carry into the next project

I’d still start by understanding people’s day and making the problems clear enough for the wider team to work on. I’d involve operational partners early and work with engineering on what we could realistically change.

But I’d pay more attention to the move itself. Can people do their essential work at least as well as before? Do they understand what’s changing? And if our plans change, have we told them?

Making the case for better UX matters. So does being honest about what we can deliver. On that project, we made useful improvements to the interface, but we didn’t take enough care with the expectations we’d created. That’s the part I wouldn’t want to repeat.

The counsellor workspace case study goes into more detail on the design and where we missed the mark.