Macro, Product and System Design
Building a scalable product interface and design system for an AI-powered marketing platform — from blank canvas to a structured, componentised product.
Role
Design, & System Architecture
Type
Product Systems
Year
2025
Context
Macro started as a simple idea. The founder wanted to build an all-in-one marketing platform where brands could run ad campaigns, manage outreach, automate sequences, and leverage AI to improve performance.
The vision was ambitious — the product would eventually support Meta and Google ad campaigns, email and WhatsApp outreach, automation workflows, AI-assisted reporting, and competitor intelligence.
But when the project started, none of that existed yet. There was only a basic MVP concept and a small working Meta ads module. My role was to translate that vision into a real product experience and build a system that could scale as new modules were added.
The Challenge
The biggest challenge was that we were essentially designing the product from scratch. There was no existing design language, no component system, and no defined interface patterns.
At the same time, the product was expected to grow quickly. New modules — outreach, automation, reporting, AI capabilities — were already planned. Without a structured system, the interface would quickly become inconsistent and impossible to scale.
Core problems to solve
- No design language, tokens, or component library to build from
- Multiple complex modules planned with no unified interface pattern
- Product expected to scale fast — individual screen design would not hold
- Developers needed a predictable, implementable system alongside design
- Both light and dark modes required from the start
Approach
The process started with product design — not the system. I worked closely with the founder to translate the core idea into user flows, information architecture, and initial interface structures. Once the MVP screens were taking shape, we began extracting the underlying system behind those screens.
We studied several modern design approaches including ShadCN components, Tailwind-based systems, and other scalable UI libraries. The goal was not to copy a library, but to understand how scalable systems are structured and why they work.
From there, we began defining tokens, primitives, and components that would power the interface at every level.
System Architecture
The design system was structured in four distinct layers — each building on the one below it. This hierarchy meant new features could be added without touching the foundation.
Layer 01
Design Tokens & Variables
The foundation of the system. Defined colors, spacing, typography, radius values, and interaction states using Figma variables — enabling both light and dark modes to switch consistently across every component.
Layer 02
Base UI Elements
Built directly on top of tokens. Each primitive is a single-purpose, non-decomposable element that inherits all token values and responds correctly to theme switching.
Layer 03
Composed UI Patterns
Larger interface patterns assembled from primitives. Because they inherit from the same token base, any token-level change propagates consistently through every component automatically.
Layer 04
Feature Modules
Full product screens and feature flows assembled from components. New modules can be built quickly because the building blocks already exist, reducing design and dev time significantly for each new feature.
Key Decisions
Several decisions made during the build shaped how scalable and maintainable the system became over time.
System First, Screens Second
Instead of designing screens individually, we extracted the system from early screens. This ensured every design decision had a reusable component equivalent from day one.
Dual Mode from Day One
Light and dark modes were built into the token layer from the start using Figma variables — not retrofitted later. This kept both themes consistent and prevented technical debt.
Developer Alignment
The token and component structure was designed to mirror a Tailwind-based implementation. This reduced the gap between design and development, making handoff faster and more predictable.
Outcome
4-Layer System
Tokens → Primitives → Components → Product modules — a fully layered design architecture
Light + Dark
Both theme modes built into the token layer from the start — no retrofitting required
Faster Builds
The design system quickly became the foundation of the product. Instead of designing screens individually, new features could be built using existing primitives and components — improving design speed and reducing UI inconsistency.
For developers, the structured tokens and components made implementation more predictable and easier to maintain. Most importantly, the system allowed the product to grow without the interface becoming fragmented.
Get In Touch
Let's Build Something Useful
If you’re building a product and want to move faster, let’s talk.