Summary
SynapseSys began with a product thesis:
relationships between ideas should be executable.
The first visual answer was deliberately loud: black canvas, phosphor green, pixel shadows, dashed orthogonal edges, command-line forms, and a blocktype mark that made the product feel like a machine you could operate.
That was useful. It proved the product had a point of view. It also was not enough.
The harder design problem was not making another AI interface look futuristic. It was:
How do you keep strong terminal identity while making the product feel clinical, trustworthy, readable, and usable during long thinking sessions?
Project Frame
- Role: solo product designer and design engineer for visual language, interaction system, component behavior, and implementation.
- Scope: canvas aesthetic, theme system, typography, blocktype logo, node and edge grammar, loading states, onboarding, landing direction, motion system, design QA.
- Evidence: commit history from March 7 to July 1, 2026,
ANIMATIONSYSTEM.md,docs/MICROINTERACTIONSPEC.md,docs/edge-visual-spec.md, audits, captures, and playground stories.
Reviewer Takeaway
- Taste was not treated as decoration. It became a product constraint: make AI feel powerful without letting it take authorship away from the user.
- The final direction is distinctive because it combines clinical map-reading, terminal command language, retro blocktype, and modern SaaS legibility in one system.
- The strongest design decision was restraint: keep the terminal DNA, reduce glare, soften default contrast, and push attention back to nodes, edges, and user intent.
Product Notes
- Initial aesthetic problem: avoid generic AI slop without becoming a novelty terminal skin.
- Final direction: Midnight as readable default, Terminal and Pip-Boy as expressive legacy modes, Daylight as proof the system could survive professional use.
- Motion rule: every animation had to explain system state, spatial causality, or interaction momentum.
- Unfinished edge: identity is strong, but the next pass should keep reducing onboarding noise, component density, and mobile canvas friction.
Taste In The Age Of AI Slop
AI product visuals have become too easy to fake: soft gradients, floating cards, glowing chat boxes, fake dashboards, empty agent metaphors. They look expensive for one screenshot and interchangeable by the second.
For SynapseSys I wanted the opposite. The interface had to feel authored. It needed to say: this is not a chatbot with a canvas attached. This is a thinking surface where relationships become operations.
The taste test was not "does it look cool?" It was:
- Can a user still read the map after the first impression fades?
- Does AI output feel like material on canvas, not external commentary?
- Does motion show what changed and why?
- Can the product keep visual identity across auth, pricing, settings, sharing, errors, onboarding, and mobile states?
- Can the aesthetic survive light theme without collapsing?
That last question mattered. A terminal-only product can hide weak hierarchy behind glow. A real visual language keeps working when the background turns white.
Initial Aesthetic Problem
The first coherent direction was pure terminal: black background, bright green signal, pixelated type, right-angled lines, grid dots, and hard block shadows. Early March 7 commits established the foundation in a compressed sequence: design tokens, keyframes, Navbar, ModeToolbar, SidePanel, UI primitives, terminal auth forms, Konva dot grid, node cards, handles, orthogonal edges, dash animation, edge menu, editor, and command palette.
That gave SynapseSys recognizable identity immediately.
It also created three problems:
- Glare: original green-on-black terminal mode was memorable, but long reading sessions became visually hot.
- Hierarchy: when every element speaks in the same signal color, product identity is strong but prioritization is weak.
- Trust: a clinical AI product cannot look like a toy hacker console when it asks users to organize important thinking.
A March 23 UX architecture audit said the quiet part directly: SynapseSys had a strong coherent terminal aesthetic, but the same audit flagged demo guidance, broken theme rendering, and raw error states as trust gaps.
The design lesson: identity had landed. Product trust had not.



