Making a complex candidate journey explain itself

Applicant Center was HireRight's candidate-facing application for background screening. It was where candidates provided the personal, employment, education and other information needed to complete their screening. For the candidate, Applicant Center was the screening experience. Behind it, however, sat a much larger ecosystem. Clients initiated screening orders through Screening Manager. Candidates supplied their information through Applicant Center. That information moved into OpTool, where HireRight's researchers carried out the verification work, requested additional information when necessary and produced the screening results that eventually returned to the client.

Applicant Center sat in the middle of that chain, connecting the person being screened with the operational systems responsible for actually performing the screening.

That position mattered. We had considerable freedom to rethink what candidates experienced, but Applicant Center still had to provide the information the rest of the screening process depended on.

The ecosystem itself was already changing

When we started rebuilding Applicant Center, it wasn't intended to be the only application undergoing significant change. Screening Manager had already received a visual modernisation, which I had worked on, and a deeper modernisation was being explored. A replacement for the internal researcher experience in OpTool began not long after Applicant Center. For a period, all three parts of the screening ecosystem were moving toward a new generation while the legacy products continued running the business underneath them.

The earlier Screening Manager work had also exposed a different problem. Many of the inconsistencies we were trying to solve weren't really Screening Manager problems at all; they existed across HireRight's products. That work became part of the evidence for investing in a shared design system rather than continuing to solve the same problems independently inside each application.

That shared foundation became ReVolve. But ReVolve wasn't a finished design system handed to the Applicant Center team. It was being created alongside the products that needed it, with limited dedicated resources. Applicant Center became its first major product environment, giving us somewhere to apply emerging foundations and components against the complexity of a real product. The relationship therefore worked in both directions. ReVolve gave Applicant Center a common foundation, while Applicant Center continuously exposed what that foundation still needed to support.

Then the future we were designing for changed

The wider modernisation programme didn't develop as originally expected.

Replacing OpTool proved considerably larger than anticipated and was eventually removed from the immediate roadmap. The deeper Screening Manager modernisation was later shelved for different reasons. Neither necessarily disappeared as a future possibility, but the assumption that Applicant Center would soon live entirely inside a modernised ecosystem was no longer safe.

Applicant Center was at a different stage.

By then, we already had working software capable of supporting much of the screening behaviour required by HireRight's largest US clients. Rather than stopping another substantial piece of modernisation work, the business allowed Applicant Center to continue toward release.

That left us rebuilding one part of an ecosystem while accepting that the systems around it might remain largely legacy for years.

We had to support the world that existed without making it the blueprint for the world we were building.

We had to build for the ecosystem we had without locking the next one to it.

Ground-up didn't mean greenfield

The new Applicant Center still shared fundamental infrastructure with the product it was replacing.

Old and new experiences needed to coexist during the transition. Existing databases had been designed around the legacy architecture. Researchers continued working through legacy OpTool and established verification processes. The information required downstream didn't disappear simply because we wanted to collect it differently upstream.

And, above all, background screening remained a highly regulated process. Legal and compliance requirements weren't something a redesign could simply remove.

Those were real constraints.

What wasn't yet clear was how much of the experience surrounding them was equally necessary.

That distinction gave us an unusually broad design space. We weren't being asked to reskin the existing Applicant Center or translate its screens into a new visual language. We could reconsider almost everything candidates encountered, provided the resulting product continued satisfying the obligations and systems around it.

Over the course of the project that meant questioning how information was collected, structured and validated; how candidates moved through a screening; when requirements appeared; how progress was preserved; how returning candidates were recognised; whether previous information could be reused; how international histories were represented; how the experience behaved across devices; and eventually even how we determined which clients could safely move from the legacy product to the new one.

Four years changed both the product and our understanding of it

Applicant Center developed over roughly four years.

During that time product managers, engineers and business analysts changed, while a smaller core remained relatively stable, including the two designers working on the experience. The surrounding modernisation programme changed. ReVolve matured alongside us. Our understanding of the legacy product deepened. Things we initially thought were good solutions were challenged as we learned more.

Eventually, the new Applicant Center progressed from Limited Availability to General Availability in the US.

