Mapping the journey

The claim experience is a multi-channel customer journey with a low customer satisfaction score. To improve it we needed a better understanding of the experience: we narrowed down specific pain points by facilitating discovery sessions across departments, interviewing internal specialists, clients and stakeholders, and mapping processes. We distilled them into problem statements. This was one of them.

Align the team with empathy

Using a human-centered design thinking approach, I created personas as a way to share empathy across the team, turning research into clear, memorable archetypes everyone could align on. Built from interviews with customers, internal specialists, and stakeholders, these personas made user needs and emotional drivers tangible, giving cross-functional partners a shared lens to evaluate trade-offs, prioritize work, and design with greater confidence.

Rethinking intake around a behavior that had already changed

In cross-functional sessions with Claims Ops, AI Lab, Marketing, and IT, we revisited the claim intake flow from a single observation: after an accident, a driver’s first instinct is now to document the scene with their phone, not call an authority. We mapped every branch of the existing intake logic (loss type, cause, parties involved, damage, location) to find where that instinct could replace form-filling instead of fighting it, weighing a few different ways to structure a guided flow around it before settling on the direction below.

Rebuilding the full intake, with guided photo capture as the centerpiece

The shipped flow replaced one long, generic form with a branching, incident-aware intake: short, focused questions on what happened, who was involved, and when and where, instead of a single undifferentiated form, ending in a review-and-edit summary before submission so nothing gets buried. Photo capture sits at the end of that flow, and it’s where we invested the most redesign effort: it leads with the camera instead of a checklist, helping customers take clearer, more consistent photos the first time, so adjusters and downstream teams receive usable evidence without repeated follow-ups.

Fig: high-fidelity flow, reporting a collision, start to confirmation

Fig: the guided photo capture flow in detail

Validating the redesigned intake, start to finish

We tested the redesigned intake and guided photo capture flow with real customers, refining the sequencing, copy, and feedback states so the experience remained clear under stress. Filing a claim after an accident is rarely a calm moment. Losing the phone call also risked losing the human validation of being heard, so we built that reassurance into the digital flow itself: clear confirmations and plain-language status that reflected the customer’s story back to them. This iteration improved comprehension and reduced abandonment across the flow.

A shorter, smarter intake: fewer questions, more of the work done for the customer

Benchmarked against the current web FNOL (first notice of loss) flow, FILO cuts the number of compulsory questions roughly in half and prefills most of what the system already knows, so customers spend less time typing and more time getting their claim moving. The effect carried through to internal operations too: better-guided photo capture meant fewer retakes, clearer status updates meant fewer follow-up calls to check on a claim, and the overall process moved from taking weeks to a matter of days.

Projected downstream impact

Understanding the operational system

PTC is a complex, safety-critical, multi-stakeholder operational journey with high cognitive load and strict compliance requirements. To improve the experience, we first needed a shared, end-to-end understanding of how PTC is experienced in real operations. We identified key pain points by facilitating cross-functional discovery sessions, interviewing internal specialists and stakeholders, and mapping the operational processes across roles and systems, synthesizing findings into clear problem statements. Time spent in the control center, watching dispatchers work a live board, made the stakes and the rhythm of the job impossible to miss. This was never a workflow to redesign from a whiteboard.

Designing with railway experts

Instead of designing for traditional user personas, my approach was built around the operational roles that collectively ensure the safe and efficient movement of trains: railway engineers maintaining the technical infrastructure, locomotive conductors and train operators interacting with the system in real time, and control-center dispatchers overseeing network-wide operations. Designing for this ecosystem required facilitation skills and prioritizing situational awareness, clarity under pressure, and seamless coordination throughout the design phases.

Ideation within a safety-critical, regulated architecture

Design decisions had to comply with railway safety standards, ISO-aligned quality frameworks, and governmental regulatory approval before implementation. Working closely with railway engineers, system architects, and regulators, iterations focused on translating complex operational signals into clear, actionable interfaces, prioritizing situational awareness, alert prioritization, and rapid comprehension under pressure. A key capability was letting dispatchers see the network not just as it stood, but as it was about to: projected train positions and potential conflicts a few minutes out, so corrective action could happen before a situation escalated rather than after.

Fig: early UI explorations (blurred to protect proprietary railway data)

Walking the interface through real scenarios with the people who'd run it

Before any screen reached a live board, changes went through structured scenario reviews with dispatchers and railway engineers, walking through operational cases against the interface to surface places where a design assumption didn’t match how the job actually gets done, ahead of the formal safety certification every part of a PTC system has to clear before it can touch a live network.

What the interface work was aimed at

PTC’s actual safety performance is reported through regulatory channels, not something a portfolio page can responsibly quantify. The comparison below describes what changes structurally between manual monitoring and a PTC-assisted board, not a measured result.

Projected impact

Analytics had a ceiling, not a bug

