01Executive Summary

ForgeRock's support team was overwhelmed by "how do I…?" tickets that could realistically have been resolved through existing knowledge base content, with no system in place to intercept them before they reached a human agent. I led the end-to-end design of a dynamic recommendation system, built on new machine learning capabilities to surface relevant content before a user committed to submitting a ticket.

The project required root-causing assumptions baked into existing engineering decisions, restructuring the underlying data model, and navigating measurement through a live company merger that confounded the metrics meant to prove its impact.

02Problem & Context

Users

Customers and partners submitting support tickets through ForgeRock's web help centre.

Business need

Reduce avoidable ticket volume by deflecting resolvable "how do I" queries toward existing self-service content - easing load on the support team without degrading user experience.

Why it mattered

No prior usability testing had been done on the ticket submission flow, and no system existed to intercept users before they committed to creating a ticket. Every avoidable ticket represented both a cost to the support team and a missed opportunity to resolve the user's need faster through content that already existed.

03Role, Team & Constraints

My role

Led the project end-to-end - problem framing, research, data audit, design and stakeholder alignment - as one of three designers supporting UX and UI across the web help centre platform for a company of nearly 1,000 employees.

Stakeholders

7 lead engineers and 10 cross-functional stakeholders, built up over two years of relationship and process establishment.

Constraints

• An entirely new feature area for the business, with no existing pattern or precedent to build from
• A live company merger underway during the project, materially affecting user behaviour and traffic independent of the redesign
• An existing form structure with assumptions baked in by engineering that needed to be unpicked before a real solution could be designed

04Research & Insights

I led discovery myself, designing and running six research interviews with primary users - structured around two core questions: what frustrates users about the current ticket flow, and how they'd expect self-service content to surface without feeling intrusive.

The findings reshaped the approach significantly:

• The form itself was a source of frustration. Every interviewee felt the current form needed improvement - this wasn't a minor irritation, it was a near-universal signal.
• Field dependencies were actively frustrating. Two-thirds of interviewees specifically flagged the field dependency structure - fields disabling and enabling based on prior input, as a point of friction.
• Existing recommendations weren't working. Half of interviewees felt existing machine learning recommendations were either unnoticed or interruptive. This was the critical insight - it ruled out simply bolting new recommendations onto the existing form. The problem wasn't just what content appeared, it was how and when it surfaced.

I went further than the interviews to validate the direction. I pulled and reviewed the underlying data structure of the existing form, working with the support team to audit every field for genuine value - identifying and removing one with no demonstrable purpose, a decision that required convincing a cross-functional stakeholder group to let go of something they'd assumed was necessary.

I also root-caused the field dependency structure rather than accepting it as fixed. Investigating the original rationale with engineering revealed it had been a blunt attempt to control form completion order - not a genuine technical requirement. That reframing opened up a different solution entirely.

05Key Decisions & Tradeoffs

Decision 1: Restructure the data model instead of designing around it

Rather than treating the existing field dependency structure as a constraint to design within, I challenged its origin and found it wasn't load-bearing.

• Why this: The dependency structure was causing real user frustration and wasn't solving the problem it was assumed to solve. Once the rationale was understood as outdated rather than necessary, redesigning it became the right call rather than a risky one.
• Tradeoff: Required convincing engineering to revisit a structural decision they hadn't expected to be questioned - a harder conversation than working within the existing constraints would have been.

Decision 2: Replace disabled fields with sequential steps and guided interaction cues

Instead of fields that blocked input until prior steps were completed, I restructured the form into clear sequential steps using visual and interactive cues to guide users without disabling functionality outright.

• Why this: Disabled fields read as broken or restrictive to users; guided sequencing achieves the same ordering goal without the friction.
• Tradeoff: More complex interaction design than simply leaving the dependency structure in place, requiring closer collaboration with engineering to implement correctly.

Decision 3: Redesign when and how recommendations surface, not just their content

Given that existing recommendations were going unnoticed or felt interruptive, I treated placement and timing as design problems in their own right rather than secondary to content relevance.

• Why this: The research was explicit that the how was the core failure, not the what. Solving content relevance alone would have repeated the same mistake.
• Tradeoff: Required building a foundation for responsible, gradual content surfacing rather than shipping a fully-realised recommendation engine on day one - a deliberately phased approach over a more impressive-sounding complete solution.

06Solution

Restructured form architecture

The form was rebuilt around a leaner data model with the unnecessary field removed and reorganised into sequential steps that replaced disabled fields with visual and interactive guidance cues.

Redesigned recommendation surfacing

Rather than bolting machine learning recommendations onto the existing flow, the system was redesigned to surface relevant content responsibly - informed directly by user feedback on what felt intrusive versus helpful.

Phased content roadmap
Recognising that self-service patterns weren't yet fully understood, the solution included a phased plan to introduce additional content types over time, building in room to learn rather than assuming the first version would be the right one.

07Results & Impact

I want to be direct about the limits of what this data can tell us rather than overstate the result.

The release landed during a live company merger, which materially affected traffic and user behaviour independent of the redesign - knowledge platform searches dropped 38% over the same four-month window, and overall ticket volume fell 12%, both largely attributable to confusion over which platform served which company post-merger.

Against that backdrop, ticket drop-out during creation moved only slightly - from 8.2% to 8.3%. In isolation, that looks flat. But holding completion steady while removing friction and adding entirely new functionality, during a period of significant external disruption, is a more meaningful result than the raw number suggests on its own.

Strategic impact

The project established a structural and process foundation - a leaner data model, a clearer step-based flow, and a phased framework for responsible content surfacing - that the business could build on once the merger's confounding effects cleared.

08Reflection & Next Steps

What I'd do differently

I'd build the measurement plan with the merger timeline in mind from the outset, ideally establishing a cleaner baseline window before the disruption began, so the impact of the redesign itself could be isolated more confidently.

What remains unsolved

The honest conclusion is that the test-and-learn approach needs to continue post-merger, once the data isn't confounded by external noise. Whether the redesigned flow performs as intended under normal conditions is still an open question - not something the current data can answer.

Where this goes next

A phased rollout of additional content types as we learn what self-service patterns actually work, building on the foundation this project established rather than treating it as a finished system.