BLAZOR / Madison Resources HR Staffing CRM

Blazor-Native CRM Built End-to-End on the Gator Design System

Blazor

Blazor

4

4

4

0

0

0

DS

DS

DS

.NET COMPONENT PLATFORM

.NET COMPONENT

PLATFORM

CORE RESEARCH

FINDINGS

DUPLICATE

RECORDS

DUPLICATE

RECORDS

GATOR DESIGN SYSTEM APPLIED

GATOR DESIGN SYSTEM APPLIED

KEY

DELIVERABLES

CLIENT

CLIENT

CLIENT

ROLE

ROLE

ROLE

TEAM

TEAM

TOOLS

TOOLS

Madison

Resources

Madison

Resources

Madison

Resources

Senior

UX Designer

Senior UX

Designer

Senior UX

Designer

UX, Product, Engineering

UX, Product,

Engineering

UX, Product,

Engineering

Figma, Jira, Confluence

Figma, Jira,

Confluence

Figma, Jira,

Confluence

THE PROBLEM

Madison's reps were managing contacts across disconnected views — no single place to understand a contact's full history.

Madison's reps were managing contacts across disconnected views with no way to trust what was in the system. Duplicate records had accumulated for years — anyone could create a new contact at any time with no validation. There was no way to see where a person fit within a client organization, no shared picture of pipeline status across teams, and no visibility into who owned what relationship. For a business where sales reps earn on commission, that last problem wasn't accidental. The old system let reps keep customer data opaque. The design had to solve that — not work around it.

Madison's reps were managing contacts across disconnected views with no way to trust what was in the system. Duplicate records had accumulated for years — anyone could create a new contact at any time with no validation. There was no way to see where a person fit within a client organization, no shared picture of pipeline status across teams, and no visibility into who owned what relationship. For a business where sales reps earn on commission, that last problem wasn't accidental. The old system let reps keep customer data opaque. The design had to solve that — not work around it.

RESEARCH & DISCOVERY

What reps actually told us.

Before wireframes, I talked to sales reps directly. What I heard reshaped the entire design strategy — starting with a finding that no requirements doc would have surfaced.

Before wireframes, I talked to sales reps directly. What I heard reshaped the entire design strategy — starting with a finding that no requirements doc would have surfaced.

RESEARCH ARTIFACT - SESSION NOTES

Before any wireframe, I opened a notebook.

Before any wireframe, I opened a notebook.

User flows, ownership rules, ORG-to-ORG relationship types, contact verification logic — all mapped by hand during rep conversations, before a single screen was designed

RESEARCH ARTIFACT - SESSION NOTES

Before any wireframe, I opened a notebook.

User flows, ownership rules, ORG-to-ORG relationship types, contact verification logic — all mapped by hand during rep conversations, before a single screen was designed

USER FLOW - MAPPED BEFORE ANY WIREFRAMES

OPPORTUNITIES MODEL - ONE ORG, MULTIPLE RELATIONSHIPS

"Manual entry is killing selling time."

Reps estimated only 28% of their day was spent actually selling. The rest went to data entry, duplicate cleanup, and hunting across disconnected systems.

"ATS and CRM live in separate worlds."

Disconnected systems forced double entry for every contact. Communication history fell through the gaps. The same prospect in two systems — neither complete.

"Dirty data erodes trust in the tool."

Inaccurate records, outdated numbers, duplicate entries. If you can't trust what's in the system, you stop using it entirely.

"Information is siloed intentionally."

Reps weren't sharing prospect data across teams. Initial assumption: a technical problem. The real reason was something no requirements doc would have surfaced.

INSIGHT THAT IMPACTED THE DESIGN

Reps weren't hoarding data because the system didn't allow sharing. They were hoarding it deliberately — because sharing a candidate meant losing the commission.

This isn't a features problem. It's a behavioral problem. No sharing button fixes a compensation incentive. The design had to acknowledge the tension — not pretend it didn't exist.

