Muse Design System

Overview

Muse was a scalable design system created to unify FireEye's product portfolio. Security products accumulate inconsistency quickly: each acquisition and each team brings its own patterns, and analysts pay the cost every time they move between surfaces. Muse existed to make consistency a product requirement rather than an aspiration.

What it included

• A comprehensive set of interaction patterns
• A wide range of components covering complex, data-dense interfaces
• Dark and light themes
• Detailed documentation
• Delivered in code, not just design files

The problem

A security portfolio that grows by acquisition accumulates interface dialects. Each product carried its own components, its own spacing, its own idea of what a severity colour meant. Analysts paid that cost every time they moved between surfaces mid-investigation, and designers paid it by rebuilding the same table for the fourth time.

Approach

• Audited the existing surfaces to find what was genuinely different versus accidentally different — the second category is where a system earns its keep.
• Built foundations first: colour, type, spacing, and a severity scale that meant the same thing in every product.
• Designed for data density. Security interfaces are tables, timelines, and graphs under time pressure, so the component set was weighted toward those rather than marketing surfaces.
• Shipped it as code alongside the design files, so adopting the system did not require a team to first translate it.

The system

Impact and results

• Adopted by the entire UX team and shipped in 12 products and features — a design system only counts once other designers reach for it by default.
• One component language across the portfolio. Muse unified the vocabulary across FireEye's security products, so a pattern learned in one console carried to the next.
• Adoption without translation. Delivered in code as well as design files — the system was something engineering could install, not a PDF to interpret.
• Theming as a system property. Dark and light were handled at the token layer rather than as two parallel component sets to maintain.
• A Marketplace surface extended the same language to integrations, so third-party content did not visually fracture the product.