Shaping the Future of a B2B Enterprise Talent Engagement Platform

Hollaroo is a talent engagement platform used by organisations to build communities, nurture candidates, and streamline recruitment workflows. I joined the team as a UX/UI Designer and Frontend Developer with a brief to improve visuals and client‑side interactions.

What I discovered was a deeper architectural problem: the platform’s frontend had grown into an unmaintainable legacy system with hundreds of Razor templates, dozens of jQuery scripts, and no unified design direction. This case study outlines how I redesigned the user experience, rebuilt the frontend architecture, and delivered a scalable micro‑frontend system that modernised the entire platform.

There were multiple layers that required addressing:

• User Experience

  Recruiters faced fragmented, high-friction workflows. Evaluating candidate suitability required constant back-and-forth hopping between a sparse search table and separate profile pages. Every interaction triggered a full page reload, breaking user flow, destroying filter contexts, and making candidate discovery needlessly exhausting.

• Visuals

  The interface had evolved organically into a utilitarian, cluttered patchwork without a coherent design system. Information was dense, typography lacked hierarchy, and responsive polish was missing. Accommodating 15+ corporate tenants without shared design tokens resulted in brittle CSS overrides and inconsistent brand presentation across the platform.

• Technology

  A monolithic ASP.NET 4.0 architecture weighed down by over 600 Razor views and 50+ scattered jQuery scripts. Server-rendered markup and client-side logic were tightly tangled with zero type safety or documentation. Routine UI updates risked cascading regressions across tenant configurations, and page loads consistently hovered around two seconds.

• Business Profitability

  Engineering velocity slowed to a crawl as technical debt consumed almost all development capacity. Every client-requested feature or new tenant meant bespoke work, so most engineering capacity went to maintenance rather than product. The slow delivery cycle and dated platform experience increased maintenance overhead, slowed down sales cycles, and elevated churn risk.

When facing an aging monolith serving live enterprise tenants, the instinct is often a clean-slate rewrite. But freezing roadmap development for over a year to rebuild every screen in the dark carries immense business risk, especially when a single regression could disrupt hiring for thousands of active users.

We chose the pragmatic path: an incremental migration. I've proposed separating domain boundaries and rebuilding the frontend as standalone micro-frontends embedded directly into the legacy ASP.NET shell. This allowed us to ship improvements from month one, validate each workflow against real recruiter feedback, and systematically retire legacy views without a single minute of platform downtime.

Before touching a line of code, I ran a dual-track discovery process: an exhaustive technical audit of the legacy monolith paired with structured UX research across our enterprise client base.

To pinpoint why users struggled with the existing platform, I conducted:

• Heuristic Evaluation: Audited core flows against usability standards. The audit revealed severe workflow fragmentation: full-page reloads on every interaction and shallow listings that lacked critical evaluation context. Users were trapped in constant back-and-forth navigation just to inspect basic qualifications, violating a fundamental principle: users should go deeper after making a decision, not just to discover the information needed to make one.

• Client Polling & Interviews: Surveyed recruiters and account managers across active enterprise tenants. Candidate discovery was universally ranked as their most critical daily tool, but also the most exhausting due to the constant back-and-forth navigation to profile views.

• Competitive Benchmarking: Analyzed leading recruitment platforms like LinkedIn Recruiter and drew inspiration for high-density listing interfaces from platforms such as glassdoor.com and theprotocol.it. Modern workflows had abandoned paginated tables in favor of responsive, split-screen preview paradigms.

• Expert Review, Variant Comparison & Outcome Measurement: Every page and selected components were reviewed as competing variants. For each screen I produced alternative layouts and interaction models, then ran them past the team in critique sessions, keeping the stronger direction and discarding the rest. Where a screen carried enough risk, the shortlisted variants went to experienced recruiters and account managers from active tenants for hands-on sessions in their own workflow. Validation did not stop at release: each rebuilt module was compared against the view it replaced using the metrics we already had, page load time, completion and drop-off rates, engagement, and structured feedback gathered from recruiters and account managers after rollout. Those numbers confirmed which changes landed and which needed a second pass, which is how the ~30% lift in form completion were identified in the first place.

• User Journey Mapping: Traced recruiter workflows from search and evaluation to candidate outreach. These workflow clusters directly informed our micro-frontend domain boundaries.

  Old journey: continuous page reloads and navigation hops away from search.

  New journey: in-place preview and dynamic filtering keep recruiters on one surface.

Alongside UX research, I mapped all 600 Razor views and 50+ jQuery scripts to identify data dependencies.

Together with backend engineers, we designed a micro-frontend architecture where each domain module operates as an isolated SvelteKit SPA embedded directly into the legacy ASP.NET host. Our core technology choices directly addressed our operational constraints:

While each module remained completely independent at runtime, they shared a unified frontend architecture:

• Reactive state management: ES6 classes with Svelte 5's $state and $derived. No external state library. Each module's state is self-contained and testable.
• Custom form system: Field-level validation, error outlining, async cross-field checks, and optimistic submission with automatic rollback.
• Apollo adapter: A reactive wrapper around Apollo Client that brings observables into Svelte 5 reactivity seamlessly.
• URL-driven filter/sort: Filter state synchronised with URL search params. Share filtered views, preserve state across sessions, create prefilled links.
• Shared component library: Modal, Toast, PopOver, tooltip, accordion, button/badge/card/input families. Managed as a monorepo with Turborepo so shared improvements land across all modules at once.

The infrastructure compounded. The first modules paid the setup cost. Each new module took less time than the last because shared components were already in place, ready for reuse.

Recruiters spend the bulk of their workday identifying and assessing talent. In the legacy platform, this daily workflow was weighed down by a painful "table-hopping tax." Candidate discovery was rendered as a sparse table with over 40 hidden filter dimensions. Because the rows displayed virtually no qualification details, recruiters had to click into a candidate profile, wait for a two-second page load, review details, click back, and re-apply lost filter contexts.

The legacy candidate search: minimal data per row forced recruiters into endless context-switching.

To eliminate this friction, I explored several interaction models before finding the winning formula:

• Hover previews failed: They required continuous, precise cursor control, broke down completely on touch devices, and caused user fatigue during high-volume screening.
• Customizable columns failed: Candidate evaluation requires rich, unstructured context (employment history, verified skills, interview notes) that simply cannot be squashed into table cells.
• Overlay modals failed: While faster than full-page navigation, modals blocked the search list entirely, breaking the recruiter's mental map and spatial context.

The breakthrough was a synchronized side-by-side workspace: a focused candidate stream on the left paired with a responsive profile preview and filter panel on the right. Recruiters could adjust multi-dimensional criteria while immediately scanning rich candidate credentials without leaving the search surface.

The redesigned workspace: dual-pane discovery keeping search context and profile evaluation in sync.

We backed this interaction with on-demand profile architecture. Rather than fetching 10+ candidate data sections (employment history, skills, tags, notes, documents) as a blocking waterfall, sections loaded asynchronously in parallel with bookmarkable, URL-routable edit modals. Recruiters called the new experience "a complete game changer," turning an exhausting daily bottleneck into a fluid, rapid screening workflow.

For candidates and talent community members, the legacy portal felt impersonal, rigid, and strictly desktop-bound. Complex application forms caused high drop-off rates, while relevant vacancies and community updates remained buried under static pages.

We re-architected the candidate journey around speed, mobile accessibility, and continuous engagement:

• Easy Apply & Targeted Preferences: Replaced cumbersome multi-step applications with a streamlined submission flow. Candidates set their location, industry, and salary preferences once, tailoring the job feed and triggering automated alerts when relevant roles open.
• Continuous Community Surfaces: Transformed events, resource libraries, and discussion groups into dynamic single-page surfaces. Candidates can join communities, RSVP to events, or engage in threaded discussions with optimistic UI updates and zero page refreshes.
• Mobile-First Polish: Every touch interaction, from candidate cards to expandable event details - was built with native touch targets and responsive layouts that perform smoothly across devices.

By removing friction from applications and turning static pages into interactive hubs, candidate engagement surged by roughly 60%, with application and forms completion rates improving significantly across all tenant communities.

Behind the user-facing improvements was a critical business objective: enabling scale. Hollaroo supported 15+ enterprise clients, each demanding unique branding, customized landing views, and role-specific permissions. Previously, this required maintaining dozens of templates that drove up operating costs.

We resolved this with three systemic investments:

• The Universal token based design system: a three-layer style system that improved both the speed of onboarding and the ease of implementing unique brands.
• Component driven Homepages architecture: a modular component library (hero sections, aggregated feed cards, carousels) styled via centralized design tokens. New enterprise clients could have all their homepages prepared within 1-2h.
• Branded Mailing Manager: an admin tool that applied each client's branding to outgoing mail automatically and let administrators schedule campaigns from a single place. Mail moved from a manually branded, ad hoc process per client to a templated and repeatable one.

A composable tenant homepage: shared primitives customized per client without code duplication.

Reflecting on the project, it delivered significant wins, but also provided clear insights on what I would handle differently on future enterprise initiatives:

• The Compounding Power of Shared Infrastructure: Investing upfront in a dedicated form system, Apollo wrapper, and shared design tokens paid enormous dividends. The first two modules carried high setup costs, but later modules were delivered in a fraction of the time.
• What I'd do differently: include more 3rd party components: At this stage velocity was most important. I should have started development with selection of a well supported and customisable component library.
• Sequencing the research to match the stage of the product: Validation here was expert review and power user sessions before release, plus measured outcomes against the previous view afterwards. That split was deliberate. The legacy interfaces were actively costing the business, recruiters were describing them as exhausting. Moving volume onto the rebuilt modules was the outcome that mattered, and refining a detail between two working options was the lower-value problem. Split testing pays off when the interface is sound and the remaining question is which of two good versions is better. That was not the situation, so I would make the same call again.