Work About me Contact Resume
Back to work
Enterprise Web Application

CRM Panel

Designing a Multi-Team Healthcare CRM From Scratch. A detailed 0→1 product design case study covering product thinking, role-based workflows, information architecture, interaction design, UI systems and developer-ready delivery.

Role
Lead Product Designer
Users
Multiple internal teams
Scope
0 → 1 Product Design
Focus
CRM · Workflows · Data · Roles
Prospect lifecycle
Many teams, one shared workspace
01ProspectCaptured
02LeadQualified
03Follow-upScheduled and tracked
04AssignmentOwner and team
05CustomerOngoing interactions
01 — Project Overview✦

The CRM is an internal enterprise platform designed to help multiple teams manage prospects, leads, follow-ups, assignments, customer interactions and operational activities from a centralized workspace.

Designed from scratch rather than redesigning an existing CRM interface.
Created a scalable product structure for multiple teams and responsibilities.
Designed around operational workflows rather than isolated screens.
Established reusable UI and interaction patterns for future modules.
Worked across product thinking, UX, UI, prototyping and developer collaboration.
02 — The Business Context✦

As HealthSy's operations expanded, multiple teams became involved at different stages of the customer journey. The CRM needed to create a shared source of operational information while allowing each team to work according to its responsibilities.

The design challenge

How might we build one scalable system that supports multiple teams, different responsibilities, complex workflows and large amounts of operational data without making the experience overwhelming?

03 — Starting From Zero✦

There was no existing CRM interface to simply improve.

The product had to be established from the ground up. I began by understanding the system behind the interface before defining individual screens.

Q1
Who uses the system and what is each team responsible for?
Q2
Which information is shared and which is role-specific?
Q3
Who owns a prospect at each stage?
Q4
How does a prospect move through the lifecycle?
Q5
Which actions require confirmation or recovery?
Q6
What information must be visible immediately versus progressively disclosed?
04 — Users & Roles✦

The CRM was designed for a multi-role environment. Different users interact with the same underlying information but have different priorities, responsibilities and available actions.

01
Team Leads
Team performance, prospect allocation, workload, pipeline visibility and follow-up status.
02
Business / Sales
New prospects, assigned prospects, customer details, follow-ups, activities and conversions.
03
Operations / Supporting Teams
Operational information, customer activity, status changes and internal coordination.
04
Administrators
Configuration, access, master data, user management and overall visibility.
05 — Information Architecture✦

This created a predictable relationship between where users are, what they are looking at and what they can do.

NavigationModulesViewsRecordsActions
Context before action: users understand the record or status before acting.
Progressive disclosure: complex information is revealed when relevant.
Role relevance: users see information and actions aligned with responsibility.
Consistency: repeated patterns behave consistently throughout the system.
Information architecture
A predictable hierarchy
01Navigation
02Modules
03Views
04Records
05Actions
Users always know where they are, what they are looking at and what they can do.
06 — Designing the Prospect Lifecycle✦

A central UX problem was representing the movement of prospects through the CRM.

Instead of treating every prospect as an isolated record, the experience was organized around lifecycle stages.

Stage 01
New Prospect
Stage 02
Assigned
Stage 03
Follow-up / Ongoing
Stage 04
Converted / Closed
Make the current state immediately understandable.
Show ownership and responsibility clearly.
Preserve enough history to understand what happened.
Surface the next meaningful action.
Keep status changes understandable and deliberate.
07 — Designing for Multiple Teams✦

The goal was not to create a completely separate product for every team. The underlying system remains shared, while the experience surfaces the information and actions relevant to each responsibility.

Shared data + Role-specific workflows
08 — Dashboard & Overview
“What do I need to know or act on right now?”

The dashboard was designed to answer this practical question. Information was organized around operational relevance rather than simply displaying every available metric.

Key metrics and status information
Prospect and pipeline visibility
Team activity and workload
Follow-up information
Important actions and operational signals
Dashboard model
Organised around operational relevance
What needs action now?
Key metrics and status
Prospect and pipeline visibility
Team activity and workload
Follow-ups
Important actions and signals
Table workflow
Tables as a working environment
01Search
02Filter
03Sort
04Open record
05Act
09 — Tables as a Primary Workspace
Tables are a working environment, not a passive data display.

CRM users work heavily with structured information, so tables were treated as a primary working environment rather than a passive data display.

Clear column hierarchySearch and filteringSorting and paginationRow-level and bulk actionsSelection statesStatus visibilityContextual actions
10 — Record Details
The user's working context.

The record-detail experience brings together the information required to understand and act on a prospect without repeatedly switching between unrelated screens.

Detail hierarchy
WhoWhatStatusHistoryActivityNext Action
Record detail hierarchy
Context before action
Who
Prospect identity
↓
What
Interest and details
↓
Status
Current stage
↓
History
Past interactions
↓
Activity
Recent updates
↓
Next action
What to do now
Assignment flow
Responsibility made visible
01Current owner
02Assign / reassign
03Status updated
04Feedback shown
05Next owner acts
11 — Assignment & Ownership
Make responsibility visible.