Reference Logic
There was no moodboard file in the repo, so the honest reference set lived in implemented behavior:
- Terminal CLI: command language, cursor rhythm, boot sequence, monospace labels, square controls, operation badges, text-first affordances.
- CRT phosphor: scan rhythm, glow decay, boot draw, decrypt text, staccato shimmer, idea active state as signal turning on.
- PCB systems diagrams: orthogonal edge routing, bridge arcs, port selection, dashed lines, refusal to make every connection a smooth curve.
- Clinical software: restrained default color, dense information surfaces, clear status, auth and billing trust wrappers, reduced decorative motion.
- Blocktype identity: logo, UI shadows, node cards, badges, and panels share hard rectangular grammar. Nothing rounds itself into generic SaaS softness.
The references mattered because SynapseSys sits between worlds. It is a clinical AI product, but the core interaction is spatial, generative, and weird. It needed enough retro-machine character to feel ownable and enough modern product discipline to stay credible.
Typography, Color, Density, Spacing
Typography expressed the tension clearly. Early direction leaned into terminal fonts. Later theme work made the type system more practical: terminal-styled modes stayed in family, but product surfaces could use JetBrains Mono where readability mattered.
Color evolved the same way. Terminal green remained the brand signal, but Midnight became the mature default: dark readable background, softer green, lower-contrast borders, enough muted text for secondary information. Daylight used blue as accent, proving the graph vocabulary could translate into professional work mode.
Density became part of the brand. SynapseSys should not feel like a landing page. It is a canvas tool:
- thin top chrome instead of a large app header
- small uppercase labels and badges
- compact toolbars at canvas edges
- grid dots as orientation, not decoration
- node cards sized for scanning
- operation labels attached to generated material
- side panels and settings surfaces that keep terminal structure without swallowing the canvas
Spacing is intentionally mechanical. Controls sit in rows. Edge paths turn at right angles. Shadows are offset blocks. The product avoids soft rounded card stacks because the underlying metaphor is not a lounge or assistant. It is a machine arranging and transforming ideas.
Playground As Evidence
The source repo's /playground page became a component lab for the visual system. It was added and expanded across commits like 012475b (themes, settings overhaul, playground stories), cbb16bc (restore animations showcase), 3309c55 (OperationShimmer), 680fe2c (sphere presets + live-tuning playground), and 0357c62 (expand design system playground coverage).
That matters because the design system was not only judged from a hero screenshot. The playground let me inspect components as product states:
- UI primitives: Button, Input, Toast, ConfirmDialog, pixel icons.
- Node components: preview, collapsed, skeleton, ghost node, operation badge, concept span, highlight chips, provenance tooltip, edit mode, prompt input.
- Canvas chrome: EdgeMenu, EdgeOperationPill, selection actions, node context menu, tab context menu.
- Layout and overlays: Navbar, ModeToolbar, SidePanel, TabBar, SearchPalette, ShortcutOverlay, share dialog, canvas detail panel.
- Onboarding and loading: CanvasHintBar, terminal spinner, progress bar, page loading frame, BootSequence, node skeleton loading.
- Motion and landing experiments: animation showcase, hero sphere presets, feature demos, live tuning.
The useful part of a playground is not volume by itself. It lets taste fail in small places before it fails in the product: wrapping bugs, contrast misses, over-animated loading, action menus that feel like decoration, ghost nodes that feel too permanent, themes that work in CSS but not in Konva canvas tokens.
Motion As Product State
The animation system is one of the strongest parts of the identity because it is specific. It does not use generic fade-and-slide polish everywhere.
The motion docs define three timing tiers:
quick: 100ms handles, tooltips, button statesstandard: 200ms mode swaps, chip entry, dropdownsemphasis: 350ms node creation, panel entrance, viewport motion
That created a design language: fast, snappy, slightly mechanical. The default curve is not soft. It snaps.
Actual components carry that logic:
- BootSequence: reverse stroke draw of the blocktype logo, offset shadow expansion, fill, decrypt text, CLI progress, then fade into canvas.
- Grid canvas: dot grid, reveal/ripple behavior, pan/zoom, viewport persistence make canvas feel like a stable coordinate system.
- NodeCard: drag lift, pixel shadow, focus ring, edit/view transitions, resize handles, overflow microcopy, content-aware max height, and ghost displacement keep cards physical without turning them skeuomorphic.
- ConnectionPreview: handle proximity, snap target, orthogonal preview line, magnetic endpoint, and zoom-compensated snap radius make connection creation feel precise.
- EdgeShape: dashed operation paths, hover dimming, selected priority, bridge arcs, zoom-compensated stroke width, animated dash offset, and tether-first result emission.
- OperationShimmer: each AI operation gets its own loading signature: expand radial burst, synthesize crystallization, summarize backspace/delete, compare split oscillation.
- GhostNode: suggestions appear as visible but uncommitted material, then animate into real nodes only if the user accepts them.
- ThemePicker: hover previews update both CSS variables and JS canvas tokens because Konva edges cannot rely on CSS alone.
- Navbar, ModeToolbar, SidePanel, SearchPalette, Toasts, Auth forms: square controls, mono labels, hard borders, stateful color, restrained entrance motion.
The point of the motion system is causal clarity. When AI generates something, the interface should not simply say "loading." It should show where the result came from, which operation is running, and when provisional material becomes real.
Component Motion Inventory
I treated animation as a component-level contract, not a sitewide effect. The audit broke it down into systems:
- CanvasStage and GridLayer: keep world position stable, render dotted grid, avoid recalculating too much during active gestures, preserve spatial trust while panning, zooming, and dragging.
- BootSequence and ProgressBar: establish the product as a machine booting up through reverse logo draw, hard offset shadow, decrypt text, and CLI progress.
- NodeCard states: new-node arrival, drag lift, pixel shadow, handle magnetism, focus states, edit/view swaps, resize feedback, overflow microcopy.
- SkeletonCard, ShimmerLines, OperationShimmer: make AI waiting states operation-specific instead of generic.
- ConnectionPreview and handles: make connection creation feel magnetic through proximity, snap radius, target pulse, orthogonal preview lines, and zoom-compensated hit behavior.
- EdgeShape and edge menus: turn relationships into product controls through dash animation, z-order, dimmed context, bridge arcs, operation labels, action pills, and race-condition hardening around picker state.
- GhostNode layout: keep AI suggestions provisional through lower-opacity cards, accept/dismiss controls, materialization delay, and temporary displacement of nearby nodes.
- ThemePicker and CanvasThemeHydrator: sync DOM CSS variables with JavaScript canvas tokens. The animation is modest because continuity across canvas chrome matters more than flair.
- Shell components: Navbar, ModeToolbar, SidePanel, TabBar, SearchPalette, Toast, ConfirmDialog, and auth forms reuse terminal grammar but stay quieter than the canvas.
- Landing playground components: test higher-expression brand motion, including sphere reveal, parallax, hover interactivity, feature demos, and live tuning. These could sell the product while the canvas stayed work-focused.
The conclusion was not "make everything move more." Some components became better when motion was reduced, made more staccato, or tied to a precise state change.
Edge Grammar Became Visual Language
The edge system is where the visual design and product model meet. A connection is not a decorative line. It is a readable relationship, a command target, a pending operation, a generated result path, and a future source of more work.
So the visual language needed more than straight lines:
- orthogonal paths instead of arbitrary diagonals
- selected-edge priority and hover dimming
- bridge arcs at crossings
- operation labels and pills at meaningful midpoints
- dash patterns that imply active work
- zoom-compensated strokes and hit areas
- route choices that preserve scanability over cleverness
One routing direction looked technically impressive: PCB-style staircase fan-out through shared ports. It made dense maps look engineered, but it collapsed meaning into a thick bundle. The chosen route spends more space so individual relationships remain selectable, labelable, and understandable.
Ghosts Protected Authorship
AI suggestions are useful until they become clutter. If every related concept becomes a permanent node, the graph stops feeling authored by the user. It becomes AI debris.
So suggestions became ghost nodes. A ghost node is visible but not committed. It appears near a selected idea, connected by a faint suggestion line. The user can accept it, dismiss it, or ignore it. If accepted, the ghost materializes into a real node and the graph updates. If ignored, it disappears without polluting the canvas.
That design decision created real state complexity:
- cache suggestions by source node
- track ghost anchors
- place ghosts around selected nodes
- displace nearby nodes without permanently moving them
- materialize accepted suggestions optimistically
- pan the viewport enough to reveal the new branch
The principle was simple:
AI should widen the user's peripheral vision, not take over the map.
Retro, Modern, Terminal, Blocktype
The final aesthetic works because each influence has a job.
Retro gives the product memory. The blocktype mark, green signal, square borders, and CLI motion make SynapseSys recognizable before anyone reads the pitch.
Modern gives it discipline. The app still needs auth, settings, pricing, billing, sharing, export, usage limits, analytics, and error states. Those surfaces cannot be pure art direction. They need clarity, hierarchy, and boring product trust.
Terminal gives it agency. The product feels commandable. Operations have names. Loading states look like work. The interface suggests the user is driving a system, not asking a mascot for help.
Blocktype gives it structure. Logo, shadows, nodes, badges, and panels all share rectangular weight. That shape language makes the canvas feel like a map of discrete executable objects.
The combination is what makes SynapseSys distinct. It is not cyberpunk for its own sake. It is not minimal SaaS with a green accent. It is a clinical command surface for thinking.
Old SynapseSys Chronology
The old alextraykov/synapse-sys repo shows a simpler but useful design arc: the product started as terminal whiteboard theater, then slowly exposed graph-product controls without losing the green-on-black identity.
I replayed seven checkpoints from main. The first one, ee22f361 from January 17, 2025, did not produce a screenshot because the CRA app was missing public/index.html. The source still matters: it establishes the first design answer as terminal-style nodes on a whiteboard canvas, before the product had enough app chrome to behave like a graph tool.