Coveo’s admin analytics sat between the third and fourth generation of the category: real signal, but siloed across dashboards with no path from insight to action. Users could see a metric change but not why, and fell back on cross-referencing reports or asking a Customer Success Manager to interpret results. Meanwhile the category itself was already moving toward conversational, explainable analytics. The gap wasn’t a missing feature, it was a generation behind.

Building alignment without a formal mandate

I conducted the initial competitive analysis and synthesized insights from Product, Customer Success, and Professional Services, then framed the problem and articulated a vision for how analytics could evolve. Through one-on-one conversations, working sessions, and early concept explorations, I connected stakeholders across product, AI, and go-to-market teams and progressively built the shared understanding needed to move forward.

A customer beta program

Introducing the concept to early access customers surfaced the same handful of patterns again and again: the assistant needed to hold onto working context (which environment, which prior selection) across a session, not just a single message; safety and reversibility mattered as much as raw capability once it could touch a live storefront; feedback had to be nearly frictionless to capture, or people simply wouldn’t leave it; and even experienced users needed some structured, hands-on onboarding before they could tell what the tool was actually capable of. Access on its own didn’t teach anyone how to use it well.

Aligning use cases across the platform

I collaborated with teams across Commerce, Knowledge, and Workplace to identify common patterns and shared needs, defining a unified approach to insights, explanation, and action that could scale across the platform, while ensuring alignment with the design system and platform architecture so the solution could integrate as a foundational capability, not an isolated feature.

Early signal from the beta

The beta ran with too small a group, for too short a window, to produce disclosable metrics. The clearest early lesson was methodological, not numerical: low usage in a given account often reflected a data-readiness gap on our side, not disinterest, so the team shifted toward tracking suggestion-generation rate and response reliability alongside raw usage, rather than usage volume alone. The figures below are directional estimates of where the assistant appeared to move the needle against the program’s stated goals, illustrative only, not measured results.

The organization was scaling faster than the experience

As Coveo evolved around three Lines of Business, each organization gained greater autonomy over its own product strategy and customer experience. That autonomy increased local velocity, but it also created a systemic risk: teams began making increasingly independent decisions about navigation, interaction patterns, shared capabilities, and product architecture. Individually, many of those decisions made sense. Collectively, they were making Coveo feel less like one platform. I believed this would eventually become more than a design consistency problem. It would become a competitive one.

One customer, many roles

This wasn’t a project with a single end-user persona to synthesize. A single enterprise account rarely has one relationship with the platform: the same customer might run a technical team handling implementation and integration, a business or support organization measuring relevance through knowledge articles, FAQs, and support-case deflection, and a merchandising team on the commerce side tuning recommendations, facets, and other relevance-driven features, often across several websites or workspaces. Each role touches a different surface of the same underlying capabilities. Because the product was organized around our internal Lines of Business rather than around these roles, that one customer inherited a fragmented set of experiences to manage what should have felt like a single relevancy engine.

Summit exposed the problem

Summit gave me a chance to make this systemic issue tangible. What initially looked like Admin Console complexity revealed something deeper: our product architecture increasingly reflected organizational boundaries rather than customer mental models. I worked through models that separated shared platform capabilities from Line-of-Business-specific experiences, not to make every product identical, but to establish where consistency created leverage and where specialization created value.

Influence without authority

The hardest part wasn’t designing the model, it was getting three autonomous organizations to converge around it without formal authority over any of them, while centralization challenged local ownership, existing roadmaps, and established ways of working. Some teams saw the value; others had little incentive to prioritize platform coherence over immediate product needs. So the work became organizational: I repeatedly brought the problem into product initiatives, leadership conversations, prototypes, and design-system discussions, and built artifacts that showed how independently reasonable decisions accumulated into customer-facing fragmentation. I advocated for dedicated ownership and leadership around shared experience foundations. Within my own organization, that work led to a Staff promotion while assuming an additional Team Lead role, expanding my responsibility beyond individual product delivery, though the broader organizational problem remained unresolved.

Validated by adoption, not by a usability round

No formal usability testing applies to this kind of work. The real test was whether three autonomous organizations would adopt a model that asked each of them to give up some local control. Reception was mixed: some teams saw the value immediately, others had little incentive to prioritize platform coherence over their own roadmap. That mixed response was itself the signal — it’s what showed me influence without authority has real limits, and that the model would need executive sponsorship to move past voluntary adoption.

Three years later, the conversation is changing

The consequences of fragmentation moved beyond design consistency over time: independent product evolution made it harder to present a cohesive experience to larger enterprise customers buying across multiple Lines of Business, customers who don’t care that those products belong to different internal organizations and simply expect Coveo to behave like Coveo. Today, there is growing organizational interest in establishing that coherence: enterprise requirements are making cross-product experience increasingly important, the organization is reconsidering shared foundations, and dedicated Design Systems leadership and resources now exist where they didn’t before. I don’t claim sole ownership of that shift — organizational change never belongs to one person — but the direction reflects problems I had been surfacing, documenting, and designing against for several years.