Grid.ai / Lightning AI Machine Learning Dashboard Design

Machine learning dashboard design is the practice of creating interfaces that give ML engineers a clear, fast view of experiment results, compute costs, run status, and dataset health in a single workspace. It differs from standard analytics dashboard design because the users are technical specialists working with high-density data outputs who run multiple experiments simultaneously and need to compare results across dozens of variables without leaving the interface. For Lightning AI, formerly Grid.ai, this meant designing Train so that experiment tracking, cost monitoring, data issue management, and result evaluation all live in one screen. The interface supports filtering and tabular navigation without any page transitions, so engineers stay in context from the moment they open a run to the moment they evaluate its output.

General business users need dashboards that explain data in accessible language and guide them toward obvious next actions. ML engineers already understand the data. They need interfaces that stay out of the way and let them work fast. For Train, this shaped every structural decision. Labels were minimized. Information density was maximized. The navigation panel never changes regardless of what the engineer is viewing. Code access is available inline without opening a separate terminal. Cost totals are persistent across all views. These decisions came from mapping how Lightning AI’s engineers actually move through a training run, from setup through evaluation, and removing every step that required switching tools or losing context. The design challenge on this project was not making things simpler. It was making things faster.

A design system for an ML platform needs to cover every state the interface can enter during a training run, not only the success states that appear in design mockups. That includes loading states when a run is in progress, error states when a run fails or data is incomplete, empty states when a project contains no experiments yet, and edge cases where results are partial or inconclusive. The design system Fuselab built for Lightning AI covers navigation patterns, button states, popover behavior, support messages, and error states across all of these scenarios. Every component is documented with implementation specifications so Lightning AI’s internal development team could build accurately and extend the system independently as both Train and Blueprints evolved without returning to Fuselab for clarification on every new feature.

In ML experiment tracking, heat maps give engineers the ability to scan a full set of run results and immediately identify which experiments performed well and which did not, without reading through individual logs line by line. High-performance runs stand out visually from low-performance ones across the complete experiment set. Spider visualization, also called radar chart visualization, groups multiple metrics for a single experiment into a normalized visual format where the performance profile of one run can be compared against another across several dimensions simultaneously. In Train, both visualization types were chosen specifically because a single Lightning AI experiment generates multiple distinct metrics and row-by-row table comparison becomes impractical at scale. The visualizations do the comparative work so engineers can focus on what the results mean rather than how to read them.

Single-screen navigation means every action a user needs to complete their primary workflow is accessible from one view without navigating to a separate page or opening a new context. For Train, this was a primary design constraint. An ML engineer moving through a run cycle needs to access experiment filtering, result comparison, cost monitoring, and inline code editing. In most platforms these live across separate pages or separate tools. In Train they are all resolved within the same viewport. The navigation panel is fixed and never changes regardless of what the engineer is viewing, so they always know how to reach anything else without losing their current context. The entire site map for Train was built around this principle before a single screen was designed, mapping every user flow to confirm the structure supported it before the visual design began.

Inline code access in a visual ML interface means the engineer does not need to leave the dashboard and open a separate terminal or IDE to inspect or modify the underlying code for a run. Train includes a code view accessible directly from the experiment interface, with a split-panel layout that keeps the visual dashboard visible alongside the code editor at the same time. Session data is consistent across both views so switching between visual and code mode does not reset the current context or require the engineer to reload anything. This design decision came from observing how Lightning AI’s engineers actually work: visual output and code are not separate workflows, they are two perspectives on the same task, and separating them into different tools creates a context switch that interrupts the thinking process, not just the navigation.

For Lightning AI, Fuselab’s scope covered UI/UX design and the full design system for both the Train and Blueprints products. Development was handled entirely by Lightning AI’s internal team. Fuselab delivered all design assets, component documentation, and interaction specifications to a standard that allowed direct implementation without a gap between what was designed and what was built. Both products are fully live. For clients who need design and development under one engagement, Fuselab also handles full-stack product builds including backend development and API integration. For clients who have strong internal development teams, as Lightning AI did, Fuselab focuses on delivering a design system thorough enough that the team can build, extend, and maintain the product independently long after the engagement ends.