e95e104fterminal-window cards, green dot grid, + New Terminal, and HackerNoon-style icon affordances made the product feel commandable before it felt mature.
a67ccfe7ReactFlow chrome, connection labels, node action rows, and animated routes made relationships look like product objects rather than decorative lines.
7ff568d3the toolbar named modes directly: hand, box select, action states. The UI became more legible, but still explained itself loudly.
a414bc9flabeled mode controls collapsed into icon-first toolbar language. It became denser, less tutorial-like, closer to real tool chrome.
d92cc2e5visual system stayed almost unchanged while canvas ripple performance moved from 35s LCP toward usable load. Taste had to survive implementation cost.
0734c853old main stabilized as green terminal graph surface: expressive, recognizable, high-contrast, but not yet clinical enough for long-session trust.The design read from this old line: SynapseSys already had identity before the v2 pass. What it lacked was restraint. The terminal metaphor was coherent, but every surface spoke at the same volume. The later design work did not need invent a brand from zero. It needed preserve authorship, reduce glare, and turn a loud prototype into a product surface a person could think inside.
What Changed Over History
The commit history shows the design becoming more mature through pressure:
- March 7: tokens, keyframes, terminal UI primitives, auth forms, canvas grid, nodes, handles, orthogonal edges, dash animation, side panel, editor, search palette.
- March 14 to March 22: Node Interactions v2, AI actions, edge system expansion, app shell, tests, specs, five-theme system, font switching, picker UI.
- March 28 to March 29: schema data hardening, observability, loading states, settings, playground stories, canvas refactors.
- April 4 to April 8: OperationShimmer, landing redesign, causal-anchor generation feedback, retry error handling for edge creation, generating badges, hydration fixes, demo card title wrapping fixes.
- April 10 to April 11: onboarding rework, edge routing improvements, audit fixes, content-first nodes, trackpad pan/zoom, SidePanel polish, security lock-down.
- April 13 to April 16: billing provider changes, theme/name/tone calibration, Editorial theme experiment, node resize polish, landing sphere, themed nav, landing animation performance.
- April 22 to April 24: canvas polish, streaming, resize, menus, card layout, mobile/touch foundation, gesture freeze, profile, multilingual AI, Midnight baseline, theme token duplication, budgets, auth rate limits, deployment guardrails.
- May 8 to July 1: analytics expansion, AI edge-operation hardening, operation picker race fixes, AI connection flow fixes, waitlist gating, demo overlay updates.
The shape of history matters. The aesthetic did not move in a straight line from rough to pretty. It moved from expressive to trustworthy.


