sebin-george

Lead Management System

Designing a generalised Lead Management System from competitive research to shipped product.

Domain:

Martech

Designed For:

Web

Team:

1 UX Designer,1PM,2 Developers

TL;DR

Problem: Every new client got a fully custom LMS. As demand grew, this became impossible to sustain.

What I did: Sole UX Designer on the team. Owned end-to-end design from scoping and research through to shipped product working along 1PM and 2 Developers across a 4 month build.

Outcome: V2 shipped to select clients with significantly improved data density and usability.

CHALLENGE

We had built multiple specialised LMS platforms for our clients.

This created three compounding problems:

For our sales ops teams: switching between multiple LMS instances depending on which client they were working on created constant reorientation different workflows, different field names, different navigation for the same underlying tasks.
For clients: new implementations took months. By the time a system was set up, early campaign momentum was already lost.
For our dev team: every feature request even small ones had to be replicated across separate codebases. There was no shared foundation to build on.

The cost of this wasn't visible in any single project. It showed up as compounding overhead every time we said yes to a new client.

*client name & data removed

Two separate LMS instances, each built for a different client. Same core functionality, zero shared code.

EXPLORING SOLUTIONS

We weighed three approaches:

An internal dashboard layered on top of existing systems for cross-client management.
A multi-tenant platform, where client-specific behaviour — pipeline stages, scoring rules, routing logic, field sets — is driven by configuration rather than custom code
A shared feature library that devs could selectively enable per client.

Leadership and the PM decided on the multi-tenant approach — it required the highest upfront investment but was the only option that solved the root problem rather than patching around it. My role from this point was to translate that architectural decision into a usable product: working out how configuration-driven behaviour would actually surface in the UI, without making the experience feel fragmented or overly technical for any single client.

Structuring it like a SaaS product also makes onboarding and acquiring new clients significantly easier.

... BUt WHY BUILD a custom LMS?

There are plenty of LMS in the market so why build an LMS from scratch?

We have deep integrations into our clients proprietary systems and access to years of data across different formats, making it challenging to migrate.

The strategy became clear: build a generalised LMS derived from our existing one, but bring it up to the standard of modern LMS products.

From a design standpoint, this also gave us something off-the-shelf tools couldn't: the ability to shape the entire experience around how our clients actually work, rather than adapting their workflows to someone else's product logic."

So I explored.

I audited our existing in-house LMS and explored competitor products to understand the gap.

Prehistoric UI — heavily saturated colours, dated visual design, and a steep learning curve. New users had to learn the system's quirks before they could do any actual work.
Dead-end navigations — flows that led nowhere, forcing users to backtrack or guess their way around.
Years of layered code — the system technically worked, but was fragile and hard to extend without breaking something else.
No duplicate resolution — the same lead could exist multiple times with no way to detect or merge them.
External dashboard — analytics lived in an external Superset instance, completely disconnected from the LMS itself.
Blunt access control — no proper role-based permissions, meaning you couldn't easily control who could see or do what.
Missing modern features — no built-in forms, no workflow automation features competitors offered out of the box.

Bigin by Zoho
It covered the critical features without overwhelming the user, which validated our decision to prioritise a clean, focused experience over feature bloat.

Attio
Attio's compact UI was the single most influential reference in this project. It proved that high data density and clean visual design weren't at odds — a lesson that came back directly when we identified row height as V1's biggest usability flaw.

Pipedrive
feature-rich and functional, but the least polished UI of the four.

HubSpot

The industry benchmark, included as a reference for table structure and pipeline conventions.

These findings, combined with conversations with our marketing team about how campaigns actually run, shaped which modules needed to exist and how they should connect.

PRODUCT STRUCTURE

The module set drew from two sources: what worked in our existing LMS, and what was missing relative to the market. Some modules were carried over, some were rebuilt, and a few were entirely new.

The hardest IA call was deciding what lived at the top level vs. what was nested inside a module. Campaign Management was particularly tricky, it could have been a view inside Leads, or its own primary section. We made it a first-class module because campaign owners and sales ops have different primary workflows; collapsing them into one section would have forced awkward compromises on both navigation and permissioning.

Building Campaign

The campaign management module is a new concept in a LMS. When a marketing team runs a campaign they have to run and track it across different platform. This gives rise to a fractured view point, we wanted to consolidate it.

I collaborated with our marketing team to figure out how a campaign works across different platform like Google, Meta, LinkedIn, WhatsApp, VFN, Walk-in etc

The scope wasn't obvious upfront. Early in the build, it became clear the module's requirements were more complex than initially scoped different platforms had different data structures and different definitions of what counted as a "campaign result."

We resolved this by running three working sessions with the marketing team, mapping their actual campaign workflow step by step. What emerged was a clear first-version scope: track campaign source, status, and lead volume per channel. Granular platform-specific metrics click-through rates, cost-per-lead by sub-campaign were explicitly deferred to V2, documented in a scope decision we shared with the PM and stakeholders.

Form Builder

Teams were relying on external tools — Google Forms, Tally, Microsoft Forms — to capture leads, which fragmented the experience across systems. None of the competitor LMS platforms we evaluated had native form-building either. Bringing this in-house meant one less disconnected tool in a sales rep's workflow.

Bulk Import

Built alongside forms, to support adding leads at scale rather than one at a time.

To build or not to build

Good scoping is as much about subtraction as addition. A few calls made during this phase:

Deals & Pipeline view — a significant feature in competing products, but absent from our existing LMS. We deferred it to a later version, since the initial release targeted existing clients who didn't need it yet.
Workflow Builder — removed based on feedback and timeline constraints. The complexity-to-usage ratio didn't justify shipping it in V1.
Products module — early wireframes for this evolved into enough of an independent need that it was spun off as a separate product: a Product Information Management (PIM) tool.

Deferred after validating that existing clients tracked deals externally. Introducing this in V1 would have added complexity without addressing their actual pain

The products module grew complex enough during wireframing that it warranted its own product. Spinning it off kept the LMS focused.

Cut in V1 after scoping revealed the build cost was high relative to how often clients would actually use it. Flagged for V2 if demand grows.

FIXING FLAWS

After V1 shipped to select clients, a clear usability problem emerged: component height.

Table rows and cells were too tall, which meant users could only see 4–5 rows of data at a time instead of the expected 8–10 — and the problem got worse on smaller screens.

This was one of the places where the Attio reference paid off directly. Its compact UI proved that dense data didn't have to mean cluttered. We reduced component height and padding across the board, resulting in a noticeably more compact, scannable layout, without changing the underlying information.

V2 is currently live with 4 clients. Anecdotally, onboarding new clients has become significantly faster: the configuration-driven architecture means a new client setup that previously took months can now be completed in 2 weeks.