But the scale of the work wasn't really defined by four years, the number of screens we produced, or the number of features we rebuilt.

It came from having permission to question almost the entire candidate experience while still operating inside a system where some things genuinely could not move.

That left us with a much more important question than how do we rebuild Applicant Center?

What actually had to stay?

The legacy product told us where to look, not what to build

There was no formal brief for rebuilding Applicant Center. The product had been developed and expanded over many years, beginning long before I joined HireRight. Features had accumulated as screening requirements, client needs and operational processes changed, but relatively little documentation existed explaining why individual parts of the experience worked the way they did.

Our direction was essentially verbal and it gave us the freedom to do whatever was necessary for its success. That gave the team considerable freedom, but very little specification for what the replacement actually needed to support. Creating that specification from scratch wasn't particularly realistic either. Applicant Center contained years of accumulated product and screening knowledge, much of which existed primarily in the software itself so we started with what we had: The legacy Applicant Center wasn't our source of truth. We treated it as the previous implementation of a brief we no longer had.

Years of development had left more than one answer to the same problem

That made the legacy product useful, but not straightforward. Applicant Center hadn't evolved as one continuously designed system. Over the years, different teams had solved similar problems relatively independently, sometimes creating their own interpretations of functionality that already existed elsewhere. The result was a product containing repeated and overlapping solutions alongside an ageing technology stack and visual language. Those became three of the clearest reasons for rebuilding rather than continuing to modernise the existing application:

• Technology had reached the point where the existing stack was limiting where the product could go.

• Functionality had accumulated in isolation, leaving multiple features solving very similar problems in different ways.

• Experience reflected years of those decisions through an increasingly outdated and inconsistent interface.

A rebuild gave us an opportunity to address all three together, but replacing the technology and visual language wouldn't necessarily produce a fundamentally different product. Before we could decide what to build, we still needed to understand what all of those accumulated features were actually trying to accomplish.

We reconstructed the brief by taking the product apart

We worked through the legacy experience feature by feature. The starting question wasn't “How should we redesign this?”. It was:

Why does this exist?

An existing feature told us that somebody, at some point, had needed the product to accomplish something. Our job was to work backwards until we understood what that actually was. That could lead to a screening requirement, a client need, a downstream operational dependency, a technical decision or a legal obligation. Once we understood the reason, we could validate whether it still applied rather than assuming that its presence in the existing product justified carrying it forward.

Sometimes an entire feature represented something the new Applicant Center still needed to accomplish. Sometimes only part of it did. Sometimes several apparently different features turned out to be different implementations of essentially the same underlying need. And occasionally, once we understood why something existed, there was no longer a compelling reason to rebuild it at all.

Eventually, a feature became individual pieces of information

That investigation often went much deeper than the feature itself. Once we established that an outcome was still required, we broke down the information needed to achieve it. For every piece of data the legacy Applicant Center requested, we could ask another set of questions.

Does the screening actually need this? If it does, does the candidate genuinely need to provide or confirm it? If they don't, is there another reliable source from which the system can obtain it?

That distinction became increasingly important because information required by the screening wasn't automatically information we needed to ask the candidate to enter.

Some information genuinely belonged to the candidate. Other information could already exist within the system or be retrieved from an appropriate source. And some information had survived inside legacy features even though the new experience no longer had a meaningful reason to collect it.

The objective wasn't simply to make the forms shorter.

The quality of a background screening depends heavily on the completeness and accuracy of the information behind it. Every unnecessary field created another opportunity for a mistake. Asking for the same information repeatedly created opportunities for conflicting versions of the same fact. Large, unfocused forms made candidates divide their attention across information that didn't necessarily belong together.

Reducing unnecessary candidate input therefore improved more than convenience.

The quality of the data depended partly on the quality of the experience used to collect it.

We weren't trying to make screening easier by asking less of the screening. We were trying to give candidates better conditions for providing what the screening genuinely needed, accurately and completely.

Rebuilding the product also meant reconsidering how decisions were made

There was another part of the legacy Applicant Center that wasn't captured in the formal rationale for rebuilding it.

HireRight operates in a heavily regulated industry, so Compliance necessarily had substantial influence over the product. There were areas where their expertise had to determine what was legally possible, and Design could not independently reinterpret those requirements.

