The redesign was decided. What needed to change was still open.
When I joined Ledsak in August 2025, the team already wanted to redesign the CRM. My first job was to understand what was getting in the way of using it.
The product already did a lot: teams could capture leads, assign them, follow up, and manage deals. But controls were scattered across modules, related activities lived in separate places, and some workflows stopped short of what users needed to do.
I mapped the modules and their connections, then worked through the existing screens and flows. Alongside the documentation and conversations with stakeholders, this helped me identify what to move, what to connect, and what was missing.
That became the starting point for the redesign: give the product a clearer structure before working through the individual screens.
I started with the work that happened every day
The CTO and I prioritized Lead Management and the workflows around it. I proposed changes, discussed what the team could build, and adjusted the designs as we worked through the details. Settings came later in the design sequence, although many everyday workflows would depend on it.
Server load was a recurring constraint. Every new capability needed to earn its place without adding unnecessary processing. I also worked with the developers to carry shared components and design guidelines into the build—a part of the work that continued well beyond handoff.
Put settings where people can expect to find them
Configuration used to sit inside individual modules such as Leads and Deals. Finding a control depended on remembering which module it belonged to.
I brought these controls together under Settings, with access managed through roles and permissions. This gave administrators one place to configure the product and kept those controls out of everyday lead work.
There was an adjustment cost. Existing users knew the old locations, and moving a control meant changing a habit they had already learned. That became one of the clearest lessons from the release: a more consistent structure still needs a thoughtful transition.
Businesses could collect custom data. They needed to filter it, too.
Ledsak already let businesses add custom lead fields. But in the deployed experience I reviewed, users couldn’t filter those fields in the main Leads table, and filtering was unavailable on mobile too. The CTO described customer workflows that involved exporting the data and finding the relevant records in Excel.
A sales manager might need leads created during a particular week, assigned to Amit, from either Delhi or Gurgaon, with activity after a certain date. A fixed set of dropdowns couldn’t handle that combination.
I designed column filters for quick, specific queries and an advanced panel for combining conditions. Filter chips show what’s active, and saved filters let people return to a useful query without building it again.
I also accounted for the moment a query finds nothing. Instead of leaving an unexplained blank table, the empty state asks users to adjust their search or filters.
Saved filters have shipped, and conditional filtering is live on selected fields. The full AND/OR experience is still being built.
Let people shape the table around their work
I kept name and contact information prominent because people need them to recognize a lead and spot possible duplicates. Beyond that starting point, users can choose their columns and change their order. The layout is remembered in the same browser.
Different people also use different actions repeatedly. I kept every record action in the three-dot menu and let users drag up to two of them onto the row. They can pin one, two, or none.
The limit matters because a shortcut takes up space on every row. Two gives people room to choose without turning the table into a wall of buttons.
Bulk actions follow the same idea: show an action when it becomes relevant. With nothing selected, the primary button says Create New. Select a lead and it becomes Bulk Action. Clearing the selection brings Create New back.
Entities
Analytics
Settings
All leads / 3 records
| Select | Name | Stage | Branch | Actions |
|---|---|---|---|---|
| Aarav Mehta | Qualified | Delhi | ↗ ⋯ | |
| Riya Sharma | New enquiry | Gurgaon | ↗ ⋯ | |
| Kabir Singh | Contacted | Delhi | ↗ ⋯ |
Select a record to explore contextual bulk actions.
Interactive illustration · Fictional records · Select rows to see the action change.
Frequent actions, within reach.
Users can pin zero, one, or two actions. The menu keeps every remaining action accessible.
Make the creation form follow the business
As clients added custom fields, the lead form risked becoming a long list of inputs. Businesses needed a way to organize those fields, too.
I connected Lead Creation to the field configuration in Settings. Administrators can group fields into sections, set their order, choose what’s required, and control whether a field appears in forms, filters, or tables.
The creation form then follows that structure. A client can organize data entry around its own process without needing a separately designed form. The setup still needs care: choosing required fields and sensible sections is part of making a usable form.
Bring the lead’s history into one view
To understand a lead, users needed to piece together activity from different areas. I brought those interactions into a chronological timeline inside Lead Details.
Users can review the history in one place and expand an interaction when they need more detail. As histories grow, how easily people can scan and find a specific event remains something to evaluate.
Some decisions were about what to leave out
The CTO and I worked through requests with usability, performance, and development effort in mind.
We changed the default date range from All Time to Today, while keeping historical data available. The aim was to avoid loading more data than the initial view needed; we haven’t measured the server-load improvement.
We limited charts to the top ten categories to keep them readable. That makes the initial view more focused, although it doesn’t show the full distribution.
When call monitoring was requested, I recommended against adding it. I was concerned about disrupting existing workflows, increasing resource demands, and handling sensitive conversations. The team rejected the proposal.
What’s live, and what we’re still working on
| Capability | Status |
|---|---|
| New navigation and information architecture | Shipped |
| Saved filters | Shipped |
| Column visibility and reordering | Shipped |
| Customizable pinned actions | Shipped |
| Contextual bulk actions | Shipped |
| Configurable lead creation | Shipped |
| Advanced conditional and AND/OR filtering | Partly shipped |
| Shared design system | Partly implemented |
The core workflows are implemented. Bug fixes and some UI alignment are ongoing, and shared components haven’t yet been adopted consistently across every screen.
The release brought useful feedback—and some relearning
Most of the client feedback I received was positive about the features, filtering, and workflows. The move to centralized Settings took more getting used to, particularly when roles and permissions affected what a person could see.
This feedback gives us a useful direction, but we haven’t measured changes in task completion, retention, or revenue. What we can point to is the work delivered: clearer navigation, configurable tables and forms, and actions that respond to what the user is doing.
What I’d carry into the next redesign
I’d spend more time helping existing users through the change. Moving a setting can make sense in the new structure and still leave someone looking in its old location. Guidance around moved controls and permission visibility would help that transition.
I’d also make implementation review a more explicit part of the design process. Creating components was a start; getting them used consistently required continued work with engineering. As the remaining pieces ship, I want to evaluate how people find settings, understand active filters, and complete their everyday lead tasks.