Blue Origin

During my summer internship at Blue Origin, I was embedded in the BDMS (Blue Data Management System) team as a UX Design Intern. BDMS is Blue Origin's in-house platform for storing, managing, and visualizing test data across multiple campaigns and missions, used by over 1,500 engineers and analysts company-wide.

My work focused on enhancing the platform's plotting capabilities through user research, ideation, and interaction design, ultimately delivering new features that help engineers analyze mission-critical data faster and without switching to external tools.

BDMS is a critical tool for test and flight operations across all Blue Origin business units. In 2025, it directly supported key company priorities tied to some of the most ambitious programs in the industry.

Despite being central to engineering operations, BDMS had significant gaps in its plotting capabilities. Engineers were spending time working around the tool rather than with it, constantly pulling data out to other software just to do basic analysis.

Before these features were designed, the BDMS interface was limited to a single-plot view with no in-line calculation or multi-channel comparison support. Scroll through to explore the existing experience.

I conducted 9 user sessions with engineers across Blue Origin, including sessions from a face-to-face BDMS feedback event and individual interviews with test engineers. Three distinct user types emerged, each with different relationships to test data.

This came up repeatedly across sessions and was the clearest signal behind the Tool Fragmentation finding. Because Responsible Engineers of Tests span so many components, they're constantly jumping between systems and contexts: BDMS, WinPlot, MATLAB, exported spreadsheets, just to complete a single analysis. The breadth of their knowledge was exactly what made the tool-switching cost so high. Reducing that friction was the core design goal.

BDMS was assessed against 10 usability principles. Three major violations were identified:

Based on research findings, two features were prioritized for their impact across user roles and their potential to meaningfully reduce context switching.

Search & filtering and annotations were both surfaced in research, but they addressed a different layer of the workflow: data navigation and team communication rather than in-context analysis. Scoping to Element Math and Stacked Plots first let us focus on where engineers were losing the most time without spreading effort across the full product surface.

Ideation involved brainstorming sessions with the UX team and key stakeholders, exploring innovative plotting techniques while keeping scope grounded in user needs and technical feasibility.

WinPlot's modal interface gave a familiar reference point for mathematical operations. Video editing software showed how multi-panel layouts can support simultaneous workstreams. Day trading analysis tools demonstrated flexible, panel-based interfaces that keep context visible while performing calculations.

IGS, an internal system at Blue Origin, showed how configurable layout systems work in practice. ProRealTime and TradingView provided strong references for grid-based, multi-chart interfaces. Video and music editing software offered patterns for managing and navigating multiple panels efficiently.

The most useful references didn't come from other data tools. They came from spaces where people already manage complexity across multiple panels at once. Trading platforms like TradingView showed how to surface dense, configurable data without overwhelming the user. Video editing software like Final Cut Pro and Adobe Premiere Pro demonstrated how collapsible panels and timeline-based layouts keep context visible while you work. WinPlot was the closest thing to a direct analog, but it also showed exactly where the existing mental model broke down. Looking outside the obvious helped me see what BDMS actually needed to feel like: not a scientific tool with a redesigned UI, but something closer to a professional workstation.

Four options were developed for Element Math and three for Stacked Plots. Each was evaluated against user needs, technical constraints, and stakeholder feedback before a recommended direction was selected.

WinPlot's modal was the baseline, but user research surfaced two blockers: complex expressions were hard to parse, and hiding the plot during calculation disrupted the engineering workflow. Four options were explored to find an interaction model that kept the data in view throughout.

All four options were walked through with engineers in in-person sessions where they raised concerns and described how they'd use each one in a real test. The modal-based options were ruled out immediately for blocking the plot view, and bracket notation was strongly preferred over tags, matching the shorthand engineers already carried from WinPlot.

Engineers frequently needed to compare data across sensors and launches side by side, but the existing one-plot-per-screen model made that workflow slow and disjointed. Three layout options were explored to support multi-plot analysis without overloading the interface.

Fixed-split and grid options felt too rigid; engineers needed to configure layouts based on what a specific test required, not adapt their workflow to a preset. Option 3's context-menu model gave them that control without adding setup overhead.

The work completed during this internship addressed the most pressing pain points, but the long-term goal is a comprehensive analysis platform that keeps engineers in BDMS for the full journey from data collection through insight. The features built this summer are the foundation, not the finish line.

The thing that surprised me most was how attached I was to conventions I'd absorbed without realizing it. I'd been designing with the people around me in mind: people who label things the way I label things, who think about interfaces the way design communities tend to think about them. When I brought tag-based element selection into the sessions, it made complete sense to me. Tags are readable, they're editable, they feel modern. Engineers looked at them and immediately wanted brackets.

That wasn't a preference; it was a workflow. Every time an engineer goes into a test, they already know what they're looking for: specific channels, specific calculations, specific relationships. That knowledge is encoded in their shorthand, and that shorthand uses brackets. Designing around labels would have meant asking them to re-learn something they'd never consciously learned in the first place.

That experience changed how I approach research. It's not enough to ask what people need. You have to find out what they already do, especially the things they take for granted. The edge cases that came out of those sessions weren't edge cases to the engineers. They were just Tuesday. Big shoutout to my mentor Wilo Dietrich and manager Shaan Gautam, and the whole BDMS team for bringing me into the work.