That single insight drove every privacy decision in the system. The Private flag wasn't a feature request. It was the design's answer to a compensation problem.

HIERARCHY VISIBILITY MODEL — WHAT EACH USER LEVEL CAN SEE, AND WHY

The tension the design had to resolve.

The tension the design had to resolve.

The tension the design had to resolve.

BUSINESS WANTED

Shared data — Better forecasting

  • Shared candidate visibility

  • Shared candidate visibility

  • Manager oversight

  • Accurate pipeline reporting

  • Cross-team collaboration

  • Cross-team collaboration

  • Accurate pipeline reporting

  • Cross-team collaboration

REPS WANTED

Protect the pipeline — Protect the commission

Protect the pipeline — Protect the commission

  • Fast entry during calls

  • Control over visibility

  • Own their candidates

  • No management surveillance

  • Fast entry during calls

  • Control over visibility

DESIGN RESOLVED

Activity transparency — Pipeline privacy

Activity transparency — Pipeline privacy

  • Notes visible-pipeline protected

  • Ownership explicit at every level

  • Private flag on contacts

  • Visibility toggle on relationships

  • Notes visible-pipeline protected

  • Ownership explicit at every level

DESIGN DECISIONS

Every decision traced back to a finding.

Four distinct design choices — each one a direct response to something we heard in the field.

Four distinct design choices — each one a direct response to something we heard in the field.

  1. Quick-add panel — designed for the speed of a phone call.

QUICK-ADD-SLIDE-IN CONTACTS LIST STAYS VISIBLE DURING CALL

FINDING

FINDING

Reps generate leads live on calls. Thirty seconds, limited information. They cannot stop to fill twelve fields while someone is talking.

Reps generate leads live on calls. Thirty seconds, limited information. They cannot stop to fill twelve fields while someone is talking.

INSIGHT

INSIGHT

INSIGHT

Partial records at point of entry are intentional — not a data quality failure. Reps enrich detail as prospects move through the funnel, not all at once.

Partial records at point of entry are intentional — not a data quality failure. Reps enrich detail as prospects move through the funnel, not all at once.

DESIGN

DESIGN

DESIGN

Slide-in panel keeps the contacts list visible — no navigation break mid-call. Minimal required fields. "Save and Open" creates the record now, lets the rep return for detail later. The contact is placed correctly in the ORG hierarchy immediately — no orphaned records.

Slide-in panel keeps the contacts list visible — no navigation break mid-call. Minimal required fields. "Save and Open" creates the record now, lets the rep return for detail later. The contact is placed correctly in the ORG hierarchy immediately — no orphaned records.

  1. Cards over tables — a layout decision that was also an architectural decision.

CARD EXPLORATION - ORG STRUCTURE - ADD ORG & PERSON

FINDING

FINDING

Early-stage records are sparse by design. A data table of empty cells signals bad data — even when the record is intentionally minimal at first-call capture. And the CRM needed to translate cleanly to mobile

Early-stage records are sparse by design. A data table of empty cells signals bad data — even when the record is intentionally minimal at first-call capture. And the CRM needed to translate cleanly to mobile

INSIGHT

INSIGHT

INSIGHT

Multiple layouts were explored and rejected. The two-column card layout won on three counts: partial records look intentional, the layout is mobile-first by nature, and cards can change without rebuilding the system. It wasn't just a visual preference — it was infrastructure

Multiple layouts were explored and rejected. The two-column card layout won on three counts: partial records look intentional, the layout is mobile-first by nature, and cards can change without rebuilding the system. It wasn't just a visual preference — it was infrastructure

DESIGN

DESIGN

DESIGN

Cards throughout the CRM. Prospect records, customer records, org entries — all render cleanly from first-call capture to fully qualified customer. The pattern holds at every lifecycle stage and scales to mobile without a layout rebuild.

Cards throughout the CRM. Prospect records, customer records, org entries — all render cleanly from first-call capture to fully qualified customer. The pattern holds at every lifecycle stage and scales to mobile without a layout rebuild.

  1. Duplicate detection at point of entry — before bad data is created.

