Turning legacy complexity into a system teams could move forward with

Improving a product we already knew we would replace

Screening Manager was HireRight's client-facing application for placing screening orders and receiving completed reports. It was a critical part of the screening ecosystem, but by the time this project began, its age was increasingly visible and client complaints were rising. There was already a longer-term answer: replace it.

That replacement, however, was still expected to take roughly four to five years before it could be viable enough to replace the legacy software. Screening Manager needed to continue serving clients throughout that period, which created an unusual brief. Investing heavily in redesigning its workflows made little sense when those workflows were eventually expected to disappear, but leaving the existing experience untouched for several more years wasn't acceptable either. I joined the project as the sole Senior Product Designer, working with a Product Manager, Business Analyst and two developers.

The mandate was deliberately narrow: Modernise the visual experience without fundamentally changing how the product worked. Minor UX improvements were possible when there was a strong case for them and the development cost remained comfortably below a sprint, but this wasn't an opportunity to quietly turn a visual refresh into a product redesign.

That constraint became the starting point for almost every decision that followed.

We weren't designing the future of Screening Manager. We were deciding how much better the present could become without investing in a future we already expected to replace.

The workflow was largely fixed. The experience around it wasn't.

A visual-only mandate can easily become a reskin: replace colours, update typography, introduce newer controls and leave everything else untouched, but that approach wasn't enough here. Even when the underlying workflows had to remain stable, there were still decisions being made by the interface: what attracted attention first, what appeared related, how actions were distinguished, how dense information was organised and whether similar interactions behaved consistently from one part of the product to another.

So rather than starting by asking how Screening Manager should look, I started by looking for the parts of the experience we could improve without violating the reason the scope existed in the first place. A UX problem didn't automatically justify changing a workflow. Where an improvement required substantial new logic, altered established behaviour or meaningful engineering investment, it generally remained outside the project. Where hierarchy, structure, component behaviour or a small interaction change could materially improve the experience without creating disproportionate implementation cost, we had room to act.

The constraint wasn't something to work around. It was part of the design problem.

Similar screens were being solved as separate screens

As I worked through Screening Manager, another pattern became increasingly important. The product was large and fragmented, but many of its pages weren't fundamentally unique. Different areas repeatedly used very similar structures and interaction patterns, even when their implementations had diverged over time. Treating every page as an independent redesign would have reproduced that fragmentation in the modernised product and created unnecessary work for a development team of only two people so I began grouping pages according to the structures they shared.

Instead of designing Page A / Page B / Page C / Page D as four isolated deliverables, we could identify the common structure underneath them and solve that structure once. The visual modernisation started becoming less about individual screens and more about a small set of reusable decisions that could propagate through a much larger product. That helped us keep the experience consistent, but it also changed the economics of implementation. With two developers and a deliberately constrained investment, every reusable decision reduced the amount of work required to modernise the next part of Screening Manager.

Consistency wasn't only a design-quality decision. In a constrained modernisation, it was an implementation strategy.

Fixing inconsistency exposed a problem larger than Screening Manager

The more of Screening Manager we modernised this way, the harder it became to treat its inconsistencies as problems belonging only to Screening Manager. The application hadn't become fragmented because individual teams deliberately wanted inconsistency. Different problems had been solved at different times, by different people, under different constraints, without a sufficiently strong shared foundation connecting those decisions. Modernising the product could fix the visible result, but it couldn't prevent the same thing from happening elsewhere.

This mattered because HireRight was beginning to modernise more than one part of its product ecosystem. Applicant Center was moving toward a ground-up rebuild, deeper modernisation of Screening Manager was being explored, and other products faced many of the same foundational questions we were resolving here. If each product answered those questions independently, we could make Screening Manager more consistent while continuing to create inconsistency at an organisational level, which was a much more expensive problem.

Fixing the screens could improve one product. Sharing the decisions behind them could improve the products that came next.

