TurboML

Backend engineers managed the data infrastructure, while data scientists and ML engineers built pipelines, trained models, and deployed them. Their work crossed several tools, each with its own controls and conventions. Following a dataset through that process was difficult.

TurboML was built for streaming events rather than relying only on batch processing. The design challenge was to make that real-time workflow understandable without hiding the technical details people needed to inspect and control.

I interviewed the ML team, reviewed competing platforms, and mapped technical workflows to guide the design.

Learning the domain was part of the design process. I worked through how data entered the platform, what users needed to verify, and how datasets were prepared for modeling. Questions about what users could inspect or change, and where they would resolve errors, helped me understand the decisions each screen needed to support.

Overloaded screens, difficult integrations, and inconsistent controls made the workflow harder to follow. I organized the experience around four connected stages, keeping technical detail available within a clear structure.

I designed the homepage around recent activity and quick access to important areas of the app. Activity logs helped teams see what had changed, while shortcuts gave them a direct route back into their work. The aim was to make the starting screen useful for an ongoing workflow, not just a collection of platform metrics.

I brought data setup into a structured flow so users could move from adding data to checking its structure and configuring datasets for modeling within the same product.

A visual interface needed to support engineers’ expertise. I introduced code and visual options so users could work with a more structured flow while retaining the ability to customize their pipelines.

Users fetched a snapshot of incoming data, defined and validated new features in Jupyter, then submitted selected definitions for TurboML to compute continuously as new data arrived. Understanding this progression gave me context for designing the feature-engineering experience.

Data previews and feedback helped users inspect what they were working with as they created features.

In a real-time product, users need to see what happened after an action and whether the system is behaving as expected.

Backend capabilities and product ideas evolved throughout the project. I kept revisiting the information architecture and user flows with the team so the interface reflected what the product could actually do.

The design system gave us shared patterns across data, features, models, and monitoring. Reusing controls and visual conventions helped connect those modules while we continued iterating on individual workflows.

I developed the brand identity alongside the product. The bull-inspired mark expressed strength, speed, and resilience, with forms that hinted at the T and M in TurboML. Curved lines referenced continuous data streams, while the orange-to-red palette gave the brand an energetic character.

I carried that identity into the landing page, pitch decks, and marketing materials, connecting the product experience with how we introduced it to the outside world.

I also designed this website for TurboML. View website ↗

My scope also included TurboTrace, an observability platform for understanding AI application flows. Alongside the core TurboML work, I designed interfaces for inspecting traces and exploring what was happening inside those applications.

I could not make this product clearer without understanding the work behind it. Conversations with the ML team helped me see why a field, log, or configuration option mattered. That changed what I considered unnecessary complexity: some details were essential to an engineer’s ability to make a decision.

I also learned to treat feedback as part of the workflow. In a streaming system, a well-organized form is only part of the experience. Users need to see what happened after they acted, and whether the data or pipeline is behaving as expected.

Working toward launch while the backend evolved taught me to revisit flows without losing consistency across the product. Shared patterns gave us a stable starting point, while frequent conversations helped me adapt individual screens as the team learned more.