Because several teams interact with prospects, ownership is a critical part of the experience. The interface was designed to make responsibility visible and reduce ambiguity around who should act next.

Current owner and responsible team
Assignment context
Current status
Available actions
Clear feedback after assignment or reassignment
12 — Interaction Design✦

Enterprise products are shaped by small interactions as much as by primary screens.

I established consistent feedback and recovery patterns across the CRM.

01
Toast notifications
Immediate feedback after an action.
02
Confirmation dialogs
Protection for consequential actions.
03
Undo states
Recovery where users may need to reverse an action.
04
Loading states
Maintain context while data or actions process.
05
Empty states
Explain the current condition and what users can do next.
06
Error states
Communicate the problem and provide a path forward.
13 — Complexity Without Making It Feel Complex✦

The product contains multiple teams, workflows, permissions, records, statuses and actions. The design principle was simple:

Complexity should exist in the system, not in the user's mental model.

Progressive disclosureClear hierarchyContextual actionsConsistent componentsFamiliar interaction patternsLogical groupingRole-based visibility
14 — Building the Design System✦

Reusable UI foundations, built alongside the product.

Because the product was built from scratch, reusable UI foundations were established alongside the product experience.

Buttons, inputs, dropdowns and searchFilters, tabs and navigation patternsTables, cards and status badgesModals, drawers and tooltipsToasts and feedback patternsPaginationEmpty, loading and error states
Design system
From foundations to product screens
Foundations
ColourTypographySpacingGridIconography
↓
Components
ButtonsInputsCardsTablesStatus badgesModals
↓
Patterns
FormsListsEmpty statesFeedbackNavigation
↓
Product
DashboardTablesRecord detailsAssignment
Illustrative structure only. No product screens are shown.
15 — Designing for Scalability✦

The CRM was designed as a product foundation, not a collection of one-off screens. Decisions around components, navigation, tables, filtering and role-based experiences were made with future modules and growing operational complexity in mind.

Designed to absorb
More teams and users
More records and larger data sets
Additional statuses and workflows
New modules
Evolving permissions and responsibilities
16 — End-to-End Design Process✦

The design process moved from understanding the business to making the product implementation-ready.

Business requirementsUser and role understandingInformation architectureUser flowsWireframesInteraction designDesign systemHigh-fidelity UIPrototypeDeveloper handoff
17 — Prototype & Validation
Validating workflows before development.

Interactive prototypes were used to validate important workflows before development. The focus was on comprehension and task completion: could users understand where they were, find the right prospect, identify ownership, understand status and perform the next action without confusion?

Validation questions
What each prototype test checked
Can users…
Understand where they are?
Find the right prospect?
Identify ownership?
Understand status?
Perform the next action?
18 — Collaboration With Development✦

My role extended beyond creating Figma screens.

I worked with development to make the product implementation-ready.

Communicating component behaviour and states
Clarifying interaction and edge cases
Considering responsive behaviour
Resolving feasibility questions
Maintaining consistency during implementation
Translating product intent into buildable UI patterns
19 — Key Design Decisions✦

The product was shaped by a set of principles that balanced enterprise complexity with everyday usability.

01
Role-based experience
Different teams should not be forced through the same workflow.
02
Data-first interface
Tables and filtering are first-class experiences.
03
Progressive disclosure
Advanced information and actions appear when needed.
04
Consistent interactions
Repeated actions behave predictably.
05
Strong status visibility
Users can understand record state at a glance.
06
Reusable components
A shared system reduces inconsistency and accelerates future design.
20 — Outcome✦

The result was a from-scratch CRM foundation for HealthSy's internal teams, bringing multiple workflows into a structured digital workspace.

01
Centralized prospect and customer-related workflows
02
Clear team collaboration and ownership
03
Structured follow-up and lifecycle management
04
Role-based experiences
05
Reusable interaction and UI patterns
06
A scalable foundation for future product expansion
21 — What I Learned✦

Designing the CRM reinforced that enterprise UX is less about making individual screens beautiful and more about making complex systems understandable.

Complex information architectureMulti-role product designWorkflow and lifecycle designData-heavy interfacesDesign systemsEnterprise UXProduct thinkingCross-functional collaboration
22 — Summary✦

Building a CRM from zero for a multi-team healthcare organization.

A complex internal platform designed to bring prospects, teams, workflows, ownership and operational data into one scalable workspace.

0 → 1
CRM built from scratch
Multi-team
Role-based workflows
End-to-end
IA to developer handoff
Scalable
Reusable design system & patterns

Let's
design & build
something great.

Surya signature
Phone
+91 97877 48686
Location
Coimbatore, Tamil Nadu, India
LinkedIn Dribbble Behance
© 2026 Surya D. — Product Designer