The modernisation became evidence for a design system

There had already been discussion around creating a shared component library or design system, but Screening Manager gave us something more useful than an argument for consistency in principle. It gave us evidence from a real product. We could see where repeated solutions had diverged, identify which structures genuinely recurred, understand where standardisation reduced implementation effort and demonstrate that shared foundations could solve problems teams were already encountering.

That evidence helped me make the case for what became ReVolve, HireRight's design system. This wasn't the original purpose of Legacy Modernisation and we didn't start the project with a hidden design-system roadmap. The opportunity became clearer because of what the work exposed.

The strongest argument for a design system wasn't that consistency was good. It was being able to show where inconsistency was already costing us.

Many of the primary components developed for the Screening Manager modernisation became a structural baseline for ReVolve, but we deliberately didn't carry the visual language across unchanged. ReVolve introduced Noto Sans, a more neutral black-and-white component palette, blue as its primary accent, and standard semantic colours. The underlying component patterns remained familiar while their visual expression changed. Screening Manager was ultimately expected to be rebuilt, so the reskin could act as an intermediate state: reducing the behavioural transition users would eventually face without making the rebuilt experience feel like another minor reskin.

The before and after metrics mattered because the workflow barely changed

The constraint on Screening Manager meant that success couldn't depend on reinventing how people used it. Most of the underlying workflows, business logic and information requirements remained where they were. That made the before and after particularly useful evidence. The difference wasn't a new journey replacing an old one; it was what happened when the same journey was given clearer hierarchy, more consistent interaction patterns and a reusable visual structure.

Rather than redesigning each screen independently, we applied the same decisions repeatedly across the product. The result was an interface that remained recognisable to existing users while behaving much more consistently from one part of Screening Manager to another.

Consistency had to survive beyond the screen

The before-and-after comparisons show the visible change, but solving each screen independently would have recreated the same problem in a cleaner interface. As the modernisation progressed, recurring controls and behaviours were pulled into reusable components. Buttons, inputs, menus, tables, states and other common patterns were defined once and then applied across Screening Manager rather than being reinterpreted for each page.

With only two developers working on the modernisation, this wasn't just about design consistency. Reuse reduced the number of decisions that had to be designed, specified and implemented repeatedly.

A constrained intervention still produced measurable change

The reason this project became useful evidence wasn't simply that the modernised product looked more contemporary. After launch, the impact appeared in how clients experienced the product and in the support burden surrounding it.

Within the first 24 weeks, Screening Manager recorded 75% fewer client complaints, approximately £560K in support-cost savings and 4.2 / 5 client satisfaction.

We hadn't rebuilt the product. The workflows were substantially the same, the infrastructure was substantially the same and the product was still the legacy product expected eventually to be replaced. The intervention was deliberately constrained and yet improving the foundations of the experience had produced a measurable effect.

The project gave us evidence that foundational experience quality wasn't only cosmetic. It had operational and customer consequences.

The interface was temporary. The evidence wasn't.

Legacy Modernisation started because Screening Manager needed to remain usable while the organisation worked toward replacing it and that shaped the project from beginning to end. We didn't attempt to turn a visual modernisation into an unlimited redesign, and we didn't optimise every part of the experience as though this were the product HireRight intended to keep forever. We worked inside the investment the product could reasonably justify, but accepting that constraint didn't mean treating the work as disposable.

Grouping similar pages reduced the cost of modernising a large fragmented product, reusable patterns improved consistency without requiring us to rebuild its workflows, measuring the result demonstrated that foundational experience quality could affect both client perception and operational cost and the inconsistencies we uncovered gave us evidence for a problem that wouldn't disappear when Screening Manager eventually did.

That evidence helped make the case for ReVolve. In that sense, the most durable outcome of the project wasn't any individual screen, it was recognising which decisions were worth allowing to outlive the product.

We knew the interface was temporary. So I looked for the parts of the work that didn't have to be.