Historically, however, that necessary influence had sometimes extended beyond regulatory decisions into broader Product and UX decisions.

We already knew that before the rebuild began.

The timing of the project gave us an opportunity to establish a clearer model. A new Product leader had joined shortly before the rebuild, bringing experience from another highly regulated industry where the separation between regulatory expertise and product ownership had been more explicit.

With leadership support, we could establish clearer responsibility from the beginning of the project.

The intention wasn't to involve Compliance less.

It was to involve them where their expertise mattered most.

Compliance helped establish what the product had to protect. Product and Design remained responsible for deciding how those requirements became an experience.

Where the distinction wasn't clear, we worked through it together.

That made Compliance particularly important while we were reconstructing the missing brief. Finding something in the legacy product that appeared to exist for compliance reasons didn't tell us whether the exact behaviour was legally necessary.

We needed to understand the requirement underneath it.

Sometimes the existing behaviour represented a genuine boundary we had to respect. Sometimes the requirement was real but there was considerably more room to redesign the experience around it than the legacy implementation suggested.

Clarifying that difference required Compliance's expertise just as much as designing within it required ours.

Otherwise, we risked rebuilding the same product with better visuals

That separation of responsibilities mattered because the problems in the legacy Applicant Center weren't produced by its interface alone. The product reflected years of technical decisions, isolated feature development, regulatory requirements and the organisational structure through which decisions had been made.

Changing the technology could solve the first. A new visual language could solve the most visible part of the last. Neither automatically changed the system that had produced the experience. If we carried the same assumptions and decision ownership into the rebuild, we could spend years replacing Applicant Center only to end up with something fundamentally similar running on newer technology and looking considerably better.

Rebuilding the interface required us to understand the system. Rebuilding the product also required us to understand the system that had produced the interface.

By the time we began designing individual parts of the new Applicant Center, we had something much more useful than a list of legacy features to reproduce, we had begun reconstructing the brief underneath them.

We had a clearer understanding of where different kinds of requirements came from, a healthier model for deciding who should own the decisions around them and, crucially, we had stopped treating the previous implementation as an answer. It was somewhere to start asking questions.

Our first solutions were still carrying the old product

Once we had begun reconstructing the requirements underneath Applicant Center, we could start designing around them. That didn't mean we immediately stopped thinking like the product we were replacing and one of the clearest examples was Education. Our early work had already challenged the information being collected. We had broken the existing feature down, questioned individual requirements and removed information that no longer needed to be part of the candidate experience. The resulting wireframe was cleaner and more focused than the legacy version, but it was still fundamentally one long Education form.

We had questioned what we collected, but not yet how we collected it

Breaking the legacy product apart had helped us recover the underlying requirements, but removing unnecessary fields didn't automatically produce the right experience. We had changed the contents of the form, but we hadn't yet questioned why it needed to be one form at all. Education wasn't really a single object. A candidate could have attended several institutions, completed multiple qualifications, returned to education later in life or need to provide different kinds of information for different records. Treating all of that as one continuous form made the interface responsible for managing complexity that actually belonged to the information model underneath it so we reconsidered the unit we were designing.

Instead of: Education = a form

we started treating it as: Education = a collection of records the candidate can manage individually.

That seemingly small change affected much more than the layout.

More screens didn't necessarily mean more complexity

Moving away from the long form produced more individual screens. On paper, that could look like we had made the journey longer, but screen count wasn't a useful measure of complexity. The long form required the candidate to understand and manage a large amount of information in one context. Breaking the interaction into focused steps allowed each screen to ask a smaller, more coherent question while the Education hub maintained the candidate's understanding of the whole. The journey could now move through focused contexts:

School details → Degree details → Candidate details → Review → Education

Rather than asking candidates to navigate one large structure, the system could manage that structure for them.

The same question started appearing elsewhere

Education wasn't an isolated redesign problem. Once we started questioning the structure of our own solutions, similar assumptions became easier to recognise throughout Applicant Center. A required piece of information didn't necessarily need to block everything that came after it, a validation error didn't necessarily need to prevent a candidate from continuing, a mandatory inactivity timeout didn't necessarily mean candidates had to lose unsaved work and additional screening requirements didn't need to appear unexpectedly at the end simply because that was where the legacy product had surfaced them.

