Improving Constraint Clarity in NASA Playbook
Making invisible scheduling rules easier to understand and act on
Overview
Role: Design intern
Team: NASA Ames Research Center, Scheduling and Planning System for Exploration (SPIFe) team
Timeline: Jan – Mar 2022
Focus: Product design, UX research synthesis, interaction design, content design, visual systems
Outcome: Redesigned the constraint experience across two layers:
Language: Clearer message formulas for 14 constraint types
Visual UI: Modular constraint cards, violation states, timeline highlights, and resolution flows
Context
NASA’s Playbook tool supports mission scheduling workflows where timing, dependencies, and limited resources matter. Some activities must happen before or after others. Some must start or end at specific times. Some resources can only be used by one activity at a time. These rules are represented as constraints.
As missions move farther from Earth, immediate support from ground control becomes less reliable. Crew members need tools that help them understand and resolve scheduling issues more independently.
Playbook UI
NEEMO using Playbook during an undersea mission
An astronaut using Playbook aboard the ISS
Problem
The existing constraint UI showed violations whenever a scheduling rule was broken, but did not make them easy to interpret.
Users could see that something was wrong, but still had to manually answer:
What rule was violated?
Which activities are involved?
Where are those activities in the timeline?
What should I change?
In a dense mission schedule, that created too much translation work for the user.
What Playbook looks like when a constraint is violated
Research direction
From internal user interviews and prior team research, I identified two opportunities to improve constraint comprehension:
Improving the language so rules and violations were easier to read.
Improving the visual system so users could connect messages to activities in the timeline.
Empathy mapping with findings from interviews
Improving the language
Turning system logic into readable rules
Playbook supported 14 unique constraint types. Each needed to be described clearly and consistently.
Instead of treating each message as a one-off sentence, I explored reusable message formulas. The goal was to explain both:
the expected rule
the current schedule state causing the violation
Example structure:
Rule: Activity A must start before 10:00.
Violation: Activity A must start before 10:00, but currently starts at 11:00.
This made each message function as both explanation and diagnosis.
Violation: Activity A must start before 10:00, but currently starts at 11:00.
Rule: Activity A must start before 10:00.
Message system ideation
New message formula table
Message before & after examples
Improving the visual system
Constraint violations stream redesign
Activity card redesign
Activity card redesign
Making constraint relationships visible
Language helped users understand the rule, but constraints are relational. A violation may involve multiple activities across the timeline.
To make those relationships easier to follow, I redesigned constraints as modular cards.
The cards showed:
constraint status
involved activities
violation details
suggested fixes
This created a consistent constraint object that could appear inside activity cards, in the violations stream, and as an entry point into the timeline.
Key design decisions
-
Constraint information needed to work in multiple places. A card-based system made each constraint feel stable and recognizable across contexts.
-
Users could scan the high-level violation first, then expand the card for suggested fixes. This helped avoid overloading an already dense timeline.
-
Color blocks connected constraint cards to involved activities. When a user selected a card, related activities were elevated in the timeline, reducing the effort of searching and cross-referencing.
-
Badges showed when an activity was involved in multiple violations. Red markers made relevant start and end times easier to locate.
Constraint card redesign
Final flows
Flow 1: Resolving from an activity card
A user expands an activity, sees its constraints, selects a violated constraint card, and sees the related activity highlighted in the timeline.
This supports users who discover a violation while inspecting a specific activity.
A user expands an activity, sees its constraints, selects a violated constraint card, and sees the related activity highlighted in the timeline.
This supports users who discover a violation while inspecting a specific activity.
Flow 2: Resolving from the violations stream
A user opens the violations stream, scans structured violation cards, selects one, and jumps into the relevant timeline context.
This supports users triaging multiple schedule issues at once.
Outcome
After my internship, Playbook continued to evolve beyond the original project scope. I later learned from my former manager that Playbook was being used as the scheduling tool for NASA’s Commercial Lunar Payload Services program, supporting robotic missions to the Moon.
Several parts of my internship work remained embedded in the product: the revised constraint language was still in use, some redesigned icons remained in the interface, and the icon design rules I contributed to became part of the team’s design system.
For an internship project, this was especially meaningful. Parts of the work continued to live inside a real mission planning tool and became part of the product’s longer-term design system.
This project taught me that complex systems do not become usable just because they expose the right information.
Playbook already knew which constraints were violated. The design challenge was translating that system knowledge into language, structure, and visual context that helped users act with confidence.
If I continued this work today, I would focus on validation: measuring whether users could understand violations faster, locate related activities more easily, and resolve overlapping violations with fewer steps.
Reflection
Bonus Content: Concept Art for NASA