Enterprise Design System - David Hawkins

Overview

insightsoftware grew through acquisition into a portfolio of more than 17 enterprise applications across reporting, accounting, and data & analytics. Each product had been built by a different company, on a different stack, with its own navigation conventions, terminology, and visual language. Customers who licensed multiple products had to re-learn the platform every time they switched applications.

I led the design of a unified global experience that gave the entire portfolio a shared navigational language, a consistent way-finding model, and a governed set of cross-application UX contracts (without forcing every application team to rebuild their product from scratch). The system preserved each product’s functional identity while establishing the shell, orientation patterns, and interaction standards that made the portfolio feel like one platform.

My Role

Senior Product Designer for the Global Experience Platform.

I owned the design of the application shell, primary and secondary navigation, the way-finding model, and the documented UX contracts that application teams built within. As lead, I personally owned 9 of the 17 applications end-to-end and coordinated with designers on the remaining 8 to ensure system-wide consistency.

I worked directly with executive product leadership to translate platform strategy into durable UX standards, partnered with each application’s PM lead through a structured adoption process, and stayed embedded with engineering through implementation, testing edge cases, non-ideal states, and role-specific scenarios.

The Problem

Three problems compounded across the portfolio:

Fragmentation. Each acquired product had its own header, navigation, account menu, and notification model. Users licensing multiple products were effectively learning multiple platforms.

No shared interaction contracts. Common patterns for onboarding, notifications, form validation, status indicators, search, filters were solved differently in every product. There was no governing layer.

No path to coherence at scale. New acquisitions kept arriving. Without a global framework, every new product would either be re-designed from scratch (expensive, slow) or shipped as-is (more fragmentation).

The system needed to do two things at once: prevent fragmentation, and preserve team autonomy. Application teams needed room to solve their own domain problems without re-litigating navigation, identity, or way-finding every time.

My Design Work

1. Foundational Styles

The foundations gave every application the same visual and verbal baseline before any product-specific design began. Typography is Inter (with a documented fallback stack), with a defined scale for headings, body, subtitles, and labels — each level specified down to weight, size, and line-height. A vocabulary guide set the platform’s voice through do/don’t examples: descriptive titles, action verbs, precise diction, short labels, and sentence-style capitalization.

The color architecture spans brand, primary, secondary, and neutral palettes, plus utility colors for error, success, warning, and focus states — every swatch documented with its hex value and intended usage. Dedicated palettes cover chart tones, monoline icon colors, and avatar colors, so even data visualization and identity surfaces stayed consistent across products.

The button system rounds out the foundations: primary, secondary, ghost, and destructive variants, each specified across normal, hover, pressed, disabled, and focused states in two sizes, with icon placements, padding and min-width rules, and dark-background treatments. All button styles meet WCAG AA contrast except disabled states.

Foundational styles — Inter typeface, fallbacks, and heading scale

Foundational styles — body, subtitle, and label type specs

Foundational styles — vocabulary do/don't guidance for titles, labels, and actions

Foundational styles — read-only text in inline and stacked displays

Foundational styles — neutral palette with documented usages

Foundational styles — utility colors for error, success, warning, and focus states

Foundational styles — primary button states and sizes

Foundational styles — secondary button states and sizes

Foundational styles — ghost button states and sizes

Foundational styles — destructive primary button states

Foundational styles — destructive secondary button states

Foundational styles — destructive ghost button states

Foundational styles — button paddings, sizes, and dark-background treatments

2. Information Architecture & Way-Finding

I defined the IA standards every application had to honor:

Primary navigation — top-level sections of an application, anchored to the left rail with consistent iconography.
Secondary navigation — sub-sections, surfaced contextually based on the primary section selected.
Breadcrumbs — the user’s location-trail through deep hierarchies, with documented truncation rules.
Page headings — standardized layout and metadata zones so users could orient themselves on any screen in any product.
Workflow state surfaces — where, when, and how to expose task state, claim status, or pipeline progress.

These were not suggestions. They were contracts. Application teams had latitude inside their primary sections to solve their domain problems, but they could not redefine where navigation lived, how it behaved, or how state was surfaced to the user.