The question increasingly became:

What is actually required here, and what behaviour have we attached to that requirement ourselves?

Progress and completeness didn't need to happen at the same time

One of the larger changes that followed was how Applicant Center treated incomplete information. The legacy experience relied heavily on hard stops. If required information wasn't available, the candidate could be prevented from progressing, but candidates don't necessarily have every piece of their history available at the moment they're completing a screening. They might need to check a date, find a document or confirm information elsewhere so blocking progress didn't make that information more accurate. In some situations, it could create pressure to enter something simply to get past the screen.

So we separated two ideas that the legacy experience had often treated as the same thing:

Can I continue?

and

Is my screening ready to submit?

The new experience could allow candidates to move forward while keeping incomplete areas visible and recoverable. Validation still protected the information required for submission, but it didn't have to control every movement through the product.

Progress and completeness didn't need to happen at the same time.

That also changed the role of the final review. Instead of being simply the last screen before submission, it could give candidates a view of the state of their screening: what was complete, what still needed attention and where they needed to return. That made review a control surface for the journey rather than just its conclusion and because sections no longer had to behave as isolated sequences of hard stops, candidates had more control over the order in which they completed their information without weakening the completeness required at submission.

We designed for interruption rather than pretending we could prevent it

The screening process sometimes required information candidates wouldn't have immediately available. They might need to leave, find a document, confirm a date or simply return later. The mandatory inactivity timeout introduced another interruption we couldn't remove. Rather than trying to design those interruptions away, we asked a different question: if someone has to leave, what is the smallest amount of work they should be able to lose?

We settled on a single input. Every time the candidate moved from one input to another, the value they had just entered was saved silently. There was no Save button and no separate action to remember. Everything behind their current input had already been preserved. If they left unexpectedly or were timed out, the most they could normally lose was whatever they were entering at that moment.

We couldn't guarantee an uninterrupted journey. We could design the smallest possible consequence when it was interrupted.

Choosing which battles had to be won allowed us to collaborate better

Rebuilding Applicant Center gave us considerably more freedom to rethink the candidate experience, but it didn't remove the environment the product operated within. Background screening is heavily regulated, and Compliance needed to remain closely involved throughout the project. We had established clearer ownership before the rebuild began: Compliance helped us understand the legal and regulatory boundaries, while Product and Design remained responsible for how the experience worked within them.

That separation made collaboration healthier, but it didn't make every decision straightforward. There were still areas where Design wanted to push further than Compliance was comfortable with, interpretations differed, or a technically permissible direction carried enough uncertainty that Compliance preferred the more conservative option. In those moments, the question wasn't simply whether we could argue for the experience we wanted.

It was whether this particular decision was important enough to spend some of the trust we had built because we all knew that compliance and design were protecting different things.

Some tension was inevitable because the two disciplines were responsible for different kinds of risk. Compliance needed the screening process to remain legally defensible and understandably tended towards caution when there was uncertainty. Design needed to protect the candidate from unnecessary friction, confusion and anxiety, and that meant questioning restrictions when we couldn't understand what requirement made them necessary.

Neither responsibility was inherently more important and disagreement didn't mean the relationship was failing. In many cases, disagreement was exactly what collaboration was supposed to expose.

We didn't reopen every disagreement

This is where the story becomes much more interesting. There were occasions when Compliance rejected a direction we wanted to pursue. Most of the time, we accepted that decision and continued designing within the boundary they had established even when we suspected there might be room for a different interpretation, because technically winning every disagreement would have been a terrible way to build the product.

We needed Compliance to remain willing to engage with us, examine unusual cases, reconsider established interpretations and help us understand where genuine flexibility existed. Constantly escalating decisions we didn't like would have made that relationship harder, not better so we became selective. When something was rejected, the question wasn't immediately: Can we challenge this? It was closer to: Does this matter enough to the candidate experience that the whole team believes it is worth challenging again? Only a small number of decisions reached that threshold.

We didn't optimise every compliance discussion for the best possible feature. We optimised the relationship for the best possible product.

