Substance Designer graphs grow fast, and past a few dozen nodes they get hard to read. The structure is there but nothing shows it, and connections between distant parts of the graph cross everything in between. I designed two features against that during a two-year contract with the Substance 3D team. Frames give users a way to group and label parts of a graph. Portals move data between distant nodes without drawing a line to do it.

Substance Designer is a node-based authoring tool used to create procedural textures and materials for games, VFX, and design. It’s known for its flexibility, precision, and non-destructive workflow, and is widely used in AAA pipelines and real-time engines.

A connection in Substance Designer is a line drawn between two nodes. When the nodes are far apart, that line crosses everything between them. Portals pass the data from a transmitter to a receiver with no line at all, which solves the clutter and creates a new problem: with nothing to trace, users need another way to tell where a value came from and where it goes. Most of the design work went into that.

Prototypes

The prototypes worked through how a portal shows itself in the graph: pins that can be shown or hidden, a link you can reveal when you need to trace one, and properties that read the same way whether you come at them from the graph or from the panel.

UX specification

To support implementation, I created a detailed visual spec outlining interaction states, naming behavior, and visual feedback across both transmitter and receiver nodes. These mockups were tailored to help engineering navigate edge cases and maintain consistency across hover, selection, and connection states. The goal was to reduce ambiguity and speed up integration while reinforcing visual clarity and intuitive behavior in the final implementation.

Yes, and…

This gallery shows alternate designs and prototypes explored during development. Some were beyond the scope of our milestone goals, but they helped inform the direction of the final feature. These explorations remain useful reference points for future improvements or adjacent features.

Frames already existed as a way to draw a box around part of a graph. They did not nest, they did not resize with what they held, and their labels were one line of plain text. I redesigned the system to handle all three, so a graph can carry its own documentation.

Prototypes

Prototypes were essential for working through the details of the new frame behavior. I created six animated interaction samples in Adobe’s internal format to illustrate key behaviors and transitions. These helped clarify edge cases, show intent, and support more productive conversations with engineering. Clear visuals and motion were especially useful for communicating the nuances of selection, nesting, and labeling in a complex, layered graph environment.

Frame Design System

Users pick their own frame color, so every choice they can make has to survive three states: default, hover, and selected. I tested hues and alpha values against the graph background to find where a title stops being readable and where a filled frame starts hiding what is inside it.

UX specification

I wrote a UX spec covering interaction behavior and visual feedback across nested and styled frames. It included a proposal for the visual styling, which meant learning how Qt renders frames to know what was actually available. The styling was not adopted. The spec still surfaced edge cases early, and it holds up as a reference for later work.

Frame description formats

A frame’s label was one line of plain text. I looked at what it would take to make it a description instead, and compared four ways to author one: plain text, Markdown, HTML, and an inline WYSIWYG editor. Each was scoped against what Qt could render. The team went with HTML.