Genie

A node canvas for creators who don’t think in graphs.

Client: Genie, my own product
My role: Founder, Product definition, Interaction model, Prototypes
Year: 2024 – 2026
Discipline: Product Design, AI / ML Interfaces, Prototyping, Design Systems

Genie canvas on a laptop: text, image and reference nodes wired into a video node that has produced four frames

The problem

Node editors expect you to understand the system before you can use it. Artists don’t start there. They start with a goal, like “remove this background” or “make this sharper”, and most node editors make them think like engineers to get there.

My first menu was about us, not users

Genie’s first canvas had four categories: Generators, Tools, Widgets and Plugins. Each one described how the system worked, not what people wanted to do. People found the same feature in three places, mixed up widgets and plugins, and couldn’t find things they asked for every week.

Diagram: the original four-layer taxonomy, named after the implementation, and what the audit found

Two questions instead of four categories

The new menu starts from two questions: am I making something new, or changing something I have? Create is sorted by media type: image, video, text, audio and 3D. Edit is sorted by action, so a path reads “Enhance → Upscale” instead of “Widgets → Image → Generation → Upscale”.

Diagram: the two-question replacement, CREATE organised media-first, EDIT organised verb-first

AI tools sit with the rest

Whether a tool uses AI is not a category. Upscale and Denoise use models, Sharpen and Crop don’t, and they all sit in the same menu, sorted by what they do to your picture. A small marker shows which ones take time and cost credits.

Diagram: AI and non-AI operations merged into one intent-based menu, with processing marked rather than segregated

Simple types for artists

ComfyUI shows technical types like latents and samplers, which suits its expert users. Genie only shows types people already know: text, image, video, audio, mask, file, 3D, code, number and boolean. One adjustment node takes an image or a video, so cropping a video works like cropping an image.

Diagram: engine internals versus the user-facing type vocabulary

One source of truth

A component usually exists three times: in Figma, in code and in the docs. They drift apart, because a Figma change takes a second and a code change needs a review. So the shipped component became the source, and the other two follow it.

Diagram: Figma, code and docs drifting apart, and why "everyone remembers" is not a system

Figma linked to the real component

Code Connect links each Figma component to the real one, so developers get the import and props instead of a picture. The Figma MCP server gives coding agents the same link, so they reuse the component instead of guessing from a screenshot. Renaming a variant in Figma breaks the link right away, which is the point.

Diagram: Figma to Code Connect to the real component, exposed to an agent over the Figma MCP server

Variant names matter now

Once “Primary” in Figma maps to variant="primary" in code, the names in the design file are part of the product. A link still can’t say when not to use a component, so that has to be written down.

Prototype Code Connect binding mapping Figma variants onto the component’s props

Docs an agent can follow

A designer fills gaps in a thin doc from memory or by asking someone. An agent can’t, so it gets things wrong right away, where you can see it in the code. Writing docs for agents showed exactly where ours were missing information.

Diagram: what a human component doc assumes versus what a coding agent has to be told

What each component doc covers

When not to use the component and what to use instead. What each variant means, not just how it looks. Which states exist and which don’t. The accessibility rules, written out. Each component has a short markdown file next to its code, plus one design.md for decisions that apply to all of them.

Prototype component document written for a coding agent, covering when not to use it, variant meaning, states and the accessibility contract

What I learned

Storybook renders every variant and state and runs accessibility checks on each one. The docs written for agents turned out to be better docs for people too. And the hardest part of designing for artists was not showing off every feature we had built. If a menu feels natural to the people who built it, test it with someone else.

Outcome

4 → 2

menu layers, organised around what people want to do

model internals shown to users: no latents, samplers or conditioning

Goal

A simple, powerful creative tool for artists.

Solution

1. A web app: share files instantly, edit with teammates, no model downloads. 2. Community workflows open in one click, and their authors earn a share of revenue. 3. An AI agent builds workflows for you, so the tool stays simple but fully customisable.