That also meant deliberately accepting solutions we knew weren't the ideal UX. Sometimes removing friction introduced regulatory uncertainty; sometimes a more conservative behaviour was acceptable because the candidate impact wasn't significant enough to justify reopening a settled discussion. We didn't see those compromises as failures or as decisions that happened outside the design process. They were design decisions in their own right. The threshold was different for every disagreement: a rare edge case might not justify another difficult conversation, while something affecting most candidates, increasing the likelihood of inaccurate information or undermining one of the principles of the rebuild might. We were constantly balancing candidate impact, regulatory risk, frequency, confidence and the cost to a relationship we needed to sustain for the rest of the project.

The best interaction in isolation wasn't always the best decision for the product.

Trust made harder conversations possible

The interesting consequence of being selective was that when the team did push back strongly, that pushback meant something. We weren't challenging Compliance simply because a restriction made the interface harder to design. Most boundaries had already been accepted and incorporated into the product so when Product and Design collectively believed something was important enough to revisit, there was a stronger basis for the conversation and those conversations weren't necessarily about convincing Compliance they were wrong. Sometimes the answer remained no and that was still useful.

A well-understood no gave us a boundary we could confidently design against. Other times, discussing the underlying requirement revealed that the boundary was wider than the previous implementation had suggested, giving us room to find a better candidate experience without weakening the protection Compliance was responsible for.

Compliance defined the boundary. Design explored the space inside it. Sometimes collaboration helped us discover that the space was larger than we initially thought.

The process mattered because the relationship had to survive the project

Some of the experiences we shipped were not the experiences we would have designed without regulatory constraints. Some boundaries remained even when we would have preferred to move them.

But the goal was never to win every argument.

We needed to build the strongest candidate experience we could inside a regulated system, while maintaining the relationships that allowed us to keep questioning that system over four years.

Sometimes protecting the ability to have the next difficult conversation mattered more than winning the current one.

We didn't need to finish everything before anyone could use it

After years of rebuilding Applicant Center, “finished” wasn't a particularly useful definition. The legacy product supported a large number of clients, products and screening configurations accumulated over years, across multiple countries and varying legal constraints per country. Recreating all of that before releasing anything would have kept the new experience hidden for much longer, while rebuilding capabilities that might no longer justify their existence so the question changed.

Instead of asking “When have we rebuilt Applicant Center?”, we started asking:

Who is Applicant Center ready for now?

That shift connected much of the work that had happened before it. The requirements we had reconstructed, the capabilities we had chosen to retain, the new completion model and the decisions made with Compliance could now be evaluated against real client configurations.

Business Analysts examined how the largest US clients actually used Applicant Center: which products they ordered, which capabilities those products depended on and which screening requirements their candidates encountered. They eventually covered the top 100 US clients , not as a list of clients we intended to launch to, but because it was a way of understanding which capabilities would unlock the largest useful part of the product.

Some legacy capabilities had significant usage and needed to survive. Others had little or effectively no meaningful use and could be retired rather than rebuilt. Parity therefore stopped meaning:

Everything the old Applicant Center could do. It became instead the outcomes that still needed to exist for the clients we could support.

A capability wasn't valuable because it moved us one step closer to feature parity. It was valuable because of the additional client configurations it allowed the new product to support.

Once the product covered enough meaningful client configurations, we didn't need to restrict Limited Availability to the companies used in the original analysis. Any eligible client within the initial US boundaries could opt in. The top 100 helped us decide what to build. Eligibility determined who could use it. As another retained capability became available, more client configurations became supportable. Those clients could become eligible while unsupported scenarios remained safely on the legacy Applicant Center so rollout became a continuing loop.

The US Applicant Center moved from Limited Availability into General Availability. International expansion was intended to follow, and we had already designed for international complexity inside US screenings. Candidates could have studied, worked or held credentials elsewhere, but the broader international launch had not happened by the time I left. What shipped was substantial: the candidate-facing part of a large screening ecosystem had been rebuilt from the ground up, while continuing to work with much of the infrastructure and operational environment that preceded it and it had moved from design, through Limited Availability, into General Availability.

The product changed because our definition of the problem changed