Why Final Look Fits Product
SynapseSys is about turning relationships into operations. The final aesthetic makes that visible.
The grid implies space. Node cards imply manipulable objects. Edges imply executable relationships. Badges imply operation history. Boot shimmer states imply system work. The theme system implies this is a product, not a one-off demo. The blocktype mark implies an engineered machine.
Most importantly, the design protects authorship. Ghost nodes are not permanent until accepted. Pending states are not treated as durable truth. AI loading is connected to source material. Edges remain readable when the map gets dense.
That is why the visual language fits: it makes the product's moral stance visible.
AI can help generate. The user still owns the map.
What I Would Refine Next
I would keep reducing visual noise before adding more expression.
- Make Midnight even calmer by lowering secondary glow and giving long text more breathing room.
- Export a full screenshot and video set for every important playground state, not only audit captures.
- Tighten onboarding so the demo never opens as an empty, unexplained machine.
- Keep legacy Terminal and Pip-Boy as expressive modes, but default new users into readable Midnight or Daylight.
- Rework mobile density around gesture confidence instead of shrinking the desktop canvas.
- Add a small component-motion gallery for BootSequence, OperationShimmer, GhostNode, edge operations, theme switching, and onboarding.
- Continue replacing raw failure states with designed product states: expired links, auth recovery, budget limits, provider errors, AI failures.
The next version should not be more visually intense. It should feel more inevitable: fewer effects, clearer hierarchy, same unmistakable machine.
What This Shows
This design case is about taste under implementation pressure.
I did not just choose a palette. I shaped a visual system across themes, graph geometry, loading states, component behavior, landing experiments, audits, and hardening work. The current SynapseSys aesthetic is unique because it combines retro blocktype confidence with modern product restraint.
The part I want a reviewer to remember: taste is not a screenshot. Taste is a sequence of choices that keeps the screenshot useful after the product becomes real.