MAESTRO revision history,rebuilt for scale.
A scalable revision timeline for NASA's Extravehicular Activity procedure software - so mission teams can navigate ten revisions or ten thousand with the same effort.
Due to the nature of MAESTRO as an internal NASA application, I can't publicly share a live build. This case study showcases my design process, screen recordings, screenshots, and AI-assisted prototypes to demonstrate the product's evolution while protecting sensitive project information.
From cognitive load to clarity
Same problem, two interaction models. One scaled with the data. One didn't.
The original vertical timeline. Effort scaled linearly with the length of history.
A fixed-size timeline with a draggable viewport. Any revision is one gesture away.
MAESTRO is NASA's procedure authoring and execution software, used to create and run Extravehicular Activity (EVA) procedures. Since 2023, it has helped mission teams edit procedures before and during spacewalks while maintaining shared situational awareness.
As procedures evolve, every revision becomes part of the mission history. Users needed a faster way to review previous versions, compare changes, and understand how procedures evolved over time.
My role was to co-design an improved revision history experience that made navigating large revision histories faster, clearer, and more scalable.
A timeline that couldn't scale
Functional for a small number of revisions - a wall once a procedure crossed a thousand.
- 1Long scrolling became inefficient with large revision histories
- 2Comparing different revisions required excessive navigation
- 3Users lacked a quick way to jump between versions
- 4Important historical changes became harder to locate over time
Design a revision history experience that lets users:
- Quickly navigate hundreds or thousands of revisions
- Compare multiple versions
- Reduce scrolling and unnecessary navigation
- Maintain context while exploring procedure history
Reframing the problem
Before exploring solutions, I studied how users actually moved through the existing history panel.
“The timeline itself wasn't the problem - it was the interaction model. Users weren't struggling because there were many revisions. They were struggling because the only way to navigate them was continuous scrolling.”
That reframed the problem. This wasn't really about adding a comparison feature - that would have been a symptom fix. The deeper issue was that the timeline's interaction model didn't scale with the data.
Our focus shifted from redesigning the visual timeline to redesigning how users navigated it.
Two coordinated views — one for context, one for depth.
Density adjusts to the range in focus.
Direct manipulation over indirect scrolling.
Never lose your place in the dataset.
Design principles
From research and internal discussions, we established what the new experience needed to do.
How do you let someone navigate an arbitrarily long history - 10 revisions or 10,000 - without the interaction cost growing with it?
That reframing ruled out anything that scaled linearly. The goal became a fixed-size navigation surface - a timeline that always fits the screen, where only the data mapped into it changes.
A draggable timeline handle
After sketching multiple concepts, one idea consistently solved the biggest usability issue.
A draggable timeline handle that acts as a navigation window. The timeline stays fixed while users move quickly through revision history by dragging a viewport.
Navigation went from a scrolling experience to a direct manipulation one - the effort to reach any point in history stays constant.
Comparison needed to feel native rather than bolted on: users select a start and end point directly on the same timeline they're already scrubbing.
From concept to interaction
Working alongside another designer, I translated the concept into interactive Figma prototypes.
Drag the handle to move through revisions with the current position always visible.
Select two points on the timeline to define a comparison range.
Last 10, last 50, date range, all - for users who know what they want.
Diff results surface inline, inside the actual procedure steps - so a change reads in the real language of the procedure, not as an abstract line-number diff.
Lightweight at any size
The final design makes revision history feel effortless, even at thousands of revisions.
Try the timeline yourself
A working prototype I built with AI to pressure-test the interaction model before hand-off. Open the history panel and scrub through revisions.
This prototype focuses on testing the revision history feature and interaction flow - not the actual NASA EVA procedure content.
Built with HTML, CSS, and JavaScript using AI-assisted prototyping.
Open prototype in a new tab →This project was highly collaborative. I partnered closely with senior UX designers, software engineers, and product stakeholders - reviewing concepts, validating interactions, and iterating on prototypes so the solution was both technically feasible and intuitive for end users.
The redesigned revision history provides a more scalable approach to navigating procedure revisions. Users move through history using a draggable timeline while maintaining context and easily comparing versions - supporting the traceability and shared situational awareness EVA execution depends on.
Internal metrics can't be shared, but the redesign represents a significant usability improvement that better supports MAESTRO's long-term growth.
Sometimes the biggest improvement isn't adding functionality - it's changing how users interact with the information they already have.
Rather than redesigning the data itself, we redesigned the interaction model - creating a solution that scales with the product while making complex workflows feel significantly more manageable.