# Ledsak — Product Design Case Studies Portfolio · October 2026 ## 01 — Helping teams find their way around Ledsak I redesigned Ledsak’s navigation and lead workflows so teams could find the right controls, work with their data, and adapt the CRM to their business. **Role:** Sole Product Designer, working with the CTO and CEO **Team:** Three developers and the CTO **Timeline:** Design started in late November 2025; development started in February 2026 **Status:** Core workflows are live. Bug fixes, some UI work, full AND/OR filtering, and design-system implementation are ongoing. ### 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. ### 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. --- ## 02 — When one more module became a platform question I worked with the CTO to design Entity: a way for businesses to manage their own record types, fields, and workflows beyond Leads. **Role:** Sole Product Designer, defining the product and workflows with the CTO **Team:** One developer and the CTO **Timeline:** Design started around March 2026; development started around May 2026 **Status:** Implemented and used by clients. Evaluation and iteration continue. ### It started with a healthcare client A healthcare client needed to keep managing people after they became patients. A lead captured the initial enquiry, but ongoing patient care needed different information, workflows, and connections to doctors. The client also wanted repeat enquiries attached to the existing patient and a separate directory for doctors. We started developing a Patient module. Then other requests came in: one client needed agent workflows; another needed to manage documentation. The details were different, but each request called for records and processes beyond the CRM’s existing modules. Adding fields to Leads would only take us so far. A doctor and a patient needed their own records and workflows. ### We started looking for the pattern behind the requests The CTO and I explored whether a shared configuration system could handle these needs. We researched how other CRMs supported custom business objects and used those examples to assess how the approach could work in Ledsak. We chose to build Entity. Instead of developing a fixed module for each new request, the team could configure supported record types, fields, activities, relationships, and workflows. That changed the design problem. We needed to make configuration understandable and decide where administrators needed freedom—and where the system needed protection. ### Keep familiar interactions. Let the business model change. Administrators can give an Entity a name, identifier, description, icon, and active status. They can define its fields, choose which activities are available, and rename activities such as Notes, Calls, Tasks, Meetings, and Emails to suit their terminology. For the lists and record details, I reused the patterns already established in Leads. The complex design work was in the behavior behind those screens: what could change, how records connected, and what happened when a record moved into another workflow. Reusing the interface let us focus on those questions while keeping the experience consistent across the CRM. ### Give administrators flexibility with a protected foundation I proposed locking the definitions of fields the system depends on, including Pipeline, Stage, Created By, Assigned User, Status, and timestamps. Administrators can add business-specific fields, but they can’t edit or delete these system-field definitions. The CTO reviewed and approved the approach. The CTO also proposed Reference and One-to-Many field types. These let businesses connect records—for example, linking a Patient to a Doctor. The same model can support a Family Entity connected to several individuals who share contact information. That’s a configuration the framework supports; it isn’t a confirmed client deployment. ### Make conversion carry the context forward I proposed prefilling information during conversion, making field mapping configurable, and retaining the original record. The CTO helped define which fields could be mapped and how the mapping would work technically. An administrator maps source fields to destination fields. When a user starts conversion, the destination form carries over the mapped information. The user reviews it, adds anything else required, and selects the appropriate pipeline and stage. For the healthcare client, a Lead becomes a Patient record with its own workflow. The Patient keeps a reference to the original Lead, and the Lead remains stored. We also let administrators choose whether converted Leads remain visible in the Leads listing. Some businesses want them available for reference; others want that workspace focused on active enquiries. When visible, the converted Lead carries a Patient tag. The mapping system supports multiple source objects, so the approach can extend beyond Lead-to-Patient conversion. ### A matching phone number doesn’t always mean the same person Businesses identify people differently. Administrators can choose a unique ID, phone number, email, a combination, or another configured field for matching. Incoming enquiries that match an existing Patient can then be associated with that record. Shared contact details make this less straightforward. Family members might use one phone number, so automatically treating every match as one person could connect an enquiry to the wrong record. For manual entry, the system alerts the user when a matching number exists. For external enquiries treated as re-enquiries, newly submitted details are kept in notes so staff can compare them and verify the person’s identity. A Family structure can also be configured where it fits the business. This preserves the information needed for review. It still depends on people checking ambiguous matches, so incorrect associations remain a risk to evaluate. ### Where I led, and where we worked together I owned the UX/UI design and translated our product decisions into the configuration and record workflows. The CTO and I worked closely on the underlying behavior, with different contributions along the way. | Decision | Contribution | |---|---| | Explore a reusable Entity model instead of separate modules | CTO and me | | Protect system-field definitions | My proposal; reviewed and approved by the CTO | | Prefill information during conversion | My proposal | | Make field mapping configurable | My proposal | | Retain original Lead data | My proposal | | Introduce Reference and One-to-Many fields | CTO’s proposal | | Define mapping eligibility and technical behavior | CTO’s contribution | ### A reusable foundation became a ready-made starting point The healthcare client actively uses the Patient and Doctor setup. Entity has also been implemented in real estate and EdTech, with healthcare seeing the strongest adoption. As more healthcare requirements came in, the team built a Patient Module integration on top of Entity. Enabling it creates a Patient Entity with default fields and a pipeline. The implementation team then adjusts the setup to suit the client. That gives the team a head start on common healthcare needs while leaving room for each business’s process. ### Implementation impact — less client-specific development According to the CTO’s estimates, work that previously took around 20 days of client-specific development and workflow implementation could be configured in 2–3 days using Entity, for requirements the framework supports. | Before Entity | With Entity | |---|---| | Around 20 days of client-specific development and workflow implementation | Around 2–3 days configuring supported requirements | That suggests an estimated 85–90% reduction in implementation time for comparable scope. These are the CTO’s retrospective estimates; they weren’t independently measured, and comparable testing and deployment scope hasn’t been verified. Creating custom fields was still part of both approaches. The saving came from reusing supported functionality instead of rebuilding the business workflow for each client. ### The work continued after release I observed how clients used Entity and collected feedback through the Business Development team. We’re using those inputs to keep iterating as different businesses put the system to work. We haven’t yet measured usability improvements. The concrete result so far is that Entity supports business records beyond Leads across several industries, and now powers a predefined Patient setup too. ### What this changed about how I approach requests This project made me pay closer attention to what repeated requests have in common. Patient management, agent workflows, and documentation initially looked like separate features. Looking across them helped us see a product capability we could reuse. It also made the cost of flexibility clear. Someone still needs to understand the fields, relationships, mappings, and matching rules they configure. Protecting system fields was one safeguard. Configuration errors and ambiguous matches are areas I want to keep evaluating as the system grows. --- ## Editorial notes before publication - Screens are anonymized Figma designs unless labeled otherwise. Design evidence does not establish production behavior. - Timelines are approximate. Core redesign workflows and Entity are implemented; full AND/OR filtering and some UI and design-system work remain ongoing. - Client feedback is qualitative. No measured task-completion, retention, or revenue claims are made. - Entity implementation-time figures are retrospective CTO estimates for comparable supported requirements, not a controlled measurement. - Family is a supported configuration example, not a confirmed client deployment.