Design a Safe and Transparent Rebase Workflow for a Visual, No-Code Environment

Year

2025

Role

Sole product designer

Duration

3-4 weeks for v0, continued iteration afterward

Context

As Palantir prepared to introduce platform-wide branching, we needed to support a foundational Git concept: rebasing.

Foundry is Palantir’s data+operations platform, and Workshop is its visual no-code builder for creating mission-critical apps. Users assemble applications using pages, sections, widgets, and variables — everything is object-based and edited visually.

With the rollout of platform branching, we needed a way for builders to safely merge their work without accidentally overwriting teammates’ changes. In Git, this is done with rebasing,

Problem space

Translate Git-like rebasing into a visual environment — preserving context, exposing differences, and allowing safe modification — despite the lack of line-level diffs.

Git’s rebasing relies on a textual diff mental model:

Lines are added / deleted

Diffs are explicit
Conflicts are localized

Workshop, however:

operates on components (widget, variable…), not lines

stores changes as changelog events (addition, edit…)
hides specific diff details inside JSON
relies heavily on spatial visual context
cannot render multiple app states side-by-side

This mismatch makes rebasing inherently fragile in a no-code environment.

Git’s rebase in line-by-line diff in VS Code

Workshop's component-based changelog

Design goal for V0

Visual, reasonable, predictable, safe

Rebasing in Workshop spans ontology resources, application logic, and deeply nested visual configurations—making real production modules complex.

This meant the UX needed to compensate for invisible differences and opaque auto-merges.

We saw that this is a complex problem space and we set goals for the v0 to unblock branching users with principles as follows.

Preserve spatial context

Users should always understand where changes occur in the app hierarchy.

Expose merge reasoning

Surfacing both conflict and non-conflict deltas is essential for trust.

Favor predictability over granularity

Component-level diffs are coarse; clarity of outcome matters more than perfect detail.

Support safe modification

Users must be able to preview different versions and make edits before committing

V0 design preview

1. A clear entry point into “Rebase Mode"

2. Visual context stays intact

3. A structured, component-level conflict panel

4. A clear next step after completion

V0 Launch & What We Learned

We delivered a V0 within ~4 weeks to unblock users and validate the core workflow. The launch successfully removed hard blockers and enabled users to complete tasks that were previously impossible or manual.

While the feature was functionally successful, early usage revealed a deeper issue: trust, not capability, was the primary barrier to adoption.

Key learnings:

Auto-merges reduced trust. Even when changes didn’t conflict, silent merges made the system feel unpredictable. Users wanted clearer visibility and control before rebasing.

Debugging lacked spatial clarity. In complex apps, changes were hard to reason about because related resources were deeply interconnected and not visually grounded.

Conflict resolution felt detached from structure. The conflict panel didn’t reflect the app’s hierarchy, and since many users don’t name layers consistently, diffs were confusing without contextual cues.

These insights reframed the problem from “making rebasing possible” to making it feel safe, predictable, and understandable, directly shaping the direction of subsequent iterations.

These insights are shaping an ongoing redesign centered on trust, predictability, and user control. I’d be excited to dive deeper into the explorations and follow-ups in conversation.