Overview
Bitmovin is an Austrian video technology company powering video encoding and adaptive streaming for media companies, broadcasters, and OTT platforms worldwide. Their platform processes millions of encoding jobs monthly — used by engineers and media operations teams who need precise, real-time information at a glance.
As the sole UX/UI Designer and design system owner, I built Bitmovin's first cross-product component library and design language from the ground up — unifying three product surfaces (encoding dashboard, analytics, and player UI) that had grown in isolation with no shared standards, no consistent token system, and no documented component guidelines.
The project required close collaboration with engineering and product management, regular design reviews with technical stakeholders, and structured knowledge transfer sessions to ensure the system was adopted and actively maintained beyond my direct involvement.
The Challenge
Designing for a deeply technical audience — engineers and media operations specialists who value precision over aesthetics, and who work in the dashboard for hours at a time — meant the design system had to serve functional needs first, with visual consistency secondary.
The existing UI had grown organically across three separate product surfaces. Components were duplicated, interaction patterns were inconsistent, and there was no shared visual language. Each product felt like it had been designed by a different team, because it had.
Process
01 — Audit
I started with a full component inventory across all three products — cataloguing every UI pattern, identifying duplicates, and documenting interaction inconsistencies. This gave us a clear picture of the scope and prioritised where to start: data tables, status indicators, and form inputs were used across all three surfaces and had the most inconsistency.
02 — Token System
I defined a dark-first token architecture separating brand primitives, semantic aliases, and data visualisation colours. Semantic tokens covered status states (success, error, warning, running), interactive states (hover, focus, disabled), and data density levels. The dark-first decision reflected both the technical aesthetic and the practical reality that engineers work in the dashboard under varied lighting conditions for extended periods.
03 — Component Build
I built the Figma component library with full state variants for every component — covering default, hover, focus, disabled, error, and loading states. Data table, chart, and form components were given highest priority given their frequency of use. Every component was documented with usage guidelines, do/don't examples, and accessibility notes.
04 — Engineering Collaboration & Handoff
I ran structured design review sessions with engineering leads, walking through component specs, token values, and interaction behaviour. I used Zeplin for handoff and Confluence for token and component documentation. Contrast ratios were validated against WCAG AA for dark backgrounds across all text and interactive components.
05 — Knowledge Transfer
I led a series of knowledge transfer workshops with the engineering team to embed design system governance into their workflow. These sessions covered how to consume the Figma library, how to request new components, and how to maintain existing components as the product evolved — ensuring the system outlasted my direct involvement.
Key Design Decisions
- Dark-first design language: Engineers work in the dashboard for extended periods across varied environments. The dark theme reduces eye fatigue and makes the high-contrast orange brand accent immediately visible for primary actions — a deliberate contrast with most SaaS dashboards that default to light.
- Monospace for all data values: Job IDs, configuration values, API keys, and encoding parameters use JetBrains Mono throughout. The choice makes data scannable, visually aligned, and immediately familiar to a developer audience — making the interface feel native rather than imposed.
- Progressive disclosure in configuration: Advanced encoding parameters are hidden behind "Advanced settings" — surfacing only the most common options by default. This reduces cognitive load for new users without removing power for experienced ones.
- Inline status, no modals: Job status, error messages, and progress indicators live in-context within table rows. Engineers monitoring multiple jobs simultaneously do not need to open modal dialogs to check status — the information is always visible in the primary view.
- Calibrated data density: The dashboard shows many concurrent jobs. Column widths, font sizes, and whitespace were systematically calibrated so that 30+ rows are scannable without horizontal scrolling — validated through usability sessions with on-call engineers.
Outcomes
- Built Bitmovin's first design system from zero — unified across 3 product surfaces, adopted by engineering as the shared component and token standard across the entire platform
- Reduced component fragmentation from 80+ inconsistent UI patterns to a controlled library of 35 documented, reusable components with full state coverage
- Knowledge transfer workshops embedded design system governance into the engineering team's workflow — the system remained actively maintained after the engagement ended
- Presented design decisions and system architecture to Bitmovin's product leadership, securing alignment on the dark-first design language and component governance strategy
- Improved scanning efficiency in the encoding dashboard — validated through usability sessions with the core engineer user group, focusing on time-on-task for monitoring and error diagnosis workflows