Turning uncertainty into product direction.

The challenge

This programme didn’t begin with AI. It began with the people managing enterprise accounts — and the wider teams supporting them — overwhelmed by fragmented information.

Critical alerts were scattered across multiple internal systems, each surfacing different information at different times, with little consistency in how work should actually be prioritised. Users frequently encountered inconsistent information as they switched between operational tools and data sources — manually comparing reports and deciding what deserved attention first.

Leadership believed intelligent assistance might help — but there was no evidence it was the right answer, what it should actually do, or whether people would trust it enough to adopt it.

Rather than committing engineering investment on assumption, we first needed evidence.

The task ahead was bigger than designing an interface. It meant understanding how people actually worked across regions, customer types and business models — before deciding what, if anything, should be built.

My role

I led the UX workstream for the entire programme — accountable for turning organisational uncertainty into a validated product direction, not simply for producing research or designing screens.

Across the programme, I planned and directed a multi-phase discovery effort spanning five global regions, personally moderating the majority of interviews, workshops and usability sessions myself. Where language or local expertise made that impractical, I directed regional facilitators while remaining accountable for synthesis and judgement, so the standard of evidence stayed consistent everywhere the programme ran.

Beyond research, I owned the shape of the solution end to end: mapping fragmented workflows into service blueprints, defining the interaction model and information architecture, and translating evidence into the functional product requirements the concept was built on. With no internal engineering capacity available, I partnered with an external engineering company to convert that direction into coded Proofs of Concept across four platforms. I also led the concept’s naming and visual identity, and synthesised the full programme into the executive recommendation leadership ultimately acted on.

Our first objective was to challenge assumptions rather than confirm them. Through interviews, surveys and workshops across every region, we explored how people actually managed competing demands, and where the real friction sat.

The problem wasn’t simply “too many alerts.” It was fragmented decision-making.

Interviews and workshops surfaced meaningful differences by region, customer type and role — some colleagues managed a single strategic account, others managed hundreds of accounts across hundreds of locations. Those differences, not a single averaged persona, went on to shape every decision that followed. This chapter also surfaced problems the original business case hadn’t anticipated — duplicated information, ineffective communication and decision fatigue chief among them.

Before designing a single interface, I mapped how alerts moved through the organisation, tracing more than thirty operational alert types across multiple systems, user roles and business processes. This exposed where information originated, how it flowed between teams, and where users experienced unnecessary complexity.

Rather than optimising individual screens, I designed the future-state service itself. The work established a scalable service architecture covering both time-sensitive and non-time-sensitive alerts, defining consistent behaviours, decision points, backstage processes, operational responsibilities and user journeys before interface design began.

Just because the organisation could generate an alert didn’t mean the user should receive it.

These service blueprints became the shared reference for Product, Engineering and Design — aligning everyone around how the service should work before deciding how it should look.

Time sensitivity & priority

One of the most significant discoveries from the research was that the problem wasn’t simply the number of alerts users received.

The real challenge was understanding which alerts genuinely required attention, when they required action, and what users were expected to do next.

I developed a future-state alert strategy covering both time-sensitive and non-time-sensitive alerts, establishing a consistent relationship between urgency, priority and user behaviour before any interface design began.

These principles became the foundation for the alert lifecycle, prioritisation framework and future-state service blueprint.

Before any engineering investment, I tested an interactive prototype through moderated sessions combining an in-person usability lab with remote research across every other region.

The goal was never to validate an interface. It was to find out whether people trusted the concept.

People needed to understand the logic behind prioritisation and genuinely feel it reduced their effort — evidence that shaped the next iteration well before any code was written.

In-person usability testing

I planned, built and ran the organisation’s first in-person and remote usability testing programme — recruitment, prototype design, facilitation and interviewing, through to observation, synthesis and feeding findings directly back into product design.

Remote user research

Remote moderated research sessions used to validate concepts with participants across multiple regions, enabling rapid feedback and iterative refinement throughout the design process.

One question remained unanswered: when several things demanded attention at once, what should the system decide to surface first? Rather than answer that ourselves, we built a dedicated prioritisation research programme — workshops that surfaced how people reasoned about urgency, risk, customer impact and effort, followed by a survey that validated those patterns at scale.

The result wasn’t another interface. It was an evidence-based decision model.

That model became the logic behind the prioritisation engine built into the Proof of Concept. It also surfaced genuine regional variation, which emerged through the workshops and survey rather than any visual test — some markets weighted customer size more heavily, others weighted contractual risk. That evidence directly shaped how a future version of the model could adapt by region and role, rather than forcing one rule onto everyone.

Prioritisation workshops

I planned and facilitated cross-functional prioritisation workshops around user needs, operational value and business priorities.

The outputs from these workshops helped define the requirements that ultimately informed the prioritisation algorithm and future alert strategy.

Only once the concept itself was validated did the programme move into coded Proofs of Concept. Partnering with an external engineering team, I translated the UX direction into working builds across four platforms — never intended as production software, but as a way to test implementation approaches before committing internal engineering investment.

Multiple coded concepts were evaluated. People consistently preferred the standalone mobile experience — but the evidence told a different story: most worked primarily from laptops, many had no company-issued phone, and a separate app would likely go unused.

It wasn’t the most exciting option. It was the option most likely to succeed.

That recommendation is the clearest evidence of the whole programme’s purpose: judgement, grounded in evidence, over personal preference.

Outcome

The programme succeeded — not by shipping software, but by removing the uncertainty that would have made shipping software a gamble.

What it delivered was a validated product direction, an evidence-based prioritisation model, future-state service blueprints, functional product requirements, working Proofs of Concept, and — most importantly — executive confidence grounded in global evidence rather than assumption.

From uncertainty to product direction.

The programme concluded with a concept film that brought together months of research, prioritisation and validation into a single vision for stakeholders. Rather than presenting isolated features, it demonstrated how evidence had shaped every aspect of the proposed experience.