Company
Role
Lead UI/UX Designer
Project Type
Timeline
2022 – 2023
CalibCRM was built for a small startup team that was trying to manage sales and business operations with too many disconnected tools. The product started as an internal MVP with a longer-term possibility of becoming a customer-facing CRM later.
At the time, Calibraint operated with a lean business team of smaller team with CEO managing the business operations. Work was entirely distributed across disjointed tools. Leads were tracked in one system, daily tasks managed in another, team communication happened in emails and Skype, and documents were scattered across cloud storage.
Information was dispersed, meaning context had to be constantly reconstructed. The problem was not the team's organization; it was the structural reality of their software.
THE BREAKING POINT
The true cost of operating across multiple tools was not the lost time in switching contexts, it was the loss of critical information.
When a representative logged a call in one system and updated a task in another, the full customer narrative existed nowhere as a unified record. Retrieving complete context required manual assembly.
This was not merely an inefficiency, but a compounding visibility gap that degraded decision-making across every stage of the pipeline.
THE STRATEGY
The hypothesis was direct: unified information eliminates context loss.
However, building a central CRM required more than consolidating data. It demanded designing how different users would perceive and interact with that information. A sales representative and a founder have fundamentally different information needs. Forcing both into identical views creates friction.
This necessity drove two strict commitments:
First: Establish design system discipline from the MVP phase. The interface needed to scale predictably as features grew, requiring consistent components, patterns, and interaction models from the start.
Second: Enable customization in core surfaces. Rather than imposing a generic CRM shape, the product needed to reflect individual workflows—allowing sales reps to see next actions, founders to see pipeline health, and team members to configure their own information hierarchies.
THE APPROACH
01
Mapping the actual workflows
The process began by mapping how the team currently gathered information and where friction actually occurred.
This understanding shaped an information architecture built entirely around how these specific users made decisions, rather than relying on a traditional CRM template.
02
Integrating system discipline early
As the product evolved, components, patterns, and interaction models needed to remain consistent. Reusable elements and strict design logic were established from day one to prevent visual fragmentation as new modules and features were inevitably added.
03
Validating with real work
Validation occurred continuously through regular sessions with the actual team. The product evolved through this feedback because it had to support real work, not impose theoretical processes
THE OUTCOME
The transition from multiple dispersed systems into one coherent platform successfully eliminated the context-assembly problem. Complete customer history, real-time pipeline visibility, and team communication became instantly retrievable from a single record.
The team's work pattern fundamentally shifted. Representatives could retrieve complete context without switching systems. Follow-ups became structured and traceable.
The most significant indicator of success was that the product ceased to be perceived as a separate tool; it became indistinguishable from how the team actually worked.
I do not have current adoption data or recent feedback because I left the company four years ago, so I'm not claiming numerical impact. What I can confidently say is that the internal team gained clearer visibility into customer status, conversation history, and workflow progress, which made coordination easier and the process more manageable.
MY ROLE
When the product vision was owned by the Product Manager, my contribution lay in shaping the design direction and establishing the structural web thinking required for scale.
This included leading the design system logic from the start, pushing for user customisation to meet different information needs, and running continuous validation.
This represented leadership through design discipline, the ability to influence direction, establish standards, and validate assumptions.
WHAT I LEARNED
This project reinforced that internal products work best when they adapt to the team, not the other way around.
The real design challenge was not adding more capability, but removing the complexity that made the system harder to use.
That clarity made role-based customization possible, so each person could see the information relevant to their decisions. When that happened, the product stopped feeling like a tool and started functioning as part of the work itself.