Way-finding — menu item component states, from default through selected and focused

Way-finding — switch applications menu specification

Way-finding — primary navigation and application menu specification

Way-finding — application menu expand and collapse behavior

Way-finding — user menu with settings, invite guest, switch account, and log out

Way-finding — secondary navigation with static sub-application menus

Way-finding — secondary navigation with floating dropdown menus

Way-finding — oversized menu recommendations for long navigation lists

Way-finding — secondary navigation in regular and cozy densities

Way-finding — breadcrumb rules with truncation for deep hierarchies

3. Announcements & Notifications

Keeping users informed was a contract, not a per-product decision. I designed a coordinated notification architecture with a distinct surface for each level of urgency, used identically in every application:

Announcements — a dismissible platform-level banner for system-wide messages.
Toast notifications — transient responses from the server (informational, error, warning, success) with optional actions.
Content information — persistent inline messages that surface state inside forms and information areas.
Badges — numeric counters on the navigation rail that direct attention to where work is required (up to 99, then a dot).
Notification menu — a persistent inbox on the rail, grouped by recency, with unread indicators and mark-as-read.

Because the surfaces and their meanings never changed between products, users always knew where to look for what mattered — and application teams never had to re-invent messaging patterns.

Announcements — dismissible platform-level banner

Toast notifications — informational, error, warning, and success variants with actions

Content information — inline state messages for forms and information areas

Badges — numeric counters on the navigation rail

Notification menu — inbox grouped by recency with unread states

4. Data Tables

Data tables were the workhorse of the portfolio — nearly every application presents records in a grid, so the table had to be the most thoroughly specified component in the system. I designed a single table component with three density modes (default, short, and compact) and documented every behavior application teams needed:

Sorting on any column, with clear directional indicators.
Row hover actions — edit, delete, and overflow actions revealed in context.
Row selection — checkboxes with an indeterminate select-all state for bulk operations.
Truncation — long text and overflowing tag sets collapse gracefully, with tooltips revealing the full content.
Search & filters — a filter builder (column, condition, value) with result counts and stackable criteria.
Horizontal scrolling for wide datasets, and pagination with configurable rows per page.
Nested rows — expandable records that reveal detail panels or subtasks inline, without leaving the grid.

Data tables — default table with roles, connections, and pagination

Data tables — row selection checkboxes and cell truncation with tooltips

Data tables — horizontal scrolling for wide datasets

Data tables — nested expandable row with record details and activity log

Data tables — nested rows with subtasks and collaborators

Adoption Process

The system was only valuable if application teams adopted it. I built a structured, repeatable adoption process:

Audit. Partner with the application’s PM lead to inventory existing IA, navigation, and core workflows.
Map. Identify which user journeys mapped cleanly to global patterns and which would need product-specific accommodation.
Prototype. Design updated navigation patterns against the structural standards, including non-ideal states and role-specific scenarios.
Scope & prioritize. Hand engineering a clear, sequenced backlog tied to release planning.
Implement. Stay embedded through development, reviewing builds against spec and resolving edge cases.
Validate. Test against role-based access scenarios, multi-tenant data, and the full state matrix.

The structured process was the reason adoption worked. Application teams were not asked to absorb a 200-page guideline document and figure it out. They were given a partner, a sequence, and a clear definition of done. Resistance dropped because the process respected their roadmap and their domain expertise.

Outcomes

Adopted across all 17 enterprise applications spanning three business units (reporting, accounting, data & analytics).
9 applications owned end-to-end by me as design lead; 8 coordinated with partner designers under the same standards.
28+ documented component and pattern categories shipped in a single source-of-truth Figma library paired with engineering-ready specs.
WCAG AA accessibility baseline with documented contrast pairings for every neutral, brand, and utility color.
Reduced design drift across a large, distributed product organization through governance documentation that codified interaction contracts at the pattern level.
Established a repeatable adoption framework that subsequent acquisitions and new product teams onboarded against without bespoke design re-litigation.