DESIGN ARTIFACT — DUPLICATE DETECTION GATE

Four states of the validation flow. The Private flag on the third panel is the commission tension made visible in the UI — a match exists, but its details are protected.

FINDING

FINDING

Duplicate records and inaccurate contact data had eroded trust in the CRM. Reps stopped relying on it because they couldn't trust what was in it.

Duplicate records and inaccurate contact data had eroded trust in the CRM. Reps stopped relying on it because they couldn't trust what was in it.

INSIGHT

INSIGHT

Fixing dirty data after the fact is harder than preventing it. The check needs to happen at creation — not during a quarterly cleanup sprint

Fixing dirty data after the fact is harder than preventing it. The check needs to happen at creation — not during a quarterly cleanup sprint

DESIGN

DESIGN

DESIGN

Real-time duplicate detection surfaces matches while the rep is still typing. When a match is marked Private, the system shows it exists without exposing the protected details — data integrity enforced without forcing reps to reveal proprietary relationships. That single rule required product owner sign-off. It touched commission territory directly.

Real-time duplicate detection surfaces matches while the rep is still typing. When a match is marked Private, the system shows it exists without exposing the protected details — data integrity enforced without forcing reps to reveal proprietary relationships. That single rule required product owner sign-off. It touched commission territory directly.

  1. Card layout as relationship architecture — the power of the CRM made visible.

DESIGN ARTIFACT — RELATIONSHIP ARCHITECTURE EXPLORATION

Multiple structural models evaluated before landing on the hierarchy tree. Complexity made navigable without exposing the underlying data model.

FINDING

FINDING

Staffing relationships are complex — one salesperson can have connections to multiple org levels, branches, and departments simultaneously. The existing system had no way to model this.

Staffing relationships are complex — one salesperson can have connections to multiple org levels, branches, and departments simultaneously. The existing system had no way to model this.

INSIGHT

INSIGHT

A card isn't just a UI component — it's a node in a relationship graph. The card pattern makes the data model visible without exposing technical complexity to the user.

A card isn't just a UI component — it's a node in a relationship graph. The card pattern makes the data model visible without exposing technical complexity to the user.

DESIGN

DESIGN

DESIGN

Three representations were evaluated before landing on the tree. Flat table variants made cross-division relationships readable as data but invisible as structure. For a rep managing an account like ESI — East, Mid, and West divisions each with multiple city branches — reading a tree versus scanning a table was the difference between understanding the account and not.

Three representations were evaluated before landing on the tree. Flat table variants made cross-division relationships readable as data but invisible as structure. For a rep managing an account like ESI — East, Mid, and West divisions each with multiple city branches — reading a tree versus scanning a table was the difference between understanding the account and not.

FINAL MODEL

Full org hierarchy with Private contacts visible as nodes. Relationship exists — details protected.

IN PRODUCT

Org Summary embedded directly in the contact record. No separate navigation required.

MY ROLE

Led UX design for Navigator CRM — from contact relationship architecture through Blazor component specs and Gator DS implementation.

WHAT I OWNED

Full scope — contact taxonomy, relationship visibility, progressive disclosure, wireframes, Blazor component specs, and design system application across all Navigator CRM modules.

HOW I WORKED

Navigator runs on .NET Blazor. Every component spec was written for Blazor's rendering model — parameter bindings, state definitions, and responsive behavior across desktop, tablet, and mobile.

THE CONSTRAINT

Gator DS governed all pattern decisions. Card layouts, filter patterns, status badges, and command surfaces were pre-established. Specs had to be precise enough for Blazor implementation without back-and-forth.

Navigator CRM was built on the Gator Design System — the atomic component library created for Madison Resources earlier in the engagement. Every UI pattern drew from Gator's governed component set, specified with Blazor binding expectations and integration guidance in mind.

PROCESS

From contact taxonomy and relationship mapping to .NET Blazor handoff.

1

Discovery & Understanding the Problem

