Datamotive visual proof
-
-
-
-
-
Datamotive token sheet
What this case proves
What was true at the start.
Three products, three brand voices, three colour systems. EasyMigrate, EasyHybridDR, and EasyProtect had grown visually in isolation. A cloud architect reviewing the materials could not tell whether Datamotive was one company or three. The brand was technically present; the system holding it together was not.
My point of view going in.
Foundations before components. Components are the wrong first step when you do not yet know what a component should contain.
Three products, three brand voices, three colour systems. No shared foundation. EasyMigrate, EasyHybridDR, and EasyProtect had each grown visually in isolation. The website displayed different type weights on adjacent pages. Marketing decks used incompatible grid systems. Social assets from different quarters were unrecognisable as the same company. Technical diagrams (a critical trust signal for enterprise buyers evaluating DR infrastructure) had inconsistent line weights, arbitrary colour usage, and no standard for how data flow was indicated. A cloud architect reviewing the materials could not tell whether Datamotive was one company or a product family from three different vendors. The brand was technically present; the system holding it together was not.
The engagement was a full-time role, not a focused project. Every week brought active design work: product UI, sales decks, campaign assets, social content, and the occasional emergency request. The design system was being built in parallel with everything else, not before it, not instead of it. There was no dedicated frontend engineer. There was no design system budget. There was a shared belief that a unified system would compound the quality of every subsequent deliverable, which made the initial investment tractable without changing the workload.
The starting point was not components. Components are the wrong first step when you don’t yet know what a component should contain. The starting point was decisions: what is the brand’s primary colour, and what are its semantic roles? What is the type scale, and what does each step mean? What spacing values are permitted, and at what grid intervals?
Encoding those decisions as CSS custom properties (the token layer) before touching a single UI element meant every subsequent build decision had a reference. When building a card component, the question “what shadow should this have?” became “which elevation token applies here?” instead of a judgment call repeated twenty times with twenty slightly different answers.
Figma variables mapped to CSS custom properties at parity: $color.brand.primary in Figma became --accent in code. $spacing.lg became --spacing-lg. The design tool and the production environment shared a single vocabulary. When a token changed in Figma, the intent was immediately legible in the CSS. No translation, no interpretation, no drift.
The React component library consumed the token system directly. Components accepted no raw colour or spacing values as props: they consumed tokens or semantic variants. This made the library extensible to new product identities without touching component code: a new product line needed new token values, not new components.
The no-handoff model removed the gap between design intent and implementation. When the same person designs and builds, the implicit reasoning behind a visual decision survives into the code. There are no misinterpretations of spacing intent, no loss of typographic reasoning, no erosion of hierarchy through the translation layer.
A token-based brand system with sixteen documented foundations: logo usage, colour tokens, type scale, spatial system, grid, border radius, shadow elevation, card anatomy, button variants, icon conventions, badge system, data visualisation, technical diagram standards, accessibility requirements, responsive behaviour, and developer handoff guidelines. Three product identities (EasyMigrate, EasyHybridDR, EasyProtect) sharing one token set with distinct primary palette variations. A technical diagram standard that brought consistency to migration, replication, failover, and recovery flows across all product documentation. A production website for datamotive.io built with React.js, Tailwind CSS, and Server Components, deployed on Vercel with Sanity as CMS, codebase refined with Codex and Antigravity IDE. A TCO calculator that computes cross-cloud DR costs, built as a lead converter on the website. All of this while maintaining the normal weekly output of a full-time visual design role across all digital and print.
Datamotive: enterprise cloud migration and DR. Agentless, multi-cloud, 10-minute recovery SLA. Three product lines (EasyMigrate, EasyHybridDR, EasyProtect) had grown in fragments: separate colours, separate voices, separate UI. To enterprise buyers, it read as three companies.
Founder’s direction: evolve, don’t redesign. The hexagon, cube, and teal had meaning and recognition. Strengthen the foundation. Preserve the meaning.
The challenge: build a system rigorous enough that three product teams could ship in parallel while I was still handling every other task as a full-time visual designer.
Competitive research (three days, via Claude): cloud migration and DR tools default to dark mode, neon accents, and abstract circuitry. The category reads as “startup” or “legacy enterprise,” with little in between.
The opportunity: a warm, confident register. Mature without old. Trustworthy without boring.
A 15-area brand audit mapped what needed formalising: logo rules, colour tokens, type scale, grid, component anatomy, diagram conventions, proof modules, dev handoff. The core (hexagon, cube, teal, “eliminating cloud boundaries”) was strong. The system around it was missing.
Four enterprise buyers, four mindsets:
- CIO / CTO: Business continuity. Predictable recovery, executive confidence. Doubts vague claims.
- Cloud Architect: Migration design, failover. Technical diagrams, precise language. Loses trust when marketing oversimplifies.
- IT Infrastructure Manager: Uptime and DR readiness. Reads operational credibility into design consistency.
- System Integration Partner: Easy-to-explain value, partner-friendly materials. Can’t sell a fragmented brand.
Same brand. Four profiles. One coherent voice, and a system that holds across all of them.
The system is called Architectural Fluidity.
The principle: stacked sheets of matte architectural glass. Section separation comes from tonal shifts, spacing, and hierarchy, not heavy borders. The metaphor gave the team a shared language. When someone asked “should this feel heavy here?” the answer was in the principle.
Positioning: Datamotive reduces operational risk across migration, DR, and infrastructure modernisation. The promise distils to three words: Reliable recovery. Clear communication. Enterprise confidence.
Personality, locked at six: Clear. Reliable. Technical. Calm. Enterprise-grade. Foundation-first. Six words that rule out more decisions than they mandate.
The system-level bet: one brand, four tunable parameters: primary colour, tone weight, information density, diagram register. Every product shares grid, type, and layout. The emotional register flexes. Extensible to a fifth or sixth product without starting over. That’s what sold leadership on the approach.
Audit & benchmarking (Claude): 15 brand areas: logo, identity, palette, type, buttons, cards, grid, sections, product pages, icons, diagrams, trust signals, CTAs, tone, docs. Benchmarked against mature SaaS. Highest urgency: logo rules, colour tokens, type scale, grid, diagram standards, proof modules.
Brand language (Claude + human): Before/after messaging table across six scenarios: migration, DR, infrastructure, security, business value, CTAs. Rule: feature-first → outcome-first; hype → proof-led confidence. “Zero downtime guaranteed” retired. “Build reliable failover readiness for moments when recovery matters” in. CTA library settled at eight phrases, calibrated to buyer stage.
Visual exploration (ChatGPT + Gemini): Direction boards in parallel. 120 generated, 12 curated, 3 selected, one per product.
Design system (Google Stitch + Figma): Stitch scaffolded UI from natural-language prompts; Figma locked the system. Token-first: colours, type, spacing, shadows before components. 16 foundations documented: logo, tokens, type, spacing, grid, radius, shadows, cards, buttons, icons, badges, data viz, diagrams, accessibility, responsive, handoff. Token library = single source of truth for logo, type, palette, React components.
Technical diagrams: Simple nodes, teal flow lines, navy labels. Consistent line weights and directional logic for migration, replication, failover, recovery. Animated dashes only on active data-flow states.
TECHNICAL DIAGRAM · DR FLOW STANDARD
Production assets (Adobe CS): Logo refinement, collateral, imagery, motion. Illustrator, Photoshop, After Effects. Hexagon meaning (structure, stability, connection, precision) and cube meaning (infrastructure, workloads, recoverable environments) documented so future designers extend the motif without drift.
Production frontend (React.js + Tailwind + Vercel + Sanity): Built from scratch with React Server Components. Vercel preview deploys per change. Six-stage workflow: design → local dev (VS Code) → Claude Code refine → Git → preview → merge. Codex and Antigravity IDE used for code review and quality improvement. Claude Code handled scaffolds, refactors, and token consistency checks. It compressed the translation layer, not the judgment. Sanity powers the CMS layer. A TCO calculator for cross-cloud DR cost comparison was built as a lead converter on the site.
Pipeline orchestration (Claude + ChatGPT + Gemini): Multi-modal AI handled brief-to-code-export support. The system kept cross-functional output brand-consistent while I stayed responsible for the broader full-time design workload.
From audit to production: six stages, one output.
15-area brand audit via Claude. Benchmarked against mature SaaS. Identified 8 priority gaps.
Messaging architecture across 6 scenarios. Feature-first → outcome-first. 8-phrase CTA library locked.
120 generated across ChatGPT + Gemini. 12 curated. 3 selected, one per product identity.
Stitch scaffolded, Figma locked. 16 foundations documented. Token library = single source of truth.
Technical diagram standards across migration, DR, failover, and recovery flows. Adobe CS for logo, collateral, motion.
React.js + Tailwind + Vercel. Claude Code for scaffolds and token consistency checks. Six-stage git workflow to production.
Front-load voice. The visual system came quickly. Architectural Fluidity gave the team a shared model on day one, and token-first made the visual consistency compounding and fast. The brand language took three full iterations to get right. “Reliable recovery” versus “eliminate downtime risk” sounds like copywriting; it’s actually positioning, and the difference mattered to the four buyer profiles. If I were starting again, I’d run the messaging architecture in week one, before a single visual decision was made, with the same structured rigour I applied to the token layer. Language is harder to encode than colour. It’s also the part enterprise buyers read most carefully.
"The pipeline isn't a shortcut. It's a different kind of rigour."
| METRIC | RESULT | NOTE |
|---|---|---|
| External cost avoided (est.) | ~₹3,00,000 | Brand system and production frontend delivered in-house |
| Product brand identities | 3 | EasyMigrate, EasyHybridDR, EasyProtect under one token set |
| Brand-consistent UI | Token system | Shared foundations for cross-functional teams |
| Parallel delivery | Full-time role | Built alongside full-time visual design responsibilities |
If I were starting again, I'd front-load voice and tone. The visuals came quickly. Architectural Fluidity gave the team a shared model immediately. The brand language took three iterations. Language is harder to generate than colour. It's also the part enterprise buyers actually read.