Translating invisible scheduling logic into violations users could understand, locate, and resolve.
Improving Constraint Clarity in NASA Playbook
Overview
Role: Product Design Intern
Team: NASA Ames Research Center, Scheduling and Planning System for Exploration (SPIFe)
Timeline: Jan – Mar 2022 (3 months)
Challenge: The Playbook mission scheduling tool could identify when scheduling rules were violated, but users still had to interpret dense system messages, locate related activities, and decide what to change. In a timeline shaped by timing, dependency, and resource constraints, that translation work created unnecessary cognitive load.
Focus: Product design, UX research synthesis, interaction design, content design, visual systems
Outcome: Redesigned the end-to-end constraint experience across two strategic layers:
Language: Created reusable message formulas for 14 constraint types, turning algorithmic rule data into readable explanations and diagnoses.
Interface: Designed modular constraint cards, violation states, timeline highlights, and inline resolution paths so users could connect each rule violation back to the activities involved.
Context
Mission schedules are shaped by rules users cannot always see
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.
Multi‑activity dependencies
Resource contention rules
State‑based visibility logic
Conflicting workflows (triage vs deep‑dive)
Need for clarity without oversimplifying system logic
Why this matters
As missions move farther from Earth, communication delays mean astronauts must diagnose and resolve issues autonomously. Unclear constraint messages directly slow mission execution.
Playbook UI
NEEMO using Playbook during an undersea mission
An astronaut using Playbook aboard the ISS
What made this hard
Multi‑activity dependencies
Resource contention rules
State‑based visibility logic
Conflicting workflows (triage vs deep‑dive)
Need for clarity without oversimplifying system logic
Users & Operational Context
Playbook was not a single-user tool in a simple environment. It supported mission planning workflows where different users needed to understand the same schedule from different perspectives.
-
Needed to build and adjust activity timelines while respecting timing, dependency, and resource constraints.
-
Needed constraint information to be readable quickly, especially when they had to understand what changed and what required action.
-
Often helped interpret constraint violations, explain why they occurred, and identify what schedule changes would resolve them.
The design challenge was to reduce the amount of manual interpretation required across that workflow. Instead of making users decode system output, the interface needed to help them understand what happened, where it happened, and what they could do next.
Problem
Playbook could detect violations, but users still had to decode them
The existing constraint UI could tell users that a scheduling rule had been violated. But it did not clearly answer the questions users needed in order to act:
What rule broke?
Which activities caused it?
Where are those activities in the timeline?
What change would resolve the issue?
This meant Playbook had the information, but users still carried the burden of interpretation. In a dense mission schedule, every unclear message created more searching, cross-referencing, and hesitation.
What Playbook looks like when a constraint is violated
As-is / to-be workflow
The as-is flow
In the existing flow, Playbook could detect the violation, but the user still had to do the translation work.
Constraint appears
User reads technical message
User searches related activities and resources
User infers the cause
User cross-references system logic or asks for help
User decides what to change
The to-be flow
The redesign focused on closing the gap between system detection and user action.
Constraint appears
User sees a plain-language explanation
Related activities and resources are visible
User understands the cause
User sees a clearer resolution path
User acts with more confidence
Research direction
The core issue was not only visibility, but translation
Research made it clear that constraint comprehension was not a single UI problem. It was a workflow problem across users, tools, and system logic. Playbook could identify that something was wrong, but users still needed to understand the violation well enough to decide what action to take.
The redesign needed to translate constraint logic across two layers:
Language: Users needed violations to read less like system output and more like clear explanations.
Visual context: Users needed to connect each message to the relevant activities in the schedule.
Empathy mapping with findings from interviews
Before
Constraint messages were fragmented and system-oriented. They surfaced that something was wrong, but did not always make it clear what caused the issue, which activities were affected, or what the user should do next.
After
The redesigned flow organized each constraint around three user questions:
What is the issue?
What is it connected to?
What can the user do next?
This shifted the experience from decoding system output to making an informed planning decision.
Part 1: Improving the language
Constraint messages needed to behave like explanations, not error codes
Playbook supported 14 constraint types, each with its own underlying logic. If each violation message was written as a one-off sentence, the system would stay inconsistent and difficult to scale.
I treated constraint language as a content system. For each constraint type, I defined reusable message formulas that explained both the expected rule and 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 turned each message from a vague alert into a small diagnostic object: what should have happened, what happened instead, and why the schedule was now invalid.
Message system ideation
New message formula table
Message before & after examples
Part 2: Improving the visual system
Violations needed to become objects users could scan, select, and trace
Language could explain the rule, but it could not solve the whole problem alone. Constraints are relational: a violation may involve multiple activities, separated across a dense timeline.
I redesigned constraints as modular cards so each violation could behave like a stable object across the interface: readable in a stream, attached to an activity, and connected back to the timeline.
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.
Constraint card redesign
Constraint violations stream redesign
Activity card redesign
Key design decisions by user need
| User need | Design decision |
|---|---|
| Understand what went wrong quickly | I rewrote constraint messages as plain-language explanations instead of raw system output. The goal was to help users identify the issue without first decoding technical phrasing. |
| Understand what caused the issue | Each message connected the violated rule to the current schedule state causing the problem. This made the constraint feel less like an isolated alert and more like part of the planning workflow. |
| See what the issue is connected to | Because constraints could involve multiple activities, resources, or timing relationships, the redesigned cards surfaced related activities and timeline context instead of forcing users to infer those relationships manually. |
| Know what to do next | The redesigned flows gave users clearer entry points into resolution, whether they started from an activity card or the violations stream. |
| Avoid unnecessary visual overload | I used progressive disclosure so the most important information appeared first, while supporting details remained available when needed. |
| Preserve technical accuracy | The goal was not to simplify the system by removing important details. It was to keep the underlying logic intact while making it easier to parse. |
| Support future constraint types | The card-based structure created a reusable pattern that could scale beyond one constraint type without requiring a new layout each time. |
Final flows
The redesign supported both local fixes and broader issue triage
Flow 1: Resolving from an activity card
This flow supported users who discovered a problem while inspecting a specific activity. Instead of leaving the activity card to hunt through a separate error list, they could expand the card, inspect its violated constraints, and see the related timeline context immediately.
Flow 2: Resolving from the violations stream
This flow supported users triaging multiple schedule issues at once. The violations stream acted as a command center: users could scan structured cards, select a violation, and jump directly into the relevant timeline context.
Impact on users & system scalability
User impact, based on UX evaluation heuristics
Clearer explanations reduced the effort required to interpret violations
Direct links to timeline context made diagnosing issues faster and more intuitive
Immediate visibility of relationships between activities improved understanding
Support for both triage and deep‑dive workflows let users work the way they prefer
Greater system transparency
System-level impact
Modular constraint cards support new rule types without redesign
Structured message patterns reduce future UX writing and engineering overhead
Reusable components simplify maintenance and improve long‑term scalability
Unified interaction patterns create consistency across Playbook’s violation surfaces
A more extensible foundation supports increasing mission and rule complexity
Outcome
Parts of the work continued beyond the internship and into the product
After my internship, Playbook evolved into the scheduling tool for NASA’s Commercial Lunar Payload Services program. Several pieces of my work remained in the product: the revised constraint language, some redesigned icons, and the icon rules that became part of the team’s design system.
The project wasn’t just a concept exercise. It became part of a real mission‑planning tool and helped shape Playbook’s longer‑term design language.
Reflection
Complex systems become usable when their logic becomes legible
Playbook already knew which constraints were violated. The challenge was translating that system logic into language and structure users could act on.
If I continued this work, I’d focus on helping users identify and resolve conflicts earlier through predictive detection, constraint‑aware suggestions, and “what‑if” simulation.
At its core, the work is about making the system’s logic legible enough that users can act with confidence, not caution.