Audited Navigator contact views, interviewed staffing coordinators, and mapped where the current system created friction.

2

Mobile-First Responsive Strategy

Established a mobile-first foundation as a deliberate architectural decision — every layout and component designed for mobile constraints first.

3

Card-Based Component Architecture

Designed the relationship model connecting contacts, companies, placements, and coordinators into navigable flows with progressive disclosure.

4

Card-Based Component Architecture

Built a card system using Gator DS components giving coordinators scannable, action-ready views.

5

UX Architecture & Prototyping

Established a layout system that brought scattered controls back into proximity with the data they affected.

6

.NET Blazor Implementation Support

Delivered Gator-aligned, implementation-ready specs for .NET Blazor, staying in through integration to close the gap between design and shipped behavior.

RELATIONSHIP VISIBILITY

Contact context at a glance

The core challenge was surfacing relationship depth — who a contact was connected to, their placement history, and current status — without requiring coordinators to navigate across multiple views. Progressive disclosure solved it.

GATOR DS IN PRACTICE

Governed components, faster delivery

Every pattern decision was grounded in an established system. Card layouts, filter patterns, status badges, and command surfaces were all pre-governed. Engineering moved faster because the design was already consistent and documented.

"Gator wasn't just a library — it was institutional knowledge embedded in components."

AGILE PROCESS

Building a shared language between design, dev, and QA

Developers were filling in story gaps their own way and QA had no consistent baseline to test against. Working with the PM, I designed the story structure and Azure DevOps state workflow — explicit criteria gave QA something to test directly against, kickbacks became documented and traceable, and stories stopped stalling at handoff.

PROCESS IMPROVEMENTS

Fewer mid-sprint questions

Explicit criteria reduced developer questions during active sprints — decisions were made before work started, not during it.

QA had a clear baseline

Acceptance criteria were written at a testable level — QA tested against the story directly rather than interpreting intent.

Kickbacks became traceable

Every kickback was documented with a written reason in Azure DevOps — creating a clear record rather than a verbal loop.

Consistent pipeline movement

Stories moved through defined states in sequence — stalls at handoff points became visible and addressable.

Junior devs worked independently

Detailed criteria for complex stories meant junior developers could implement without waiting for design clarification.

Less back-and-forth at handoff

Design and dev aligned on scope before stories entered the sprint — reducing revision cycles after work had already started.

WORKFLOW DESIGNED WITH PROJECT MANAGER — AZURE DEVOPS WORK ITEM STATES

Story Examples - Click to View

OUTCOMES

A governed, relationship-aware CRM experience — consistently delivered across Navigator on .NET Blazor.

Data entry shifted from a free-for-all to a governed process — duplicate records blocked at point of creation, not cleaned up after the fact.

Account structure visible to management for the first time — replacing mental models that previously lived only in individual reps' heads.

Commission tension resolved through design — the Private flag gave reps protection and the business transparency, without forcing a choice between them.

Contact type ambiguity eliminated — every person placed correctly in the org hierarchy at point of entry, with role and relationship explicit.

PROJECT GALLERY

From org modeling to governed contact architecture

User Flow — View, Add & Edit

Opportunities Model — One Org, Multiple Relationships

Layout Exploration — Two-Column View/Edit/Add

Hierarchy-Visibility-Model

Relationship Diagram Sales Rep

Relationship Diagram Org to Rep

Add Contact Default Flow

Add Person and Contact At Same Time

Quick Add Workflow

Wireframes Notes- Sales Rep

Wireframes Notes- Sales Manager

Wireframe Notes - Corp Info

Quick Add Person & Org

Quick Add Person Dialog

Quick Add Org Dialog

Org Detail View

Org Add Link

Org Link Added

Person Detail View

Person Add Relationship

Person Relationship Added

What I'd do differently

Involve .NET Blazor engineers earlier in component review. Gator translated well into Blazor, but some interaction patterns around data binding and progressive disclosure required revision once server-side rendering constraints were flagged. Earlier joint reviews would have caught those gaps before handoff.