The goal: give non-technical marketers hands-on experience building with AI in a collaborative capacity, not just generating one-off assets, but composing, comparing, and reusing the workflows behind them.

My Role

In a team of three, alongside two engineers I personally:

Owned the product design of the canvas: the interaction model, the module system, and the end-to-end flow.
Designed and built the frontend, shipping the node, chaining, and template systems to production.
Condensed technical workflows into something a non-technical marketer could use unaided.

Timeline

4 months

The Problem

Marketing teams struggle to collaborate when working with generative AI tools.

Observations

I worked directly with marketing and creative product teams to train them on how to prompt AI models for asset ideation and creation, I observed that using traditional chat based tools made it very difficult for them to collaborate and share their processes and ideations.

They generated assets in chat-based tools: ask, refine, repeat, in a linear timeline. The process works fine for a single throwaway image or as a party trick but quickly breaks down the moment teams want to learn from each other or they attempt to work through more complicated iterations as creative teams often do.

Four core issues

The same four problems surfaced again and again. I treated them as the rubric the rest of this study has to answer — every later decision earns its place by resolving one of them.

Hard to get it right

Refinement is clumsy and linear — every tweak means re-typing the whole ask.

Easy to get lost

Assets scatter across chat threads; past generations are gone the moment you scroll.

Hard to compare and edit

No side-by-side, no branching — you can’t hold two options up against each other.

Impossible to collaborate

Chat is single-player. A workflow can’t be shared, forked, or built on as a team.

The honest scorecard

Nodes don’t sweep. The criteria are the four pains from the last section, plus the one thing chat does effortlessly — the floor. Naming where my choice loses is what makes the rest of the argument trustworthy.

Criterion (← the four pains)

Chat / conversational

Node canvas

Low floor — anyone can start

✅ Wins — just type

⚠️ At risk — high floor unless designed down

Workflow visibility

❌ Hidden, linear

✅ The structure is the artifact

Iteration & comparison

❌ Linear, past gens lost

✅ Branch + collection grid

Organization

❌ Scattered across threads

✅ Spatial, collections

Collaboration

❌ Impossible, single-player

✅ Forkable, real-time

The bet: chat wins exactly one thing — the floor — and wins it for free. Nodes win everything structural, and for a team-workflow goal those wins are decisive. The single place nodes lose is the floor, and a floor is a solvable design problem. The next section is the receipts.

The structural decision

A chat based interface wins one thing: a low floor. It is easy to jump in and start typing. The node based canvas wins everything structural, from visibility and comparison, to organization and collaboration.

The node based interface provides the optimal structure for a collaborative tool, but the floor is high to get started. This project focuses on building out the internal features to lower the floor and ensure the users can easily start creating with the interface growing with them as they learn.

The Module

The nodes consist of modules and assets. Each link to the other to create chains which users expand on. The nodes need to be as simple as possible without preventing power users from achieving their full potential.

The core structure

I found that node workflows naturally evolve left to right while branching out like a tree, it is an intuitive way for users to work through iterations having the base be on the left and then progressively working towards the right as the ideas evolve.

The modules that make up the chain should therefore inherit the same structural rules with content flowing left to right.

Horizontal axis

Across → content

Input → prompt → output, left to right. A module acts as a miniature a chain.

Vertical axis

Down → time

History (past outputs) sits above the prompt; settings (future output) sit below. The vertical axis of the module acts as a timeline for the data surrounding the given module.

Low floor by default

The core module shows only what a beginner needs: one the inputs and a prompt input box. Advanced inputs, settings, and history stay hidden until they are needed.

The input panel

Decision 1

All external effects live in the input panel

Prompts, reference images, uploaded files, upstream outputs, styles, and brand packs all arrive through and can be organized in the same input model. There is one place to look when modifying the content the module has to work with. Brand consistency becomes just another input you pick alongside references.

Decision 2

Dynamic layout

Just like the module as a whole, the input panel starts simple and then expands to reveal options and inputs when necessary. At first only the ports you drag to sit up front with the more advanced options sitting under the "Add Input" dropdown. When attaching a style or reference pack using that dropdown it then appears above the fold in its own section. Inputs for the Prompt and Reference sections automatically reveal additional slots as elements get connected, growing as users interact with them.

Decision 3

Toggle input types directly from the panel sections

For modules with multiple distinct input modes, users can toggle between them directly from the section within the panel keeping the control centralized.

The action bar

Settings follow the low-floor rule twice over. A quick-settings pill surfaces the two or three controls people actually reach for — aspect ratio, variations — a single tap away; the full panel (resolution, model, and the rest) opens only when asked. It also shows an estimated cost per run: a small honesty that builds trust in a tool spending real money. And it sits below the prompt — the “future” of this generation, completing the vertical timeline.

Settings follow the low-floor rule twice over. A quick-settings pill in the action bar surfaces the two or three controls people actually reach for the most. Tapping them opens a modal to quickly switch that option. This reducing the need to open the full panel, speeding up iterative refinements.

Scaling Up

Learn the grammar once, and the same moves scale — from one asset to your whole team.

Asset Collections

The first way things scale is breadth. Variations from a single module group collect automatically into one node, which makes comparing options effortless — and a collection can feed a downstream module two ways: run the workflow once per asset, or hand the whole set over as a single batch. One node, doing three jobs at once:

Job 1

Organize

Collapse to one hero asset to keep things clean, or expand to a grid to compare side by side.

Job 2

Agregate and Loop

Runs a downstream module once per item — the power of a for-loop, with no concept of a loop to learn.

Templates

The second way things scale is reuse. A working chain collapses into a single node the whole team can run. The expert builds the pipeline once, then places input and output nodes inside it to author exactly which controls appear on the outside — so a used template looks and behaves like any other module: same collapsed card, same input panel, its complexity hidden but one click away. You save what works, and hand the team a one-click superpower — the reuse payoff a chat tool could never give.

Reflection

Results from the pilot implementation

I tested working builds with the same marketing teams that I originally trained, against their old chat workflow.

It is easy for anyone to simply generate more assets. The real question we wanted to answer was whether teams reached an approved asset faster, with less waste, and more range. We were able to measure these statistics with the pilot teams against their old chat workflow. (directional estimates from the pilot with the real marketing teams but not exact figures)

60% ↓

Fewer dead-end generations

runs that ended without an approved asset

Parallel branches and side-by-side comparison let people keep the good directions instead of hitting a wall.

25% ↓

Fewer iterations to an approved asset

75% fewer when the workflow was a saved template

History is never lost and proven pipelines get reused, so teams learn from each other’s attempts.

We also observed a wider diversity of assets that were being created per brief using the new workflow which we attributed to the collaboration and mood-boarding-like behavior that we observed occurred when users could freely explore without risk of losing track of their experimentations.

What it taught me

Working on Creative Cortex taught me that the limit of a creative tool is not necessarily the power of the tools but rather the extent to which it makes people feel free to explore.