César Rengifo — Design Blog

The new era of designers: AI and a future full of promise

Sat, 20 Jun 2026 00:00:00 GMT

I recently sat down with a cross-functional team at a bank—designers, researchers, engineers, business, and communication people alike—to talk about the thing I keep coming back to: the intersection of design and technology, and how AI is quietly rewiring what a designer can be. We didn’t spend the time talking about generating images—we talked about a new era where designers shape every step of the business, from the first idea on a napkin to the product in the end user’s hands.

That’s the shift worth paying attention to. The most exciting part of this moment isn’t the tools. It’s what they unlock in people.

It was never about generating images

When most teams hear “AI for designers,” they picture a prompt box that spits out a hero image. That’s the least interesting thing happening right now.

The real shift is the collapse of the wall between thinking and building. The designer who once sketched a flow and waited can now ship it: prototype the interaction in real code, write the spec that defends it, stand up the API that powers it, and hand engineering something that already runs. The discipline boundaries—research, design, product, front-end—stop being handoffs and start being a single mind moving fast. This is the multidisciplinary designer AI finally makes possible: one person carrying an idea from a half-formed brainstorm to a working, shippable artifact without losing intent at a single seam. Tools like Claude Code, Codex, Figma Make, and Cursor aren’t shortcuts—they erase the gap between what you can imagine and what you can build, and they hand that power to whoever is willing to think clearly and reach across the lines.

This is the same filter I apply across all my AI-assisted design workflows: AI is a multiplier when it executes a clear intent, and noise when it’s asked to invent the intent for you. The designers winning with these tools are the ones who already know how to think clearly about a problem.

A new era for designers: the boundaries are gone

The walls that used to define “design work” have quietly come down. What a designer can do today stretches far past aesthetics—into software engineering, sales, marketing, customer experience, animation, film, print, and industrial design.

We’re no longer just the people who make things look good. We’re the people who can take an idea from a sketch to a fully functional product and get it into someone’s hands. When the cost of producing a working artifact drops, the constraint stops being “can I build this?” and becomes “do I understand the problem well enough to build the right thing?”—which is exactly the question designers were trained to answer. This is the throughline I traced in why the future belongs to designers who build: the practitioners who can move between disciplines are the ones compounding their impact.

How does a designer impact every step of the business?

Here’s the part that lands hardest in a room full of designers: with AI in the loop, a single designer can meaningfully touch the entire arc of a product, not just the middle of it.

Brainstorm and discovery. Use an LLM as a thinking partner to pressure-test the brief, surface contradictions, and generate framing options to react against—before opening a design tool.
Requirements and specs. Turn a conversation into a clear, testable spec that product and engineering can actually align on, instead of a deck that gets reinterpreted three ways.
Build. Scaffold real components and prototypes with Claude Code or Cursor, so the handoff is a head start rather than a translation exercise.
Go-to-market. Draft the landing page, the launch copy, the sales narrative—keeping the product’s voice consistent from the UI to the pitch.
Customer experience and delivery. Shape onboarding, microcopy, and support flows so the last mile feels as considered as the first screen.

Every room gets a boost, from the first look to the very last step. That’s not a designer doing five jobs badly—it’s a designer applying one consistent way of thinking across the whole chain, with AI absorbing the production tax that used to make it impossible. Doing this at scale across a team is its own discipline, which I dig into in design systems for agentic workflows.

Design thinking is the throughline

None of this works because the tools are magic. It works because design has always been a way of thinking—about people, constraints, tradeoffs, and outcomes—and AI turns that way of thinking into something you can execute at the speed of conversation.

That’s why designers, specifically, are well-positioned for this era. The skill that transfers across every step of the business isn’t pixel-pushing; it’s the ability to hold the user, the goal, and the constraints in mind at once and decide what matters. AI gives that judgment reach. It doesn’t replace the judgment—it amplifies it.

Remote and async become an advantage

There’s a quieter benefit hiding in all of this. When thinking is documented, specs are explicit, and prototypes are real, distributed work stops feeling like a compromise.

A well-written spec is asynchronous by nature. A working prototype answers questions a meeting would have raised. The same AI workflows that expand a designer’s range also make remote, async, and hybrid teams genuinely more effective—because they force the clarity that co-located teams often skip. The new era of designers and the new era of distributed work are the same story.

Key Takeaways

AI’s real value for designers isn’t image generation—it’s richer brainstorms, sharper meetings, and better-documented requirements.
The boundaries around “design work” are gone; a designer can now shape every step of the business, from first idea to delivery.
Tools like Claude Code, Codex, Figma Make, and Cursor remove the production tax, so the remaining constraint is clarity of thought.
Design has always been a way of thinking; AI turns that thinking into a superpower you can execute.
The clarity these workflows demand makes remote and async work an advantage, not a tradeoff.

The new era of designers is already here—and the future, for anyone willing to think across the whole business, is genuinely promising. We’re just getting started.

Want this conversation in your room? I speak with teams and at events about everything at the intersection of design and technology—from AI-assisted workflows to what design leadership looks like in this new era. If that’s a fit for your team or stage, let’s set up a speaking session.

CLAUDE.md for designers: turn Claude Code into a design partner

Wed, 13 May 2026 00:00:00 GMT

Most product designers using Claude Code spend the first ten minutes of every session re-explaining the same things: who the product is for, which components already exist, what the brand actually sounds like, and which patterns are explicitly off-limits. That repetition is not just expensive in tokens—it is the reason AI output keeps drifting toward generic SaaS templates instead of the product you are actually trying to ship. The fix is a CLAUDE.md template for product designers: a small, structured file that turns Claude Code from a clever autocomplete into a design partner that loads your taste, your rules, and your anti-patterns before the first prompt is ever typed. This post walks through the exact blocks that file needs and gives you the complete template to copy—no downloads, no repository to clone, everything you need is below.

What CLAUDE.md actually is, and why designers should care

CLAUDE.md is the persistent context file Claude Code reads at the start of every session. It sits at the root of your project, gets loaded automatically, and stays in scope for the entire conversation. Think of it as the agent’s onboarding doc—except instead of being read once and forgotten, it gets re-read every time the agent boots. The equivalent in other tools is AGENTS.md for Cursor and Codex; the file name varies, the function is identical: structured, opinionated context that the agent does not have to be reminded of.

For engineers, the pattern is familiar. CLAUDE.md files in the wild are dense with build commands, deploy hooks, test runners, and folder conventions. That works for engineering because the work product is mostly verifiable code. Product design is different. The signal is taste, hierarchy, interaction quality, content tone, and judgment about when to break a pattern. None of that lives in a package.json. If you want AI to ship work that looks designed, you have to encode the design layer in the same place engineering encodes its layer—and most designers have not done that yet.

This is the same lens I covered in AI agent infrastructure beyond prompt engineering: individual prompts are the smallest unit of leverage. The infrastructure around the prompt—skills, scripts, persistent memory—is where the compounding returns live. CLAUDE.md is the persistent-memory slot for design judgment.

Why most CLAUDE.md files fail product design work

Walk into any AI-first codebase and you will find a CLAUDE.md. Read it carefully and you will notice what is missing: visual hierarchy, density rules, layout intent, content voice, accessibility floors, brand-safe color usage, and the specific patterns this product avoids on purpose. The file was written by engineers, for engineers. It produces code that lints, tests, and deploys—and looks like every other AI-generated SaaS app on the internet.

That visual sameness is not a model problem. It is a context problem. When an agent is asked to “build a settings screen” without design context, it pattern-matches against the most common shape of a settings screen in its training data: card, header, toggles, save bar. The output is technically correct and visually anonymous. The only way to push it toward your product is to give it the design decisions up front—what density, what typography scale, what the empty state looks like, which interaction patterns you have explicitly rejected, and what “good” actually means for this surface.

The failure mode I see most often is designers treating CLAUDE.md as optional documentation. It is not documentation. It is the operating contract between you and the agent. If you do not write it, the agent writes one for itself based on whatever it has seen most. That default is almost never what your product needs.

CLAUDE.md is not documentation. It is the operating contract between you and the agent — and if you do not write it, the agent writes one for itself.

What does a designer’s CLAUDE.md actually need to contain?

Seven blocks. Each one maps to a specific failure mode in AI-assisted design output. The template below includes all of them; the work is filling them in with answers that are true for your product, not generic ones.

1. Project context. Product type, audience, primary user tasks, and the non-negotiable principles that shape every decision. This is the section that tells the agent what kind of product it is working on. “B2B SaaS for finance teams—density matters, data legibility is non-negotiable, marketing-style hero patterns are wrong here” is infinitely more useful than “a web app.” The first 30 lines of the file shape behavior the most; do not waste them on platitudes.

2. Hard rules. Things the agent must never do. “Never use arbitrary Tailwind values—always reference theme tokens.” “Never add a hover state without a focus-visible equivalent.” “Never invent a new component when an existing one can be composed.” Hard rules are the floor. They prevent the worst categories of drift without requiring you to police every interaction.

3. Preferences. Things the agent should default to when there is no explicit instruction. Spacing scale, type ramp, motion easing, copy voice, error tone, empty-state pattern. Preferences are softer than rules—they bend when context demands it—but they keep output inside your visual grammar by default.

4. Anti-patterns. This is the block most designers forget, and it is the one with the highest leverage. AI defaults toward the most common visual idioms in its training data: card-heavy dashboards, gradient hero sections, three-column feature grids, “modern SaaS” type scales. If your product is dense, technical, or deliberately uncomfortable, you have to name those defaults and rule them out explicitly. “We do not use card-based dashboards.” “We do not use hero gradients.” “Do not propose marketing-style layouts inside the product.” The agent will not infer your refusals from your principles—you have to write them down.

5. Success criteria. Outcome-oriented checks the agent applies before declaring work done. Accessibility floor (WCAG AA), responsive behavior, keyboard navigation, content variability (long copy, missing data, error states), and any product-specific gates. Success criteria turn the agent from “generated something plausible” into “verified it meets the bar.”

6. Interactive intake. A short, scripted onboarding the agent runs when you start a project where context is missing. This is what makes the template usable on day one of a new repo: the agent asks five to ten targeted questions—product, audience, stack, primary surfaces, design system status—and writes the answers into CLAUDE.md and supporting docs. No more staring at a blank file wondering what to put in it.

7. Routing to deeper docs. A pointer table that tells the agent where to look when it needs more detail. docs/design-system.md for tokens, components, and spacing. docs/ux-principles.md for flow, hierarchy, and progressive disclosure rules. docs/intake-workflow.md for the interactive setup itself. The root file stays short; the depth lives in the docs.

These seven blocks are the spine of the file. Everything else—the supporting docs and any scoped per-surface files—exists to keep the root prompt focused while still giving the agent a path to deeper context when a task warrants it.

The complete CLAUDE.md template, ready to copy

Here is the full file. Copy it into a CLAUDE.md at the root of your project, then replace every bracketed placeholder with answers that are true for your product. The comments explain what each block is for; you can delete them once you have filled in your own content. This is the whole template—nothing is hosted elsewhere.

# CLAUDE.md — Design operating contract

> This file is loaded at the start of every Claude Code session. It encodes the
> design judgment for this product so the agent ships work that looks designed,
> not generic. Keep it under ~200 lines; push depth into docs/ (see Routing).

## 1. Project context

- **Product:** [e.g. B2B observability platform for SRE teams]
- **Audience:** [who uses it, their context, their constraints]
- **Primary user tasks:** [the 3–5 jobs the product exists to do]
- **Non-negotiable principles:**
  1. [e.g. Density and data legibility win over visual polish]
  2. [e.g. Every surface must be keyboard-navigable]
  3. [e.g. Content is the interface; chrome stays out of the way]

## 2. Hard rules — never do these

- Never use arbitrary Tailwind values; always reference theme tokens.
- Never add a hover state without a focus-visible equivalent.
- Never invent a new component when an existing one can be composed.
- Never ship copy that leads with an apology; lead with the action.
- [Add your own non-negotiables here.]

## 3. Preferences — defaults when no instruction is given

- **Spacing:** [your scale, e.g. 4px base, 8/12/16/24/32 steps]
- **Type ramp:** [your scale and intended hierarchy]
- **Motion:** [easing + duration defaults, when to animate]
- **Copy voice:** [tone, person, sentence length, error tone]
- **Empty / loading / error states:** [the default pattern for each]

## 4. Anti-patterns — explicitly rejected defaults

> The highest-leverage block. Name the generic idioms the model reaches for so
> it stops proposing them.

- We do not use card-based dashboards.
- We do not use hero gradients or marketing-style layouts inside the product.
- We do not use three-column feature grids.
- [Add the drift categories you keep rejecting in review.]

## 5. Success criteria — checks before work is "done"

- Meets WCAG AA contrast and has visible focus states.
- Works at all breakpoints; no horizontal scroll on mobile.
- Handles content variability: long copy, missing data, error states.
- Keyboard-navigable end to end.
- [Add product-specific gates here.]

## 6. Interactive intake — run when context is missing

When starting a project where this file is incomplete, ask 5–10 targeted
questions (product, audience, stack, primary surfaces, design-system status),
then write the answers back into this file and the docs/ files below. Confirm
the plan with me before generating any code or content.

## 7. Routing to deeper docs

| Need                              | Read this file            |
| --------------------------------- | ------------------------- |
| Tokens, components, density       | docs/design-system.md     |
| Flow, hierarchy, disclosure rules | docs/ux-principles.md     |
| The interactive setup script      | docs/intake-workflow.md   |

That single file is enough to change how every session starts. The three docs/ files referenced in the routing table are optional at first—create them when the root file starts to feel crowded.

Progressive disclosure: keeping the root prompt short and the docs deep

The single most common failure I see with CLAUDE.md is bloat. Designers who learn the pattern keep adding to the root file until it is 800 lines of mixed rules, preferences, color values, component APIs, and product trivia. At that size, the agent loses the signal in the noise—and you pay the token cost on every single session.

The fix is progressive disclosure. Keep the root CLAUDE.md under 200 lines. Move depth into supporting documents the agent loads only when relevant.

The routing table in the template points to three:

docs/design-system.md — tokens, components, layout density, states, accessibility patterns. Loaded when the agent is building or modifying UI.
docs/ux-principles.md — flow design, hierarchy, interaction quality, progressive disclosure rules, AI output review checklist. Loaded when the agent is making product decisions, not just rendering them.
docs/intake-workflow.md — the interactive onboarding script. Loaded once per new project.

You create these the same way you created the root file: a markdown heading per topic, your real content underneath. There is nothing to install—they are just plain files the agent reads on demand.

You can also scope CLAUDE.md files by directory. The agent respects the nearest relevant CLAUDE.md, so a /app/CLAUDE.md overrides the root for frontend work, and /app/dashboard/CLAUDE.md overrides both inside the dashboard surface. This is how you encode that the marketing site uses one density and type scale and the analytics dashboard uses another—without forcing every rule into one file.

This is the same operating model behind portable design systems for agentic workflows: structured, scoped, versioned context that survives tool changes and team turnover. Your CLAUDE.md is the design-system layer for the AI agent itself.

Interactive intake: a starter prompt that adapts to your product

The other failure I see is the empty-file problem. Designers copy the blocks, open CLAUDE.md, and stare at the headings. Filling it in feels like writing a brand book from scratch.

Block 6 above solves this with an interactive intake. Once the file is in your project root, start a session with one of two messages:

Use this as an interactive setup prompt. First infer what you can from
this repository, then ask only for missing information that affects the plan.

Or, if there is no repository yet:

Use this as an interactive setup prompt. I want to answer a short guided
intake instead of having you inspect a repository.

The agent then does the work it is best at: reading what it can, asking only about the gaps that change the plan, and producing a draft CLAUDE.md plus a list of files to create or update. You review the plan before any code or content lands. This is the same discipline behind spec-driven development for designers in the age of AI: you specify intent, the agent surfaces gaps, you align before production. CLAUDE.md is just the persistent, project-level version of that contract.

The intake is not a one-time event. As the product matures and patterns drift, you re-run targeted portions of it—“add an anti-patterns block based on the last three reviews where AI output missed the mark”—and the file evolves with the work. The file is alive.

What changes when product designers ship this layer

The behavioral shift is concrete and shows up within the first few sessions.

### Output starts on-brand

The agent's first draft of a screen, component, or content block looks like
your product, not a generic template. Review cycles move from color values
and spacing to hierarchy and storytelling.

### Handoffs get cleaner

Engineering reads the same CLAUDE.md the agent reads. Cross-functional
context becomes a shared file, not a Slack thread. Disagreements about
"what we said the pattern was" disappear because the pattern is in version
control.

### Junior collaboration gets safer

A junior designer or PM can ask the agent for a draft and trust that the
output respects the system. You stop being the bottleneck for "is this
on-brand?" because the system answers most of those questions before the
work reaches you.

### Anti-patterns stop reappearing

Generic dashboards, gradient heroes, marketing patterns inside the product
— the drift categories you used to flag every other review stop landing in
the work because the agent rules them out before generating.

This is the practical version of the principle I argued in AI-assisted design workflows that actually work: AI is a multiplier on intent that is well-specified, and CLAUDE.md is where that intent lives across every session. It is also the enablement model from shipping landing pages with Claude Code and GitHub — distributed contribution inside design-led guardrails.

For founders, the visible effect is speed-to-market without brand fragmentation. For VPs, it is delivery consistency across an AI-assisted team. For designers, it is the realization that the agent can finally be trusted with the parts of the job that used to require constant supervision—and that the time saved goes back into the parts of design that still demand human judgment.

How to adapt this template for your team in one afternoon

You do not need a quarterly initiative to ship this. The full adoption fits in a focused afternoon.

Create the file structure at the root of your project. Add a CLAUDE.md and a docs/ folder with the three supporting files described above. Add scoped CLAUDE.md files inside the surfaces where you want different behavior—copy the shared structure and override only what diverges.
Rewrite the first 30 lines. Replace the generic project overview with your actual product type, audience, primary user tasks, design constraints, and the three or four non-negotiable principles your work is built on. Be specific. “B2B observability for SRE teams; density and data legibility win over visual polish” beats “we build great products.”
Extract hard rules from what you already have. Walk your design system docs, critique notes, and recent PR reviews. Anything you have said more than twice—“never use arbitrary spacing values,” “all components ship with focus states,” “error messages lead with the action, not the apology”—is a hard rule. Pull it into the file verbatim.
Add anti-patterns as drift appears. Do not try to predict every failure mode on day one. After the first week of AI-assisted work, log the categories of output you rejected. Those rejections become the anti-patterns block. The list grows fastest in the first month and stabilizes after that.
Layer scoped CLAUDE.md files where surfaces diverge. Marketing site, product app, internal dashboard, admin tooling—if the design rules are meaningfully different, give each surface its own scoped file. Copy the same seven-block structure into a /app/CLAUDE.md or /app/dashboard/CLAUDE.md and override only what is local; the agent respects the nearest relevant file. The root file holds what is shared; the scoped files hold what diverges. This is the same architecture that keeps real design systems coherent across multiple products.

By the end of an afternoon you will have a CLAUDE.md that is opinionated, project-specific, and ready to load on every session. The compounding starts immediately. The rest is maintenance—prune what stops being true, add what you keep repeating, evolve the file as the product evolves.

You do not need to download anything to start—the template above is the whole thing. Copy it into a CLAUDE.md at your project root, rewrite the placeholders for your product, and ship the AI operating layer your team has been missing.

Key Takeaways

CLAUDE.md is the persistent context Claude Code loads every session—if you do not write the design layer into it, the agent fills the gap with generic defaults from its training data.
A designer’s CLAUDE.md needs seven blocks: project context, hard rules, preferences, anti-patterns, success criteria, interactive intake, and routing to deeper docs.
Anti-patterns are the highest-leverage section and the one most designers skip—name the visual defaults you reject explicitly so the agent stops proposing them.
Use progressive disclosure: keep the root file under 200 lines and push depth into docs/ and scoped per-directory CLAUDE.md files for product, marketing, and internal surfaces.
Add an interactive intake prompt to the template to turn the empty-file problem into a guided onboarding the agent runs against your repository.

Design systems for agentic workflows: how teams scale output

Tue, 05 May 2026 00:00:00 GMT

Design systems for agentic workflows change what a design team can scale. In most companies, design still becomes a bottleneck when the organization needs more visual output: pitch decks for fundraising, visual stories for LinkedIn, campaign graphics, product launch assets, and internal explainers. The demand is cross-functional, but the production model stays centralized. The result is predictable: great work, slow throughput, and too much waiting.

The shift I am testing now is simple to describe and hard to implement well: build portable design systems that let more people create first drafts safely, then let designers step in for the final polish. The value is not that everyone becomes a designer. The value is that everyone can start on-brand, with the right structure, and with quality rails that reduce rework. That moves design leadership from gatekeeping to enablement.

This is the core lesson from building three systems optimized for LLM workflows across different contexts.

The leadership bottleneck is not creativity, it is access

Most teams are not blocked by lack of ideas. They are blocked by access to design capacity. Marketing has campaign ideas but waits for layout bandwidth. Product has launch announcements but waits for branded visual support. Sales needs presentation updates but waits for a designer to recompose every slide manually.

When a Head of Design sees this pattern, the strategic question changes from “How can I design more?” to “How can I enable more people to create responsibly?” Agentic workflows make that question urgent, because teams already use LLM tools to draft content and code. If the visual system is not ready for that behavior, output quality drifts fast.

The cost of doing nothing is not only slower delivery. It is brand fragmentation: different teams inventing their own color usage, spacing habits, icon choices, and presentation language because there is no portable system guiding the first draft.

How can a head of design enable everyone without losing quality?

The answer is to separate who starts from who ships.

Many people can start.
Design still sets the constraints.
Design still owns final quality and polish.

That split gives teams speed without sacrificing craft. People outside design can generate assets, slide structures, post visuals, and first-pass compositions. They do it inside a system that already encodes brand logic and usage rules. Designers then spend time where they create the most value: composition refinement, hierarchy, storytelling, and final consistency.

This is the same leadership move engineering made years ago with reusable components, CI guardrails, and code review. You do not block contribution; you shape contribution. A design system optimized for agentic workflows applies the same principle to visual production.

What I built: three systems for different levels of reuse

I have been developing three systems in parallel to test how much breadth is useful and where specialization wins.

1) A broad brand system for presentations and brand assets

This system is intentionally wide. It supports presentations, campaign visuals, social graphics, and general collateral. It includes brand primitives, composition patterns, typography guidance, icon rules, and asset templates that can be interpreted by LLM-assisted tools.

The goal is not pixel-perfect uniformity across every asset. The goal is recognizable brand coherence at team speed. When a PM, marketer, or founder drafts a visual, the output starts in the right direction instead of starting from a blank canvas.

2) A specialized system for developer tools and internal products

The second system is narrower and deeper. It is fed by current product tooling decisions: color surfaces, intent states, typography stacks, icon mapping, and reusable UI components. This makes it easier to replicate patterns into internal tools or new product surfaces without rebuilding the visual language each time.

This is where the bridge between design and engineering becomes concrete. The system is not only “a design file.” It becomes a shared contract that supports implementation decisions and reduces visual drift between product and internal software.

If you want a deeper technical view of how this connection works in practice, Figma MCP plus AI token workflows and semantic token architecture for Peridio and Avocado OS break down that side of the stack.

3) A white-label-ready system for multi-team adaptation

The third system is designed for theme swapping and team-level customization. White-label support changes the architecture requirements from day one: semantics over hardcoded values, clear theming layers, and predictable override points.

This matters beyond client customization. Even inside one company, different teams need controlled variation for context, audience, or product line. A white-label-capable system gives you flexibility without fragmentation.

Why portability is now a strategic requirement

The AI tooling landscape changes every quarter. If your system is trapped inside one proprietary workflow, you inherit migration risk every time your team evaluates a new assistant, model, or generation pipeline.

That is why I moved this work toward a GitHub-native, portable setup with open guidelines. Portability means the system can be interpreted by multiple tools, not only one vendor path. It means your brand logic survives platform shifts.

Google’s release wave around Stitch and open agentic guidance reinforces this direction: systems that include explicit tone, constraints, and usage instructions help LLMs produce better first drafts with fewer hallucinated style choices. The lesson is practical, not theoretical. If the instructions are portable and structured, outputs are more consistent across tools.

For teams already using AI to ship faster across code and marketing surfaces, this is the same operating model I described in AI-assisted design workflows and shipping AI-assisted landing pages with Claude Code and GitHub: put decisions in versioned systems, not in individual memory. The agent-facing version of that idea is the CLAUDE.md template for product designers—a portable, copy-and-paste operating layer that encodes brand rules and anti-patterns so AI output starts inside the system instead of fighting it.

What changed in team behavior after systemizing the draft phase

Before this shift, most visual requests arrived as “Can design help with this?” and started with an empty file. After the systems were in place, requests changed shape. Teams started with “I drafted this using the system, can design review?” That subtle language change signals a major operational change: the first move now happens inside the team that owns the initiative.

This also improved review quality. Designers were no longer reacting to random visual directions from scratch. They were reviewing work that already shared basic grammar: typography logic, spacing rhythm, brand-safe color usage, and layout conventions. Feedback moved from corrective (“This is off-brand”) to additive (“This hierarchy can be stronger,” “This story needs a sharper narrative arc”).

Speed improved, but so did confidence. Non-design partners stopped feeling like they were “doing design wrong” because they had guardrails. Designers stopped feeling like brand quality depended on catching every small mistake manually. The system carried more of that burden by default.

The operating model: many creators, one quality owner

A portable agentic design system works best when responsibilities stay clear:

Head of Design: defines principles, guardrails, approval thresholds, and evolution roadmap.
Cross-functional teams: generate first drafts within the system for their specific needs.
Designers: polish, correct hierarchy, tune narrative quality, and approve final assets.

This model does two things at once. It increases output volume and increases strategic focus for design leaders. Instead of being trapped in endless first-pass production, design can invest in system quality, team coaching, and the high-leverage work that compounds over time.

That is also why I frame this as organizational design, not only visual design. You are designing participation rules for creativity.

Broad system or small tailored systems: what I am testing now

Right now I am in exploration mode on a practical question: should one broad system handle most asset types, or should I run smaller systems tailored for specific jobs such as presentations, blog miniatures, and social graphics?

The tradeoff is clear:

Broad systems improve consistency and reduce setup overhead.
Tailored systems improve precision for a specific output category.

In practice, this may not be a binary decision. A strong pattern is emerging: keep a shared foundational layer (brand, semantics, tone, primitives), then add thin task-specific layers where constraints and output formats differ meaningfully.

That hybrid model keeps portability while respecting workflow realities. It also gives teams a better mental model: one base language, multiple dialects by task.

Why this has urgency in the current AI cycle

The reason to do this now is timing. Teams are already adopting AI creation tools, whether or not design leadership formalizes a system. If no portable design system exists, adoption still happens, but quality drifts in hidden ways: inconsistent visual tone, fragmented templates, and duplicated effort across teams.

When leadership waits too long, recovery gets expensive. You end up unifying many local workflows after they have hardened into habits. Building the system early is cheaper than cleaning up visual sprawl later.

The opportunity is that current tool momentum finally supports this direction. LLMs are good enough to follow explicit constraints when the constraints are clear, portable, and written for machine interpretation. That gives Heads of Design a practical way to extend brand stewardship beyond the design team without lowering standards.

What this changes for design leadership right now

The biggest change is mindset. A Head of Design is no longer only the owner of design output. The role becomes owner of the creative operating system.

When you build portable design systems for agentic workflows:

More people can contribute without compromising brand integrity.
Designers spend less time on repetitive first-pass production.
Teams iterate faster because they can begin work without waiting in a queue.
The organization becomes more resilient to tooling shifts.

Most importantly, design leadership becomes a force multiplier for the whole company. This is not about replacing designers. It is about letting design expertise reach more work, earlier.

If you are shaping this kind of cross-functional design capability in startup environments, the case-study context in the Peridio case study (coming soon) and the operating patterns in prompt engineering for designers can help frame implementation decisions.

Key Takeaways

Design systems for agentic workflows turn design from a production bottleneck into an enablement layer for the whole team.
The most effective model separates contribution from final quality ownership: many people draft, designers polish and approve.
Portable, GitHub-native guidelines reduce tool lock-in and keep brand logic stable across fast-changing AI ecosystems.
A three-layer strategy can work well in practice: broad brand system, specialized product system, and white-label-ready adaptation layer.
Teams that codify this now will compound speed, consistency, and cross-functional creative capacity faster than teams that keep design knowledge trapped in individuals.

Spec-Driven Development for Designers in the Age of AI

Sat, 21 Mar 2026 00:00:00 GMT

Spec-driven development for designers is the practice of writing clear, testable intent before asking AI agents to produce implementation artifacts. In practical terms, it shifts design work from “prompt and hope” to “specify, validate, and ship.” That matters now because the bottleneck in most teams is no longer pure production speed. The bottleneck is alignment across product, engineering, marketing, and leadership under AI-accelerated timelines.

For founders, this means faster decisions with fewer expensive reversals. For VP Product and VP Engineering leaders, it means more predictable delivery quality because behavior and constraints are explicit before work fans out across teams.

Why this matters now for design leaders

AI tools made output cheap. Coordination did not get cheaper.

Most teams can now generate mockups, copy variants, and code scaffolds quickly. But speed without alignment creates a familiar failure mode: more artifacts, more rework, and less confidence. Designers often sit in the middle of this tension. They carry product intent, facilitate engineering handoffs, and support go-to-market storytelling. If that translation layer is weak, AI acceleration amplifies drift.

Spec-driven development helps because it creates a shared frame before production starts. Instead of debating interpretation after implementation, teams align on behavior, edge cases, acceptance checks, and non-goals up front. The output is not just cleaner code or cleaner UI. The output is cleaner cross-functional execution.

This is the same leadership pattern behind how I embed in engineering teams as a design director: reduce ambiguity early so teams can move faster later.

What spec-driven development is (and what it is not)

Spec-driven development is still evolving, and different tools use the term differently. A useful framing comes from Susanne Kaiser in Martin Fowler’s article on SDD tools: Understanding Spec-Driven-Development: Kiro, spec-kit, and Tessl.

One of the most practical ideas from that piece is separating three levels:

Spec-first: write a strong spec before implementation.
Spec-anchored: keep the spec alive as the feature evolves.
Spec-as-source: treat the spec as the primary artifact over code.

For most design-led teams today, the highest-leverage starting point is spec-first, with selective movement toward spec-anchored for critical workflows. Going directly to spec-as-source is usually too rigid unless your team has strong governance and very clear boundaries.

SDD is also not “write longer prompts.” A long prompt can still be ambiguous. A spec, by contrast, has structure: problem framing, scope, constraints, acceptance criteria, failure states, and review checkpoints.

Why designers are uniquely positioned to lead SDD

Designers already translate between intent and execution. SDD formalizes that strength.

When designers own spec quality, they improve four handoff surfaces that usually break under pressure:

Product alignment: clarify the decision to be made, not just the screen to be built.
Engineering alignment: capture states, constraints, and implementation boundaries.
Marketing alignment: define message-critical behavior so launch narratives match shipped reality.
Leadership alignment: make progress legible through explicit milestones and acceptance checks.

This is where SDD becomes a leadership capability, not a documentation task. The designer is not producing paperwork. The designer is reducing entropy across the system.

A practical SDD workflow for design teams using AI

You do not need a heavyweight process to get value. A lightweight five-part spec works in most startup and scale-up environments.

1) Intent and business outcome

Start with one paragraph that answers:

What user or business outcome are we trying to change?
Why now?
What would “good” look like in measurable terms?

Example outcomes can include reduced onboarding drop-off, faster proposal turnaround, or fewer revisions between design and engineering.

2) Scope, constraints, and non-goals

List what is in scope and explicitly what is not. Include delivery constraints such as timeline, platform limits, design system dependencies, accessibility requirements, legal constraints, or data availability.

This section prevents the common AI failure mode where an agent “helpfully” solves a larger problem than requested.

3) Behavioral requirements and edge cases

Define the expected behavior in concrete terms:

Core user paths
Empty, loading, and error states
Content variability (long copy, missing fields, multilingual content)
Responsive behavior
Accessibility expectations

If you use acceptance language (given / when / then), keep it compact and tied to critical behaviors only.

4) Implementation tasks and review gates

Break the work into small tasks that map back to requirements. Add review checkpoints:

Spec review (design + product + engineering)
Implementation review (does behavior match spec?)
Launch review (does communication match shipped behavior?)

This keeps the process iterative, which addresses a key concern raised in Fowler’s SDD tooling analysis: overproducing documents without improving control.

5) Evidence and learning loop

Close the loop after release:

What changed in cycle time, rework, or quality?
Which parts of the spec reduced ambiguity?
Which parts were unnecessary overhead?

Use this to tune your next spec. SDD works best as an evolving team habit, not a static template.

How can designers use SDD without slowing teams down?

Use a “minimum effective spec” rule.

Most teams fail with SDD in one of two ways: they under-specify and get chaotic output, or they over-specify and create review fatigue. The middle path is to scale spec depth to risk.

A practical rubric:

Low-risk changes (small UI updates): short spec, 5-10 bullets, one review pass.
Medium-risk changes (feature expansion): full lightweight template, explicit edge cases, two review checkpoints.
High-risk changes (cross-functional launches): spec-anchored approach, stronger acceptance checks, post-launch retrospective.

If a spec does not reduce decisions during implementation, it is too vague. If it takes longer to review than the work itself, it is too heavy.

Founder lens: where SDD drives startup velocity

Founders are not buying process. They are buying speed with confidence.

SDD helps founders in three concrete ways:

Faster decisions: teams can approve or reject directions earlier because assumptions are explicit.
Less rework: fewer interpretation gaps between design intent and shipped behavior.
Clearer go-to-market execution: sales and marketing assets stay closer to what the product actually does.

When design, engineering, and messaging stay aligned, launches feel less like emergency choreography. This is one reason AI-enabled design systems and workflow specs matter in operating reality, not just in design craft discussions. You can see this cross-functional alignment theme in AI-assisted design workflows: what actually works in 2026.

VP Product and VP Engineering lens: where SDD improves reliability

For VP leaders, the problem is usually not effort. The problem is variance.

Teams can ship quickly while still producing uneven quality because each function is working from slightly different assumptions. SDD reduces that variance by giving everyone a shared behavioral contract.

The practical benefits show up in delivery operations:

Fewer late-stage surprises because edge cases are documented earlier.
Better sprint predictability because tasks map to explicit requirements.
Cleaner QA cycles because acceptance checks are defined before build.
Easier cross-team coordination because dependencies are visible in the spec.

This is also why SDD pairs well with design systems and implementation-aware design leadership. In systems-heavy contexts like the Peridio case study (coming soon), clarity of interfaces and constraints is what keeps product velocity and quality from diverging.

What breaks when teams adopt SDD poorly

Most SDD failures are operating failures, not tooling failures.

1) Documentation theater

Teams produce many files but skip true review. The fix is simple: fewer artifacts, stronger checkpoints.

2) Spec bloat

Every minor change gets enterprise-level process. Scale depth to risk; keep low-risk work lightweight.

3) False confidence

A written spec can create an illusion of control if acceptance checks are weak. Always validate behavior against the spec, not against intent in someone’s head.

4) AI overreach

Agents generate beyond scope when constraints are unclear. Use explicit non-goals and bounded tasks.

5) No feedback loop

Teams never measure whether specs improved outcomes. Track a small set of indicators: rework rate, cycle time, and revision rounds.

A 30-day rollout for designers leading AI workflows

If you want to test SDD without disrupting the team, run a focused 30-day pilot.

Week 1: baseline and template

Pick one feature with medium delivery risk.
Capture baseline metrics: revisions, cycle time, and handoff clarifications.
Create a one-page spec template for your team.

Week 2: first implementation

Run one cross-functional spec review before implementation.
Use AI agents for scaffolding and synthesis, not for unbounded generation.
Keep tasks small and traceable to requirements.

Week 3: tighten and standardize

Remove sections that created noise.
Add clarity where reviewers asked repeated questions.
Document one “definition of done” checklist for design + engineering handoff.

Week 4: evaluate and decide next level

Compare baseline vs pilot outcomes.
Decide what to adopt as default process.
Choose where to stay spec-first and where to move toward spec-anchored workflows.

This approach keeps the discipline pragmatic and protects team momentum.

SDD for designers is a leverage play, not a trend

Spec-driven development is important in the age of AI because execution speed is no longer the hardest problem. Coordinated execution is.

Designers who can turn ambiguous intent into structured, testable, cross-functional specs create leverage across the organization. They help founders move faster with less risk and help VP leaders improve reliability without adding bureaucracy.

If you are already building these bridges in your current process, SDD gives you a stronger operating model for scaling that impact.

For teams working on the design-to-engineering boundary, design engineering workflows and AI-assisted collaboration patterns are a practical next step before expanding process depth. For the persistent, project-level layer that carries spec discipline into every AI session, the CLAUDE.md template for product designers is the operating contract that keeps agents inside your design judgment by default.

Key Takeaways

Spec-driven development for designers turns AI output into aligned execution, not just faster artifact generation.
The most practical starting point is spec-first, with selective spec-anchored adoption for high-risk workflows.
Founder value is speed and confidence; VP value is predictability and reduced delivery variance.
SDD fails when it becomes documentation theater; it works when spec depth matches delivery risk.
A 30-day pilot is enough to validate whether SDD improves rework, cycle time, and cross-functional clarity.

Figma MCP + AI: design tokens from variables to production JSON

Fri, 20 Mar 2026 00:00:00 GMT

Design tokens break down in predictable ways. A designer renames a variable in Figma to fix a naming inconsistency. An engineer references the old CSS custom property because the documentation was never updated. An internal dashboard ships with the wrong surface color because it was built before the last token audit. Three months later, the product looks like three different companies made it.

The problem is not that tokens are a bad idea. The problem is that tokens live in two places—Figma and code—and without an explicit workflow to keep them synchronized, they drift. The solution I use at Peridio and Avocado OS is a JSON-first token system that connects Figma variables to code through Figma MCP, AI-assisted auditing, and Style Dictionary transforms. The result: one source of truth that feeds external products, internal tools, marketing assets, and brand documentation without manual transcription.

For the token architecture itself—how primitives, semantics, and context layers are structured—see Peridio & Avocado OS: semantic tokens and AI-native design systems. This post is the workflow layer underneath that architecture: how you build it, connect it, and keep it honest over time.

Why Figma variables need to mirror the JSON graph exactly

Before connecting anything, Figma variables need to be organized in a way that makes synchronization possible. That means collections that map to JSON layers, not groupings that made visual sense in a past file.

The structure I use:

Primitives — raw values; one collection, all modes (light, dark, high-contrast). No component references at this layer.
Semantic — named roles: surface.canvas.default, text.primary, intent.warning.bg. This collection references primitives by variable alias—never by raw value.
Context / Brand — overrides per brand (Peridio vs. Avocado OS) or per product (console vs. marketing site). This collection references semantics, again by alias.

The naming convention matters: semantic/surface/canvas/default in Figma should map directly to semantic.surface.canvas.default in JSON. Slashes in Figma variable names become dots in JSON keys. If these don’t match, any script that syncs the two needs a translation table—and translation tables accumulate bugs.

Variable types by layer:

Primitives: COLOR, FLOAT, STRING (for font families)
Semantics: COLOR only—semantic spacing and radius consume primitive floats through component properties, not variable aliases, to keep the graph readable
Context: COLOR only—override values only where the brand or product actually diverges

Setting this up correctly upfront is slower than dumping all variables into one collection. Every tool downstream—Figma MCP, Style Dictionary, AI agents—works from the same named graph. When the graph is consistent, machines can operate on it reliably.

How Figma MCP connects AI to your variable library

Figma MCP (Model Context Protocol) exposes the Figma API as a structured interface that AI tools—Claude, Cursor, custom agents—can call directly in a conversation. Instead of a designer manually copying variable values into a spreadsheet to share with an engineer, the AI reads them from Figma in real time, reasons about them, and either proposes changes or writes them back.

A typical audit session starts with: “Read all semantic color tokens and check whether each text/background pair meets WCAG AA for normal-size body copy.” The MCP client calls the Figma API, retrieves the variables, resolves aliases to raw hex values, runs the contrast check, and returns a list of failing pairs with suggested primitive adjustments. The designer reviews and approves; the approved changes can be written back to Figma via MCP in the same session.

This is different from plugins that run inside Figma. MCP runs in the AI conversation context—you can chain it with other tools (linting the JSON file, checking against code, generating a migration note) without context-switching between apps.

Common MCP operations for token work:

Read variable state — pull all variables and their current values before starting any token refactor to create a baseline snapshot
Detect alias chains — identify variables that reference other variables more than two layers deep; deep chains are fragile and should be flagged for simplification
Check naming consistency — compare Figma variable names against the JSON key structure; surface mismatches that would cause sync errors
Write bulk updates — after approving a proposed ramp change, write updated primitives to Figma without manual entry

The key constraint: MCP operations on Figma are most reliable on named, well-organized variable libraries. A chaotic file with orphaned styles and inconsistent naming produces unreliable reads. The organizational discipline in the previous section is what makes MCP trustworthy.

Building and maintaining the JSON source of truth

The JSON file is the canonical record of every token decision. Figma is where designers iterate; JSON is where the decisions land. The flow is:

Figma variables → JSON (canonical) → Style Dictionary → CSS / Tailwind / iOS / Android

Running a sync script—or asking an AI agent via MCP to produce a diff—yields a JSON file that matches the current Figma variable state. Here is the minimal shape for the semantic layer, extending the full schema in the architecture post:

{
  "semantic": {
    "surface": {
      "canvas": {
        "default": { "value": "{primitive.color.neutral.0}", "type": "color" },
        "muted":   { "value": "{primitive.color.neutral.50}", "type": "color" }
      }
    },
    "text": {
      "primary":   { "value": "{primitive.color.neutral.950}", "type": "color" },
      "secondary": { "value": "{primitive.color.neutral.600}", "type": "color" },
      "link":      { "value": "{primitive.color.brand.600}",  "type": "color" }
    }
  }
}

Each value is an alias reference, not a raw hex—so when a primitive changes, all semantics that reference it update through Style Dictionary without a manual find-and-replace.

Governance rules for the JSON file:

The file lives in the same repository as the component library, reviewed through the same PR process as code
Changelog entries are required for any semantic rename or primitive ramp change
Old alias names are deprecated in deprecated.json for one minor version before removal—never deleted silently

How Style Dictionary transforms reach every platform

Style Dictionary is the transform layer that converts JSON aliases into platform-specific outputs. One configuration maps the JSON structure to multiple build targets:

// style-dictionary.config.js (simplified)
module.exports = {
  source: ["tokens/**/*.json"],
  platforms: {
    css: {
      transformGroup: "css",
      buildPath: "build/css/",
      files: [{ destination: "tokens.css", format: "css/variables" }]
    },
    tailwind: {
      transformGroup: "js",
      buildPath: "build/js/",
      files: [{ destination: "tailwind-tokens.js", format: "javascript/es6" }]
    },
    ios: {
      transformGroup: "ios-swift",
      buildPath: "build/ios/",
      files: [{ destination: "StyleTokens.swift", format: "ios-swift/class.swift" }]
    }
  }
};

Running style-dictionary build produces CSS custom properties for the web component library, a Tailwind config extension for the marketing site, and Swift constants for native iOS work—all from the same JSON. When a token value changes, one PR updates the JSON, CI runs Style Dictionary, and all platform outputs regenerate in the same commit.

This is what “reusable across the board” means in practice. The JSON does not need to be manually translated for each surface. The transform is automated; human judgment is reserved for token design decisions, not copy-paste maintenance.

Reaching every surface: internal tools, external products, brand assets

A semantic token system scales across surfaces precisely because semantics describe purpose, not appearance. When surface.canvas.default and text.primary are consumed by a Figma component library, a React component library, and a static marketing site, they can share identical visual output or diverge intentionally through context overrides—without forking the component source.

Internal tools are often the first surface to drift. Because they are never customer-facing, they skip design review and accumulate hardcoded colors and one-off styles. The solution is friction reduction: when the shared component library pulls from the same token layer and is easy to import, using the design system becomes the path of least resistance. Internal tools built on the shared library inherit every token update automatically.

External products (the customer-facing UI at Peridio, the Avocado OS console) consume tokens through the component library. Brand context overrides let Peridio and Avocado OS use distinct accent colors and photography treatment while sharing every surface, intent, and spacing token. The two products look related, not identical—which is correct for a platform company where both share infrastructure but serve different narratives.

Marketing sites use the Tailwind token extension. The clamp()-based fluid spacing tokens land in tailwind.config.js under spacing; brand primaries land under colors. Marketing engineers build with Tailwind utility classes wired to the same semantic values the product team uses. When the brand ramp shifts, the marketing site and product UI update from the same source without a coordination meeting.

Brand documentation and presentation assets are where token systems most often stop short. Slides, one-pagers, and executive reports are built in Google Slides or Keynote, which have no API to the token system. The bridge I use: a brand kit JSON that is a flattened subset of semantic tokens—hex values resolved, no aliases—that feeds a custom slide template and AI-assisted content generation scripts. When brand colors update, the brand kit JSON regenerates from Style Dictionary, and a Cursor/Claude workflow updates the template’s color swatches. Not fully automatic, but it reduces brand drift in documents from a constant problem to quarterly maintenance.

Using AI to detect and prevent token drift

The most valuable AI integration is not generating new tokens—it is catching drift between Figma and the JSON file. Token drift is quiet: a designer adjusts a variable in Figma during a late-sprint fix, the JSON is not updated, and CI does not catch it because CI only tests the JSON, not Figma.

A regular audit workflow:

Figma MCP read — pull current variable state from Figma
JSON diff — compare against the file in the repo
Discrepancy report — AI produces a list of variables that differ, with “Figma has X, JSON has Y” for each
Review and resolve — designer decides which is correct; AI writes approved updates back to Figma or opens a PR for the JSON

Running this before every sprint review catches drift before it compounds. On a large system, this would take a human an afternoon per month. As an AI-assisted workflow, it runs in under ten minutes and produces a diff the whole team can read.

The broader principle: AI tools work reliably on token systems when the inputs are structured. A flat list of hex values is unstructured—a model cannot reason about intent or catch semantic drift in it. Layered JSON with stable semantic names is structured; models can diff, audit, propose, and explain changes the way a careful engineer would.

How do you know when the token system is working?

The token system is working when:

A designer can change a brand ramp value in one PR and see it propagate correctly to the product UI, the marketing site, and the design system documentation with no manual follow-up
An engineer building a new internal tool can import the component library and produce an on-brand screen without referencing the design file
A new product surface can be added by defining a context override block in JSON without forking any component code
An AI agent auditing the token file can produce a sensible, accurate diff—because the structure is consistent enough to reason about

All four are achievable with the setup described here. None are achievable with an ad hoc approach where tokens are “kind of documented somewhere” and components hardcode color values.

Key Takeaways

Figma variable collections should mirror the JSON layer structure (primitives → semantics → context); any mismatch creates a translation problem that accrues bugs over time.
Figma MCP connects AI directly to variable state, enabling automated audits, bulk updates, and drift detection without manual exports.
JSON is the canonical record; Figma is the iteration environment. Style Dictionary transforms JSON into CSS, Tailwind, iOS, and other targets automatically.
Every surface—product UI, internal tools, marketing site, brand documents—reaches the token system through the appropriate transform output, not through copy-pasted hex values.
AI-assisted drift detection is the most practical ongoing use: comparing Figma variables against the JSON file on a regular cadence and producing a reviewable diff before it compounds.

The architecture behind this workflow is in Peridio & Avocado OS: semantic tokens and AI-native design systems. For how this token system connects to deployment and release branches, see branching strategies for design-engineering collaboration.

Peridio & Avocado OS: semantic tokens and AI-native design systems

Fri, 20 Mar 2026 00:00:00 GMT

Design tokens are the contract between brand, product, and code. At Peridio and Avocado OS, that contract had to stretch across customer-facing product surfaces, developer tooling, internal operations software, and narrative marketing—without fragmenting into five different “almost the same” palettes. This post is how I think about that problem now: a semantic, JSON-first token system with explicit surfaces, complementary accents, and intent roles (informational, warning, success, critical), wired into Figma and AI-assisted code workflows so the whole company can ship on-brand.

The core idea is simple to state: primitives hold raw values; semantics describe purpose; contexts choose which semantics apply. AI tools and MCP-style integrations only work reliably when those layers are explicit—otherwise models hallucinate hex codes and spacing, and every team reinvents the same decisions.

For how tokens stay synchronized with engineering branches and releases, see branching strategies for design-engineering collaboration. For the marketing-and-code side of AI-assisted delivery, ship landing pages with Claude Code and GitHub covers the same operational rhythm at a different altitude.

Multi-surface reality: one company, many “products”

A platform company rarely ships one UI. You get:

External products — what customers buy and recognize on a pricing page.
Internal products — dashboards and consoles your team lives in daily.
Internal solutions — glue software: workflows, approvals, lightweight tools that will never have a marketing site but still need clarity.
Internal software — longer-lived internal apps that behave like product: permissions, audit trails, SLAs.

Each surface has different risk and density. Customer UIs need polish and accessibility at scale. Internal tools need scannability, error recovery, and speed. Semantic tokens let you reuse one component library while shifting emphasis—density, contrast, and accent usage—without forking components.

Avocado OS carries the story of a production-grade OS: trust, stability, and technical depth. Peridio carries fleet operations, security, and control. The visual system should let both narratives coexist: shared infrastructure tokens, distinct brand ramps where the story diverges.

Semantic surfaces: where color does its job

Surface tokens answer “what is behind this UI?”—not “what blue is this?”

A workable baseline set:

Canvas — the default page background; lowest elevation.
Raised — cards, panels, popovers; one step above canvas.
Inset — wells, inputs, dense tables; visually pushed back.
Overlay — scrims and modal shells; may carry blur or alpha.
Brand — hero bands, marketing strips; may use larger chroma.

Components never consume #2B6CFF directly. They consume roles like surface.canvas.default, surface.raised.default, surface.inset.muted. Dark themes remap those roles without touching component code.

Complementary color: brand primary without muddy neutrals

Enterprise palettes often die in the grays: everything looks like a spreadsheet. Complementary accents sit next to your brand primary—used for highlights, secondary CTAs, data viz series, and “related but not primary” actions.

In token terms, split brand from accent complementary:

Brand primary — main actions, key links, focus rings tied to identity.
Accent complementary — charts, tags, secondary emphasis, illustration strokes.

Both reference primitive ramps (brand.500, complement.400) but semantic aliases (action.primary, data.series.secondary) keep components honest. Marketing can push chroma in hero sections; product UI stays restrained—same token architecture, different context overrides.

Intent: informational, warning, success, and critical

Intent tokens encode meaning: “this message is for awareness” vs “this could break production.” Map them consistently across toast, banner, inline field validation, and system badges.

Define semantics for:

Informational — neutral or cool bias; never implies failure.
Warning — attention without panic; reversible states, deprecations.
Success — completion, healthy status, positive diff.
Critical — destructive actions, blocking errors, security issues.

Each intent gets a full mini-palette: background, foreground, border, and optional icon. That avoids the classic bug where warning text passes contrast on white but fails on tinted warning backgrounds.

Pair intent tokens with elevation so dense internal apps stay readable: intent.warning.surface on surface.raised.default should meet WCAG for both default and high-contrast modes.

JSON-first tokens: scalable, fluid, and machine-readable

The format below is not a dump of every hex value. It is a shape you can extend: add brands, locales, density modes, or new product lines without renaming the world. Tools (Style Dictionary, Tokens Studio exports, custom scripts) can flatten this for CSS, iOS, Android, or Tailwind.

Dimensions worth encoding:

Meta — schema version, default theme, supported audiences.
Theme — light/dark/high-contrast; each maps semantic roles to primitives.
Brand — Peridio vs Avocado OS ramps; optional co-brand for partner collateral.
Audience — external, internal, mixed (e.g. docs read by customers and staff).
Product line — which app shell loads which subset (console vs marketing site).
Motion & fluid — optional clamp() references for type and spacing scales.

{
  "$schema": "https://example.com/design-tokens/peridio-avocado/2026-03-20",
  "meta": {
    "name": "peridio-avocado-os",
    "version": "1.0.0",
    "defaultTheme": "light",
    "defaultAudience": "external",
    "modes": ["light", "dark", "hc-light"]
  },
  "primitive": {
    "color": {
      "neutral": { "0": "#FFFFFF", "950": "#0B1220" },
      "brand": { "400": "#3B82F6", "500": "#2563EB", "600": "#1D4ED8" },
      "complement": { "400": "#F59E0B", "500": "#D97706" },
      "intent": {
        "info": { "500": "#0EA5E9", "surface": "#E0F2FE" },
        "warning": { "500": "#F97316", "surface": "#FFEDD5" },
        "success": { "500": "#22C55E", "surface": "#DCFCE7" },
        "critical": { "500": "#DC2626", "surface": "#FEE2E2" }
      }
    },
    "space": {
      "static": { "1": "4px", "2": "8px", "3": "12px", "4": "16px", "6": "24px" },
      "fluid": {
        "section-y": "clamp(2rem, 5vw, 5rem)",
        "gutter-x": "clamp(1rem, 3vw, 2rem)"
      }
    },
    "radius": { "sm": "6px", "md": "10px", "lg": "16px", "pill": "999px" },
    "type": {
      "family": { "sans": "Inter, system-ui, sans-serif", "mono": "JetBrains Mono, monospace" },
      "size": { "fluid-body": "clamp(0.95rem, 0.35vw + 0.9rem, 1.05rem)" }
    }
  },
  "semantic": {
    "surface": {
      "canvas": { "default": "{primitive.color.neutral.0}", "muted": "{primitive.color.neutral.50}" },
      "raised": { "default": "{primitive.color.neutral.0}", "muted": "{primitive.color.neutral.0}" },
      "inset": { "default": "{primitive.color.neutral.100}", "muted": "{primitive.color.neutral.50}" },
      "overlay": { "scrim": "rgba(11,18,32,0.55)" }
    },
    "text": {
      "primary": "{primitive.color.neutral.950}",
      "secondary": "{primitive.color.neutral.600}",
      "inverse": "{primitive.color.neutral.0}",
      "link": "{primitive.color.brand.600}",
      "link-hover": "{primitive.color.brand.500}"
    },
    "border": { "default": "{primitive.color.neutral.200}", "strong": "{primitive.color.neutral.300}" },
    "focus": { "ring": "{primitive.color.brand.500}", "offset": "2px" },
    "intent": {
      "info": {
        "fg": "{primitive.color.intent.info.500}",
        "bg": "{primitive.color.intent.info.surface}",
        "border": "{primitive.color.intent.info.500}"
      },
      "warning": {
        "fg": "{primitive.color.intent.warning.500}",
        "bg": "{primitive.color.intent.warning.surface}",
        "border": "{primitive.color.intent.warning.500}"
      },
      "success": {
        "fg": "{primitive.color.intent.success.500}",
        "bg": "{primitive.color.intent.success.surface}",
        "border": "{primitive.color.intent.success.500}"
      },
      "critical": {
        "fg": "{primitive.color.intent.critical.500}",
        "bg": "{primitive.color.intent.critical.surface}",
        "border": "{primitive.color.intent.critical.500}"
      }
    },
    "accent": {
      "brand": "{primitive.color.brand.500}",
      "complement": "{primitive.color.complement.500}"
    }
  },
  "context": {
    "brand.peridio": {
      "semantic.accent.brand": "{primitive.color.brand.500}",
      "semantic.text.link": "{primitive.color.brand.600}"
    },
    "brand.avocado": {
      "semantic.accent.brand": "{primitive.color.brand.500}",
      "semantic.surface.canvas.muted": "{primitive.color.neutral.50}"
    },
    "audience.external": {},
    "audience.internal": {
      "semantic.surface.canvas.default": "{primitive.color.neutral.50}",
      "semantic.text.secondary": "{primitive.color.neutral.700}"
    },
    "product.console": {
      "semantic.surface.raised.default": "{primitive.color.neutral.0}",
      "primitive.radius.md": "8px"
    },
    "product.marketing": {
      "primitive.space.fluid.section-y": "clamp(3rem, 8vw, 7rem)"
    }
  }
}

This structure scales because new contexts are additive. When internal operations needs a denser table mode, you add density.compact overrides—not new components.

Fleet consoles and OS narratives: what the tokens optimize for

Firmware and edge platforms introduce UI patterns that generic SaaS kits ignore: long technical strings (versions, hashes, device IDs), multi-step deployment timelines, region or fleet segmentation, and destructive actions that can brick hardware or strand devices in the field.

Token design should anticipate those patterns:

Monospace semantics — text.code or text.data reference a mono stack and slightly tighter line-height; they pair with surface.inset so dense tables remain legible without turning the whole app into a terminal.
Status chroma — device health maps to intent semantics: provisioning might use informational blue, degraded performance warning orange, offline neutral gray—not arbitrary badge colors picked per screen.
Destructive emphasis — critical intent wraps confirm dialogs and irreversible fleet actions; the same tokens appear in marketing copy when you explain risk, so language and UI stay aligned.

Avocado OS needs to feel like infrastructure you can trust: stable neutrals, restrained motion, crisp type. Peridio needs to feel like control at scale: hierarchy that surfaces what changed, what failed, and what needs a human—without shouting. Shared surfaces and intent tokens let both stories use one library; brand context swaps accent emphasis and photography treatment where the narrative diverges.

Figma MCP, variables, and why the graph matters

Figma is still the fastest place to validate hierarchy, spacing rhythm, and brand feel—but variables must mirror the same semantic graph as JSON. When an MCP or plugin can read named collections (theme / brand / audience), the model does not guess: it binds to semantic.surface.canvas.default the same way Style Dictionary does.

Practical alignment checklist:

One variable per semantic role in Figma; primitives live in a separate collection.
Modes for light/dark; optional brand mode for Peridio vs Avocado OS art direction.
Component props reference variables, not raw styles—same discipline as code.

Claude Code and repo-native workflows

Once JSON lives in the repo, Claude Code (and similar agents) can refactor themes, propose contrast fixes, or generate Tailwind/CSS layers from the same source. The win is not “AI picks colors”—it is AI edits the contract under review, in git, with diffs your team can audit.

I treat AI-assisted design workflows as the umbrella: prompts and guardrails matter, but structured inputs matter more. A flat list of hex codes is unstructured; layered JSON with semantic names is structured—models behave better, and humans do too.

Tokens in CI: snapshots and contrast as regression tests

When tokens live in git, they can be tested like code. That is the difference between a design system that slides backward quietly and one that stays honest.

Useful checks:

Contrast pairs — script that fails CI if text.primary on surface.canvas.default (and each intent surface) drops below your chosen WCAG threshold for body and UI copy.
Resolved snapshots — generate a flat JSON or CSS artifact in CI and diff it against the previous release; unexpected renames or missing aliases show up as build failures, not mystery bugs in production.
Component visual baselines — Storybook or Loki against a small matrix: light/dark × one external page × one internal console frame. You are not screenshot-testing every pixel of marketing; you are guarding token wiring.

The point is not to slow down design iteration. The point is to make token edits reviewable: a PR that changes a semantic alias should show up as a small, explainable diff—in Figma, in JSON, and in the snapshot output.

How do you keep internal tools from drifting off-brand?

Internal software moves fast and often skips design review. The antidote is defaults, not policing: if the shared component library pulls from the same semantic map, “fast” still looks like the company. Reserve exceptions for real security or density needs—document them as context overrides, not one-off hacks.

Governance I use in practice:

Token changes go through the same visibility as API changes: changelog, migration notes.
Visual QA samples: one external page, one console screen, one internal form—same release.
Deprecation: alias old names for a full minor cycle before removal.

Key Takeaways

Surfaces and intent should be first-class semantic roles—not ad hoc fills—so themes and brands remap without refactors.
Complementary accents sit beside brand primaries for charts, tags, and secondary emphasis without polluting neutrals.
JSON that encodes theme, brand, audience, and product line scales to external product, internal product, internal solution, and internal software through context overrides, not forked libraries.
Figma variables and repo-native tokens stay aligned when they share one semantic graph; MCP-style tooling then reads stable names instead of guessing.
AI-assisted coding pays off when agents edit structured token files under review—diffable, testable, and reusable across the org.

Deeper product context lives in the Peridio and Avocado OS case studies (coming soon)—this article is the system layer underneath both stories.

Figma MCP templates for scalable company collateral

Wed, 04 Mar 2026 00:00:00 GMT

Every company has the same bottleneck. White papers, sales battle cards, event one-pagers, executive decks, customer case studies—all of them route through one designer or a small design team. Marketing waits in a queue. Sales reuses a deck from two quarters ago. The CEO pastes bullet points into Google Slides with the wrong brand colors. The collateral exists, conceptually, but it ships late, off-brand, or not at all.

The instinct is to hire more designers. But the actual problem is not headcount—it is the workflow. Every document is treated as a one-off production job instead of a structured content swap on a proven template. Figma MCP changes this equation entirely. It turns Figma templates into content pipelines that anyone on the team can feed, without ever opening Figma. The result: one designer builds the template once, and the entire company produces on-brand collateral from it at scale.

This post covers the mindset, the workflow, and the practical steps to set it up.

Why most Figma templates stay locked inside Figma

Templates are one of the most common artifacts in a design system. Style guides define them. Brand teams build them. But in practice, most Figma templates are designed to be used inside Figma—by people who know Figma. That limits the audience to designers and the occasional brave marketing manager who learned auto layout under duress.

The deeper issue is structural. A typical template has unnamed layers, inconsistent text node hierarchies, and manual overrides that break the moment someone changes a headline from two lines to three. These templates work visually but they are not machine-readable. No tool—AI or otherwise—can reliably extract content from a Figma file where the text layer for the main headline is called “Text 47” and the subtitle is nested three groups deep with no naming convention.

The shift is simple to describe and requires discipline to execute: design templates for extraction, not just for visual presentation. When you build a template knowing that its content will be read by Figma MCP, translated into markdown, and populated by non-designers, every naming choice, every auto layout decision, and every image fill pattern serves a dual purpose—visual fidelity and programmatic access.

The four-step workflow

The core workflow has four steps. Each one builds on the previous, and the system gets more valuable as the template library grows.

Step 1 — Design the template with auto layout and named layers

Auto layout is non-negotiable. Every text frame, image container, and content block must reflow when content changes length. A fixed-position layout breaks the moment someone swaps a three-word headline for a seven-word headline—and that swap is exactly what this workflow is built for.

Naming conventions matter more here than in any other Figma workflow. Every text node that holds swappable content needs a descriptive, consistent name: hero/headline, hero/subheadline, section-1/body, section-1/caption, cta/button-label. These names become field names in the extracted markdown. If they are vague or inconsistent, the extraction produces a file that nobody can map back to the template without opening Figma—which defeats the purpose.

Image fills follow the same principle. Use named frames with image fills rather than embedded raster images. When MCP reads the file, it can extract the image URL from a fill property. When the next version of the document needs different images, the new URLs are specified in the markdown and written back to Figma—no manual drag-and-drop.

The template should be built as a Figma component with variants if you plan to support multiple formats (one-pager vs. two-pager, landscape vs. portrait). Variants share the same content schema but differ in layout, which means one markdown file can populate multiple output formats.

Step 2 — Extract content via Figma MCP into a markdown file

With the template structured and named, Figma MCP reads every text node and produces a markdown file that mirrors the template’s content architecture. The extraction preserves hierarchy: headings map to markdown headings, body text maps to paragraphs, captions map to smaller text blocks. Character counts and line breaks are preserved so that the content fits within the layout constraints the designer set.

A typical extracted markdown file looks like this:

# Q2 Partner Enablement Kit

## Hero
- **headline**: "Ship faster with embedded design leadership"
- **subheadline**: "How Peridio reduced time-to-market by 40% with a fractional Head of Design"

## Section 1
- **heading**: "The challenge"
- **body**: "Early-stage hardware startups face a unique design problem: firmware interfaces, mobile companions, and cloud dashboards all need coherent UX—but the team is too small for a full design org."

## Section 2
- **heading**: "The approach"
- **body**: "A fractional design director embedded in the engineering team, owning the design system, component library, and cross-functional workflows from day one."

## Images
- **hero-image**: "https://figma.com/file/abc123/image-fill-url"
- **section-1-diagram**: "https://figma.com/file/abc123/diagram-url"

## CTA
- **button-label**: "Book a discovery call"
- **button-url**: "https://cesartevisual.com/contact"

This file is the content shell. It maps one-to-one to the Figma template. Every field has a name, a value, and an implicit character budget set by the auto layout constraints in the original design.

Step 3 — Replicate the markdown and swap the content

This is where the leverage multiplies. The markdown file is duplicated for each new document. A sales rep creating a battle card for a different vertical copies the file and replaces the content—preserving the field names and staying within the character limits so the layout holds.

No Figma knowledge is required. The person filling in the content works in a text editor, a CMS, or even a spreadsheet that maps columns to markdown fields. They see exactly what content goes where, how long each block can be, and what images are needed. The constraint is explicit and structural, not implicit and visual.

For teams producing high volumes—event collateral across multiple conferences, localized one-pagers for different markets, vertical-specific battle cards—this step can be partially automated. An AI assistant takes a content brief (“rewrite this battle card for the healthcare vertical, emphasizing compliance and audit trail features”) and produces a new markdown file that respects the character constraints and field structure of the original. The designer reviews; the AI produces.

Step 4 — Swap images and sync back to Figma

The extracted markdown includes image URLs from the original template’s image fills. When the new document needs different visuals, the content author replaces the URLs in the markdown file. When the content is pushed back to Figma via MCP—or used to generate a new instance of the template—the images update automatically.

This closes the loop. The content goes out as markdown, gets populated by non-designers, and comes back as a complete content package that Figma MCP can write into a new page or a duplicated component instance. The designer’s role shifts from production (“please make me a one-pager”) to system maintenance and quality assurance (“review the new batch, approve, export”).

What can you produce with this workflow?

The workflow is format-agnostic. Anything that starts as a designed template with swappable content is a candidate:

Event collateral — booth banners, handout sheets, speaker one-pagers, sponsor kits. A single event template populated twenty times for twenty speakers takes an afternoon instead of a sprint.
White papers and technical briefs — same structure, different subject matter. The layout, typography, and brand treatment stay locked; only the written content and diagrams change.
Sales battle cards — competitive positioning documents that sales reps use in deals. Each card follows an identical layout but the competitor, differentiators, and objection-handling content change per target.
Executive presentations — quarterly board decks, investor updates, customer QBRs. The template holds the narrative structure; the data and talking points swap per audience.
Marketing campaign assets — landing page copy blocks, social media kits, email header graphics. When the campaign changes, the content swaps; the brand system holds.
Customer-facing documentation — onboarding guides, quick-start cards, feature announcement sheets. Product marketing populates these without touching Figma.

The common thread: the design decision is made once, in the template. The content decision is made many times, in markdown. The two never need to happen in the same tool or by the same person.

How does this empower non-Figma-savvy teammates?

The real impact is organizational, not technical. When collateral production is decoupled from Figma expertise, every function in the company gains the ability to produce on-brand materials independently.

Marketing writes content in markdown or a structured brief and gets back polished documents without filing a design request. Campaign velocity increases because the bottleneck—waiting for design—disappears for templated work.

Sales populates their own battle cards and leave-behinds. A rep preparing for a call with a prospect in a new vertical can produce a customized one-pager in thirty minutes by swapping content in a markdown file, rather than waiting three days for design to prioritize it.

The CEO or executive team requests new investor decks or board presentations by providing bullet points and data. The extraction workflow handles the rest. The design director reviews and refines, but the first draft takes minutes, not days.

Customer success builds onboarding materials and renewal collateral from the same templates. When the product changes, they update the markdown content and the documents regenerate—no design queue, no stale PDFs circulating with outdated screenshots.

The designer’s role transforms. Instead of being a production resource (“make me a thing”), the designer becomes a systems architect: building templates that scale, maintaining the content schema, evolving the brand system, and reviewing output quality. That is a more leveraged, more strategic, and more sustainable use of design leadership than running a request queue.

Why thinking about this process from the beginning matters

Retrofitting extraction into an existing template library is possible but painful. Unnamed layers need renaming. Manual overrides that break auto layout need rebuilding. Inconsistent text hierarchies need flattening. Image fills that were pasted as raster layers need converting to fill properties. The cleanup work can take longer than building the template correctly from scratch.

The upfront cost of designing for extraction is small: a naming convention document, a commitment to auto layout, and a content schema that maps text nodes to markdown fields. That investment pays dividends every time the template is used—not just the first time, but the fiftieth, the hundredth.

Three principles make the difference:

Name everything as if a machine will read it. Because it will. hero/headline communicates intent to both a human reviewing the file and an MCP client extracting content. Text 47 communicates nothing.
Use auto layout as a contract, not a convenience. Auto layout does not just make things look right when content changes—it guarantees that the layout holds when someone swaps a 40-character headline for a 90-character headline. Fixed-position templates cannot survive content swaps; auto layout templates can.
Treat the markdown schema as a deliverable. The extracted markdown file is not a byproduct of the template—it is a first-class output that non-designers will use daily. Review it for clarity, label quality, and character budget accuracy the same way you would review a component API.

When these principles are in place from the start, the design team operates as an enablement function: building infrastructure that multiplies the output of every other team. One designer, with the right template library and extraction workflow, can support the collateral needs of an entire growth-stage company.

Key Takeaways

Figma MCP turns templates into content pipelines. Extract template content as structured markdown, let non-designers populate it, and push updated content back—no Figma expertise required from the content authors.
Design for extraction from day one. Named layers, auto layout, image fills with extractable URLs, and a consistent text hierarchy make templates machine-readable and reusable at scale.
The four-step workflow—design, extract, replicate, sync—decouples design decisions from content decisions. The template is built once; the content is swapped many times by different people across the organization.
This enables every function. Marketing, sales, executives, and customer success can produce on-brand collateral independently, without waiting in a design queue.
The designer’s role shifts from production to systems architecture. Building templates that scale is a more strategic and sustainable use of design leadership than running a request queue.

For how AI-assisted design production extends this workflow into sales decks, executive reports, and marketing assets, see AI for design directors: production workflows for sales and executive collateral. For the broader operating model connecting design, marketing, and engineering pipelines, see AI-assisted design workflows: what actually works in 2026.

Designers who build: how modern teams ship faster and better

Thu, 12 Feb 2026 00:00:00 GMT

The future belongs to designers who build. Not because every designer needs to become a full-time engineer, and not because visual craft matters less. The shift is that product teams no longer reward isolated excellence. They reward integration. A designer who can move between interface decisions, implementation constraints, cross-functional communication, and business outcomes becomes a leverage point for the company.

That is the practical difference this post focuses on: designers who build help teams ship faster with fewer interpretation gaps. They reduce handoff loss, raise decision quality, and make collaboration across engineering, product, and marketing much more concrete. For founders, that translates into speed and confidence. For VPs, it translates into delivery reliability and cleaner execution.

Why this matters now

The old model was linear. Product strategy happened in one room, design happened in another, engineering interpreted whatever came over the wall, and marketing rebuilt the story later. Every handoff introduced drift.

Modern teams do not have enough margin for that drift. Startup timelines are tighter, AI tooling is raising execution expectations, and cross-functional output has become visible to leadership faster than ever. The designer who can both shape intent and pressure-test execution becomes a stabilizing force in that environment.

This is why technical depth in design is a leadership capability, not a hobby. The point is not to write code for ego. The point is to create fewer failure points between idea and shipped outcome.

What does “designers who build” actually mean?

It means operating beyond static deliverables.

A designer who builds can still lead with research, interaction thinking, and visual quality. The difference is that they can also produce working artifacts that survive contact with real constraints: states, edge cases, accessibility requirements, data conditions, content scaling, performance tradeoffs, and integration with existing systems.

That changes the quality of cross-functional conversations:

Engineering reviews become specific earlier because artifacts are testable
Product planning gets sharper because feasibility is surfaced before commitment
Marketing and sales narratives stay aligned because the product story is grounded in what actually ships
Leadership decisions improve because progress is observable in working form, not just slides

For the tactical version of this collaboration model inside engineering rituals, how I embed in engineering teams as a design director breaks down the operating mechanics.

Four operating behaviors that separate designers who build

1) Build artifacts that can be evaluated, not just admired

A polished mockup is useful. A working artifact is directional evidence.

When an artifact can be clicked, tested, reviewed, and questioned, teams can evaluate behavior instead of debating assumptions. This is where design starts accelerating delivery instead of adding another interpretation layer.

This does not require production-perfect code every time. It requires choosing the right fidelity for the decision: prototype for flow risk, component scaffold for implementation risk, content-ready screen for messaging risk.

2) Speak in the language of each function

Cross-functional influence depends on translation. Founders care about speed-to-market and clarity of bets. VPs care about execution quality and team throughput. Engineers care about maintainability, edge cases, and system behavior. Marketing cares about message consistency and usable source material.

A designer who builds can bridge these contexts because they can represent work in forms each function trusts. That bridge creates momentum.

The workflows in AI-assisted design workflows: what actually works in 2026 show how this translation layer gets stronger when AI is used for synthesis and production support, not for replacing judgment.

3) Keep learning adjacent systems

Designers who build stay curious outside their lane: version control, component architecture, content systems, analytics, and deployment basics. This learning is not a detour from design craft. It is what makes design decisions hold up in real operating conditions.

The compounding effect is significant. Each adjacent skill removes one more communication bottleneck and one more dependency loop.

4) Tie design work to business movement

The strongest signal is not “I shipped a component.” The strongest signal is “This changed decision speed, launch quality, or conversion outcomes.”

Designers who build connect craft to outcomes with concrete language:

reduced cycle time from concept to shipped state
fewer handoff revisions between design and engineering
faster content readiness for launch assets
higher confidence in roadmap decisions due to earlier artifact testing

This is the posture that moves a designer from contributor to leadership multiplier.

Founder lens: why this speeds up companies

Founders do not buy design for aesthetics. Founders buy speed, clarity, and risk reduction.

A designer who builds contributes to all three:

Speed: fewer loops lost to ambiguous handoffs
Clarity: faster validation of whether a direction is actually viable
Risk reduction: earlier visibility into technical and messaging constraints

This is especially important when teams are lean and each role carries wide responsibility. The person who can convert strategy into execution-ready artifacts across functions effectively compresses the org chart.

In practice, this often looks like the same design lead shaping the product surface, supporting engineering delivery choices, and enabling sales or marketing with assets that remain consistent with the shipped product. The operating pattern behind that model appears in the Peridio case study (coming soon), where design systems, implementation detail, and product communication had to stay synchronized.

VP lens: why this improves delivery quality

VP Product and VP Engineering leaders often inherit the same failure mode: teams shipping quickly but inconsistently. The root cause is usually not effort. It is fragmented understanding.

Designers who build reduce that fragmentation by producing artifacts and decisions that are harder to misinterpret:

component-level behavior is clarified before sprint pressure peaks
edge-case conversations happen before QA, not during incident response
cross-team standards become easier to adopt because they are demonstrated, not only documented

This is where design engineering contributes directly to reliability. It creates a shared reference model across product, design, and engineering, which improves both velocity and quality.

30/60/90-day map for designers who want to build

The fastest way to grow this capability is not to “learn everything.” It is to build a narrow stack and apply it repeatedly in real project cycles.

Days 1-30: Build fluency around implementation constraints

Learn how existing components are structured in your codebase
Review accessibility states and interaction edge cases in shipped UI
Pair with an engineer on one real ticket from scope to release
Rewrite one design spec using implementation-aware language

Output goal: a spec and artifact that engineering can implement with minimal clarification loops.

Days 31-60: Own a cross-functional slice end-to-end

Pick one feature area and produce the design, component behavior notes, and launch-facing content
Include realistic states: loading, empty, error, long content, and responsive behavior
Use AI for synthesis and scaffold support, but keep human review strict
Track revision rounds and communication bottlenecks

Output goal: one shipped slice where design intent survives from planning through delivery and launch communication.

Days 61-90: Systematize and teach

Convert repeatable patterns into team-ready guides or templates
Document the “definition of done” for design-engineering handoffs
Share measurable outcomes from the previous 60 days
Mentor one teammate through the same operating model

Output goal: organizational lift, not just individual output.

Common traps that weaken the model

The phrase “designers who build” can drift into performative behavior. The goal is not to collect tools. The goal is to reduce delivery friction and improve outcomes.

Avoid these traps:

Tool theater: adopting new tools without changing team outcomes
Solo hero mode: shipping personally but failing to raise team capability
Code-first bias: forcing implementation too early before problem framing is clear
Craft neglect: treating visual and interaction quality as secondary
Unclear success metrics: celebrating activity without business impact

The healthy model is balanced: deep craft, technical fluency, and cross-functional leadership operating together.

Key Takeaways

Designers who build are not replacing design craft; they are extending it into execution where handoff risk usually lives
Technical depth in design is a leadership capability because it improves decision quality, delivery reliability, and cross-functional alignment
Founders benefit through faster cycles and lower execution ambiguity; VPs benefit through cleaner handoffs and more predictable shipping
A focused 30/60/90 plan builds this capability faster than broad, unfocused upskilling
The long-term advantage is not personal output volume; it is the ability to raise team-level performance across product, engineering, and marketing

Preparation for future self: small favors that reduce stress

Fri, 16 Jan 2026 00:00:00 GMT

I like doing favors for my future self.

That sentence started as a joke I told myself when I packed a bag the night before a flight, wrote tomorrow’s first draft before ending today, or left a clean desktop before closing the laptop. But over time, it became a working philosophy. Preparation for future self is not about perfection. It is about reducing avoidable friction so the next version of you can spend energy on the part that actually matters.

The strange part is how often this work disappears from memory. You set something up, move on, and forget it. Then a stressful moment arrives, and what you need is already waiting: a checklist, a template, a decision note, a ready file, a rehearsed opening line. In that moment, it feels like someone helped you. In a way, someone did. It was you, earlier.

Preparation is time-delayed kindness

Preparation for future self is a kind of time-delayed kindness. Past you invests when there is slack. Present you receives that investment when pressure is high.

That framing changed how I think about discipline. I used to frame preparation as a productivity tactic. Useful, but cold. Thinking of it as kindness made it personal and sustainable. Instead of asking, “How can I be more efficient?” I started asking, “What would make tomorrow easier to carry?”

The answers were usually small:

write the first three bullets before the meeting starts
organize links and references before context switching
prepare the one message I know I will avoid writing tomorrow
set naming and folder conventions before file chaos begins
leave one sentence that tells me where to restart

None of these actions are dramatic. That is the point. They are small favors, and small favors compound.

Why this matters more in leadership roles

As responsibilities widen, unprepared moments get expensive. When you are leading design, partnering with engineering, and supporting cross-functional work, one avoidable scramble can ripple through a whole team. Your stress becomes scheduling pressure for everyone else.

That is why I see preparation as a leadership behavior, not a personal preference. In fast-moving environments, you cannot prevent every surprise, but you can reduce how many surprises are self-inflicted.

When I work with distributed teams, preparation has three direct effects:

Decision quality improves: Context is available before urgency distorts judgment.
Collaboration gets smoother: People can contribute faster when the starting point is clear.
Execution gets calmer: Fewer decisions happen in panic mode.

The operating mechanics behind this style of collaboration are similar to what I outlined in how I embed in engineering teams as a design director: create shared context early, reduce interpretation gaps, and make handoffs lighter.

The favors I leave for future me most often

I do not run a perfect routine. I run a repeatable one. These are the favors I leave most consistently because they return value almost every week.

1) I leave a clean restart point

At the end of a work block, I write one short note before closing:

what I completed
what is next
where the blockers are

When I return, I do not need to reconstruct context from scratch. That simple restart note can save 20-30 minutes of cognitive warmup, especially after a day full of meetings.

2) I pre-decide low-stakes choices

Many stressful days are not hard because of one big challenge. They are hard because of dozens of tiny decisions. So I pre-decide recurring low-stakes choices:

file naming rules
folder structures
first-draft formats
meeting prep templates
review checklists

Pre-deciding these lets me preserve focus for the high-stakes decisions that need judgment.

3) I build minimum viable scaffolding

Before a new project starts, I set up the lightest structure that helps the team move:

one source of truth doc
one timeline view
one definition of done
one versioning convention

This is not bureaucracy. It is scaffolding. Without it, every new request starts from zero and coordination costs rise fast.

The same principle appears in AI-enabled work too. In AI-assisted design workflows, I shared how reusable structure beats ad hoc prompting when teams need consistency across speed and quality.

4) I write tomorrow’s opening paragraph today

When I have to publish, present, or pitch something, I rarely stop after finishing “today’s piece.” I also draft tomorrow’s opening paragraph while context is still fresh. That single paragraph acts like a runway for the next session.

This works because starting is usually harder than continuing. If future me can begin in motion, momentum appears much faster.

5) I prepare emotional buffers, not just task buffers

This one took me longer to learn. Preparation is not only logistical. It is emotional.

If tomorrow includes a difficult conversation, I write the first three sentences I want to use. If a deadline feels heavy, I define the smallest useful version I can ship. If I know uncertainty will be high, I list what I can control and what I cannot.

That emotional prep reduces the invisible load that often causes delays more than the work itself.

How can you practice this without over-planning?

Preparation for future self works when it stays light. If it becomes elaborate, it turns into avoidance.

These guidelines keep it useful:

Keep prep shorter than execution. If setup is larger than doing, trim setup.
Favor reusable systems over heroic effort. Build one checklist once; stop rebuilding it daily.
Prepare one step ahead, not ten. You need momentum, not full certainty.
End each day with one favor. One thoughtful setup action is enough to compound.
Review what actually helped. Keep the favors that reduced stress; drop the ones that only looked productive.

A simple weekly reflection prompt helps:

Which scramble was preventable?
What single favor would have prevented it?
Where should that favor live (template, checklist, note, script)?

If you run this loop every week, your operating system quietly improves without adding much overhead.

Past self, present self, future self

I think of this as a three-person team:

Past self has planning time and perspective.
Present self has pressure and limited attention.
Future self needs room to execute clearly.

Most stress spikes happen when these three selves are disconnected. Past self leaves no context. Present self reacts under pressure. Future self inherits clutter.

Preparation reconnects them.

Past self leaves decisions and structure. Present self uses them to stay focused. Future self gets a cleaner starting point.

In practice, this is why versioned systems and clear standards matter across technical and creative work. Whether you are writing content, shaping product direction, or coordinating launches, your future self benefits when your current decisions are explicit and findable. The same logic supports broader cross-functional speed in posts like designops for distributed startup infrastructure, where consistency reduces team-wide friction.

Where this changed my work the most

This philosophy changed my workflow in three places.

Writing

I used to wait for long uninterrupted windows. Now I leave partials:

bullet outlines
placeholder transitions
rough openings

Future me can continue without waiting for ideal conditions.

Collaboration

Before meetings, I leave shared context:

decision options
known constraints
expected outcomes

This turns meetings from “what are we even solving?” into “which path should we choose?”

Delivery

Before a launch week, I package assets and dependencies early:

content sources
design references
handoff notes
review criteria

When last-minute changes arrive, the team adjusts faster because the foundation is already there.

What preparation is not

This approach is easy to misread, so it helps to draw boundaries.

Preparation for future self is not:

trying to control every variable
replacing action with endless setup
creating complex systems no one uses
removing flexibility from creative work

It is simply the habit of making tomorrow lighter on purpose.

That is why I keep returning to the same line: I like doing favors for my future self. It is practical, human, and forgiving. You do not need a perfect system to practice it. You need a repeatable habit of leaving one small advantage behind.

Key Takeaways

Preparation for future self is time-delayed kindness: small setup today, less pressure tomorrow.
The best favors are lightweight and repeatable, such as restart notes, templates, and one-step-ahead scaffolding.
In leadership contexts, preparation improves team outcomes by raising decision quality and reducing scramble-driven execution.
Over-planning is avoidable when prep stays shorter than execution and is reviewed for real stress reduction.
“I like doing favors for my future self” is a practical operating principle: leave one small win for tomorrow, every day.

AI-assisted design workflows: what actually works in 2026

Tue, 13 Jan 2026 00:00:00 GMT

Every design tool now ships with an AI feature. Most of them are still gimmicks. After two years of integrating AI into my daily workflow as a design director—across product design, design systems, documentation, and engineering collaboration—here’s what consistently moves the needle: AI-assisted code generation for prototyping and component scaffolding, LLM-powered content generation for placeholder and production copy, and structured prompts for design research synthesis. The landscape has shifted meaningfully over the last year—agentic workflows are no longer experimental, reasoning models have raised the floor on output quality, and a handful of tools that were hype are now genuinely useful. But the core filter holds: everything else—AI-generated layouts, auto-wireframing, “design from a screenshot”—is compelling to demo and rarely production-ready. The distinction matters because it determines where to invest learning time and where to wait.

The AI tools that genuinely change design practice

Four categories of AI tool are producing consistent, real-world value in my workflow right now.

LLMs for thinking and synthesis. Claude, ChatGPT, and Gemini as thinking partners during early-stage design. I’ll feed user research notes, business constraints, and technical limitations into a conversation, then iterate on information architecture and content strategy before opening Figma. This is where AI produces the highest ROI relative to the effort invested. It’s not replacing design thinking—it’s compressing the time spent on the slower parts of that thinking: competitive synthesis, pattern identification across research data, generating initial structural options to react against. Extended thinking models have made this category meaningfully better—the ability to reason through contradictions in a brief before responding produces higher-quality framing than earlier models could.

AI-assisted code generation. Cursor and GitHub Copilot for scaffolding components, writing utility functions, generating boilerplate. Today, the agent modes—Cursor’s Composer in agent mode, Claude Code—have changed the interaction model from completion to delegation. The pattern is: describe the component API, states, and edge cases precisely, then review and refine the output. The key is treating AI output as a first draft, not a final artifact. Design-technical practitioners who already know how to write specs get dramatically more value from code-generation AI than those who don’t, because the quality of the prompt is the quality of the spec.

Agentic task runners. This category barely existed in early 2025 and is now a real part of my workflow. AI agents—primarily through Claude Code and Cursor’s agent mode—can execute multi-step tasks against a codebase: refactoring component APIs across a design system, generating documentation from code, running accessibility audits and outputting structured reports. The key distinction from simple code generation: agents can read context from multiple files, take sequential actions, and correct errors mid-task. The ceiling is still supervision—you don’t walk away and ship what comes back—but the amount of work that runs in the background while I focus on higher-leverage decisions has increased substantially.

Content and copy generation. Using structured prompts to generate UI microcopy, placeholder content, error messages, and onboarding sequences that reflect real product context. This is one of the most underutilized applications—designers spend significant time writing copy they’re not trained for, and AI produces usable first drafts at a fraction of the effort when given proper context.

AI as a thinking partner in early-stage design

The workflow that’s changed my practice the most is using LLMs in the space between receiving a brief and opening a design tool. This stage used to involve browsing competitors, reading through research notes in a nonlinear way, and slowly building a mental model of the problem. AI compresses that into a structured conversation.

The typical flow: I paste in the brief, relevant research findings, and any technical constraints, then ask the model to identify the key tensions in the design problem, surface gaps in the brief, and suggest three or four framing approaches I haven’t considered. I’m not looking for solutions—I’m looking for a faster path to understanding the problem well enough to design it confidently.

What AI is good at here: pattern-matching across the inputs you give it, identifying what’s missing or contradictory, generating structured options to react against. What it’s bad at: knowing which option is right for the specific product, user base, and organizational context. That judgment is still human, and it’s what separates a good brief response from a generic one.

How do you use AI for code generation without losing design control?

The question I get most from designers exploring AI code tools is how to maintain design control over generated code. The short answer: write better prompts, review everything, and treat it as pair programming, not outsourcing.

The longer answer involves a shift in mental model. When I scaffold a component with AI, I’m not asking it to design—I’m asking it to implement a spec I’ve already written. The design decisions happen before the prompt: what states does this component have, what are the edge cases, what’s the API surface, what are the accessibility requirements. The prompt is just a translation of those decisions into instructions.

The review process matters as much as the generation. I read generated code for:

Accessibility: are ARIA roles correct, is keyboard navigation complete, are screen reader labels present?
Edge cases: what happens on empty states, loading states, error states, extreme content lengths?
API clarity: does the component interface reflect how it will actually be used by engineers?
Performance: is the implementation unnecessarily complex for what it needs to do?

This review discipline is exactly what design-engineering collaboration looks like at its best—design judgment applied to technical output. If you’re interested in how this connects to working inside engineering teams day-to-day, how I embed in engineering teams as a design director covers the full collaboration model.

What still doesn’t work: AI-generated layouts and wireframes

It’s worth being direct about where AI still isn’t useful, because the hype around these categories has only gotten louder and the reality hasn’t changed enough to matter.

AI-generated layouts: Every major design tool has this feature. The output is consistently layout-by-committee: technically valid, visually uninteresting, spatially generic. The problem is that good layout is driven by content hierarchy, interaction patterns, and brand judgment—none of which an AI has access to when it generates a layout from a prompt. The output tends to look like a template from a template library, which is fine if you’re validating a concept but not if you’re designing a product. This has improved marginally with better models, but not enough to change the workflow.

Auto-wireframing from user stories: The same issue. AI can generate a screen that contains the right elements, but it can’t decide what the visual hierarchy should be, what information is most important, or how the layout should communicate priority. Those decisions are design decisions, and they can’t be specified in a Jira ticket.

Design from a screenshot: Useful for quick recreation of existing patterns, but the output is a copy, not a design. The value is as a starting point for exploration, not as a deliverable.

Fully autonomous design agents: The 2025 wave of demos showing AI agents producing end-to-end UI designs without human input hasn’t translated into production-viable workflows. Agents that can generate a page from a prompt do so without the design judgment—the hierarchy, the content prioritization, the brand specificity—that makes the output useful. The autonomy is real; the quality ceiling is still too low.

The pattern across these categories: AI is useful when it’s executing a well-specified intent. When the intent itself needs to be discovered or synthesized—which is what layout design, IA, and wireframing require—AI is still a weak tool.

Integrating AI into a design team without creating dependency

One of the more subtle challenges I’ve navigated is introducing AI tools to a design team in a way that builds capability rather than creating shortcut dependency. The risk is real: if junior designers use AI to skip the exploratory phases of design—the rough sketches, the multiple framings, the deliberate ideation—they don’t develop the taste and judgment that make the exploratory phase valuable in the first place.

My approach: AI tools enter the workflow at the refinement and production phase, not the ideation phase. Junior designers sketch in low fidelity before going anywhere near AI generation. We use AI to move faster through the parts of the process where the creative decisions have already been made, not to replace the parts where they’re being made.

For more senior practitioners, AI as a thinking partner during ideation is appropriate because the judgment layer is already developed—they’re using AI to move faster through a process they understand well. The mental model of when to apply AI and when to protect human process is something you develop through experience, not through exposure to AI tools alone. For the bigger-picture version of this shift—how AI is reshaping what a designer can be across the whole business—the new era of designers: AI and a future full of promise captures the arc.

For a deeper look at specific prompt patterns and template structures, prompt engineering for designers: beyond the chatbot covers the systematic approach to structuring AI inputs that I use across research, code, and documentation work. For the persistent, project-level version of that discipline, the CLAUDE.md template for product designers shows how to encode design judgment so Claude Code loads it on every session instead of relearning it every time.

The irreplaceable design judgment layer

AI is a multiplier, not a replacement. The quality of any AI-assisted design output is bounded by two things: the quality of the intent specified in the input, and the quality of the judgment applied to the output. Both of those are human skills that develop through practice.

Designers who are strong will use AI to move faster through problems they already understand well. The output will be higher quality than it would have been without AI, because they can explore more options in less time and apply more critical scrutiny to each. Designers who are still building foundational skills will produce mediocre work at scale—more of it, faster, all at the same quality ceiling.

The practical implication: invest in developing design judgment alongside AI fluency. The craft skills—information hierarchy, visual reasoning, interaction patterns, copy clarity—matter more in an AI-assisted world, not less. They’re the filter that turns plausible AI output into genuinely good design.

Key Takeaways

The four high-ROI applications of AI in design workflows are: LLMs for research synthesis and early-stage thinking, code generation for component scaffolding, agentic task runners for multi-step codebase work, and structured prompts for content and documentation
AI-generated layouts, auto-wireframing, and fully autonomous design agents are still weak—useful for exploration, not production
Treat AI code generation as pair programming: the design decisions happen in the prompt spec, the review process applies design judgment to the output
Agentic workflows are production-viable for well-scoped tasks—but supervision is non-negotiable; the handoff model is delegation with review, not outsourcing
Introduce AI tools at the refinement phase, not the ideation phase—protect the exploratory work that develops design judgment
AI multiplies existing capability; it doesn’t create capability that isn’t there—and that gap can widen if teams optimize for speed before judgment

AI for design directors: sales decks, reports, and marketing assets

Tue, 18 Nov 2025 00:00:00 GMT

The conventional description of a design director’s output is product UI: Figma files, design systems, component libraries, user flows. That is accurate—but incomplete. And the incomplete version is how design ends up siloed while every other function works around it.

A design director’s actual surface area, especially at a startup, includes pitch decks that raise money, one-pagers that sales leaves after calls, landing pages that convert before engineering has time to build them, executive dashboards that frame the story of the business, and brand assets that flow through every marketing channel. None of these are “product UI.” All of them live or die on design quality. And most startups handle them badly—either starving them for design attention, or letting marketing and sales invent inconsistent visual systems that undercut the brand the product team built carefully.

AI changes this equation. Not by eliminating design judgment, but by eliminating the production hours that used to separate a design brief from a finished artifact. The model is not “AI does design.” It is “design director sets the system, AI does the production labor.”

The problem: design attention is finite, surfaces are not

At a ten-person startup with one design leader, the queue of design requests is always longer than the capacity to fulfill them. Product UI takes priority by default because it is the most visible, most measured, and most team-dependent output. Sales decks, investor updates, executive reports, marketing one-pagers—these land in a secondary pile. They get done eventually, by whoever is least busy, with whatever visual language they can approximate from the brand guide.

The result is a brand split: the product looks intentional and polished; everything around it looks improvised. Investors see a beautiful app demo followed by a slide deck that doesn’t feel like the same company. A potential enterprise customer sees a great landing page, then receives a sales deck with inconsistent typography. The design work is real; the surface area is too large for a single human to cover manually.

This is not a staffing problem—it is a systems problem. The solution is not hiring three more designers; it is building a workflow where the design system’s tokens and templates become the input layer for AI-assisted production, and the design director’s time shifts from production to direction and review.

How AI fits into the workflow: structure in, artifact out

The premise of AI-assisted design production is that structured inputs produce usable outputs. A prompt that says “make a sales deck” produces generic results. A prompt that supplies the brand token values, the product’s core narrative, the target audience, and a slide-by-slide structure produces a first draft that is 60–70% of the way to done.

The design system’s job is to make that input structure accessible and consistent. When semantic color tokens, typography scales, and layout grid specifications live in a JSON file, they can be injected into AI prompts as structured context—not pasted as a hex dump, but as a named, purposeful spec that a language model can follow reliably. The same structured-template principle applies at the collateral level: Figma MCP templates that scale company collateral from a single design file make this workflow repeatable across every surface.

The workflow has three stages:

1. Structure stage — prepare the inputs the AI will use: brand token values (resolved to hex for non-code outputs), slide or report narrative, target audience profile, and a content brief from the requester.

2. Generation stage — the AI scaffolds the artifact using structured inputs. For a sales deck: outline, per-slide copy, recommended image directions, layout notes. For an executive report: section structure, data callouts, summary language. For a marketing one-pager: headline hierarchy, benefit bullets, supporting proof points.

3. Refinement stage — the design director applies visual judgment: adjusting layout, checking brand alignment, replacing AI-suggested imagery with intentional choices, and tightening copy. This stage takes a fraction of the time it would if starting from a blank canvas.

The ratio depends on the artifact. A well-templated investor update might need 20 minutes of refinement. A new sales deck for a new audience might need two hours. A marketing one-pager built on an existing layout template might need 30 minutes. In every case, the ceiling is lower than starting from scratch, and the floor—minimum quality—is higher because the AI has brand context.

Sales decks: the highest-leverage surface outside product

Sales decks are among the most consequential design artifacts a startup produces and among the least systematized. Every sales conversation is slightly different; decks accumulate edits from multiple salespeople and a founder; brand consistency erodes over quarters. Most startups end up with a “master deck” that is already out of date.

The AI-assisted approach I use at Peridio:

1. Maintain a slide library in Figma — not a full deck, but a set of modular slide templates: title cards, two-column layouts, data callouts, customer logos, feature comparison grids. These live in the design system and are always on-brand.

2. Brief the AI on the deal context — when sales requests a custom deck, the brief covers what the prospect cares about, what objections they raised, and what the deal stage is. This takes 10 minutes from the sales lead.

3. Generate a slide structure and draft copy — the AI produces a deck outline with per-slide copy, keyed to the slide library’s template types. “Slide 4: Feature comparison—use two-column layout—lead with [X differentiator] against [competitor Y].”

4. Assemble and refine — drop the AI’s slide structure into the template library, apply the right modular layouts, check for brand alignment, adjust copy where the AI was generic or missed the nuance.

5. Export and hand to sales — the result is a polished, on-brand deck that reflects the deal context. Total design director time: 60–90 minutes, versus 4–6 hours from scratch.

The library of modular slides pays compound interest. Each new deck adds components that become reusable for the next one. After six months, most sales decks take under 45 minutes to assemble because the relevant templates already exist.

Executive reporting: design makes the story legible

Founders and CEOs send weekly or monthly updates—to investors, to the board, to the team. Most are text-heavy emails or Google Docs with pasted screenshots. They communicate data but not narrative. Design can change this without making it a production project.

The workflow I run for executive reporting:

1. Define a report template — a one-pager or two-pager format with named sections: metrics summary, product progress, team and hiring, blockers, what’s changed since last update. The template lives in Figma and as a Google Slides master.

2. Weekly: AI drafts the content — the CEO or founder pastes key metrics and brief notes into a structured prompt. AI converts those inputs into the template’s sections with clean summary language and data callout formatting.

3. Design director reviews narrative and visual — check that metrics callouts are correctly emphasized, that visual hierarchy surfaces the right story, and that any new data visualizations are clear. Approve or adjust.

4. Distribute — exported as PDF or shared as a Google Slides link. Consistent format every week means investors can scan it in 90 seconds.

The critical design contribution here is the template design and the review step. A well-designed report template is worth far more than a perfectly formatted one-off. And the review step is where design judgment matters: an AI-drafted metrics summary might be technically accurate but visually bury the most important number. Catching that before it reaches the board is exactly the kind of design-adjacent leadership that is invisible when absent and obvious when missing.

Marketing assets: the brand kit as AI input layer

Marketing produces assets constantly: social images, blog post headers, email banners, ad creatives. Most of this production happens in Canva or Google Slides by non-designers doing their best to approximate the brand.

The design system solution is a restricted brand kit—a subset that surfaces only what marketers need: approved colors (resolved hex, not token aliases), approved fonts, approved layout grids, and approved photography direction. This brand kit feeds into:

Brandfetch brand kit — all approved colors and logo assets live in one place, accessible from anywhere (including directly inside Figma) or via the Brandfetch API for programmatic retrieval
AI image generation briefs — structured photography direction (subject, mood, lighting, brand palette accent) that produces consistent cover images without stock photo inconsistency
Blog post headers — Figma template with AI-assisted image generation based on post topic and brand brief; 10 minutes per header

The point is not that AI produces final marketing assets. It is that AI-assisted production, constrained by the design system’s tokens and brand kit, raises the floor on everything marketing produces—so the design director’s time is spent on high-stakes pieces, not every social image.

For the marketing-and-code pipeline specifically—landing pages, campaign builds, and the GitHub workflow that ships them—see ship landing pages in hours: Cursor, Claude Code, and GitHub.

How do these workflows compound over time?

The individual time savings are real: 60 minutes instead of 6 hours for a sales deck, 10 minutes instead of an afternoon for a report template update. But the bigger value is compounding. Each workflow gets faster as the library grows, the prompts get more precise, and the team learns what to brief and what to decide.

Six months in, the design system’s influence extends beyond product UI to every external surface the company shows the world. Sales presentations feel like the product. Executive updates feel like the brand. Marketing assets feel like the landing page. That coherence requires a design director who owns the system, the templates, and the AI workflows. But it is achievable with one person and the right setup.

That is the argument for AI-powered cross-functional design leadership as a business model, not just a productivity tip. One design director, properly set up, can hold brand coherence across product, sales, marketing, and executive communication at a growth-stage startup. Five years ago that would have required a four-person team.

For how Figma MCP turns one template into a scalable content pipeline for the whole company, see Figma MCP templates: scale company collateral from one design file. For the cross-functional operating model—how design, marketing, and engineering share a pipeline—see how Head of Design and Head of Marketing actually collaborate and AI-assisted design workflows: what actually works in 2026.

Key Takeaways

AI-assisted design production is not AI replacing design judgment—it is AI eliminating production labor so design judgment can focus on architecture, templates, and review.
Structured inputs produce usable outputs: brand tokens, content briefs, audience context, and template structures given to an AI model produce first drafts that are 60–70% complete.
Sales decks built on modular Figma template libraries and AI-generated copy take 60–90 minutes instead of a full day; the library compounds with each new deck.
Executive reporting becomes brand-consistent and rapid when a well-designed template feeds AI-drafted content that the design director reviews and approves.
Marketing asset consistency improves when a restricted brand kit—resolved from the token system—constrains the palette and typography available to non-designers.
One design director with the right system and AI workflows can hold brand coherence across product, sales, marketing, and executive communication at a startup—output that would have required a team of four before AI production tooling existed.

Ship landing pages in hours: Cursor, Claude Code, and GitHub

Tue, 04 Nov 2025 00:00:00 GMT

The old workflow for a marketing landing page was brutal: marketing writes a brief, design mocks it in Figma, engineering builds it, everyone reviews, three rounds of copy changes happen in Slack, and it ships two weeks later. At a startup, two weeks is a lifetime. The workflow I run now with marketing cuts that to hours. The secret isn’t speed for its own sake—it’s removing the handoff bottlenecks that slow everything down and misalign both teams along the way. AI is the lever, but the real change is structural: design and marketing collaborating directly in code, with GitHub as the shared workspace.

The old landing page workflow and why it breaks at startup speed

Traditional landing page production has four inherent failure modes that compound each other.

The brief-to-design gap. Marketing writes a brief in a doc. Design interprets it in Figma. Something is always lost in that translation—tone, emphasis, the specific argument marketing was trying to make. By the time the mockup reaches review, marketing has already moved on mentally, and the feedback round feels like starting over.

The design-to-engineering gap. Design hands off a Figma file. Engineering builds it. The coded version looks slightly different—spacing off, interactions missing, responsive behavior undefined. Another round of back-and-forth that adds days.

The copy-change cycle. Copy changes are the most expensive thing in the traditional workflow. Every change to headline or CTA copy means updating Figma, waiting for it to be coded, reviewing again. In Slack. Asynchronously. With a minimum of 24-hour turnaround per round.

Deployment friction. Even after everything is approved, getting it live requires a deploy. That means an engineer, a PR, a review, a merge, a pipeline. Sometimes that’s same-day. Sometimes it’s not.

Each of these gaps is a handoff, and each handoff is a place where context is lost and momentum dies. The AI-plus-GitHub workflow eliminates every one of them.

Claude Code scaffolds the 80%, Cursor polishes the 20%

The two tools have distinct roles in the workflow, and understanding the boundary between them is what makes the system work.

Claude Code is the builder. Its job is to go from a content brief to a working page structure as fast as possible. I give Claude Code the messaging brief from marketing—the value proposition, the target audience, the CTA hierarchy, the key sections—and it produces a full landing page in semantic HTML with CSS. In a single session, it generates the layout structure, responsive grid, section components, content blocks, Open Graph meta tags, and a first pass at copy adapted to the brief. Claude Code is fast and broad. It assembles the bones of the page in minutes. The output is functional but not precious—it’s a scaffold, not a deliverable.

Cursor is the finisher. After Claude Code produces the structure, I switch to Cursor for the detail work. This is where the page goes from “technically correct” to “actually designed.” In Cursor I dial in typography scales, adjust spacing to match the design system, refine color values, polish micro-interactions, fix responsive edge cases, and handle the visual details that separate a designed page from a generated one. Cursor’s context-aware editing and its ability to see the whole project at once makes this refinement loop tight enough to do in real time. A change to the headline spacing is visible in the browser preview immediately—no context switch, no deploy cycle, no Figma-to-code translation.

The split is roughly: Claude Code produces the 80% scaffold in the first session, Cursor handles the 20% polish that makes it production-quality.

How do you structure the GitHub collaboration between design and marketing?

The collaboration model is built on one principle: both design and marketing work in the same medium at the same time. Marketing isn’t writing a brief and waiting. Design isn’t building in isolation and presenting. Both are in the repository.

The workflow step by step:

Marketing drafts the brief as a PR description. The brief—messaging, target persona, CTA priorities, section requirements—is written directly in a GitHub pull request description. This puts the brief in the same place as the work, which eliminates the brief-as-doc problem.
Design scaffolds in Claude Code and opens a draft PR. The scaffolded page goes into a branch. A draft PR is opened immediately. GitHub’s PR preview deployment makes the actual page visible to marketing within minutes of starting.
Marketing reviews on the live preview. Marketing comments directly on the PR—not on a Figma file, not in Slack. They see the actual page at actual scale. Their copy feedback is specific because it’s in context. “This headline doesn’t land” is much more actionable when they’re reading it on the built page than when they’re reading it on a mockup.
Design refines in Cursor while marketing comments. Changes are pushed to the branch. The preview updates. The iteration loop is tight.
GitHub Actions deploys on merge. When both sides are satisfied, the PR merges. GitHub Actions runs the build and deploys automatically. The page is live.

Total elapsed time from brief to live: three to four hours for a standard campaign page. For a more complex page with custom sections and interactive elements, a day.

What this workflow produces beyond speed

The speed gain is real, but it’s not the most important change. The more important change is what happens to the quality of collaboration when both teams are working in the same medium.

Feedback specificity improves dramatically. When marketing can comment on the actual page at real scale—with real copy, real button states, real mobile layout—their feedback is no longer abstract. “The hero feels weak” becomes “the headline is too small relative to the background image at mobile, and the CTA is below the fold on iPhone SE.” Specific feedback is actionable feedback.

Ownership becomes shared. When the page is co-built in a shared repo with commit history from both teams, the output belongs to both. Marketing can’t say “design got it wrong” when they were commenting on PRs throughout. Design can’t say “marketing changed the brief” when every change is in the PR thread. The Git history is the truth.

Copy changes become zero-cost. Marketing can edit copy directly in the repository after shipping. A headline change is a one-line PR. Merge, deploy, done. No design involvement required for content-only changes. This changes the relationship between marketing and the product permanently—marketing has agency over their own content without depending on design capacity.

For a related perspective on how design and marketing build shared operational systems, how Head of Design and Head of Marketing actually collaborate covers the project management layer that makes this kind of joint ownership sustainable.

Slide decks and other content types follow the same pattern

The landing page workflow generalizes to any content type that has a visual structure and a content brief. Slide decks are the second most common application.

For pitch decks, conference presentations, and demo decks, the split is the same: Claude Code drafts the narrative structure, section flow, and content blocks; Cursor handles the visual refinement, layout precision, and brand application. The resulting deck lives in a repository alongside the landing page. Version history is in Git. Copy changes are PRs. Distribution is a GitHub Pages link.

Other applications of the same model: microsite campaigns, product changelog pages, case study pages, job listing pages, press kits. Anything with structured content and a visual wrapper benefits from the same scaffold-then-polish pattern.

How do you get started with this workflow?

Start small and let the collaboration loop prove itself. Pick one low-stakes campaign page, get marketing comfortable reading PR diffs and leaving comments, and set up automatic preview deployments so every branch has a live URL. Once that loop is self-sustaining, expand it to higher-value pages. The four steps below make that concrete.

Start with one simple campaign page, not your flagship homepage. Pick a page with limited complexity—a webinar registration page, a product launch announcement, a feature spotlight.
Get marketing comfortable with GitHub early. The learning curve is real, but it’s mostly about reading PR diffs and writing comments—neither requires engineering knowledge.
Set up GitHub Actions for preview deployments first. If every branch automatically deploys to a preview URL, the collaboration loop becomes self-sustaining. No one needs to ask “can I see it?” because it’s always there.
Use Claude Code via the web interface initially, not the CLI. The web interface is accessible to marketing and requires no setup. Once the pattern is established, the CLI speeds up the design side.

For more on the CI/CD infrastructure that makes continuous preview deployments work, GitHub Actions and CI/CD: a designer’s guide covers the pipeline setup that underpins this workflow.

Key Takeaways

The traditional landing page workflow has four compounding failure modes: brief-to-design gap, design-to-engineering gap, copy-change cycle friction, and deployment delay—all caused by handoffs between mediums
Claude Code handles the scaffold (structure, layout, content, meta tags) fast; Cursor handles the polish (typography, spacing, interactions, responsive detail)
The GitHub collaboration model—brief as PR description, live preview on every branch, copy changes as PRs—gives marketing agency over content and design control over quality simultaneously
Copy changes become zero-cost after shipping: one-line PRs that marketing can make without design involvement
The same scaffold-then-polish pattern applies to slide decks, campaign microsites, changelog pages, and any structured visual content

Beyond prompt engineering: AI agent infrastructure

Tue, 21 Oct 2025 00:00:00 GMT

Most prompt engineering advice stops at the chatbot: write better instructions, add role and context, specify your output format. That advice is correct and incomplete. The real multiplier is not a better prompt—it is the infrastructure you build around the AI agent before you ever type a word. Shell scripts that automate commits, linting, deploys, and project scaffolding. Reusable skill files that give the agent domain knowledge without re-explaining your conventions every session. Persistent memory that carries decisions, patterns, and project context across conversations so the agent compounds what it knows instead of starting from zero. The payoff is concrete: faster task execution, fewer tokens burned on repeated context, and a tighter loop from research to shipped code. This post covers the infrastructure layer that separates people who use AI from people who build systems around it.

Why prompt templates are not enough

Structured prompts work. The five-part pattern—role, context, task, format, tone—consistently produces better output than a vague question typed into a chat window. If you haven’t internalized that discipline yet, AI-assisted design workflows: what actually works covers the fundamentals and which tools are worth your time in 2026.

But even a perfect prompt is a one-shot artifact. You write it, run it, get output, and next session you start over. The context you painstakingly described? Gone. The project conventions you specified? Re-explained from scratch. The commit-lint-test-push sequence you ran manually last time? Manual again. Prompt templates help with the last mile of a single interaction. They do nothing for the infrastructure that makes every interaction faster.

The gap between a good prompt writer and an AI-powered practitioner is not prompt quality—it is everything that surrounds the prompt. The scripts that automate repetitive shell operations. The skill files that preload domain knowledge. The persistent context that means today’s session starts where yesterday’s left off. That infrastructure is what compounds.

Shell scripts that make AI agents repeatable

The tasks you repeat across every project—committing code, running lint checks, scaffolding folder structures, setting up environments, validating before deploy—are the lowest-hanging automation targets. A shell script that runs in one command replaces a sequence you’d otherwise re-explain to the agent or execute manually every time.

Commit workflows. A single script that stages changes, runs the linter, executes tests, formats the commit message to your convention, and pushes. Instead of five separate commands or asking the agent to remember your commit message format, you run ./scripts/commit.sh and the entire sequence fires in order. The agent can call it too—one tool invocation instead of a multi-step conversation about your git workflow.

#!/bin/bash
# commit.sh — lint, test, commit, push in one pass
npm run lint:fix
npm run test -- --bail
git add -A
git commit -m "$(cat <<EOF
$1

$(git diff --cached --stat)
EOF
)"
git push origin HEAD

Environment setup. A script that creates the standard project folder structure—deploy configs, security review checklists, error handling patterns, testing configurations, rule files for data handling—installs dependencies, and initializes git. When you start a new project, this runs once and every convention is in place. When an AI agent works in that project, the structure is already there to guide its output.

#!/bin/bash
# scaffold.sh — standardized project structure
mkdir -p config/{deploy,security,rules}
mkdir -p src/{components,utils,hooks,styles}
mkdir -p tests/{unit,integration,e2e}
mkdir -p docs/{decisions,reviews}
cp templates/.eslintrc.json .
cp templates/.prettierrc .
cp templates/AGENTS.md .
npm install
git init && git add -A && git commit -m "scaffold: initial project structure"

Pre-deploy validation. A script that runs lint checks, type checking, security scans, bundle analysis, and any project-specific gates before you deploy. No more forgetting a step. No more asking the agent “did you run the linter?” when you can make linting a precondition of the deploy script itself.

#!/bin/bash
# pre-deploy.sh — gate checks before shipping
set -e
echo "Running type check..."  && npx tsc --noEmit
echo "Running linter..."      && npm run lint
echo "Running tests..."       && npm run test -- --bail
echo "Running security scan..." && npm audit --audit-level=high
echo "Building..."            && npm run build
echo "All checks passed. Ready to deploy."

These scripts are small—ten to thirty lines each. Their value is not complexity but consistency. When every project starts from the same automated baseline, onboarding a new contributor—human or AI—takes minutes instead of hours. As I covered in my guide to GitHub Actions CI/CD for designers, the same principle applies at the pipeline level: automate the repeatable, reserve human attention for the judgment calls.

How do reusable skills reduce token cost and improve output quality?

A skill, in the context of AI-assisted development, is a structured document—typically markdown—that gives an agent domain-specific knowledge, coding conventions, and workflow instructions it can load on demand. Instead of re-explaining your design system’s component API shape, your deployment pipeline’s CI checks, or your content authoring rules in every conversation, you write it once as a skill file and the agent loads it when relevant.

The economics are straightforward. A skill file might be 500–1,500 tokens to load. Without it, you spend 500–2,000 tokens re-explaining the same context in every session, and the agent still gets details wrong because your ad-hoc explanation varies each time. Over ten sessions, a skill file saves thousands of tokens and produces more consistent output because the instructions are identical every time.

Concrete examples of skills I maintain:

Design system conventions. Component API shapes, naming patterns, token usage rules, accessibility requirements. The agent generates components that match the system without me specifying “use Tailwind v4 theme tokens, not arbitrary values” in every prompt.
Deployment pipeline. Which CI checks run, how to structure PR descriptions, what the branch naming convention is, which tests are required before merge. The agent writes PRs that pass review on the first try.
Content authoring. Frontmatter requirements, internal linking rules, tag canonicalization, SEO patterns. The agent writes blog post drafts that conform to the site’s content architecture without a style guide pasted into every conversation.
Security and error handling. Input validation patterns, error response formats, logging conventions, authentication flow requirements. The agent writes defensive code by default.

The skill ecosystem extends beyond your own files. Open-source repositories of agent skills—for accessibility auditing, framework-specific authoring patterns, performance optimization checklists—are starting to appear. You can grab a well-maintained WCAG audit skill, drop it into your project, and immediately give the agent the ability to run accessibility reviews against a standard you didn’t have to write yourself. The same pattern applies to framework skills (Astro, Next.js, SvelteKit), testing patterns, and infrastructure conventions.

In practice, skills map to features in the tools you’re already using. Cursor has project-level .cursor/skills/ and .cursor/rules/. Claude Code reads AGENTS.md and CLAUDE.md at the project root. Codex uses .codex/skills/. The naming varies; the pattern is identical: structured context that loads automatically so you spend tokens on the work, not on re-establishing what the agent should already know.

Persistent memory across sessions—the context that compounds

Every new AI session starts from zero. The agent does not know what you decided yesterday, which architectural approach you chose and why, what you tried and rejected, or which patterns you established three sessions ago. Without persistent memory, each session is isolated—you pay the context cost again, and decisions that should build on each other don’t.

Persistent memory solves this at three levels.

Session summaries and decision logs. At the end of a working session, capture the key decisions, trade-offs considered, and patterns established in a structured markdown file. Next session, the agent loads that file and starts with full context. This is not complicated—it’s a decisions/ folder with timestamped entries that the agent reads before starting work. The discipline of writing them pays for itself within two or three sessions.

Project-level rule files. AGENTS.md, .cursor/rules/, project-specific convention files—these encode decisions that apply to the entire project. “Always use CSS custom properties from the design token system, never arbitrary hex values.” “Commit messages follow conventional commits format.” “All API responses use the standard error envelope.” These are not prompts—they are persistent instructions the agent loads automatically on every session. They function as institutional memory that no team member (human or AI) has to memorize. For the design-specific version of this pattern—hard rules, anti-patterns, and visual judgment encoded for Claude Code—I open-sourced a CLAUDE.md template for product designers that ships with the seven blocks every designer’s project-level rule file should contain.

Structured context documents. A single file—call it CONTEXT.md or product-context.md—that describes the product, its users, technical constraints, and current priorities. Every agent session that loads this file starts with the same foundational understanding. When priorities shift, you update one file and every future session reflects the change. This is the AI equivalent of onboarding documentation, except the agent actually reads it every time.

The compounding effect is the point. Session one, you establish conventions and the agent follows them inconsistently. Session five, the conventions are encoded in rules files, the last three sessions’ decisions are logged, and the agent produces output that reflects accumulated project context. Session twenty, the agent knows your project better than a new team member would after a week—because it has read every decision, every convention, and every pattern you’ve established. The infrastructure carries the knowledge forward.

The tighter loop—research, spec, plan, test, build, iterate

Shell scripts, skills, and persistent memory are not isolated improvements. Together, they compress the development loop. Here’s what the full cycle looks like on a concrete task—say, building a new feature component for a design system.

Research. Load the relevant skill (design system conventions, component patterns), feed context from persistent memory (what components exist, what the last sprint decided about API consistency), and ask the agent to synthesize requirements. The agent already knows your token system, your accessibility standards, and your naming conventions. You’re not spending the first ten minutes of the conversation on setup—you’re starting at the problem.

Spec. Generate a structured component spec using the project conventions the agent already has loaded. Props table, states, edge cases, accessibility requirements, responsive behavior. The spec follows your format because the skill file defines the format. No back-and-forth about “actually, we use TypeScript interfaces, not prop-types.”

Plan. Break the work into tasks. The agent references your project scaffolding to understand where the component lives, which test directories to target, and what the PR template looks like. The plan is grounded in your actual project structure because the scaffold script already created it.

Test. Run automated checks via shell scripts before writing implementation code. Type checking, linting, existing test suites—all fire with one command. If the tests surface a constraint you missed in the spec, update the spec before writing code. The shell script catches the gap; you don’t discover it during code review.

Build. Implement with the agent having full project context loaded. The agent writes code that uses your design tokens, follows your component API patterns, and handles errors according to your conventions—because all of that is loaded from skills and rules, not improvised from a prompt.

Iterate. Save decisions to persistent memory. If the implementation revealed a new pattern worth codifying—a responsive breakpoint strategy, an animation convention, a data-fetching pattern—add it to the relevant skill file. Update the decision log. Next session starts further ahead than this one did.

The key metric is not “how fast did the agent write code.” It is how much of the session was spent on the decisions that require human judgment—information architecture, interaction design, product trade-offs—versus how much was spent re-establishing context the agent should already have. The infrastructure handles the second category so you can focus on the first. As I described in how I embed in engineering teams, the principle is the same whether the collaborator is a junior engineer or an AI agent: reduce the overhead of getting someone up to speed so they can contribute meaningful work faster.

Key Takeaways

The real AI leverage is infrastructure, not individual prompts—shell scripts, skills, and persistent memory compound across every session and project
Shell scripts make repetitive workflows (commit, lint, deploy, scaffold) into one-command operations that both humans and AI agents can run consistently
Reusable skill files give AI agents domain knowledge—design system conventions, deployment rules, content patterns—without re-explaining context every session
Persistent memory across sessions means the agent compounds project knowledge over time instead of starting from zero
The tighter the research-spec-plan-test-build-iterate loop, the more time you spend on design judgment and the less on setup and context re-establishment

How design leadership accelerates startup speed-to-market

Tue, 07 Oct 2025 00:00:00 GMT

The design director at a startup is not the person who makes the product look good. The design director is the single point of contact between product, engineering, marketing, sales, the CEO, and investors—the person who touches every external surface the company produces and keeps them all coherent. Product UI, landing pages, sales decks, pitch materials, onboarding flows, help documentation, executive updates, event collateral: each of these is a designed experience that either accelerates or slows the company down.

Most startups treat these surfaces as separate workstreams owned by separate people. Engineering builds the product. Marketing builds the website. Sales builds the deck. The CEO builds the pitch. The result is predictable: inconsistent quality, duplicated effort, misaligned messaging, and a brand experience that feels like it was made by five different companies. Every surface that doesn’t match the others becomes a rework request, a “can design take a pass at this?” ticket, or—worse—a missed opportunity that ships looking improvised.

When one design leader owns the visual language, the template system, the brand standards, and the review rituals across all departments, those problems disappear. The same processes that make engineering faster—clear specs, a component library, structured reviews—also make marketing faster, sales faster, fundraising faster. Design leadership is a cross-functional velocity multiplier, and the velocity effect compounds across every department it touches.

How does design reduce rework across product and engineering?

Rework is where startup velocity dies. A feature gets designed, built, demoed to the CEO, revised, rebuilt, changed by marketing, rebuilt again. By the time it ships, the team has touched it five times.

The root causes are consistent: ambiguous specs where engineering builds one interpretation and product wanted another. Missing edge cases—the happy path was designed but the error, empty, and loading states were not, so engineering invents them. Late stakeholder input, where the CEO sees the feature for the first time at demo and requests structural changes. Brand inconsistency, where a component ships without referencing the design system and has to be revisited.

A senior design leader addresses all four directly. Specs include interaction annotations, edge cases, and acceptance criteria so engineers can build without Slack threads. Stakeholder reviews happen during the design phase—not after engineering. A design system ensures components are built once, correctly, and reused: an engineer pulling from the component library makes zero brand decisions and ships faster. At Peridio, building the design system before the console and fleet management interfaces were complete meant engineering could implement new screens without waiting on design. The system was the design representation at the engineering layer—present in every build without requiring a designer in every PR.

The question “will this spec prevent a rework cycle?” is a design leadership question. When the answer is consistently yes, engineering velocity increases without anyone writing faster code.

How does a design director accelerate marketing output?

Marketing at a startup needs assets constantly: landing pages, blog post covers, social images, email headers, campaign pages, event collateral, white papers. When design serves only product, marketing either waits in a queue or produces assets on their own—usually in Canva, usually off-brand, usually with inconsistent typography and color that slowly erodes the visual identity the product team built carefully.

The design director’s job is to make marketing self-sufficient without sacrificing brand quality. That means building a restricted brand kit—approved colors, fonts, layout grids, and photography direction—that constrains what marketing can produce to what’s on-brand. It means creating reusable templates for recurring asset types: blog headers, social cards, email layouts, one-pagers. And it means establishing a review cadence so the design director checks marketing output weekly, not per-asset—direction rather than production.

The velocity effect is direct. When marketing has templates and a brand kit, a campaign launches on the same day as the product feature it promotes, not a week later while someone “gets design to make the assets.” Landing pages built on the design system’s token structure can be scaffolded in hours—shipping landing pages with Cursor, Claude Code, and GitHub covers how that pipeline works end-to-end. Blog post covers generated from a structured brand brief take 10 minutes instead of a design request ticket that sits for three days.

The broader operating model for how design and marketing share a pipeline—task management, handoff rituals, and the division of labor—is covered in how Head of Design and Head of Marketing actually collaborate. The point here is the velocity impact: marketing that can ship on-brand without waiting for design is marketing that moves at startup speed.

How does design accelerate sales and customer experience?

Sales needs custom decks for different audiences, one-pagers for specific verticals, demo environments that look polished, and follow-up materials that reinforce the brand the prospect just saw in the product. Without a design system feeding these surfaces, sales teams improvise: they edit the master deck with inconsistent fonts, they screenshot the product instead of using a curated demo flow, they send PDFs that look nothing like the website the prospect visited an hour ago.

The design director builds the infrastructure that makes sales self-sufficient. A modular slide library in Figma—title cards, feature comparisons, data callouts, customer logos—lets anyone assemble a deal-specific deck from on-brand components. One-pager templates for common verticals get updated quarterly, not reinvented per deal. The demo environment gets the same design attention as the production app because it is the prospect’s first experience of the product. For the full AI-assisted production workflow for sales decks and executive materials, see how design directors use AI to produce sales assets, executive reports, and marketing materials.

Customer experience extends beyond sales. The onboarding flow, the help center, the in-app empty states, the error messages, the transactional emails—every touchpoint after the sale is a design surface that either builds trust or erodes it. A design director who owns the full customer journey, not just the product UI, ensures that the experience a customer has in month three feels as intentional as the experience that closed the deal. When onboarding is clear and self-serve, support tickets decrease. When help documentation follows the same visual language as the product, users find answers faster. These are design contributions that compress time-to-value for the customer—and time-to-value is a direct input to retention and expansion revenue.

What role does design play in fundraising and investor communication?

Every artifact a startup produces for investors is a designed experience, whether it’s treated that way or not. The pitch deck, the executive update, the one-pager, the data room, the follow-up email—each one shapes an investor’s impression of the team’s clarity, taste, and execution quality. Investors are pattern matchers: a pitch deck with inconsistent typography and incoherent visual hierarchy signals that the team either doesn’t notice execution failures or doesn’t care about them. Neither reading is good.

The design director who already owns the brand system, the template library, and the review process can produce fundraising materials from the same infrastructure that serves product, marketing, and sales. The pitch deck uses the same visual language as the website. The executive update uses the same data visualization style as the product dashboard. The one-pager uses the same layout grid as the sales collateral. Investors who see this coherence across touchpoints form a specific impression: this is a company that knows how to execute.

The production cost is low when the systems already exist. A pitch deck assembled from the modular slide library and refined for narrative takes hours, not weeks. A weekly executive update templated in the brand’s format takes 30 minutes. The fundraising multiplier is not about making things look pretty—it is about making organizational quality visible in every artifact, and doing so without a dedicated production effort. For the full treatment of how design influences fundraising outcomes, see design as a fundraising multiplier: decks, brand, and investor trust.

Why does a single design point of contact accelerate everything?

The cross-functional velocity comes from a structural advantage: one person sees every surface and keeps them coherent. When the design director reviews the product UI, the marketing landing page, the sales deck, and the investor update, they are enforcing the same visual language, the same quality bar, and the same brand standards across all of them. Decisions that would otherwise require a cross-team meeting—“does the sales deck match the new product messaging?”—resolve in one person’s review because that person already knows both sides.

This is the connective tissue that most startups lack. Without it, departments develop their own visual conventions. Marketing uses one shade of blue; the product uses another. Sales writes headlines in one voice; the website uses a different one. The CEO’s pitch deck looks nothing like the marketing site. Each drift is small; together they produce the impression of a company that isn’t aligned internally—an impression that customers, investors, and recruits all read as organizational immaturity.

The design director as a single point of contact eliminates translation layers between departments. When marketing needs a campaign page, they don’t need to explain the brand to an agency or learn the design system themselves—the design director sets up the template, the brand kit constrains the output, and the review catches anything that drifts. When sales needs a new vertical deck, the design director knows what the product team shipped last quarter and can frame it accurately. When the CEO needs an investor update, the design director applies the same visual system that everything else already uses.

This operating model scales because the systems do the work. The design director’s time shifts from production to direction: building the templates, maintaining the brand kit, reviewing the output, and ensuring that every department’s external-facing work meets the same standard. The processes are the same everywhere—a template library, a brand kit, a review cadence—applied to different surfaces. That repeatability is what makes one person’s attention sufficient for an entire startup’s design surface area. For the collaborative rituals and tools that make this cross-functional hub work in practice, see design as the creative hub: where every team does their best work.

Does the velocity effect compound over time?

Yes. And the compounding is non-linear because each layer of design infrastructure makes the next one faster to build.

Quarter 1 — friction reduction and brand foundations. Specs are clearer, rework decreases, the design system starts forming. The brand kit is established and marketing begins using templates for recurring assets. The design director is mapping the full surface area: product, marketing, sales, fundraising, internal tools.

Quarter 2 — system leverage across departments. Engineers build from the component library without waiting for design. Marketing ships campaign assets same-day using templates and the brand kit. Sales has a modular slide library that covers 80% of deal contexts. The design director’s review load decreases because the systems are doing more of the quality enforcement.

Quarter 3–4 — cross-functional velocity at scale. AI-assisted workflows extend the design director’s output to every surface without proportionally more hours. Landing pages launch on the same day as product features. Sales decks are assembled in under an hour. Executive updates go out on schedule in a consistent format. Every department’s external output feels like it comes from the same company—because it does, and because the systems that produce it are mature enough to enforce that coherence automatically.

After a year, the design function is not “the team that designs the app.” It is infrastructure that makes every department more coherent and faster. That shift is measurable—in release cadence, in rework ratio, in time from product ship to marketing launch, in fundraising preparation time—and difficult to reverse. Once a team has operated with this level of design integration, the alternative looks like going back to building without plumbing.

For the engagement model, cost structure, and perspective advantage that makes this level of design leadership accessible for early-stage companies, see nearshore design leadership: the LATAM advantage for US startups.

Key Takeaways

Design leadership at a startup is not a product function—it is a cross-functional velocity multiplier that accelerates product, engineering, marketing, sales, customer experience, and fundraising through the same set of processes: systems, templates, brand standards, and review rituals.
Rework is the primary velocity killer; a design leader eliminates its root causes—ambiguous specs, missing edge cases, late stakeholder input, brand inconsistency—before they reach engineering.
Marketing moves at startup speed when the design director provides a brand kit, reusable templates, and a review cadence instead of per-asset production.
Sales and customer experience benefit from the same modular template infrastructure: on-brand decks, polished demos, coherent onboarding, and consistent help documentation that compresses time-to-value.
A single design point of contact eliminates translation layers between departments—decisions that would require cross-team meetings resolve in one person’s review because that person sees every surface.
The velocity effect compounds: friction reduction in quarter 1 becomes system leverage in quarter 2, and cross-functional AI workflows by year end—turning one design leader into infrastructure that makes every department faster.

Nearshore design leadership ROI: the LATAM startup advantage

Tue, 23 Sep 2025 00:00:00 GMT

The design hiring question most US startup founders ask is “can we afford this?” — meaning, can we afford a senior design leader at the salary that role commands domestically.

That is a legitimate question. But there is a more interesting question underneath it: what kind of design thinking are we building into the company?

Design perspective is not a commodity. It is shaped by the problems you have had to solve, the constraints you have designed under, and the users you have been building for. A design director who has spent a career shipping products across Latin American markets — different economic realities, different device landscapes, different trust models, different visual cultures — carries a different design instinct than one who has only designed for a US consumer tech context. Both are qualified. Both can lead a design function. They do not see the same problems.

This is the undernamed advantage of nearshore LATAM design leadership. The cost structure is real, and it matters. But the more durable value is what a LATAM-formed design director has seen, and what that shapes in how they approach your product.

What a LATAM design director has seen that domestic hires have not

Designing products in Latin America means designing for users with older devices and inconsistent connectivity. It means designing financial products for markets where trust in digital transactions is earned, not assumed. It means visual communication that cannot rely on icon literacy or imported mental models from Silicon Valley UI conventions. It means building onboarding flows that work when your user is on 3G and has 15 minutes of data left.

These constraints produce specific design instincts.

Resourcefulness over abundance. When you cannot solve a UX problem by adding a component, a screen, or another state, you design more carefully. LATAM product designers have generally shipped under material constraints — smaller teams, shorter timelines, less tolerance for scope expansion — that produce a more disciplined approach to what is actually necessary.

Performance as a design category. A designer who has built for users on mid-range Android devices thinks about load time, animation weight, and asset optimization as design decisions, not engineering concerns. This instinct is increasingly relevant as US products scale into global markets or try to serve users outside the MacBook-on-fiber demographic.

Empathy for skeptical users. Many Latin American markets have historically high distrust of digital interfaces — particularly in financial services, healthcare, and government contexts. Designing for skeptical users requires different clarity standards, different trust signals, and different onboarding progressions. This translates directly to SaaS products selling into risk-averse enterprise buyers or underserved US demographics.

Visual communication without assumption. Design traditions in Latin America include strong advertising, print, and identity disciplines that predate digital UI. A LATAM design director often carries a richer typographic and visual composition background than a designer who came up through product design directly. The craft shows.

The diversity of thinking advantage

The value of cognitive diversity in design leadership is not abstract. It shows up in specific decisions.

When your only design director has designed entirely within a single cultural context, your product reflects that context’s assumptions: what a “settings” page should look like, what “trust” looks like in a transaction interface, how formal or informal your copy should be, and what an empty state should communicate to someone who is skeptical rather than just inconvenienced.

A design director who has navigated multiple cultural and market contexts does not have a single answer to these questions. They have a range. They can ask “which of these is right for this user?” rather than “this is how you design this screen.” That range is directly useful in product decisions: when to simplify, when to add context, when the US design convention is the right choice and when it is being cargo-culted without serving the actual user.

This matters most when companies are expanding into diverse markets. But it matters even for products built entirely for a US audience — because the US audience is not homogeneous, and a design perspective that has never been tested against different user realities will miss those gaps without knowing it.

The LATAM design ecosystem is mature, not emerging

A reasonable concern about hiring design leadership from Latin America is whether the professional ecosystem is deep enough. The short answer: it is.

LATAM has produced a substantial design community over the past decade. Figma Community LATAM — which I co-founded — is one of the largest regional design communities in the world, with thousands of active designers across Guatemala, Mexico, Colombia, Argentina, Brazil, and nearby markets. Design conferences, active professional communities, strong university programs, and a generation of designers who have shipped products at US-facing tech companies make this a mature professional ecosystem, not a thin talent pool.

Designers who have reached Director and Head of Design level in LATAM have generally done so through a more demanding gauntlet than the US equivalent: fewer resources, more context-switching (English proficiency is table stakes), and organizations that require design leaders to operate at both strategic and hands-on levels because large specialized teams rarely exist. The scope compression makes them more capable in generalist leadership roles, not less.

The practical case: lower overhead means earlier access

The cost and operational advantages of nearshore LATAM design leadership are real. The right frame, though, is not “this is cheaper” — it is “the lower overhead means you can access this level of design thinking earlier in your company’s life.”

A senior Design Director based in LATAM with full US timezone overlap (CST, one hour behind New York) operating at 3–4 days per week:

Monthly rate: $8,000–$15,000 depending on scope
Annual equivalent at mid-range: $96,000–$180,000
Benefits and equity overhead: none (contractor arrangement)
Time to start: 2–4 weeks for an experienced independent practitioner

For comparison, a full-time US-based Head of Design:

Base salary: $180,000–$250,000
Benefits: adds 20–30% to total comp
Equity: 0.25%–1.0% at early-stage, with a 4-year vest
Time to hire: 3–5 months for a senior search

The cost difference is real: nearshore engagement at meaningful scope runs 40–60% of a full-time domestic hire’s first-year total, with no equity dilution, no benefits overhead, and faster time-to-value. But the more consequential point is this: a pre-Series A founder who cannot responsibly hire a $220,000 Design Director can bring in a senior LATAM design leader at 3 days per week for $10,000/month. That is not a consolation prize — it is a calibration that makes senior design thinking accessible at the stage when it creates the most leverage. For the operational details of how nearshore engagements are structured, see nearshore design leadership: why US companies hire in LATAM.

What does the ROI look like? Three concrete scenarios.

Scenario A: Pre-Series A, no existing design function. A company with 8 engineers and a product manager hires a nearshore Design Director at $10,000/month. In four months: a design system, a brand identity, a polished investor deck, and product interfaces that feel intentional. Critically, the design system is built by someone who has thought about edge cases, performance constraints, and diverse user contexts — not just what the product looks like in a controlled demo. Total cost: $40,000. Full-time domestic equivalent: $280,000+ in first-year comp, 3–5 months to hire, and similar strategic output arriving 6 months later.

Scenario B: Series A, one IC designer who needs direction. The IC is shipping product work but the product lacks visual cohesion; there is no shared design language; engineering is making visual decisions because no one has established the standard. A nearshore Design Director takes 6 weeks to install a design system, establish clear standards, and give the IC a direction they can work from. The IC’s output improves immediately — not just in quality, but in range, because they are now getting direction from someone whose design instincts have been tested across different user contexts. Total quarterly cost: $36,000. The alternative — promoting the IC before they are ready, or starting a 4-month VP search while the problem compounds — has no equivalent timeline advantage.

Scenario C: Entering a new market or rebranding for a diverse audience. A company is expanding into Latin American markets or reframing its product for a more culturally diverse user base. A LATAM design director is not just managing the rebrand process — they bring direct market knowledge. They know what visual and interaction expectations exist in that market. They know what trust signals work and which ones misfire. They know what US design conventions need to be adapted versus which ones translate cleanly. That cultural knowledge is not available from a domestic hire who studied the market briefly; it is embedded in years of practice. Cost of a 3-month engagement at 4 days/week: $45,000.

Nearshore is not the same as just hiring remote

A US-based remote designer and a LATAM nearshore Design Director are different in three specific ways.

Timezone without sacrifice. Guatemala City is UTC-6 (CST), one hour behind New York at most. Morning standups, live design reviews, and spontaneous pairing sessions work in real time. This is not an offshore arrangement requiring scheduling gymnastics — it is a different mailing address with full real-time collaboration.

Cultural proximity. Latin America and the US have deep, decades-long economic and cultural relationships. The business culture is oriented toward US professional norms in ways that more distant offshore markets are not. Communication styles, professional expectations, and collaboration patterns translate naturally.

Perspective dividend. A remote US designer brings US product design perspective to your US product. A LATAM nearshore design director brings a different perspective — shaped by different constraints, different markets, and different users — that adds to rather than mirrors what is already in the room. That difference is the value, not a compromise.

When nearshore LATAM design leadership makes sense

You want cognitive diversity in product decisions. If your design function has been shaped entirely by a single cultural context, a LATAM design leader changes the range of questions asked in design reviews.

You are building for or toward diverse markets. If Latin American users are a current or planned audience, LATAM design leadership is direct market access, not just structural design leadership.

You need senior expertise at earlier-stage budget. Seed to Series B companies that cannot responsibly hire a domestic VP of Design can access equivalent strategic capability at a different cost structure.

Speed to hire is a constraint. A known practitioner can be effective in 2–4 weeks. A domestic senior search takes 3–5 months. If a fundraise, product launch, or rebrand is on the 60-day horizon, the timeline question resolves itself.

The model fits less well when: physical co-location is genuinely required by the company’s culture; design is a co-founding function requiring equity-structured partnership at very early stage; or at Series C and beyond where design org complexity requires a full-time VP with full executive bandwidth. For how design leadership contributes to startup velocity more broadly — rework reduction, design systems, AI-powered cross-functional output — see how design leadership accelerates startup speed-to-market.

Key Takeaways

The undernamed advantage of nearshore LATAM design leadership is perspective: a design director formed by different constraints, markets, and users sees problems differently — and that range improves product decisions.
Designing across Latin American markets builds specific instincts: resourcefulness, performance-awareness, empathy for skeptical users, and visual communication that works beyond a single cultural context.
LATAM has a mature, deep design ecosystem — not a thin talent market — with strong professional communities, university programs, and a generation of design directors who have shipped at senior level under demanding conditions.
The cost structure is real: nearshore engagement at meaningful scope runs 40–60% of a full-time domestic hire’s first-year total cost, with no equity dilution and faster time-to-value.
The right frame is not “cheaper” — it is “accessible at an earlier stage,” when senior design thinking creates the most leverage in the company’s development.
For US companies expanding into Latin American markets, nearshore LATAM design leadership is direct market knowledge embedded in the design function — not available from a domestic hire regardless of rate.

GitHub Actions and CI/CD for automated deployments

Tue, 09 Sep 2025 00:00:00 GMT

The first time I set up a GitHub Actions workflow that automatically built and deployed my project on every push, it felt like a superpower. No more manual builds. No more “it works on my machine.” No more forgetting to deploy after merging. CI/CD—continuous integration and continuous deployment—is one of those engineering practices that sounds intimidating until you understand the mechanics, after which it sounds obvious. For designers who work in code, automated deployment pipelines change the entire shape of the work: you stop thinking about deployment as a separate task and start thinking about it as the natural end of every change.

What CI/CD actually means for design-technical work

CI/CD stands for continuous integration and continuous deployment. These are two related but distinct practices.

Continuous integration (CI) means that every time you push code to a branch, automated checks run: the project builds, linting passes, tests run. If something breaks, you know immediately—before it gets merged into the main branch and before it reaches production. For design work in code, the relevant CI checks are: does the project build successfully, does the CSS lint without errors, and (if you’ve set it up) do your components pass accessibility audits.

Continuous deployment (CD) means that when code is merged to the main branch, it automatically deploys to production. No manual deploy steps, no “who has the deploy key,” no coordination required. For a feature branch, CD often means deploying a preview URL so you can see the actual live output before merging.

Together, CI/CD creates a workflow where: push → check → preview → merge → deploy. Each step is automatic. The feedback loop from writing code to seeing it live in a browser is measured in minutes, not hours or days.

The anatomy of a GitHub Actions workflow

GitHub Actions workflows are defined in YAML files that live in .github/workflows/ inside the repository. Each file defines a set of automated jobs that run in response to triggers—pushes, pull requests, scheduled times, or manual dispatches.

A minimal workflow for an Astro or static site:

name: Build and Preview

on:
  pull_request:
    branches: [main]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
      - run: npm ci
      - run: npm run build

This workflow runs on every pull request targeting main. It checks out the code, installs dependencies, and runs the build. If the build fails, the PR is flagged and you know before merging.

The key concepts in the YAML:

on: the trigger. pull_request means it runs when a PR is opened or updated. push would run on every push. schedule runs on a cron.
jobs: the units of work. Each job runs on a fresh virtual machine.
steps: the individual actions within a job. Each step is either a reusable action (uses:) or a shell command (run:).
runs-on: the operating system for the virtual machine. ubuntu-latest is standard for most web projects.

How do you set up PR preview deployments for design review?

Preview deployments are the single highest-value thing CI/CD adds to a design workflow. A preview deployment means every pull request automatically gets a live URL where you can see exactly what the branch looks like in a real browser, at real scale, on real devices. Design review becomes reviewing the actual output, not inferring it from a Figma mockup.

Most static site hosts (Vercel, Netlify, Cloudflare Pages) provide this as a first-class feature—every PR gets a unique preview URL automatically. For self-hosted setups or more control, you can configure it directly in GitHub Actions using a deployment workflow.

With Vercel (simplest setup):

Connect your GitHub repository to Vercel
Vercel automatically creates a GitHub App that handles preview deployments
Every PR gets a comment with a preview URL from Vercel, no YAML required

With GitHub Pages + custom workflow (more control):

name: Deploy Preview

on:
  pull_request:

jobs:
  deploy-preview:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci && npm run build
      - name: Deploy to preview
        uses: peaceiris/actions-gh-pages@v3
        with:
          github_token: ${{ secrets.GITHUB_TOKEN }}
          publish_dir: ./dist
          destination_dir: preview/${{ github.event.pull_request.number }}

This deploys the PR build to a subdirectory on GitHub Pages, making it accessible at https://your-username.github.io/your-repo/preview/123. The PR number is the directory, so every PR gets its own URL. Share it with stakeholders for review before merging.

For landing pages and marketing sites built with the design-marketing workflow covered in shipping landing pages with Cursor, Claude Code, and GitHub, this PR preview setup is the infrastructure that makes real-time collaboration between design and marketing possible.

Automated accessibility checks in your CI pipeline

One of the most valuable automated checks you can add is accessibility linting. Accessibility issues that slip into production are expensive to fix and damaging to users. Catching them in CI—before they merge—changes the economics.

The axe-core library is the standard for automated accessibility testing. Combined with pa11y or direct Playwright integration, you can run accessibility audits against your built HTML automatically:

- name: Accessibility audit
  run: |
    npm install -g pa11y-ci
    npm run build
    npx serve dist &
    sleep 2
    pa11y-ci http://localhost:3000

This spins up a local server from the built site and runs pa11y against it. Any WCAG 2.1 AA violations fail the CI check and block the merge. The result: accessibility becomes a non-negotiable constraint, not an afterthought.

For design system component libraries, you can integrate Storybook with the a11y addon and run Storybook tests in CI to audit every component variant automatically. This creates a feedback loop where accessibility regressions in components are caught at the component level before they propagate to the product.

What does a mature CI/CD setup look like for design-engineering teams?

A mature pipeline for a design-engineering team runs three layers of automation on every change: fast per-commit checks (build verification, linting, and type checks), thorough per-PR checks (full lint suite, accessibility audit, visual regression tests, and a preview deployment), and on-merge production deployment with a post-deploy health check. Each layer catches a different class of problem—broken builds, visual regressions, and failed deploys—before it reaches users.

The three layers in detail:

Per-commit checks (fast, lightweight):

Build verification: does the project build without errors?
Linter: does the CSS/TypeScript lint clean?
Type checks: no TypeScript errors?
Total: 2–3 minutes

Per-PR checks (more thorough):

Build + full lint suite
Accessibility audit against key pages
Visual regression tests (screenshot comparison against baseline)
Preview deployment to a shareable URL
Total: 5–10 minutes

On-merge-to-main (production deployment):

Full build and test suite
Production deployment
Post-deployment health check (does the production URL respond 200?)
Notification to team Slack channel with deployment status
Total: 5–10 minutes

The visual regression testing layer is particularly valuable for design-engineering teams. Tools like Chromatic (built for Storybook) or Percy take screenshots of your components and pages on every PR and compare them against the last approved baseline. Any visual change—intended or accidental—is flagged for review. This catches the subtle regressions that human PR review misses: a font-weight change, a shadow that shifted, a component that renders differently on a specific viewport width.

How do you get started with GitHub Actions without an engineering background?

The best starting point is one of the built-in workflow templates GitHub provides. When you navigate to the Actions tab in any repository, GitHub suggests starter workflows based on your project type. For a JavaScript project, it will suggest Node.js workflows. For an Astro project, there are community templates.

Start with the simplest possible workflow: a build check on every PR. Add one thing at a time—lint check, accessibility audit, preview deployment. Each addition is a single step in the YAML. Read the GitHub Actions documentation for the step you’re adding; the documentation is well-written and the examples are directly usable.

The learning curve is real but shallow. The YAML syntax is strict about indentation, which causes most beginner failures. Use a YAML validator before pushing. Beyond that, the concepts translate directly from what you already know: triggers are like event listeners, jobs are like functions, steps are like lines of code.

For the broader context of how version control and branching strategies support design-engineering collaboration, git workflow scripts: designing processes that earn engineering trust covers the git workflow scripts and process design that CI/CD builds on.

Key Takeaways

CI/CD creates a push → check → preview → merge → deploy loop that is entirely automatic—deployment becomes the natural end of every change, not a separate coordinated task
PR preview deployments are the highest-value single improvement to a design workflow: every branch gets a live URL, so design review is reviewing the actual output
Accessibility checks in CI make accessibility a non-negotiable constraint rather than a late-stage audit—violations are caught before they merge
A mature pipeline has three layers: per-commit checks (fast, ~3min), per-PR checks with preview deployment (~10min), and on-merge production deployment
Start with one workflow—a build check on every PR—and add one step at a time; the YAML syntax is strict about indentation but the concepts are straightforward

How I embed in engineering teams as a design director

Tue, 19 Aug 2025 00:00:00 GMT

The fastest way to earn trust with an engineering team is to show up where they work. Not in Figma—in their codebase, their pull requests, their standups. As a design director, I don’t just hand off specs; I participate in sprint planning, review PRs for UI accuracy, pair with engineers on tricky interactions, and commit directly to the codebase when it makes sense. This isn’t about replacing engineers—it’s about removing the translation layer between design intent and production output. Every layer of translation between a design decision and its implementation is a place where fidelity is lost and trust is eroded. The goal of embedding in engineering is to eliminate those layers.

What it actually means to show up in engineering’s space

Most designers interact with engineering through a handoff artifact: a Figma link, a Zeplin screen, a spec doc. The engineer interprets it and builds. If something looks different, there’s a back-and-forth in a comment thread or Slack. This workflow feels normal until you experience what happens when it’s replaced with direct collaboration.

When I embed in an engineering team, I participate in the tools they use daily. I’m in the sprint board, not just the design board. I’m in the repository, not just the design file. I review front-end pull requests—not for code quality, which is the engineer’s domain, but for visual and interaction fidelity. When a component is 4px off its design spec or missing a focus state, I catch it before it merges, not after it ships.

The shift this creates is significant. Engineers stop treating design as an upstream process that produces files and start treating the design director as a collaborator who understands what they’re building and will help them get it right. The dynamic changes from “design hands off, engineering interprets” to “design and engineering solve the implementation together.” That’s a fundamentally different quality of output.

The sprint rituals that make embedding work

Embedding isn’t about attending every engineering meeting—it’s about being present at the specific moments where design decisions get made or re-made in code.

Daily standup (or async equivalent). I join or review the standup so I know what’s currently in flight and what’s blocked. If something touching UI is in progress, I reach out proactively—not reactively. The standup is how I prevent “design hasn’t seen this yet” from becoming a late-stage problem.

Sprint planning. I participate in sprint planning for any sprint that includes front-end work. Not to estimate story points—that’s the team’s job—but to flag design complexity that might not be visible from the ticket description alone. An animation that looks simple in Figma might require a state machine. An interaction that’s obvious to a designer might be a four-day engineering task. Flagging these in planning prevents them from becoming surprises mid-sprint.

PR reviews for UI work. I add myself as a reviewer on every front-end PR that touches visual components or user flows. My review is focused exclusively on: does this match the design intent, are all states handled, does it work on mobile, are there accessibility issues? This is separate from the engineering review for code quality. The combination of both reviews means the PR can’t merge until both the code and the visual output are correct.

Design reviews inside the sprint. Rather than holding separate design reviews at the start and end of the sprint, I run micro-reviews during the sprint: a 15-minute async Loom walkthrough when a feature is in mid-development, a quick pairing session when an engineer is about to implement something complex. The feedback loop is tighter, and rework is caught earlier.

How do you pair with engineers on complex interactions?

Pairing sessions are the most effective single practice for bridging design and engineering, and they’re also the most underused.

A pairing session for a complex interaction: I sit (or screenshare) with the engineer while they implement the interaction. I can point to the prototype and say “the delay here should be 200ms, not 300—it feels sluggish.” The engineer can say “the way this animation is structured, that delay is actually happening here, not where you think.” We solve it together in real time, in code, in the browser. The output is better and faster than any spec doc could produce.

The interactions where pairing is most valuable:

Complex animations with multiple states and timing dependencies
Responsive layout decisions that aren’t fully specced in the design file
Accessibility implementations where the right pattern isn’t obvious from the design
Anything where the spec says “matches design” but the implementation will inevitably require engineering judgment calls

For pairing to work, the design director needs enough technical fluency to understand what the engineer is doing and to communicate in their frame of reference. Not to write the code, but to read it well enough to have a productive conversation. Tools like AI code generation (which I cover in AI-assisted design workflows) are increasingly helpful here—being able to scaffold a quick implementation to show the pattern you’re looking for is faster than a paragraph of written explanation.

Managing design file drift

One of the most persistent problems in design-engineering collaboration is that the Figma file and the production codebase slowly diverge over time. Engineers make pragmatic adjustments during implementation. Design files aren’t updated. Six months later, the design system components in Figma don’t match what’s in production, and no one knows which version is the truth.

The solution is treating divergence as a shared responsibility with an explicit process for reconciliation.

My approach: I maintain a “divergence log” in the design file—a simple doc or sticky note list that tracks every time production diverges from the design file and why. Monthly, I do a sweep: components that were legitimately improved in production get updated in Figma. Components that were incorrectly changed in production get flagged for a fix. The design file is always in the direction of “source of truth,” even if it’s briefly behind production.

The other part of this is structural: engineers should feel empowered to flag when they’re about to make a design decision and want design input, rather than making the call silently. This only happens when the design director has made clear that design is available, responsive, and genuinely collaborative—not a bottleneck to route around.

What embedding looks like in remote and nearshore setups

The embedding model works in remote setups but requires deliberate adaptation. The informal proximity of an in-office environment—walking over to show someone something, catching an engineer at their desk, overhearing a conversation—gets replaced by structured async and intentional sync.

In my remote setup, I use a combination of:

Loom walkthroughs for async design reviews during a sprint. A 3-minute video walking through a design change or flagging a PR issue is more efficient than a written comment and more personal than a ticket.
Live review sessions over video for anything that requires real-time judgment calls. Screen sharing with the dev environment open, reviewing in the browser, not in static mockups.
Branch preview deployments for PR reviews. If every PR has a live preview URL, design review is reviewing the actual output, not inferring from code diffs. GitHub Actions can automate this for most modern stacks.
Dedicated pairing slots in the shared calendar. Not as-needed (which means never)—scheduled blocks of time where any engineer can book design pairing during the sprint.

For how this connects to a broader nearshore design leadership model, DesignOps for distributed startups covers the operational infrastructure that makes distributed design work across departments and time zones.

The long-term trust dividend

The most valuable outcome of embedding deeply in engineering isn’t any specific artifact or process improvement—it’s the trust dividend that compounds over time. Engineers who have worked with a design director who shows up in their PRs, who pairs with them on hard problems, who doesn’t disappear after the handoff, develop a fundamentally different relationship with the design function.

That trust manifests in specific, measurable ways: engineers flag design issues proactively rather than making silent judgment calls; they ask for design input earlier in the process; they advocate for design quality in technical architecture discussions; they pull the design lead into conversations where design should have a voice but traditionally hasn’t.

This is how design earns influence in an engineering-led culture—not by claiming it, but by demonstrating consistent value in the spaces where engineering works. The embedding practice is the mechanism. The trust is the result.

Key Takeaways

Embedding means showing up in engineering’s actual work context—sprint boards, repositories, PR reviews—not just inviting engineers to design reviews
The highest-leverage sprint ritual is reviewing every front-end PR for visual and interaction fidelity before it merges, not after it ships
Pairing sessions on complex interactions produce better output than specs because both parties can adjust in real time in the browser
Manage design file drift proactively: maintain a divergence log and reconcile monthly so the Figma file stays directionally authoritative
In remote setups, replace informal proximity with structured async (Loom, branch previews) and intentional sync (scheduled pairing slots, live reviews over video)

Branching strategies for design-engineering collaboration

Tue, 05 Aug 2025 00:00:00 GMT

One of the most underrated skills in design-engineering collaboration is understanding how branching strategies affect the way design work lands in production. When I work with engineering teams, I follow the same branching conventions they do: feature branches for new work, clear naming conventions, and pull requests that describe what changed and why. This isn’t overhead—it’s communication infrastructure. The branching model is the shared language between design and engineering for what’s in progress, what’s ready for review, and what’s ready to ship. When both sides speak that language, coordination becomes easier. When only engineering speaks it, design work is always a special case that needs explanation.

Why branching strategy matters for design work in code

Most discussions of branching strategy are written for engineering teams working on application logic. The patterns apply equally to design work in code—design system components, design tokens, front-end templates, CSS architecture—but with some important differences.

Design changes are often highly visible but structurally shallow. Changing a border-radius or a color token touches many components through inheritance, but the change itself is a one-line edit. Design token changes create wide blast radius with minimal code complexity. This is different from application logic changes, where structural complexity and visibility tend to move together.

This characteristic means design branches should usually be:

Smaller and more frequent than application logic branches. A component update, a token change, and a layout fix are three separate branches—not one.
Named with visual context that engineering understands at a glance. feature/update-card-border-radius-8px is better than feature/card-update because anyone reading the branch list knows what it touches.
Linked to design files. Every design-related PR should include a link to the Figma component or frame it implements, so reviewers can compare code output to design spec without context-switching.

The branching naming conventions that work for design-engineering teams

Naming conventions are easy to undervalue until you’re scanning a list of twenty branches trying to find the one that shipped the card component change three weeks ago. Clear, consistent names are searchable, auditable, and self-documenting.

The convention I use:

{type}/{scope}-{description}

# Design system changes
feat/button-add-destructive-variant
fix/token-surface-contrast-ratio
refactor/card-migrate-to-css-variables

# Product UI changes  
feat/onboarding-step-1-redesign
fix/nav-mobile-overflow-hidden
chore/update-spacing-scale-to-new-tokens

# Documentation
docs/button-usage-examples
docs/token-naming-guide

The types mirror conventional commits (feat, fix, refactor, chore, docs) because they signal intent to engineers reading the branch list and because they translate cleanly into PR titles and eventually into changelog entries.

The scope is the affected component or system area. The description is a brief but specific label. The goal is that someone should be able to read the branch name and know approximately what the PR contains before opening it.

How to coordinate design token changes across consumer teams

Design token changes are the branching challenge unique to design-engineering collaboration. A token change to a semantic color or a spacing value affects every component that uses that token—potentially dozens of components across multiple teams. Coordinating that kind of change requires a structured approach.

The pattern I use for breaking token changes:

Step 1: Add the new value before removing the old one. Create a branch that adds the new token value alongside the existing one. Don’t remove the old token yet. This lets consumer teams migrate at their own pace.

Step 2: Communicate the migration. Open the PR for the new token value with a clear description of which old tokens are being deprecated and when. Give consumer teams a timeline (two sprints is typical for non-urgent changes).

Step 3: Migrate your own components first. While consumer teams migrate their usages, update all design system components on their own branches to use the new token. Each component gets its own PR.

Step 4: Remove the deprecated token in a cleanup branch. Once all consumers have migrated, open a cleanup PR that removes the old token. The PR title and description should call this out explicitly so it’s visible in the git history.

This multi-step approach makes token migrations trackable, reversible, and low-risk. Each step can be reviewed, merged, and verified independently. If something goes wrong at any step, you can revert without affecting the other steps.

What does a good design PR look like?

A well-structured design PR makes the reviewer’s job easy. It gives them everything they need to understand what changed, verify that it matches the design intent, and identify any issues—without having to chase context elsewhere.

A good design PR includes:

A clear title that follows the naming convention and describes the change accurately. Not “update card” but “feat/card: add elevated shadow variant to match design spec.”

A brief description with three elements: what changed (the specific visual or interaction change), why it changed (the design decision or issue it addresses), and how to verify it (what to look at, what states to check).

A Figma link to the component or frame being implemented. Reviewers should be able to open the design file and compare directly.

Before/after screenshots where the change is visual. Even a simple screenshot comparison removes ambiguity about whether the change matched the design.

A checklist of states and edge cases that were verified: default, hover, focus, active, disabled, empty, overflow, mobile viewport.

The PR is the artifact that lives in the git history forever. In six months, when someone asks “why did we add the elevated shadow variant,” the PR description is where the answer lives. Treat it accordingly.

How do you manage design and engineering releases in sync?

Release management is where design-engineering coordination is most visible—and most prone to failure. The failure mode: design ships a new component version in the design system, but the consuming engineering team hasn’t updated to it, so production and the design file are out of sync for two sprints. Or engineering ships a feature with UI that was approved at sprint start but has since been revised in design, and nobody caught the drift.

The branching model that minimizes this:

Use release branches for synchronized design-engineering releases. When a feature requires both design system changes and product changes, create a shared release branch (release/feature-name) that both sides target. Design’s component PRs merge into the release branch. Engineering’s feature PRs merge into the release branch. The release branch is reviewed holistically before merging to main. This keeps the two bodies of work synchronized without requiring perfect timing on individual PRs.

Tag design system releases in git. When you ship a version of the design system, create a git tag (v1.3.0, v1.3.1-token-update). Product teams can reference the tag to understand exactly what version of the design system they’re consuming and whether they need to update.

Use the PR to track design-production parity. Every design-related PR should end with a verification step: check out the merged branch in the browser and verify that production matches the design file. Document the result in the PR. If there’s drift, open a new branch to fix it rather than leaving it ambiguous.

For the automated deployment infrastructure that supports this workflow—particularly PR preview deployments that let you verify design output before merging—GitHub Actions and CI/CD: a designer’s guide covers the pipeline setup in detail.

How do you get an engineering team to accept design PRs?

You earn acceptance by being a good PR author, not by asking for trust up front. Open small, self-reviewed pull requests with clean diffs, clear descriptions, Figma links, and before/after screenshots, and engineers quickly start treating design PRs like any other reliable contribution. Skepticism evaporates once the first few PRs are genuinely easy to review.

The first time a design director opens a pull request, there’s sometimes skepticism from engineering: “Will this actually be right? Will it break something? Do I have to review design PRs now on top of everything else?”

Being a good PR author means: small PRs, clean diffs, clear descriptions, Figma links, screenshot comparisons, and PRs that have been self-reviewed before opening. It means not using git to push large files or design artifacts (Figma exports, source images) into the repository. It means rebasing before opening so the diff is clean and there are no merge conflicts for the reviewer to navigate.

When you open three PRs that are each well-structured, easy to review, and correct—you’ve done the work. Engineers appreciate good PRs and will ask you to open more. The bar isn’t perfection on the first try. It’s demonstrating that you’ve thought about the reviewer experience before asking for their time.

For the git foundations that make this kind of PR workflow possible, git workflow scripts: designing processes that earn engineering trust covers the shell scripts and habits that produce clean PRs consistently.

Key Takeaways

Design branches should be smaller and more frequent than application logic branches—one component change, one token change, one layout fix per branch, not combined
Branch naming conventions with type, scope, and description make the branch list a self-documenting record of in-progress work
Token migration follows a four-step pattern (add new, communicate, migrate consumers, remove old) to avoid breaking changes across consumer teams
A good design PR includes a Figma link, before/after screenshots, and a state checklist—it’s the artifact that answers “why did we build it this way” for the next six months
Release branches synchronize design and engineering changes for features that require both design system updates and product implementation

Self-hosting as a designer: from Plex to Docker to open-source AI

Tue, 22 Jul 2025 00:00:00 GMT

I run my own servers. Not because a blog post told me it would make me a better design leader—but because I wanted to understand what happens after my designs leave Figma. Self-hosting as a designer started as curiosity: a Plex media server on a spare machine, then a VPS for a portfolio, then Docker containers for real products, and eventually running open-source AI models for design workflows. Each step taught me something about infrastructure constraints that no documentation, tutorial, or secondhand explanation could replace. The knowledge is visceral. When you’ve watched a process crash at 2am and debugged it yourself, you understand why engineering teams make the decisions they do. That understanding—constraint literacy, not sysadmin certification—is what changes how you collaborate, scope features, and earn credibility in technical conversations.

Why designers should care about what runs behind the screen

Infrastructure constraints are design constraints. This is obvious to engineers and invisible to most designers, and that gap costs both sides.

When you’ve set up a server and watched it struggle under load, you understand why engineers push back on features that require heavy real-time data. When you’ve managed a database and seen how query complexity affects response time, you understand why “just add a filter” isn’t a free feature. These aren’t things you can fully grasp from a product requirements document—they become real when you’ve dealt with them yourself.

Deployment complexity affects product decisions in ways that don’t surface in design reviews. Understanding that “adding a new service” means provisioning infrastructure, setting up monitoring, managing secrets, and handling deployment coordination—not just writing code—changes how you think about scope. A design feature that technically works but requires a new backend service has a real cost that affects sprint planning, release timing, and team capacity.

Security and privacy constraints are structural, not bureaucratic. When you’ve configured firewall rules, managed environment secrets, and set up SSL certificates, you stop seeing engineering caution around data handling as obstruction. Design decisions that treat sensitive data carelessly create infrastructure-level problems that are expensive to fix.

The goal here isn’t to become a sysadmin. It’s to develop what I think of as constraint literacy: enough hands-on experience that you can participate in infrastructure conversations as someone who understands the tradeoffs, not just someone who advocates for design requirements. That literacy compounds—it changes how you scope work, how you communicate with engineering, and how seriously your assessments are taken in product planning. For how this connects to broader engineering collaboration, embedding in engineering teams as a design director covers the day-to-day patterns this knowledge supports.

How a Plex server taught me more than any tutorial

My entry point into self-hosting wasn’t a VPS or a deployment pipeline. It was a Plex media server on an old machine in my apartment.

Setting up Plex sounds simple—install the software, point it at a folder of media files, open a browser. But the moment you want it to actually work reliably, you encounter the same concepts that underpin production infrastructure: networking (port forwarding, local vs. external access), storage (drive formats, RAID considerations, what happens when a disk fills up), and process management (the server needs to start on boot, stay running, and recover from crashes). You learn that a service is not just software—it’s software that needs to stay alive on hardware that has opinions.

The homelab is the lowest-stakes environment to learn these things. Nothing breaks except your own movie night. But the mental models transfer directly: the difference between a process and a service, what ports and firewalls actually do, why persistent storage matters, how networking works at the level below “it just connects.” Once you’ve kept something alive on a network for a few months—handled an OS update that broke a dependency, expanded storage when it ran out, configured remote access so it works outside your local network—the next step feels natural rather than intimidating.

From VPS to Docker — what building for Peridio and Avocado OS taught me

The jump from a home server to a VPS is smaller than it looks. SSH into a remote machine, install a web server, configure a domain and SSL—each step is well-documented and individually manageable. The real shift in my understanding came with Docker.

Docker containers solved a problem I’d been running into repeatedly: the “works on my machine” gap between development and production environments. When I started containerizing services for Peridio and Avocado OS, the value became concrete. A Dockerfile defines every dependency, every configuration, every environment variable. The container that runs on my laptop is the same container that runs in staging and production. Immutable. Replicable. Consistent across systems.

This matters more than it sounds. Before Docker, deploying meant hoping that the production server had the right versions of the right dependencies configured the right way. With Docker, the deployment artifact is the environment itself. Docker Compose extends this further—defining multi-service applications (a web server, a database, a background worker) as a single configuration file that spins up identically everywhere.

Working on Avocado OS in particular drove this home. The system needed to be reproducible across hardware targets—not just “it runs” but “it runs identically, every time, on every device.” Dockerizing that workflow forced me to think about infrastructure the way embedded engineers think about firmware: every dependency is explicit, every environment variable is declared, and there’s no room for “it probably has Node 18 installed.” That discipline changed how I approach every project now, even simple ones. If I can’t describe the full environment in a Dockerfile or a Compose file, I haven’t finished the setup.

For how this infrastructure thinking connects to the broader design system architecture work at Peridio, building reusable design infrastructure at an IoT consultancy covers the design token and component system side of the same product.

Why GoDaddy-era hosting can’t keep up with modern design-engineering workflows

Once you’ve containerized your projects and set up CI/CD pipelines, you hit a wall: the hosting platforms most people start with were not built for how modern teams ship software.

Traditional shared hosting—GoDaddy, cPanel-based providers, conventional FTP-upload hosts—was designed for a different era. Upload files to a directory, maybe configure a database through phpMyAdmin, done. That model worked when websites were static pages updated weekly. It breaks when your workflow demands continuous deployment on every push, cache optimization at the edge, staging environments that mirror production, elasticity that scales for launches and contracts after, and tight integration with GitHub Actions and CI/CD pipelines.

I hit this wall personally. The speed, cache behavior, and deployment constraints of legacy platforms were actively blocking the workflow I’d built. Deploys that should have been automatic required manual FTP transfers. Cache invalidation was unpredictable. There was no concept of a staging environment—you deployed to production and hoped. Scaling meant calling a support line and upgrading to a more expensive plan.

The shift to platforms built for modern deployment—Vercel, Netlify, Cloudflare Pages, Railway, Fly.io—wasn’t just a convenience upgrade. It was a workflow transformation. Each platform solves a specific part of the puzzle: Vercel and Netlify handle static and serverless deployments with automatic preview URLs for every pull request. Cloudflare Pages pairs with their edge network for cache optimization that actually works predictably. Railway and Fly.io handle containerized applications with straightforward scaling. Every one of them integrates natively with GitHub, so the CI/CD pipeline patterns that automate your builds also automate your deployments.

Staging environments in particular became a design tool, not just an engineering artifact. Being able to share a real preview URL with stakeholders—instead of screenshots, Loom videos, or “check the Figma prototype”—changes the feedback loop fundamentally. The stakeholder sees the real product, with real data, with real performance characteristics. Design review happens in the medium the user will actually experience.

Serverless configuration added another dimension. Not every feature needs a full server running 24/7. An image optimization function, a form handler, a scheduled report generator—these can run as serverless functions that only consume resources when invoked. Understanding this changes how you scope features: “this needs a server” and “this needs a function” are different infrastructure costs, and knowing the difference makes your feature proposals more precise.

How do you run open-source AI models on your own infrastructure?

The most recent layer in my self-hosting journey connects infrastructure knowledge directly to AI-powered design workflows. Running open-source AI models—rather than relying exclusively on API calls to OpenAI or Anthropic—opens up a different set of capabilities and tradeoffs that designers should understand.

Platforms like Fireworks AI make it practical to deploy open-source models (Llama, Mistral, Mixtral, and others) with production-grade reliability. The advantage isn’t just cost—though cost matters when you’re running models at volume for design automation. It’s control: you choose the model, you control the latency characteristics, you can fine-tune for specific tasks, and you understand exactly what happens to the data you send.

For designers exploring AI workflows, Ollama is the most accessible starting point. Install it locally, pull a model, and you have a local LLM running on your machine. No API key, no usage costs, no data leaving your computer. It’s the Plex of AI inference: a low-stakes environment to learn how models work, what inference speed feels like at different parameter counts, and what the resource tradeoffs actually are. A 7B-parameter model runs on a laptop; a 70B model needs serious hardware or a cloud deployment. Understanding that spectrum—and where different use cases land on it—informs how you design features that depend on AI.

The connection to self-hosting knowledge is direct. Running a local model is running a service—it needs memory allocation, it responds to HTTP requests, it has performance characteristics that depend on hardware. Running a model on Fireworks AI is managing a cloud deployment—you configure the instance, set the concurrency, monitor the costs. The same infrastructure intuition that started with a Plex server applies here: what does it cost, what are the constraints, and how do those constraints shape what you can build?

For design teams specifically, understanding model hosting means understanding why certain AI features are expensive (large context windows, real-time inference, multi-modal input), why latency varies (local vs. cloud vs. edge), and when it makes sense to build with open-source models versus commercial APIs. This is constraint literacy applied to the fastest-moving part of the design toolchain.

The tools that make self-hosting approachable in 2026

The infrastructure tooling landscape has gotten dramatically more approachable. You don’t need deep Linux expertise to run a productive self-hosted stack.

VPS providers: DigitalOcean, Hetzner, Vultr, Linode. Hetzner offers the best price-to-performance; DigitalOcean has the best documentation for beginners.

Web servers: nginx for static sites and reverse proxy. Caddy as an alternative that handles SSL automatically with cleaner configuration syntax.

Containers: Docker Desktop for local development. Docker Compose for multi-service applications. Coolify as a self-hosted Heroku alternative that manages containers and deployments through a UI.

Modern deployment platforms: Vercel and Netlify for static and serverless deployments with automatic preview URLs. Cloudflare Pages for edge-optimized hosting. Railway and Fly.io for containerized applications with straightforward scaling.

Serverless: Cloudflare Workers for edge functions. Vercel Functions for API routes alongside your frontend. AWS Lambda when you need the full ecosystem.

CI/CD: GitHub Actions for automated builds and deployments. Kamal for container-based deployments with zero-downtime.

Databases: SQLite for small projects. PostgreSQL for anything that scales. Managed providers (Neon, Supabase) for the database layer without operational overhead.

AI model hosting: Ollama for local inference and experimentation. Fireworks AI for production-grade open-source model deployment. vLLM for self-hosted high-throughput inference.

Monitoring: UptimeRobot for uptime checks. Grafana + Prometheus for full observability. Betterstack Logtail for log management.

What should designers realistically aim for?

Not everyone needs to manage their own infrastructure in production. The goal isn’t to become a sysadmin—it’s to develop enough context that you’re a more informed participant in decisions that involve infrastructure tradeoffs.

The realistic target for a design director who wants infrastructure fluency:

Can deploy and maintain a personal project on a VPS or a modern deployment platform
Understands SSH, web server configuration, SSL, and DNS at a conceptual level
Has containerized at least one project with Docker—understands images, containers, and Compose files
Has set up a CI/CD pipeline at least once, even for a personal project
Can read server logs and understand what a failed deployment looks like
Knows the difference between traditional hosting and modern deployment platforms—and why the distinction matters for team velocity
Can articulate what it costs to host an AI model and what tradeoffs different hosting options create
Can have a meaningful conversation about infrastructure tradeoffs in a product planning meeting

This level of knowledge takes a few weekends of hands-on work to develop. Start with a Plex server or a VPS—something low-stakes with personal utility. The return on that investment—in engineering credibility, in design decision quality, in independence—compounds over the career.

Key Takeaways

Self-hosting as a designer builds constraint literacy—visceral understanding of infrastructure limits that changes how you scope features, communicate with engineering, and participate in technical decisions
A Plex server or home server is the lowest-stakes entry point: the same concepts (networking, storage, process management, service uptime) that underpin production infrastructure, with nothing at risk except your own media library
Docker and containerization are the key unlock for professional infrastructure work—immutable, replicable environments that behave identically across development, staging, and production, as I experienced firsthand building for Peridio and Avocado OS
Legacy hosting (GoDaddy, cPanel, FTP) can’t support modern design-engineering workflows—continuous deployment, staging previews, edge caching, and serverless functions require platforms built for how teams actually ship software now
Running open-source AI models (locally via Ollama or in production via Fireworks AI) extends infrastructure literacy into the fastest-moving part of the design toolchain—understanding model hosting costs and constraints shapes smarter AI feature decisions
The realistic goal isn’t sysadmin competence—it’s enough hands-on experience to be a credible, informed participant in infrastructure conversations

Git workflow scripts: designing processes that earn engineering trust

Tue, 08 Jul 2025 00:00:00 GMT

Knowing git commands is table stakes. Every tutorial will teach you git rebase, git commit --amend, and git add -p. What those tutorials skip is the layer above the commands: the git workflow scripts that encode your process into something repeatable, teachable, and fast. I run shell scripts for rebasing, link checking before commits, breaking long sessions into grouped commits, and switching branches without losing context. These aren’t complex — most are under twenty lines. But they changed how I work in codebases and, more importantly, how engineering teams perceive the design function. When you show up with a system for working in git rather than a loose collection of memorized commands, the trust equation shifts.

Why process design matters more than command memorization

There is a meaningful difference between knowing that git rebase -i HEAD~5 lets you squash commits and having a script that fetches the latest main, checks for uncommitted changes, rebases your branch, and reports whether conflicts occurred — all in one command. The first is knowledge. The second is a process.

Processes compound in ways that individual commands do not. When your rebase workflow is a script, you run it the same way every time. You never forget to fetch first. You never accidentally rebase with a dirty working tree. You never lose track of which branch you were on. The script handles the mechanics; you handle the judgment calls — which commits to squash, how to resolve that token conflict, whether this branch should even exist anymore.

More importantly, processes are transferable. When a junior designer or a new team member asks how you work in the codebase, you hand them your scripts folder. That is a concrete onboarding artifact — not a Notion page that drifts out of date, but executable documentation of how you actually work. The same applies when coordinating branch naming and PR patterns across a design-engineering team: conventions encoded in scripts get followed; conventions written in wikis get forgotten. In the same spirit, scripting your process is a favor to your future self—preparation for future self: small favors that reduce stress makes the broader case for building calm execution into how you work.

Scripts for the git workflows you repeat every day

Every script here solves a friction point I hit repeatedly. Each one is under twenty-five lines, runs in bash or zsh, and does one job well.

Pull latest and rebase safely

The most common git operation for anyone working on a feature branch: bring your branch up to date with main without losing work or creating a mess.

#!/bin/bash
# rebase-latest.sh — fetch main and rebase current branch onto it safely
set -e

BRANCH=$(git branch --show-current)
if [ -n "$(git status --porcelain)" ]; then
  echo "Dirty working tree. Commit or stash your changes first."
  exit 1
fi

echo "Fetching origin..."
git fetch origin main

CONFLICTS=$(git rebase origin/main 2>&1) || {
  echo "Rebase conflicts detected. Resolve them, then run: git rebase --continue"
  exit 1
}

echo "Branch '$BRANCH' rebased onto latest main."
git log --oneline -5

The script checks for uncommitted changes before doing anything destructive. If the working tree is dirty, it exits with a clear message instead of silently stashing or — worse — losing changes mid-rebase. After a successful rebase, it prints the last five commits so you can verify the history looks right.

Link and lint check before committing

Committing code that breaks the linter or ships dead links is the kind of mistake that erodes trust with engineering reviewers. This script gates the commit on passing checks.

#!/bin/bash
# pre-commit-check.sh — run lint + link check, then commit if clean
set -e

echo "Running linter..."
npm run lint 2>&1 || {
  echo "Lint errors found. Fix them before committing."
  exit 1
}

echo "Checking internal links..."
npm run check:links 2>&1 || {
  echo "Broken links detected. Fix them before committing."
  exit 1
}

echo "All checks passed."
git add -A
git commit -m "$1"
echo "Committed: $1"

Run it as ./scripts/pre-commit-check.sh "fix: update card spacing to 8px". The linter and link checker run first; the commit only happens if both pass. Adapt the npm run commands to whatever your project uses — the structure stays the same regardless of toolchain.

Branch switching with stash

Context-switching between branches mid-session is inevitable. This script auto-stashes your current work, switches branches, and tells you what it stashed so you can restore later.

#!/bin/bash
# switch.sh — stash current work, switch branch, report
set -e

TARGET=$1
if [ -z "$TARGET" ]; then
  echo "Usage: ./scripts/switch.sh <branch-name>"
  exit 1
fi

if [ -n "$(git status --porcelain)" ]; then
  STASH_MSG="auto-stash before switching to $TARGET"
  git stash push -m "$STASH_MSG"
  echo "Stashed current changes: '$STASH_MSG'"
fi

git checkout "$TARGET"
echo "Switched to '$TARGET'. Run 'git stash pop' to restore stashed changes."

The stash message includes the target branch name so when you run git stash list later, you can see exactly which context switch caused which stash entry. Small detail, meaningful when you have three stash entries and no memory of what each one contains.

Quick rebase onto main with log

A tighter version of the rebase script for when you just want to bring your branch current and see the result.

#!/bin/bash
# rebase-main.sh — rebase onto origin/main and show divergence
set -e

git fetch origin main --quiet
BEFORE=$(git rev-parse HEAD)
git rebase origin/main

AFTER=$(git rev-parse HEAD)
if [ "$BEFORE" = "$AFTER" ]; then
  echo "Already up to date with main."
else
  echo "Rebased. New commits on top of main:"
  git log --oneline origin/main..HEAD
fi

The origin/main..HEAD log range shows only the commits that are on your branch but not on main — the exact diff that will appear in your pull request. Reviewing this output before pushing is the fastest way to catch commits that should have been squashed or messages that need rewriting.

How do you break a long coding session into reviewable commits?

The scenario: you spent three hours deep in a feature. You touched twelve files across components, styles, and tests. Your changes are correct, but if you commit them all as a single “feat: implement card redesign” commit, the reviewer has no structure to work with. If you commit them as they happened chronologically, the history is a mess of back-and-forth edits.

The solution is commit chunking — staging your changes in logical groups after the fact, writing a clear message for each group, and pushing a history that tells the story of what you built, not the order you built it in.

git add -p is the core tool. It walks through every changed hunk in your working tree and asks whether to stage it. You say yes to the hunks that belong in this commit, no to the rest, then commit that group and repeat.

A script that structures this workflow:

#!/bin/bash
# chunk-commits.sh — guided commit chunking for long sessions
set -e

echo "Unstaged changes:"
git diff --stat
echo ""

ROUND=1
while [ -n "$(git diff --name-only)" ] || [ -n "$(git diff --cached --name-only)" ]; do
  echo "--- Commit group $ROUND ---"
  echo "Use 'git add -p' to stage the next logical group, then press Enter."
  echo "(Or type 'done' to finish)"
  read -r INPUT
  [ "$INPUT" = "done" ] && break

  git add -p

  if [ -n "$(git diff --cached --name-only)" ]; then
    echo "Staged files:"
    git diff --cached --stat
    echo ""
    read -r -p "Commit message: " MSG
    git commit -m "$MSG"
    ROUND=$((ROUND + 1))
  else
    echo "Nothing staged. Try again or type 'done'."
  fi
done

echo "Chunking complete. Final history:"
git log --oneline -$((ROUND - 1))

The script loops through your remaining changes, prompting you to stage a group with git add -p, write a message, and move to the next group. When you finish, it prints the commits you just created. The result: a PR where each commit represents a coherent unit — “refactor: extract card shadow tokens,” “feat: add elevated card variant,” “test: card component visual regression” — instead of one monolithic diff.

The principle behind commit chunking is that commits are a communication artifact, not a journal entry. They should be structured for the person reading them six months from now, not for the order your brain happened to work through the problem.

Designing your own development processes

The scripts above are small — ten to twenty-five lines each. Their value is not in the code but in the practice they represent: identifying a friction point, scripting the repeatable parts, and iterating the script as your workflow evolves.

The process for designing a process:

Notice the friction. Every time you run more than three git commands in sequence to accomplish one task, that sequence is a candidate for a script.
Write the manual checklist first. Before scripting, write down the steps you follow. “Fetch main. Check for dirty tree. Rebase. Review log. Push.” The checklist is the spec.
Automate one step at a time. Start with the riskiest or most forgettable step — usually the safety check. Add the rest as the script proves useful.
Put scripts in a scripts/ folder in the repo. When scripts live alongside the code, they are versioned, reviewable, and discoverable by anyone who clones the project. They become part of the codebase, not a personal secret.
Iterate. When you find yourself working around the script — adding a manual step before or after — update the script. It should reflect how you actually work, not how you worked six months ago.

Your scripts folder is your development process made executable. It documents how you work more honestly than any process wiki because it runs — and if it drifts from reality, it breaks. That feedback loop keeps it accurate in a way that documentation alone never does.

One implication worth naming: these scripts work identically whether you run them yourself or an AI coding agent calls them. A ./scripts/rebase-latest.sh invoked by an agent in your terminal produces the same result as you typing it. The infrastructure you build for your own workflow becomes infrastructure that scales with AI tooling. For the deeper angle on building shell scripts and skill files specifically for AI agent workflows, shell scripts, skills, and memory that make AI agents useful covers the AI infrastructure layer in detail.

What happens when engineering sees you have a process

The trust shift that happens when engineers see a design director with scripted workflows — not just using git, but having a system for using git — is qualitatively different from the trust you earn by knowing commands.

Commands signal competence. A process signals discipline. Engineers build systems for a living; they recognize system-thinking when they see it in a collaborator from another function. When you open a PR with cleanly chunked commits, and your commit messages follow a consistent format, and your branch was rebased before review — that consistency is visible. It is the artifact of a process, and engineers read it correctly.

The compounding effect matters. One clean PR could be luck. Five clean PRs with the same structure, the same commit message format, the same pre-push checks passing — that is a pattern. Patterns earn trust. Trust changes the relationship: engineers start looping design into architecture decisions earlier, they ask for PR reviews on front-end work because they know design will give actionable feedback, and they stop making silent UI judgment calls because they know someone with design authority is in the same tools, running the same workflows, and will see it.

The cultural change starts from a technical practice. The technical practice starts from designing your process. For how this connects to the day-to-day embedding practice in engineering teams — sprint rituals, PR review cadence, and async collaboration patterns — how I embed in engineering teams as a design director covers the broader workflow.

Key Takeaways

Git workflow scripts encode your process into something repeatable and teachable — they are executable documentation of how you actually work, not aspirational wiki pages
Four scripts cover most daily friction: safe rebase, pre-commit checks, branch switching with stash, and commit chunking for long sessions
Commit chunking with git add -p lets you restructure a long coding session into logical, reviewable commit groups after the fact — commits should tell the story of what you built, not the order you built it
The meta-practice is the real skill: notice friction, write the manual checklist, automate one step at a time, version the scripts alongside your code, and iterate as your workflow evolves
Engineers recognize system-thinking in collaborators from other functions — a scripted workflow signals discipline in a way that memorized commands do not, and that discipline compounds into trust over time

How Head of Design and Head of Marketing actually collaborate

Tue, 17 Jun 2025 00:00:00 GMT

The relationship between Head of Design and Head of Marketing is one of the most impactful—and most mismanaged—in any startup. When it works, you get a brand that feels cohesive across every touchpoint: landing pages, decks, social, campaigns, product UI, and everything in between. When it doesn’t, you get a Frankenstein of mismatched assets, last-minute fire drills, and a design team that feels like an order-taking service for marketing. The fix isn’t cultural—it’s operational. You need shared workflows, shared priorities, and shared visibility into what’s in flight. Goodwill and regular syncs are not enough when both teams are moving fast.

Why design-marketing friction is a systems problem, not a people problem

The most common framing I see for broken design-marketing relationships is interpersonal: “the head of marketing doesn’t respect design’s process” or “design takes too long and doesn’t understand campaign timelines.” In my experience, this framing is wrong in almost every case. The friction is systemic, not personal. It comes from structural misalignments that any two reasonable people would struggle with:

Invisible capacity. Marketing doesn’t know how loaded design is until they submit a request and hear “we can get to that in two weeks.” Design doesn’t know what’s coming until marketing drops a request with a three-day deadline. Neither team has visibility into the other’s reality in real time.

No shared prioritization. Marketing has a campaign calendar. Design has a product roadmap. These two things are rarely visible to each other, which means conflicts are discovered late—at the worst possible moment before a launch.

Requests without context. Marketing sends a brief (if you’re lucky) or a Slack message (if you’re not) without sufficient context for design to start well. Design delivers work that misses the strategic intent. Review rounds pile up.

No shared definition of done. Marketing’s “ready to ship” and design’s “ready to ship” are different things, and they’re rarely aligned upfront.

Linear addresses all four of these because it creates shared operational infrastructure—not just a project management tool for one team, but a single workspace where both teams work in the same system with the same visibility.

How we structure the shared Linear workspace

The workspace setup I use has design and marketing operating as separate teams within a single Linear workspace. This gives each team their own backlog and initiatives while making cross-functional projects visible to both.

Shared project templates for campaigns. Every campaign or launch that involves both teams starts from a shared project template with consistent phases:

Brief: Marketing writes the campaign brief—target audience, messaging hierarchy, key deliverables, deadline. Design is tagged to review and ask clarifying questions. Neither team moves to creative direction until the brief is signed off.
Creative direction: Design develops the creative direction—visual strategy, tone, asset types, any new design system components required. Marketing reviews and aligns. This phase prevents the “I thought it would look different” feedback that happens after production.
Production: Execution of all assets—landing pages, social graphics, decks, product UI changes. Design owns production. Marketing reviews at checkpoints, not continuously.
Review: Structured review with explicit sign-off. Every reviewer is named and assigned. No “reply-all” feedback loops.
Ship: Final QA, asset handoff, deployment. GitHub for anything coded, shared Drive or Figma for static assets.

Each phase has an owner and a clear handoff condition. The phase doesn’t change until both owners are aligned. This eliminates the ambiguity about “where are we?” that causes most of the friction.

Aligning capacity with the marketing calendar

The most operationally valuable thing Linear enables is connecting design capacity to the marketing calendar in real time. We use cycles (Linear’s sprint equivalent) to make design capacity visible to marketing before requests are submitted.

At the start of each month, I do a capacity planning session where I estimate design hours available in each cycle and assign them to initiatives—product work, marketing support, design system work, strategic projects. Marketing can see what’s committed and what has room before they scope their campaigns.

This changes the conversation from “can you do this by Friday?” to “the Q2 product launch is in cycle 5—here’s what I have available, here’s what will need to move or wait.” It’s the difference between reactive capacity management and proactive capacity management. The former creates resentment. The latter creates respect.

We also use labels to distinguish work types:

brand for brand-consistency work that either team can audit
campaign for time-bounded marketing campaigns with external deadlines
product-marketing for launches and feature announcements that bridge both backlogs
always-on for recurring deliverables (social, blog, email)

These labels make the design backlog legible to marketing without requiring design to explain priorities from scratch in every sync.

How do you prevent design from becoming a request-taking service?

The pattern I’ve seen most often in startups is design-as-order-taker: marketing generates demand, design fulfills it. This is bad for both teams. Marketing doesn’t get the strategic design input that would make their campaigns stronger. Design doesn’t get the context that would make their output better. And the design team’s motivation and quality decline because the work is execution without ownership.

The structural fix is making design an upstream participant in campaign strategy, not a downstream executor of it.

Concretely: marketing brings design into campaign strategy sessions before the brief is written. Not to design the campaign, but to help shape what the campaign is trying to do. Questions like “what’s the visual metaphor that makes this message land?” or “what format is most effective for this audience at this stage?” are design questions that, when answered in the strategy phase, produce dramatically better briefs. Better briefs produce better work. Better work requires fewer revision rounds. The investment in the upstream conversation pays back in the downstream execution.

The linear project structure supports this: the brief phase includes a design review step before creative direction begins. Marketing can’t declare the brief done without design acknowledging they have enough to work with. It’s a small structural change that produces a big behavioral change over time.

Building trust through operational visibility

The compounding effect of good tooling paired with good process is that it changes the relationship from transactional to collaborative. When design and marketing operate in the same workspace with shared visibility into priorities, capacity, and status, both teams make better decisions—not just about their own work, but about how their work fits together.

Marketing stops treating design requests as independent tasks and starts thinking about design capacity as a shared resource to plan around. Design stops feeling like a service that reacts to demand and starts feeling like a partner that shapes demand. These are different team cultures, and the difference is almost entirely structural—it comes from visibility and shared infrastructure, not from personality or goodwill.

The trust compounds. After a few months of operating this way, marketing brings design into briefs earlier because they’ve seen the quality improvement it produces. Design brings marketing into product launches earlier because they’ve seen how marketing input shapes launch strategy. What starts as a workflow becomes a relationship.

For the technical collaboration side of this—how design and marketing use AI to actually build the assets that come out of this workflow—shipping landing pages with Cursor, Claude Code, and GitHub covers the end-to-end build process that follows a well-structured brief.

What good design-marketing collaboration looks like at scale

As the team and the project volume grow, the shared Linear workspace becomes the operating system for the design-marketing relationship. Here’s what mature operation looks like:

Weekly sync is short. Fifteen minutes, focused on what’s moving between phases and what needs cross-team alignment. Not status updates—Linear handles status updates. The sync is for decisions and blockers.
Quarterly planning is joint. Design and marketing plan their capacity together at the start of each quarter. Marketing knows what design bandwidth they have for campaigns. Design knows what marketing has coming and can plan system work (new components, brand updates) to coincide with campaign needs.
Post-mortems are shared. When a launch goes well or badly, both teams review it together in Linear. What shipped on time? What blocked production? What brief gaps caused revision rounds? The retrospective is operational, not political.
Documentation lives in the project. Brief, creative direction decisions, asset list, approval record, and post-launch notes all live on the Linear project. When someone joins either team six months later, the project is a self-contained record of what was built and why.

This level of operational maturity doesn’t happen immediately. It develops over one or two quarters of consistent practice. The setup cost is low—a few hours to build the project templates and brief formats. The compounding benefit over twelve months is large.

For how this model connects to the broader design leadership practice of working across functions, design as the creative hub covers how design builds the cross-functional operating space that makes this kind of collaboration possible at the company level.

Key Takeaways

Design-marketing friction is structural, not interpersonal: invisible capacity, misaligned priorities, contextless requests, and undefined done are the root causes
The shared Linear workspace creates operational infrastructure that gives both teams real-time visibility into capacity, status, and priorities
Use consistent project phases (brief, creative direction, production, review, ship) with explicit owners and handoff conditions—this eliminates the “where are we?” ambiguity that creates most friction
Make design an upstream participant in campaign strategy before the brief is written—the investment in strategy alignment pays back in fewer revision rounds during production
Trust compounds with consistent operational practice: after a few quarters, both teams start planning together rather than reacting to each other

Design as the creative hub: where every team does their best work

Tue, 03 Jun 2025 00:00:00 GMT

There’s a pattern I’ve seen in every product company I’ve worked with over the past 15 years: when teams need to think through something hard—a new feature, a GTM strategy, a technical architecture decision—they end up in design’s space. Not because design owns those decisions, but because design has the tools, the rituals, and the mindset that make creative thinking visible and collaborative. Design became the hub not by claiming territory, but by building a space where anyone can contribute, where ideas are tangible from minute one, and where the messy middle of problem-solving is welcome instead of hidden. That shift—from design as a service to design as the creative operating system for the company—changed how I lead teams and how I think about the discipline itself.

The whiteboard moved to the cloud, and design was already there

Before remote work became the default, the best cross-functional thinking happened in front of a whiteboard. Engineers would sketch system diagrams, product managers would map user flows, marketers would storyboard campaign ideas—all in the same physical room, all using the same basic tools: markers, sticky notes, and a shared wall. When the pandemic forced everyone remote, most teams lost that space entirely. They replaced whiteboards with slide decks and meetings with more meetings. The energy of collaborative thinking evaporated into a grid of Zoom thumbnails.

Design teams didn’t lose that space because we had already digitized it. Tools like FigJam, Miro, and Figma itself were our daily environment. We were already working spatially—laying out ideas on infinite canvases, clustering concepts, mapping relationships visually. When the rest of the company needed to collaborate remotely, the design team’s workspace was the only one that actually replicated the feeling of standing in front of a whiteboard together. So people showed up. Product managers started running their planning sessions in FigJam. Engineers started sketching architecture decisions in shared boards. Marketing started brainstorming campaigns with sticky notes and voting dots. Design didn’t take over those processes—we just opened the door and said, “The tools are here, the space is ready, come build with us.”

FigJam changed the game, but the mindset matters more than the tool

I’m a FigJam evangelist, but I want to be honest about why: it’s not because FigJam is magic. It’s because FigJam lowers the barrier to participation so dramatically that non-designers actually use it. That’s the real breakthrough. Figma’s design files are powerful but intimidating—ask a backend engineer to drop feedback on a Figma comp and you’ll see hesitation, even if they have strong opinions. FigJam strips away that intimidation. Sticky notes, stamps, drawing tools, timers, voting—it’s a toolkit designed for thinking together, not for pixel-perfect output. And because it lives inside the Figma ecosystem, the bridge between “rough thinking” and “designed solution” is seamless. A brainstorming session in FigJam can feed directly into a design file, which feeds into a prototype, which feeds into an engineering spec. The entire arc from idea to implementation stays in one connected space.

But here’s the thing: you can have FigJam in every team’s toolkit and still not get real collaboration. The tool only works if the culture supports it. I’ve seen teams where product managers treat FigJam sessions as presentations—they show up with a finished board and ask for reactions instead of contributions. That’s not collaboration, that’s a slide deck on a canvas. Real collaboration in these tools requires a design-thinking mindset: start with the problem, not the solution. Make space for divergent thinking before converging. Let people put bad ideas on the board without judgment, because bad ideas are the compost that good ideas grow from. That mindset is something designers practice every day. It’s the foundation of our discipline. And when we bring non-designers into our space, we’re not just sharing a tool—we’re sharing a way of thinking.

Design thinking isn’t a workshop—it’s an operating mode

I have a complicated relationship with the phrase “design thinking.” It’s been commodified into two-day corporate workshops with Post-it notes and empathy maps that lead nowhere. But the core principles—empathize, define, ideate, prototype, test—are genuinely powerful when they’re practiced as a daily habit instead of a quarterly event. In every team I’ve led, I embed design thinking into the regular cadence of work, not as a special process but as the default mode of cross-functional collaboration.

Here’s what that looks like in practice. When a new initiative kicks off—say, a new feature that involves product, engineering, and marketing—we don’t start with a requirements doc or a Jira epic. We start with a FigJam session where everyone maps what they know about the problem. Product brings user research and business context. Engineering brings technical constraints and system knowledge. Marketing brings market positioning and competitive intel. Design facilitates the session and synthesizes what emerges into a shared problem statement. That problem statement becomes the anchor for everything that follows. It’s not a design artifact—it’s a team artifact, created collaboratively, owned collectively. When debates arise later about scope or direction, we go back to that board and ask: does this serve the problem we agreed on?

The prototyping phase is where design’s tools become the team’s tools. Instead of writing long specs that get misinterpreted, we build low-fidelity prototypes in Figma that everyone can click through, react to, and annotate. Engineers flag technical risks early by interacting with the prototype, not by reading about the feature in a document. Marketers validate messaging by seeing it in context, inside a realistic flow, not in a Google Doc. The prototype becomes the single source of truth—a living artifact that evolves with the team’s understanding, not a static deliverable that gets handed off and forgotten.

The creative space is a leadership strategy

Opening design’s space to the entire company isn’t just about better collaboration—it’s a leadership strategy. When engineering, product, and marketing regularly work inside design’s tools and rituals, they develop a visceral understanding of what design contributes and why it matters. They see the thinking behind the pixels. They experience the iterative process firsthand. That visibility builds trust and political capital in ways that presentations and case studies never can. A VP of Engineering who has brainstormed in FigJam alongside designers understands the discipline differently than one who only sees final mockups in a review meeting.

It also changes the dynamic around ownership and accountability. When a feature is conceived collaboratively in a shared FigJam board, with sticky notes from every function, the outcome belongs to the team—not to design, not to product, not to engineering. That shared ownership reduces the finger-pointing that plagues cross-functional work. Nobody can say “design got it wrong” when they were in the room co-creating the direction. Nobody can say “engineering didn’t understand the intent” when they were clicking through the prototype and flagging issues in real time. The creative hub model distributes both the credit and the responsibility, which is exactly what healthy product teams need.

This is directly connected to how design leadership earns influence in engineering-led cultures. For the concrete day-to-day practices, how I embed in engineering teams as a design director covers the sprint rituals and collaboration patterns that make this cross-functional trust durable.

Remote-first rituals that actually work

Running this model remotely requires intentional rituals. Here’s what I’ve found works, refined across multiple startups and distributed teams:

Weekly design jams (30 minutes, open to anyone). A standing FigJam session where the design team works through a current problem in the open. Product managers, engineers, marketers—anyone can drop in, observe, or contribute. It’s not a meeting; it’s a working session with an audience. The transparency alone changes how design is perceived: people see that design is problem-solving, not decoration.

Async critique boards. A shared Figma file where work-in-progress is posted with context and questions. Anyone in the company can leave comments. This replaces the traditional design review with something more inclusive and less performative. Engineers often catch interaction issues that designers miss. Marketers flag messaging inconsistencies. The quality of the work improves because the feedback surface area is wider.

Problem-framing kickoffs in FigJam. Every new initiative starts with a 60-minute collaborative session in FigJam. The facilitator (usually a designer, but not always) runs a structured exercise: problem mapping, stakeholder needs, “How Might We” questions, and dot-voting on priorities. The output is a shared board that becomes the project’s north star. No slides, no pre-baked solutions—just collective sense-making.

Show-and-tell Fridays. A 20-minute end-of-week session where anyone—designer, engineer, PM, marketer—shows something they made or learned that week. It could be a prototype, a code snippet, a campaign result, a FigJam template. The point is to celebrate making and learning across disciplines. It keeps the creative energy alive and reinforces that the hub belongs to everyone.

How do you sustain the creative hub culture as the company scales?

This is the hardest question. The creative hub model works naturally in small teams (under 20 people) where everyone is close enough to the work that participation feels relevant. At scale, the challenge is keeping cross-functional collaboration from devolving into siloed process.

The answer is structural: the rituals need to be maintained deliberately as the company grows. The weekly design jam doesn’t stop when the team gets to 50 people—it might need a more defined structure, or it might branch into domain-specific sessions, but the principle of open working sessions stays. The problem-framing kickoff doesn’t get replaced by a requirements doc when the product organization formalizes—it gets formalized itself, as the kickoff ritual for every major initiative.

The design team’s responsibility is to steward these practices proactively. Not to impose them on the organization, but to keep offering the space, demonstrating the value, and inviting people in. The companies where design maintains strategic influence at scale are the ones where the design team never stopped opening the door.

For teams operating in distributed setups across time zones, DesignOps for distributed startups covers the operational infrastructure that keeps this kind of culture functional across geographic distance and departments.

The tools are just the beginning

FigJam, Figma, Miro, Whimsical, Loom, Notion—the specific tools matter less than the principle they enable: make thinking visible, make collaboration spatial, and make the creative process accessible to non-designers. I happen to live in the Figma ecosystem because it connects ideation (FigJam) to design (Figma) to development (Dev Mode) in a way that no other toolchain does. But the real insight isn’t about Figma. It’s about what happens when design stops being a downstream function that receives requirements and starts being the upstream space where requirements are shaped. When engineering thinks in your space, they build better. When marketing thinks in your space, they position better. When product thinks in your space, they prioritize better. Design as a creative hub isn’t about design owning more—it’s about design enabling more. And in a remote-first world where the physical whiteboard is gone, the team that builds the best digital creative space wins. That team is usually design. Not because we’re more creative, but because we’ve been practicing this longer than anyone else.

Key Takeaways

Design became the default creative hub not by claiming territory but by building tools and rituals that make collaborative thinking accessible to non-designers
FigJam’s value is that it lowers the participation barrier enough that engineers, PMs, and marketers actually use it—the tool is only as good as the culture that supports it
Embedding design thinking into regular work cadence (problem-framing kickoffs, async critique boards, weekly design jams) is more powerful than periodic design thinking workshops
Shared ownership from collaborative creation eliminates the finger-pointing that plagues cross-functional work—credit and accountability distribute together
At scale, sustain the creative hub by maintaining the rituals deliberately: the open working sessions and kickoff structures need to be protected as the organization formalizes

Design as a fundraising multiplier: decks, brand, and investor trust

Tue, 20 May 2025 00:00:00 GMT

Fundraising is a design problem. Not in the superficial sense of making a pitch deck look pretty—in the structural sense that every artifact a startup produces for investors is a designed experience, whether you treat it that way or not. The pitch deck. The one-pager. The landing page. The product demo. The follow-up email. The data room. Each one is a moment where an investor forms an impression of your company’s clarity, taste, and attention to detail. Most startups treat these as separate, ad hoc deliverables. The ones that raise well treat them as a coordinated brand experience, because that’s what they are.

Why investors read design quality as organizational quality

Investors are pattern matchers. They’ve reviewed thousands of companies, and they develop calibrated instincts for signals that correlate with the things they care about: quality of execution, attention to detail, capacity to ship, and team cohesion. Design quality isn’t aesthetics to an experienced investor—it’s a proxy for organizational quality.

A pitch deck that’s typographically inconsistent, spatially incoherent, and casually assembled signals something: this team either doesn’t notice these things or doesn’t care about them. Either reading is bad. A team that doesn’t notice small execution failures is not going to notice them in their product. A team that notices but doesn’t care has made a judgment call about what matters, and they’ve decided polish doesn’t.

A pitch deck that’s clean, hierarchically clear, and visually consistent with the company’s brand and product signals something different: this team sweats the details, has a shared visual language, and can execute end-to-end. These signals are most powerful when they’re consistent across every investor touchpoint—not just the deck, but the one-pager, the landing page, the product demo, the follow-up materials.

This is why design is a fundraising multiplier: it makes the organizational quality of your team visible in every artifact you produce. You can’t hide execution culture behind good presentation—but you can let bad presentation obscure good execution culture. The downside risk is larger than most founders realize.

What does a well-designed fundraising campaign look like?

A well-designed fundraising campaign has visual and narrative coherence across four artifact categories: presentation materials, digital presence, product demonstrations, and physical touchpoints.

Presentation materials: pitch deck, executive summary, one-pager, financial model deck. These should share a visual language: consistent typography, a coherent color palette, the same approach to data visualization. Not identical—a one-pager and a 50-slide deck are different formats with different requirements—but clearly from the same company, designed by people who made intentional choices.

The pitch deck specifically is a narrative design problem. The structure—problem, solution, market, traction, team, ask—is well-established enough that departing from it confuses investors. But within that structure, the pacing, the visual emphasis, and the information hierarchy are design decisions that determine whether the narrative lands. The slides that deserve emphasis should look different from the supporting slides. The data visualization should clarify, not decorate. The visual language should reinforce the brand promise, not contradict it.

Digital presence: the company website and product, the founder’s professional profiles, any public-facing content (blog posts, press, case studies). Investors will look at all of these. An impeccably designed pitch deck followed by a generic, under-maintained website is a contradiction that erodes the impression the deck built. The website should be the highest-fidelity expression of the brand—it’s the artifact that has the most surface area and the longest engagement time.

Product demonstrations: live demos, recorded walkthroughs, interactive prototypes. These are where design quality is most directly legible. A product that loads fast, handles edge cases gracefully, and has clear interaction patterns signals engineering and design competence simultaneously. A product that crashes or shows loading states that clearly haven’t been designed signals the opposite.

Physical touchpoints: events, investor dinners, in-person meetings. The physical environment design—banners, printed materials, the space itself—sets the tone for in-person interactions. For later-stage fundraises with significant events, physical production quality matters.

How to structure a fundraise as a design project

The biggest mistake I see in startup fundraising is treating design as a late-stage polish step. Founders spend weeks on the narrative and financials, then hand the deck to a designer two days before the meeting. That’s backwards. Design should be embedded from the start: shaping how the story is structured, how data is visualized, how the brand shows up across every format.

Here’s how I structure a fundraising design project when I work with founders:

Week 1: Narrative and structure audit. Before any visual work, review the narrative: Is the problem clearly defined? Does the solution directly address the problem as stated? Is the market sizing credible and well-sourced? Does the traction tell a compelling story? Is the ask concrete and the use of proceeds specific? These are content questions, not design questions. They have to be answered before you design anything.

Week 2: Brand and visual language alignment. What visual language does the company have? Is it documented? Is it being applied consistently? If not, this is the moment to establish or refresh it—not with a full rebrand, but with enough definition that every fundraising artifact looks like it comes from the same place. Fonts, colors, data visualization style, photography or illustration approach.

Week 3: Deck design. With the narrative and visual language set, design the deck. Build it as a system of templates, not a collection of ad hoc slides. The templates should be reusable for future versions—fundraising materials change constantly during a process, and a system of well-structured templates makes updates fast.

Week 4: All other artifacts. One-pager, website updates, demo environment review, physical materials if needed. Each gets the same visual language applied with appropriate format-specific judgment.

The build process for presentation materials has been changed significantly by AI tools. For the workflow that compresses weeks of production into hours using Claude Code and Cursor, shipping landing pages with Cursor, Claude Code, and GitHub covers the pattern that applies equally to fundraising microsites and landing pages.

What makes a pitch deck narrative land?

The narrative design of a pitch deck is a distinct skill from visual design, and it’s worth discussing separately because it’s where most design help falls short.

A pitch deck narrative works when:

The problem is felt, not stated. Rather than “the market for X is $50B,” show a specific person with a specific problem that this product solves. The investor should feel the problem before they’re told it’s large.
The solution is specific about the mechanism. What specifically does the product do that others don’t? Not “10x faster” in isolation, but what mechanism makes it 10x faster and why is that mechanism defensible?
The traction slide tells a story, not just metrics. Show trajectory. Show that the growth has an explanation—a specific thing you did that caused an inflection point. Unexplained growth is less convincing than explained growth at a slower rate.
The team slide explains why this team, for this problem. Not just credentials, but the specific combination of experiences and perspectives that makes this team the right one to build this specific thing.
The ask is concrete and the use of proceeds is specific. “We’re raising $3M to hire two engineers, one marketer, and fund 18 months of runway to reach X milestone” is more compelling than “We’re raising to grow the team and extend the runway.”

The visual design of the deck supports this narrative—it doesn’t replace it. Emphasis, pacing, and hierarchy are visual tools for making the narrative land. But no amount of visual design rescues a narrative that doesn’t hold together.

The coherence dividend: what happens when everything looks like it comes from the same company

When every touchpoint—deck, website, one-pager, demo, physical materials—feels like it was designed by the same team with the same standards, an investor forms a specific kind of impression: this is a company that has thought carefully about how they present themselves, which means they’ve thought carefully about how they build their product. The impression compounds with each additional touchpoint.

This is the fundraising multiplier in practice. It’s not that great design makes a bad company look good. It’s that design quality is genuine organizational signal—it reflects how the team thinks about quality, execution, and the experience of everyone who interacts with their work. Investors who have been doing this for twenty years have calibrated instincts for this signal. The coherence is felt, even when it’s not explicitly analyzed.

For the operational side of building this kind of coherent design output across design and marketing—the project management and workflow infrastructure that makes it sustainable—how Head of Design and Head of Marketing actually collaborate covers the systems that produce this consistency at speed.

Key Takeaways

Fundraising is a design problem at the structural level: every investor touchpoint is a designed experience that builds or erodes conviction, regardless of whether you treat it that way
Investors read design quality as organizational quality: visual consistency, attention to detail, and execution polish are proxies for the team’s broader capacity to build and ship
A well-designed fundraise has visual coherence across four categories: presentation materials, digital presence, product demonstrations, and physical touchpoints
Embed design from week one of a fundraising process—narrative structure and brand alignment before visual execution—not as a last-minute polish pass
The coherence dividend compounds: each additional touchpoint that feels like it comes from the same company reinforces the impression of organizational quality built by previous touchpoints

DesignOps for distributed startups across time zones

Tue, 06 May 2025 00:00:00 GMT

Design operations in a distributed startup is not about managing designers. It is the operational infrastructure that connects design output to every department in the company — product roadmaps, engineering handoffs, marketing campaigns, investor decks, customer-facing communications — across countries, time zones, and fundamentally different working hours. Over the past 15 years leading design for US-based startups from LATAM, the teams I’ve seen succeed all share one trait: they treated DesignOps as cross-departmental wiring, not as an internal design-team concern. The teams that failed treated design as a service that receives requests and delivers files. In a distributed company, that model collapses. When your product engineer is in São Paulo, your marketing lead is in Austin, your CEO is in New York, and your customer success manager is in Lisbon, design cannot function as a queue. It has to function as connective tissue — the operational layer that keeps every department’s output coherent, on-brand, and moving at startup speed without depending on synchronous coordination.

What DesignOps actually means at a 15–50 person distributed startup

At large companies, DesignOps is often a dedicated team: people who manage Figma libraries, run research repositories, coordinate design hiring, and maintain toolchains. At a 15–50 person distributed startup, DesignOps is not a team. It is a set of systems, processes, and toolchain decisions that the design leader builds, maintains, and enforces. The role is invisible when it works — every department gets what it needs from design without friction — and painfully visible when it doesn’t.

The distinction matters because it changes who owns what. At this stage, the Head of Design is the DesignOps function. There is no one else to delegate it to. Every decision about how design artifacts flow into engineering tickets, how marketing accesses brand assets, how the CEO gets the board deck updated, and how customer feedback reaches the design backlog — those are all DesignOps decisions, and they compound. Get them right in the first year and the company scales with design as a multiplier. Get them wrong and every department develops its own workarounds: marketing builds rogue templates, engineering makes UI decisions in code without design input, and the CEO starts asking “where is design?” in standups.

The mental model I use: DesignOps at startup scale is building the wiring of a house, not decorating the rooms. The wiring is invisible, but everything that matters depends on it.

The cross-departmental wiring

The core of DesignOps in a distributed startup is connecting design to five departments, each with a different relationship to design output. Each connection requires its own operational infrastructure.

Product: shared roadmap, prototype-driven specs

Design and product need bidirectional visibility. Product needs to see design capacity and work-in-progress at any time. Design needs to see the product roadmap and upcoming priorities before they become urgent requests.

I build this connection through a shared Linear workspace where product initiatives and design work live in the same system. When a product initiative reaches the “design needed” stage, it already has context — user research references, business goals, success metrics — attached to the ticket before design starts. Design responds with prototypes in Figma, not with abstract specs or decks. The prototype becomes the shared artifact that product, engineering, and design align around. When a prototype exists, “what are we building?” stops being an abstract conversation and becomes something everyone can click through and react to.

Design also participates in product prioritization — not to own the roadmap, but to flag feasibility constraints, identify opportunities for design-system leverage, and sequence work that has cross-cutting design implications. This participation is especially critical in a distributed team where these conversations happen asynchronously: if design’s input arrives after prioritization is locked, it has no effect.

Engineering: design QA, tokens, and PR-level fidelity

The connection between design and engineering is the most operationally demanding and the most consequential for shipped quality. In a distributed team where designers and engineers may never share a physical space, the operational infrastructure has to be explicit enough that both sides can work independently and still converge on the same output.

Three systems carry this connection. First, the design system — specifically design tokens — serves as shared infrastructure between Figma and the codebase. When both design and engineering reference the same token set, the gap between the design file and production narrows structurally. Second, I build a design QA step into the engineering workflow: before a front-end PR merges, the design lead reviews it for visual and interaction fidelity. This is not optional polish — it is the quality gate that prevents the slow divergence between design intent and production reality that plagues distributed teams. Third, design participates directly in sprint rituals — planning, review, retro — as a collaborator, not an external stakeholder waiting for a handoff. For the specific patterns that make this embedding work, how I embed in engineering teams as a design director covers the sprint-level practices in depth.

Marketing: campaigns, templates, and capacity planning

In most startups I’ve worked with, marketing is the department that most frequently needs design output and least frequently has visibility into design capacity. The result is predictable: last-minute requests, mismatched expectations, and a design team that feels like an order-taking service.

The fix is operational, not cultural. Design and marketing share project infrastructure — shared Linear projects with consistent phases (brief, creative direction, production, review, ship), shared capacity visibility, and explicit handoff conditions between phases. Marketing can see what design has committed to before submitting requests. Design can see marketing’s campaign calendar before capacity conflicts emerge. For the detailed mechanics of how this works, how Head of Design and Head of Marketing actually collaborate covers the shared Linear workspace structure that makes this sustainable.

Beyond project management, DesignOps builds the template and asset infrastructure that lets marketing operate at speed without waiting for design on every deliverable. Brand-consistent templates in Figma, a maintained component library for marketing assets, documented brand guidelines that a non-designer can follow — these are DesignOps outputs that multiply marketing’s throughput without increasing design headcount.

Executive, CEO, and fundraising: translating vision into artifacts

The CEO of a distributed startup needs design output for contexts that are invisible to most design teams: board decks, investor updates, fundraising materials, internal all-hands presentations, and the company narrative that gets told in every external meeting. In a co-located company, the CEO can walk over to the design lead and ask for a deck. In a distributed company, that interaction has to be systematized or it becomes a fire drill every board meeting.

I treat executive artifact production as a DesignOps workflow with its own cadence. Board decks follow a quarterly template. Investor materials have a maintained component library. The company narrative — the visual language, the data visualization patterns, the slide structure — is documented and versioned so that updates are incremental rather than from-scratch. When the CEO needs a deck for a partner meeting on Thursday, the DesignOps infrastructure means the starting point is 80% there, not a blank Figma file.

This also extends to internal communication. When the CEO presents a quarterly plan to the company, the visual quality and consistency of that presentation shapes how the team perceives company direction. DesignOps ensures those materials match the same brand standards as the product and the marketing site. The CEO should not have to think about whether their slides look professional — that is an ops problem, not a design taste problem.

Customer experience: closing the feedback loop

The most underbuilt DesignOps connection in most startups is between design and customer experience. Support tickets, NPS comments, churn interviews, and customer success calls contain signals that should influence design decisions — but in a distributed company, those signals often never reach the design team because there is no infrastructure to carry them.

I build a lightweight research ops layer: a shared channel where customer-facing teams post notable feedback tagged by product area, a quarterly synthesis where design reviews accumulated signals and maps them to the product roadmap, and a direct line between the design lead and the customer success lead for high-severity experience issues. The goal is not to turn design into a research team — it is to make sure customer reality informs design decisions without requiring designers to attend every support call.

How do you architect DesignOps for teams spread across 3+ time zones?

When your team spans three or more time zones — say, LATAM, US Eastern, and Western Europe — the DesignOps infrastructure has to be async-first by default. Synchronous coordination becomes a scarce resource rather than the default mode.

The architecture I use has three layers.

The async layer handles everything that does not require real-time judgment. Design artifacts, documentation updates, status changes in Linear, Figma comments, and Loom walkthroughs all flow asynchronously. When a designer in Buenos Aires finishes a prototype at 6pm local time, the engineer in Austin picks it up at 9am with a Loom walkthrough and annotated Figma file — no meeting required. The quality of this layer depends entirely on documentation discipline: every artifact must be self-explanatory to someone who was not in the room when it was created.

The overlap layer uses the natural time-zone intersections for synchronous decisions. I map overlap windows per department, not just per team. Design-engineering overlap might be 10am–2pm CT. Design-marketing overlap might be 9am–12pm CT. Design-executive overlap might be a single 30-minute slot per week. Each overlap window has a purpose: the design-engineering window is for PR reviews and sprint alignment; the design-marketing window is for campaign kickoffs and review sessions; the design-executive window is for board deck reviews and strategic alignment. Protecting these windows from being consumed by low-value meetings is one of the most important DesignOps disciplines.

The handoff layer structures what happens at the seam between time zones. When the European team’s day ends and the LATAM team’s day is in full swing, every in-progress artifact should have a clear status in Linear, an updated Figma file, and — for complex work — a Loom recording explaining decisions made and questions pending. This follow-the-sun cadence means the company’s design output moves forward nearly continuously without requiring anyone to work outside their normal hours.

The toolchain as operational infrastructure

The tools are not the DesignOps — they are the medium through which DesignOps flows. But choosing and connecting them deliberately is what separates a functioning ops layer from a collection of subscriptions.

Figma is the source of truth for all design artifacts — product UI, design system, marketing templates, executive deck components. It is also the cross-functional collaboration space where non-designers participate in design thinking through FigJam. For how this collaborative model works in practice, design as the creative hub covers the rituals that make Figma a company-wide tool rather than a design silo.

Linear is the project visibility layer. Every department’s interaction with design — product initiatives, engineering sprints, marketing campaigns, executive projects — lives in Linear with consistent statuses and ownership. This is the single surface where anyone in the company can answer “what is design working on?” without asking.

GitHub is the design-to-engineering pipeline. Design tokens versioned in the repo, PR reviews for UI fidelity, branch preview deployments where design can review in-browser before merge. For design directors who write code, it is also where design decisions become production reality.

Loom is the async decision layer. Design reviews, prototype walkthroughs, and context-setting recordings that cross time zones without requiring a meeting. A three-minute Loom replaces a thirty-minute sync in most cases.

AI pipelines amplify every layer. Template generation from design system components, automated asset production for marketing, structured report generation for executive materials — AI workflows turn the DesignOps infrastructure from a manual process into a scalable system. For the specific AI integrations that make this work, AI-assisted design workflows covers what is production-ready and what is still hype.

Key Takeaways

DesignOps at a distributed startup is not a team or a role — it is the operational wiring the design leader builds to connect design output to product, engineering, marketing, executive reporting, and customer experience across time zones
Each department needs its own connection to design with specific infrastructure: shared roadmaps with product, design QA and tokens with engineering, campaign workflows and templates with marketing, artifact systems with executive leadership, and feedback loops with customer experience
Async-first is the default for 3+ time zone teams — protect overlap windows for synchronous decisions and structure handoffs so work moves forward continuously across time zones
The toolchain is not a list of subscriptions — it is a connected system where Figma, Linear, GitHub, Loom, and AI pipelines each serve a specific operational function
DesignOps infrastructure built in the first year determines whether design becomes a throughput multiplier for the company or a bottleneck that every department routes around

Nearshore design leadership: why US companies hire in LATAM

Tue, 15 Apr 2025 00:00:00 GMT

US companies have been hiring nearshore engineering talent in Latin America for years. Design leadership is the next wave: senior designers and design directors who can own product vision, build and lead teams, and work in real time with US-based product and engineering. As a design director and Head of Design based in Guatemala, I’ve led product design for global brands and US startups alike—operating in full overlap with Central and Eastern time. What I’ve seen from both sides of these engagements is that the model works extremely well when structured correctly, and fails in predictable ways when it isn’t. Both outcomes are preventable.

What nearshore design leadership actually means

Nearshore design leadership means hiring a senior design practitioner—Head of Design, Design Director, VP of Design—who is based in Latin America but operates in US time zones and with US product culture. It’s distinct from offshore (significant time-zone gap, primarily execution-focused) and from fully distributed (no shared time zone anchor).

The LATAM advantage is specific: countries like Guatemala, Mexico, Colombia, Argentina, and Brazil are in the same or adjacent time zones as the US East and Central markets. A design director in Guatemala City is at most one hour behind New York. A designer in Buenos Aires is two hours ahead of New York. This means real-time collaboration—morning standups, live design reviews, spontaneous pairing sessions—is practical without scheduling gymnastics.

This is the key distinction that separates nearshore from offshore. The value of a senior design leader is disproportionately in real-time decisions: the design review where someone challenges a direction and needs to work through it in the room, the product call where design input shapes what gets prioritized, the engineering pairing session where a complex interaction gets resolved together. Those moments require synchronous presence. Nearshore LATAM makes that synchronous presence available without requiring US-based hiring.

Why US startups need senior design leadership outside traditional hiring

The hiring market for senior design leaders in the US has been consistently expensive and competitive for the past decade, with periodic corrections that don’t fundamentally change the structural economics. A Head of Design in a major US tech hub commands a total compensation package that’s out of reach for most seed-to-Series B startups.

The result is a predictable pattern: startups either hire too junior (IC designers managing up to product leadership, without the organizational design skills the role requires) or hire too late (waiting until Series B or C to bring in design leadership, by which point significant product and brand debt has accumulated). Both patterns are expensive in ways that don’t show up directly on the hiring budget but show up clearly in product quality, design system debt, and engineering friction.

Nearshore design leadership breaks this pattern. A senior design director from LATAM brings the same strategic capability—product vision, design systems, team building, cross-functional leadership—at a structural cost difference that makes the hire practical at the seed and Series A stage, when design leadership would have the most compounding value.

The cost difference is real and significant. But the more important point is that it makes the right hire possible at the right time, rather than forcing startups to choose between under-resourced design and delayed design leadership. For a deeper breakdown of the cost math and the diversity-of-thinking return on that investment, see the LATAM advantage: nearshore design leadership ROI for US startups.

The skills that compound in nearshore design leadership

After years leading product design from Guatemala for US companies, these are the capabilities I’ve seen matter most—for myself and for every effective nearshore design leader I’ve worked alongside. They rarely show up in a portfolio, but they’re what makes the model work.

Real-time communication as a core skill. Running a design review, handling pushback in a product meeting, communicating a design rationale to a skeptical engineer—these are the moments where nearshore design leadership is won or lost. My recommendation to any designer moving into this kind of role: treat real-time communication as a skill you deliberately practice, not something you assume you’re already good at. The gap between “fluent in English” and “persuasive in a live product conversation” is real, and closing it is worth the investment.

Deep familiarity with US product culture. Working in agile environments, understanding the relationship between design and engineering velocity, knowing how to prioritize ruthlessly in early-stage products, communicating design decisions in terms that resonate with product and business stakeholders—this fluency is learned through reps, not acquired through exposure. I’d encourage designers considering nearshore leadership roles to seek out US-facing product work early and often, because the pattern recognition compounds.

Systems thinking at the leadership level. Individual contributors can have strong craft without systems thinking. At the design director level, systems thinking is the job: how does this design decision compound over time, how does the design system support product velocity, how do I build a team that scales without breaking. Invest in understanding not just the artifacts you design, but the processes and organizational systems around them—that’s the work that separates a senior IC from a design leader.

Technical fluency as a force multiplier. The right level depends on the company, but design directors who can read code, review front-end PRs, work in git, and use developer tools fluently create dramatically less friction with engineering. In a nearshore setup where in-person collaboration isn’t the default, technical fluency reduces the communication overhead that distance creates. If you’re a designer aiming for this kind of role, building technical literacy is one of the highest-leverage investments you can make.

How do you structure the engagement to make nearshore design leadership work?

The structure of the engagement determines whether the model works or fails. The most common failure mode is treating a nearshore design director as an outsourced contractor when the role requires organizational ownership.

The structural conditions that make nearshore design leadership successful:

Same access as a US-based hire. Same tools, same Slack channels, same meeting invites, same product roadmap visibility, same engineering relationship access. Any asymmetry in information access limits the design director’s ability to lead, regardless of their capability.

Explicit ownership scope. What design decisions does this person own vs. influence vs. consult on? Ambiguity about ownership is the number-one source of frustration in both directions. Define it upfront and revisit quarterly.

Regular 1:1 with the CEO or CPO. Design leadership at the senior level needs access to company strategy and to the people shaping it. A nearshore design director without a direct line to senior leadership will struggle to position design correctly inside the organization, no matter how strong their execution is.

A reasonable overlap window. Four hours of daily overlap is the minimum for effective real-time collaboration. Most LATAM-to-US pairings have six to eight hours of natural overlap, which is more than enough. The key is protecting that window—not scheduling the design director in US meetings at 7am their time consistently, and not expecting real-time responses during their evening.

For the operational side of managing distributed design teams inside this model, DesignOps for distributed startups covers the cross-departmental wiring and communication patterns in detail. And for the team-structure layer—ownership models and communication rituals that keep distributed teams accountable—how I structure remote design teams for US startups covers the operating patterns.

The cultural context that makes LATAM designers strong partners

The specific cultural context of LATAM design talent is worth understanding. Latin American design education and practice have been shaped by strong graphic design and communication traditions, increasingly strong digital product design programs, and extensive early-career exposure to US clients through agency and nearshore engagements.

The resulting profile—designers who are fluent in English, experienced with US product culture, and trained in both visual craft and product thinking—is a specific kind of talent that the LATAM ecosystem produces consistently. It’s not the only profile that works for US companies, but it’s a strong match for the senior IC and design leadership roles that startups need most. That ecosystem is also actively built, not just inherited—what I learned founding a Figma design community in LATAM is one example of how the region’s design network compounds.

There is also a work ethic dimension that practitioners who’ve worked across markets comment on consistently: LATAM design professionals tend to invest heavily in skill development, are comfortable working in ambiguous early-stage environments, and bring both the craft focus of a strong design culture and the pragmatism that comes from working in resource-constrained markets. These are traits that translate directly into early-stage product environments.

Key Takeaways

Nearshore design leadership means senior design directors based in LATAM who operate in US time zones—not offshore execution, but real-time strategic collaboration
The primary value is making the right design leadership hire possible at the right stage (seed to Series A) at a cost structure that’s realistic for early-stage companies
The skills that compound most in nearshore leadership—real-time communication, US product culture fluency, systems thinking, and technical literacy—aren’t visible in a portfolio but are worth deliberate investment
Structure the engagement with the same access and ownership as a US-based hire; asymmetry in information access or ownership scope is the leading failure mode
Four hours of daily overlap is the minimum; most LATAM-to-US pairings have six to eight, which is more than sufficient for full-time leadership collaboration

Digital to physical: AI concepts, materials, and fabrication mindset

Tue, 01 Apr 2025 00:00:00 GMT

I have spent a lot of time at a desktop 3D printer—well over two hundred hours of printing, iterating, and learning what fails when plastic meets physics. Digital fabrication, for me, is not a certificate on the wall; it is an ongoing practice of closing the loop between digital intent and physical consequence. I am not positioning myself as someone who has run professional fabrication prep for manufacturing at scale. What I am doing is deliberately moving from rough concept and AI-assisted exploration to a part I can hold, stress, and revise. That bridge—sketch to CAD to slice to print—is where my practice is growing. This post is about why that matters for how I think as a designer and a leader: materials as tradeoffs, not trivia; the mental shift that comes from making; and the confidence that spills beyond the screen.

Digital fabrication exploration: from AI concept to physical object

The thread I care about is sequential and inseparable: idea → visualization → constraint-aware form → something real.

Sketching and conceptualizing with AI. Generative tools are useful here in the same way thumbnails are—not as the final artifact, but as a way to branch quickly through silhouettes, proportions, and “what if we solved it this way?” moments. The point is not to outsource judgment. It is to externalize possibilities fast enough that you can compare them, then commit to a direction you will own in CAD and at the printer. The AI-assisted phase helps me name what I am trying to build before I invest hours in plastic.

CAD as translation, not decoration. Once a direction exists, the work becomes explicit: dimensions, mates, clearances, orientation for printing. That step forces honesty. A concept that only lives in a mood board can stay ambiguous. A model that has to slice and survive contact with a bed cannot. From Figma to filament: why I 3D print as a product designer goes deeper on how that discipline connects to product work; here, the emphasis is on conceptualizing the physical object—not as fantasy, but as something that could exist.

The print as a truth test. The printer does not care about your narrative. It cares about layer adhesion, overhangs, thermal behavior, and whether you left enough clearance between two sliding parts. When the first layer warps or a snap fit cracks, the feedback is immediate and unsentimental. That is the connection between digital and physical I am chasing: the same idea, tested against matter.

The loop I run (and rerun). Model in CAD, slice for the machine, print, measure, break what deserves breaking, adjust parameters or geometry, print again. The wall-clock cost is higher than pushing pixels, which is exactly why it is valuable: you cannot hide behind a beautiful render. When something fails, the postmortem is specific—this orientation weakened layers, this clearance assumed too little variation, this corner concentrated stress. That habit of naming the failure mode before the next attempt is the same habit I want in design reviews and roadmap conversations: specificity beats vibes.

Parametric thinking without pretending I have solved manufacturing. In CAD, I still think in relationships—base dimensions, derived clearances, a hole that tracks a peg diameter—because that is how you keep a family of parts coherent when one input changes. That maps cleanly to design systems work (tokens, dependencies, propagation). I am not claiming factory-floor DFM expertise; I am saying the dependency mindset crosses domains, and fabrication practice makes the graph tangible.

Materials: benefits, drawbacks, and choosing when to use what

Material choice is not a label you pick once—it is a bundle of behaviors. Desktop FDM printing made that legible for me in a way specs alone never did.

PLA is dimensionally cooperative for many geometries and prints reliably in open air. It is also brittle under impact compared with tougher options—fine for jigs and decorative shells, questionable for parts that will see drops or repeated flex.

PETG trades some rigidity for toughness and layer adhesion that forgives more real-world abuse. It strings more, likes different bed and cooling behavior, and still will not save a bad load path.

ABS asks for thermal management (enclosure, ventilation discipline) in exchange for heat resistance and toughness in certain applications. It is a reminder that “stronger material” is never free—it comes with process debt.

TPU is the flexibility lesson: vibration damping, living hinges, compliant clips—at the cost of precision and speed.

I am not cataloging this to sound like a materials handbook. I am cataloging it because understanding physical complications—what each choice optimizes and what it punishes—is the same muscle as weighing frameworks, tech stacks, or org processes: there is no perfect option, only fit for the scenario. The more honestly you map tradeoffs, the fewer surprises late in the process.

What mentally enables building physical products?

There is a permission structure people rarely name. Digital design careers reward fluency in abstraction—flows, systems, narratives. Physical making adds a different requirement: you must tolerate being wrong in a medium that wastes time and material.

That tolerance changes you. You stop treating the first model as precious. You expect revision. You look for the failure mode early because the machine will find it anyway. In leadership terms, that is uncomfortably close to running pilots, shipping MVPs, and admitting when a program needs a pivot—iteration without ego.

Another shift is spatial accountability. On a screen, you can imply depth. In CAD for printing, implied depth becomes wall thickness, unsupported spans, and whether a bracket can actually carry load. You start asking “where does the stress go?” before you ask “does it look right?” That reordering—constraints before polish—is useful everywhere, including when you are aligning stakeholders who want beauty before feasibility.

You become a bigger problem solver—not only on the screen

Digital fluency lets you optimize what people see and tap. Physical practice forces you to optimize what survives contact. The problems are related but not identical:

A layout can be “correct” in Figma and wrong on a low-end device; a part can be “correct” in CAD and wrong once the first layer cools.
A flow can fail because copy was ambiguous; an enclosure can fail because tolerance was under-specified by two tenths of a millimeter.

When you practice both, you stop believing that digital correctness equals reality. You look for the gap—rendering context, manufacturing variation, human error—and you design for it. That is not pessimism; it is systems thinking with skin in the game.

The same instinct shows up in softer work: a narrative that sounds airtight in a deck but collapses in a sales call, or a process that works for one team size but not another. Physical practice does not automatically make you brilliant at org design—but it trains you to distrust the first perfect-seeming answer and to look for where reality will disagree with the model.

How does confidence in making translate to design leadership?

Confidence here is not swagger. It is the quiet knowledge that you have repeatedly taken something from “idea” to “held object,” debugged failure, and improved the next version. That cycle is transferable:

Stakeholder conversations. You speak about tradeoffs with concrete examples—time, material, risk—because you have paid those costs personally.
Cross-functional credibility. Teams feel when a leader understands constraints beyond slides. You do not have to fake manufacturing expertise; you have to show respect for constraints and a track record of learning under them.
Calm under ambiguity. Making teaches that the first answer is rarely the last. That steadiness helps when product direction is contested or timelines compress.

You are not solving only digital problems anymore—you are rehearsing the same problem-solving muscle against what you can see, weigh, and break. The overlap is the point.

Where this sits in a broader maker practice

None of this replaces industrial DFM for production at scale. It informs how I think about fidelity, iteration, and honesty in the work. For the wider picture—CAD, the home lab, and how these threads connect—see the designer’s maker lab: CAD, 3D printing, and woodworking. For systems thinking that extends beyond software into how you run a life, engineering concepts for everyday life: redundancy, MVPs, and kanban pairs well with the mindset above.

What am I still learning?

Industrial fabrication—tooling, tolerances at volume, supplier workflows—is not what I am claiming here. My exploration is desktop-scale, high-feedback, personal accountability. The through-line is unchanged: digital to physical literacy makes me a more grounded designer and a more credible leader when tradeoffs get real.

Key Takeaways

Digital–physical is one arc: AI-assisted exploration helps branch concepts; CAD and printing force those concepts into accountable form.
Materials are decisions: each filament family trades printability, toughness, heat resistance, and precision—choosing is practice in tradeoff thinking, not memorization.
Making builds mental habits: iteration without ego, constraint-first thinking, and early failure analysis apply to product, org, and leadership challenges—not only to plastic.
Problem-solving spans media: rigor on screen plus rigor in matter reduces the gap between “designed” and “true under stress.”
Confidence transfers: credibility with stakeholders and teams grows when you have repeatedly shipped ideas into the physical world and learned from what broke.

Design systems at scale for IoT consulting and connected devices

Tue, 18 Mar 2025 00:00:00 GMT

Design systems built inside a consulting firm operate under different pressures than design systems at a single-product company. At Very Technology, an IoT consultancy where I worked, we had 10+ designers assigned across a rotating portfolio of client projects—each designer leading data collection, user research, and UI design for connected-device experiences. The projects varied wildly: industrial dashboards, consumer wearables, smart-home interfaces, fleet management tools. But the most powerful thing we built wasn’t any single product. It was a shared design infrastructure—templates, component libraries, usability guidelines, and token systems—that compounded in value with every project rotation. Each time a designer finished a project and moved to the next one, the system got better, and the next project started faster.

Why consulting creates the ideal pressure for reusable design

At a product company, the design system serves one product (or a family of products under one brand). The incentive to build reusable infrastructure is real but abstract—it saves time on future features, reduces inconsistency, and onboards new designers faster. But the payoff cycle is long, and it’s easy to deprioritize system work in favor of shipping the next feature.

At a consulting firm, the incentive is concrete and immediate. Projects last anywhere from six weeks to a few months. When a project ends, you move to a completely different client, a different problem domain, and often a different device category. If you start every project from scratch—new wireframe templates, new component patterns, new usability heuristics—you burn weeks of every engagement on foundational work that doesn’t differentiate the deliverable.

The economics force the question: what can we build once and reuse across every engagement? That question, asked repeatedly across dozens of project rotations, is what drove our design system from a loose collection of Sketch files into a structured, governed, continuously improving design infrastructure.

How we structured a design system across 10+ designers and dozens of projects

The team at Very Technology wasn’t organized around a single product backlog. Each designer was embedded in a different client project, leading the design workstream from discovery through delivery. That distribution created a challenge: how do you maintain a shared system when everyone is heads-down on different work? The same ownership clarity and communication rituals that make remote design teams work for US startups are what kept a rotating, distributed consulting team aligned around one system.

The structure that emerged:

Shared template libraries. Every project type had a starter kit—wireframe templates for dashboards, mobile device control interfaces, onboarding flows for connected products, data visualization patterns for sensor data. When a designer started a new IoT dashboard project, they didn’t open a blank canvas. They pulled the dashboard starter kit, which contained layout patterns, navigation structures, and component shells that had been refined across every previous dashboard engagement.

Design tokens with IoT-specific semantics. We built a token system that went beyond colors and spacing. IoT interfaces have domain-specific patterns: status indicators for device connectivity, alert hierarchies for sensor thresholds, data-density modes for monitoring views versus consumer views. Our tokens encoded these semantic patterns so designers could apply consistent interaction models across projects without re-deriving the logic each time.

Usability guidelines as living documentation. After each project, the lead designer documented what worked and what didn’t in a shared guidelines repository. These weren’t generic heuristics—they were specific, battle-tested patterns: “For industrial IoT dashboards, users scan top-left to bottom-right for critical alerts; place the most urgent status indicators in the top-left quadrant.” “For consumer device setup flows, the average user abandons after the third screen if they haven’t seen the device respond—keep the pairing confirmation within two steps.” Over time, these guidelines became the most valuable asset in the system.

Internal workshops to cross-pollinate knowledge. Every two weeks, a designer presented their current project to the rest of the team: what patterns they used from the system, what new patterns they created, what gaps they found. These sessions served a dual purpose—they spread domain knowledge across the team, and they created a natural intake process for new system contributions. A pattern that worked on one project got proposed, reviewed, and added to the shared library.

The compounding effect: every project made the next one faster

The most powerful aspect of this model was the compounding return on design infrastructure investment. Each project rotation was an iteration cycle for the system itself.

In the early days, a new project meant two to three weeks of foundational design work before we could start producing deliverables that addressed the client’s specific problem. Wireframe templates were rough, component patterns were incomplete, and usability guidelines were thin.

After six months and a dozen project rotations, that foundational phase shrank to days. A designer starting a new smart-home interface project could pull the consumer IoT starter kit, apply the device-control component patterns, reference the usability guidelines for pairing flows and real-time status displays, and have a high-fidelity prototype framework ready within a week. The work that used to take weeks became the starting point, and the designer could spend the engagement time on what actually mattered: the client-specific research findings, the unique device constraints, the novel interaction patterns that the project demanded.

After a year, the system was mature enough that we could confidently scope engagements with tighter timelines. The reusable infrastructure wasn’t just saving internal time—it was a competitive advantage in proposals. We could show prospective clients the depth of our IoT design patterns and demonstrate that we weren’t starting from zero.

What makes consulting design systems different from product design systems

The lessons from building a design system in a consulting context translate to product companies, but the constraints are different in important ways:

Breadth over depth. A product design system goes deep on one visual language, one brand, one set of user needs. A consulting design system goes broad—it needs to flex across different brands, different user populations, and different device form factors. This forces a level of abstraction in the token and component architecture that product systems can avoid. Our components couldn’t assume a specific color palette or typography stack; they had to be skinnable by default, with the brand layer applied per engagement. This is the inverse of the deep, single-brand token architecture I later built in Peridio and Avocado OS: semantic tokens and AI-native design systems, where one product could go as deep as it wanted on a single visual language.

Documentation is the product. In a product company, the design system’s primary output is the components and tokens themselves—documentation supports adoption. In a consulting firm, the documentation is arguably the most valuable deliverable. When a designer rotates onto a new project, they need to absorb the system’s patterns quickly. The usability guidelines, the starter kit walkthroughs, the pattern rationale documents—these are what enable a designer to go from “new project” to “productive” in days instead of weeks.

Governance is lightweight and trust-based. We didn’t have the luxury of a heavy governance model with RACIs and approval committees. The team was small enough and project-rotated enough that governance was peer-based: propose a pattern in the biweekly workshop, get feedback from designers who’ve worked on similar projects, merge it into the library. The trust came from shared context—every designer had worked across multiple project types and understood the system’s constraints firsthand.

How do you build a design system when every project is different?

The key insight is that IoT projects are less different than they appear on the surface. The device categories vary—industrial sensors, consumer wearables, smart-home hubs, fleet tracking units—but the design patterns cluster into a manageable set:

Device status and connectivity — every IoT interface needs to communicate whether a device is online, offline, updating, or in an error state
Data visualization for sensor streams — real-time and historical data display for temperature, humidity, location, pressure, vibration, and dozens of other sensor types
Device onboarding and pairing — the flow that gets a user from “I just unboxed this” to “the device is connected and working”
Alert and notification hierarchies — which events are critical, which are informational, and how does the user triage them
Multi-device management — the dashboard view when a user or operator manages a fleet of devices rather than a single one

By building the system around these pattern clusters rather than around specific projects, we created reusable infrastructure that was abstract enough to flex across engagements but specific enough to provide real acceleration. A designer starting a new fleet management project didn’t need a fleet management starter kit—they needed the multi-device management patterns, the data visualization patterns, and the alert hierarchy patterns, composed for a fleet context.

This cluster-based architecture connects directly to how design tokens work at the engineering level. For how token strategy and component abstraction translate to code, branching strategies for design-engineering collaboration covers the practices that keep design system assets synchronized between design tools and production codebases.

Key Takeaways

Consulting firms create ideal conditions for design system compounding: frequent project rotations mean the system gets tested, refined, and expanded continuously across diverse use cases
Building reusable design infrastructure around pattern clusters (device status, data visualization, onboarding, alerts, multi-device management) is more effective than building around project types or client categories
The most valuable system asset is battle-tested usability guidelines—specific, documented patterns derived from real project outcomes that let designers apply proven solutions without re-deriving them
Internal workshops where designers present project learnings create a natural intake process for system contributions and cross-pollinate domain knowledge across the team
In a consulting context, documentation quality determines system velocity: when designers rotate onto new projects, the speed of their ramp-up depends entirely on how well the patterns, rationale, and starter kits are documented

From Figma to filament: why I 3D print as a product designer

Tue, 04 Mar 2025 00:00:00 GMT

I’ve been 3D printing for years—not as a hobby separate from my design work, but as an extension of it. Designing a physical object that has to fit, function, and survive real-world use teaches you things that pixel-perfect screens never will. Tolerances, material constraints, print orientation, support structures—these are design decisions with immediate, tangible consequences. When your part doesn’t fit because you forgot a 0.2mm clearance, you learn to respect constraints fast. When your print delaminates because you oriented the layers wrong, you understand the cost of ignoring manufacturing constraints in a way that no documentation can replicate. The physical world is unforgiving in the most pedagogically efficient way possible.

The parallels between physical fabrication and product design

The mental models that 3D printing builds are the same ones that make product design rigorous. They’re just encountered in a medium where the consequences are immediate and concrete rather than delayed and abstract.

Parametric thinking. In CAD, I work with parametric relationships: dimensions that reference each other so a single change propagates correctly through the model. This wall thickness is always a function of the enclosure height. This mounting hole is always offset from the edge by 5mm. Change one value and everything downstream updates. This is the exact same mental model as design tokens in a design system. The base value changes, and the entire visual language updates correctly. Working in parametric CAD made me a better design systems thinker, and building design systems made me a more disciplined CAD modeler. The cross-pollination is real.

Constraint-first design. Screen-based design allows you to ignore constraints for a surprisingly long time. You can design an interaction that’s technically impossible to implement, a layout that can’t handle variable content lengths, an animation that would require a full-screen shader pass on a mid-range mobile device. Physical design doesn’t allow this. A part that won’t print is a failed design, full stop. The discipline of designing within constraints—and understanding exactly which constraints apply—transfers directly to digital product design when you’ve felt what it means to discover a constraint after you’ve committed to a direction.

The iteration loop. The feedback loop in 3D printing is hours, not days or weeks. You model, slice, print, test. If it doesn’t fit, you iterate. After two hundred hours at the printer you develop an instinct for what will fail before you press print—the overhang that’s too steep, the wall that’s too thin for the stress it will bear, the tolerance that’s too tight for the print bed’s temperature variation. That anticipatory quality—seeing failure before it happens—is exactly what experienced product designers bring to their work. 3D printing accelerates the development of that instinct.

What 3D printing teaches about tolerances and physical reality

Tolerance is the concept that transforms a designer into someone who understands manufacturing. A tolerance is the acceptable range of variation from the specified dimension. In digital design, tolerances are theoretical—a button that’s 2px too small renders at exactly 2px too small, predictably, consistently. In physical fabrication, every manufacturing process has inherent variation, and the design must account for it.

In FDM 3D printing (the most common desktop printer type), the typical dimensional tolerance is ±0.2mm. This means that if you design a peg that should fit into a hole, and you make them the same diameter, they won’t fit—because both will have ±0.2mm variation, and the interference fit that results is too tight to assemble by hand. You need clearance: typically 0.2–0.4mm of gap between mating parts, depending on the printer and material.

Learning this in practice changes how you think about specifications in any domain. What are the tolerances in this system? Where does variation get introduced? Where do we need clearance—room for the system to work even when individual components aren’t perfect? These questions matter in software architecture, in content design, in animation timing, in team workflows. Thinking about tolerance is thinking about resilience.

CAD as a design tool: Fusion 360 for product designers

Fusion 360 is the parametric CAD environment I use, and it’s worth describing why it’s accessible to designers who haven’t worked in CAD before.

The paradigm in parametric CAD is: sketch → constrain → extrude. You draw a 2D sketch of the profile you want, define the relationships and dimensions that constrain it fully, then extrude it into a 3D solid. Most objects are composed of a series of these operations—extrusions, cuts, fillets, holes—each of which references the geometry below it in a timeline. The timeline is the equivalent of a component’s layer structure: you can go back and change an early operation and see how everything downstream updates.

The learning curve is real but manageable for someone with a spatial design background. The hardest part is the fully-constrained sketch requirement: Fusion won’t let you proceed until every point and dimension in your sketch is constrained. If you’re used to the looseness of Figma—where you can draw approximations and adjust visually—the precision requirement feels restrictive at first. After a few projects, it feels like the right kind of discipline.

Good starting projects for designers learning CAD:

A cable management clip with two dimensions: hole diameter and clip width
A small enclosure for a Raspberry Pi Zero with a lid and two mounting holes
A phone or tablet stand with adjustable angle
A desk organizer with compartments sized for your specific tools

Each of these requires the core operations (sketches, extrusions, holes, fillets) and produces a functional object you’ll actually use. The motivation from using something you designed and printed is significant.

How does 3D printing change how you work as a digital designer?

The most direct change is in how I approach constraints. After years of 3D printing, I no longer see constraints as limitations—I see them as the raw material of good design. Constraints force specificity. Specificity forces rigorous thinking. Rigorous thinking produces better design.

When I encounter a constraint in digital product design—a performance budget, a content model, an API structure, a component API—I now approach it the way I approach a print constraint: understand it completely, design within it precisely, and look for where the constraint creates opportunities rather than just where it creates limitations. A tight performance budget is a reason to strip everything to essentials. That’s a design opportunity, not just a technical constraint.

The second change is in iteration speed psychology. 3D printing taught me that the fastest path to a good outcome is usually more iterations, not longer iterations. A quicker, rougher test that fails fast and teaches something is more valuable than a slower, more careful attempt that takes longer to falsify. This is a mindset shift, not just a workflow preference, and it’s one I apply to digital design explorations directly.

For more on the digital-to-physical bridge—how concepts become printed parts, and how that practice feeds leadership—digital fabrication: AI concepts, materials, and fabrication mindset expands on that angle. And if you want to build the workspace where this happens, the designer’s maker lab: CAD, 3D printing, and woodworking covers the tools and setup.

Getting started: first printer, first print, first lesson

If you’re a product designer who’s never 3D printed, here’s where to start. The entry point has never been lower—a capable desktop FDM printer (Bambu Lab A1 Mini, Prusa MK4, Creality Ender 3 V3) costs $200–$600 and requires minimal setup.

The first print should be something you need. Don’t print decorative objects. Print a functional tool—a cable clip, a bracket, a stand, an organizer. Design it yourself in Fusion 360 (free personal license) rather than downloading from Printables or Thingiverse. The learning is in the design, not in the printing of someone else’s model.

The first failure will teach you the most. When the print warps, delamaminates, or doesn’t fit, diagnose it carefully before reprinting. The diagnosis is the lesson: the bed wasn’t level, the first layer adhesion was wrong, the tolerance was too tight, the overhang was too steep. Understanding each failure makes you a better designer of physical things—and, counterintuitively, a better designer of digital things. For real examples of functional prints solving home-lab problems—jigs, enclosures, and test fixtures—see my garden note on solving everyday problems with 3D printing.

Key Takeaways

3D printing builds parametric thinking, constraint-first design, and rapid iteration instincts that transfer directly to digital product design
Tolerances in physical manufacturing (typically ±0.2mm for FDM printing) teach the concept of designing for variation rather than nominal perfection—a mindset that applies everywhere
Fusion 360 is the right parametric CAD environment for designers: free for personal use, fully parametric, and designed around the sketch-constrain-extrude paradigm
Good starter projects are functional objects you’ll actually use: cable clips, enclosures, stands, organizers—design them yourself rather than downloading pre-made models
The iteration loop in 3D printing (model → slice → print → test, measured in hours) develops anticipatory design instinct faster than most digital design workflows

The designer's maker lab: CAD, 3D printing, and woodworking

Tue, 18 Feb 2025 00:00:00 GMT

There’s a reason Dieter Rams kept a workshop and Jony Ive spent hours in the model shop at Apple. The designers we admire most—the ones who produced objects that feel inevitable—could grab, hold, and turn the thing they were designing. They understood radius and mass and surface finish not as abstract values in a spec, but as physical facts you feel in your hand. That connection between the designer and the material world is something screen-based work has quietly eroded, and reclaiming it is one of the most rewarding things I’ve done. The moment I started designing objects in Fusion 360, printing them, sanding them, and holding the result, my digital design work got sharper too. Constraints stopped being theoretical. Tolerances stopped being someone else’s problem.

Why physical making sharpens digital design thinking

The argument for physical making as a design practice isn’t nostalgic—it’s practical. Physical materials impose constraints that screens don’t. When you design a digital interface, you can defer many decisions: edge cases can be “handled later,” content overflow can be “design should handle that,” performance constraints can be “let engineering figure it out.” Physical materials don’t allow deferral. A part that won’t survive the stress it will be under is just a bad part. A joint that won’t hold is a joint that won’t hold.

This immediacy builds a quality of design thinking that’s difficult to develop through screen-only work. Designers who have worked with physical materials develop a different relationship to constraints—not as obstacles to route around, but as the primary data that shapes the design. Constraints first, aesthetics second. This is how Dieter Rams approached product design. It’s how the best physical products are made. And it transfers directly.

The specific benefits I’ve observed in my own work:

Dimensional thinking. Working in CAD where every dimension is specified and every relationship is parametric builds precision in how I think about layout grids, spacing systems, and component sizing in Figma. The discipline of exact specification stops feeling onerous and starts feeling like craft.
Constraint-first design. Before I design anything physical, I ask: what are the manufacturing constraints? What are the material constraints? What are the functional requirements? This habit has carried directly into how I approach digital product design briefs.
Iteration tolerance. In physical making, a failed print or a miscut board is information, not a setback. This relationship to failure—where failure is expected, useful, and fast—has changed how I run design explorations.

Building a maker lab at home: the practical starting point

The barrier to entry for a home maker lab has dropped dramatically in the past decade. The tools are cheaper, more reliable, and better-documented than they’ve ever been.

The 3D printer. A capable FDM printer costs $200–$600. The Bambu Lab A1 Mini is the recommendation for designers who want something that “just works”—it’s fast, accurate, and has an excellent slicer (Bambu Studio). The Prusa MK4 is the recommendation for designers who want to understand every aspect of how the printer works. Both are capable of production-quality results. The materials to start with: PLA for most objects, PETG for anything that needs to be tougher or slightly heat-resistant.

Fusion 360. Free for personal use and arguably the best parametric CAD environment available. The learning curve is real—expect two to three weekends of deliberate learning before models feel natural—but the payoff is immediate. The parametric modeling paradigm (sketch → constrain → extrude, with a timeline of operations) transfers directly to the systems thinking that design requires. Start with Fusion 360’s own tutorial series, then Kevin Kennedy’s “Product Design Online” YouTube channel for practical project-based learning.

The slicer. The slicer is the software that converts your CAD model (STL or 3MF file) into the toolpath instructions the printer follows. Bambu Studio, PrusaSlicer, and OrcaSlicer are all excellent and free. The slicer is where you specify print settings—layer height, infill percentage, support structures, first layer calibration. Understanding the slicer is understanding what the printer is actually doing, which is essential for designing printable parts.

Hand tools. The most underrated part of a maker lab. A good set of hand tools—chisels, hand plane, marking gauge, saws—allows you to work with wood at a scale and intimacy that power tools don’t. Hand tool woodworking is slow by design. You can’t rush a hand-cut mortise. This enforced pace is pedagogically valuable: you learn grain direction, wood behavior, edge geometry, and finishing through the slowness of the process.

Why Raspberry Pi belongs in a designer’s toolkit

The Raspberry Pi is a small single-board computer that runs Linux on hardware small enough to hold in one hand. For designers, it’s a two-way design tool: you design the software that runs on it and the physical enclosure that houses it.

The Raspberry Pi project that taught me the most was a home automation controller I built from scratch. The software side: a small Python application that reads sensor data and controls relays. The hardware side: a custom enclosure designed in Fusion 360, printed in PETG, with ventilation slots sized for the thermal output of the board and cutouts for the connectors sized to 0.1mm precision. Getting both sides right required thinking across the full stack—software behavior, hardware constraints, thermal management, assembly sequence, aesthetic finish.

This is what “design engineering” means in practice: designing across the full stack without handing off between disciplines. The Raspberry Pi is one of the best tools for practicing it because it’s accessible, well-documented, and produces a physical artifact you can hold and use.

Good starting projects for a designer’s first Raspberry Pi build:

A custom case for a Raspberry Pi Zero 2 W — introduces measurement, fitting, and enclosure design in Fusion 360
A small home dashboard displaying weather, calendar, or sensor data — introduces Python, APIs, and simple web interfaces
A network-wide ad blocker (Pi-hole) — introduces DNS, networking, and system administration basics
A retro gaming console — introduces operating system configuration and peripheral integration

For a real build in this spirit, see my garden note on hacking a Kindle Paperwhite into a family dashboard—weather, calendars, and countdowns on e-ink, with a 3D printed fridge mount.

Woodworking as a design education

Woodworking is the maker practice that’s aged the least. Every principle that applies to good woodworking—grain direction, joinery, fitting, finishing—was relevant five hundred years ago and is relevant now. The materials and tools have evolved; the design thinking hasn’t.

Grain direction is the concept that transforms a carpenter into someone who understands material. Wood is anisotropic: its strength, stiffness, and shrinkage behavior are dramatically different along the grain versus across it. A joint that fails in tension across the grain will hold indefinitely along it. A panel that’s flat today will cup tomorrow if you ignore how it was cut from the log. Designing with grain direction is designing with the material’s natural behavior, not against it.

Joinery is constraint design. A mortise-and-tenon joint works because the geometry of the joint mechanically constrains the parts to resist the specific loads they’ll experience. A dovetail works because the interlocking angled geometry resists tension. Every joint is a solution to a specific loading problem. Designing joints teaches you to think about loads, constraints, and material behavior simultaneously—the same triple constraint that defines good structural design in any domain.

The finishing process teaches patience and iteration. Good furniture finishing requires multiple rounds of surface preparation, sealing, sanding, and topcoat. Rushing any stage produces visible defects in the final surface. This patience—doing each stage correctly before moving to the next—is a discipline that carries into digital design. The temptation to skip surface preparation and go straight to the finish coat is the same temptation to skip user research and go straight to high-fidelity mockups.

How do you get started without a full workshop?

You don’t need a full workshop to start. The minimum viable maker setup for a designer is:

A 3D printer and a laptop with Fusion 360 installed
A small set of hand tools: a block plane, a marking gauge, a chisel set, a pull saw
A workbench surface (a folding table works)
Safety equipment: eye protection, hearing protection for any power tools, dust masks for sanding and finishing

This setup fits in a spare bedroom, a corner of a garage, or even a large closet. The 3D printer runs quietly and can be in a living space. Hand tools produce minimal noise and no dust.

The first project should be something you need. Design a cable management solution for your desk. Build a small shelf for your workspace. Design a phone stand for your desk. The motivation of designing something useful keeps the learning momentum going when the technical challenges are frustrating.

For more on the digital-to-physical arc—AI-assisted concepts, material tradeoffs, and fabrication mindset—digital fabrication: AI concepts, materials, and fabrication mindset goes deeper on that thread. For the product-design payoff specifically—why 3D printing sharpens digital design instincts—see from Figma to filament: why I 3D print as a product designer, and for how making fits a broader hybrid practice, the design engineer: code, 3D printing, and hybrid design practice.

Key Takeaways

Physical making sharpens digital design by imposing immediate, unavoidable constraints—tolerances, material behavior, structural loads—that screen-based design allows you to defer indefinitely
A capable maker lab setup costs $200–$600 for a 3D printer, nothing for Fusion 360 (free for personal use), and $50–$150 for a basic hand tool set
Raspberry Pi projects that span software and hardware are among the best design engineering exercises available: you design across the full stack and hold the result
Woodworking teaches grain direction, joinery as constraint design, and the patience of correct process sequence—all of which transfer to digital design practice
Start with a project you need: a cable clip, a desk organizer, a small shelf. The motivation of designing something useful is what sustains the learning through the technical challenges

What I learned founding a Figma design community in LATAM

Tue, 04 Feb 2025 00:00:00 GMT

When the pandemic hit in 2020, most of us went remote overnight. For designers in Latin America, that shift exposed something that had been true for a while but easy to ignore: there wasn’t an active community for the kind of designer I was—product designers, design engineers, people working at the intersection of design and technology in startups and product companies. The communities that existed were either too broad, too passive, or focused on topics that didn’t match what I wanted to discuss. I didn’t want another portfolio-review group. I wanted a place where designers could talk about the real problems: shipping product in fast-moving teams, navigating ambiguity, working with engineers, building systems that scale. So I started one. What followed taught me more about leadership, community, and open collaboration than any professional role I’d held up to that point.

Why the LATAM design community had a gap worth filling

The Latin American design ecosystem in 2020 was more mature than most outside observers assumed. Significant design talent existed across the region—strong visual designers, emerging product designers, and a growing cohort of designers working in startup and tech company contexts. But the community infrastructure that would let that talent connect, share knowledge, and support each other was fragmented.

Most design communities in the region were national, not regional: designers in Mexico knew the local scene, designers in Argentina knew theirs. Cross-country visibility was low. A designer in Guatemala working on a hard product problem didn’t have an easy way to find peers in Colombia or Brazil who’d solved similar problems. Language wasn’t usually the barrier—most product designers in the region work in English, and most of the regional discussions happened in Spanish, which is a shared language for most LATAM countries. The barrier was structural: no shared space.

There was also a specific gap for the design-engineering hybrid profile I was building. The communities that existed skewed toward visual design, portfolio work, and junior-to-mid career practitioners. There was almost no community for senior product designers and design directors who wanted to discuss engineering collaboration, design systems at scale, AI workflows, and infrastructure. I was the target audience of a community that didn’t exist.

How I set up the community: Discord, live events, and the structure that worked

The setup was deliberately simple. Discord as the platform—active, familiar to the tech community, and with enough modular channel structure to organize different types of conversations. Friends of Figma as the organizational umbrella, which gave the community instant credibility and a ready-made framework for live events.

The channel structure I set up:

#introductions — required for all new members to introduce themselves: current role, what they’re working on, what they want to get from the community
#jobs — job postings and opportunities, both LATAM-based and remote US roles
#design-critique — work-in-progress sharing for feedback
#tools-and-workflows — tooling discussions, Figma tips, AI tools, process questions
#engineering-collab — design-engineering collaboration, git, code, technical topics
#community-events — event announcements and recordings
#general — everything else

The introductions channel was one of the best decisions. Having a structured introduction moment for each new member created a consistent onboarding experience and made the community feel like a place where people knew each other, not an anonymous forum.

The live events were the heartbeat of the community. Bi-monthly sessions on Discord or video, open to all members. The format: a 20-minute presentation or walkthrough of a design problem or project, then 40 minutes of open Q&A and discussion. The rules were minimal: all questions were welcome, anyone could answer, and the only expectation was showing up ready to help each other. No gatekeeping of “is this the right question for this space.” If someone needs to ask it, it’s the right question.

What running the community taught me about open knowledge

The most surprising thing about running the community was what happened to the knowledge flows. When you create a space where sharing is the default norm, and where there’s no competitive incentive to hoard knowledge, people share remarkable things freely.

Senior designers shared their actual design processes—not polished case studies, but the messy reality of how they work. People shared job leads with competitors. Experienced designers spent hours helping junior members work through problems they’d solved years ago, with no compensation and no agenda. Companies that were technically competing for the same clients shared knowledge about tools, workflows, and processes.

This dynamic has a name in economics: the knowledge commons. Knowledge is non-rivalrous—sharing it doesn’t diminish it, it multiplies it. The people who understand this and build communities around it end up with far more knowledge than those who hoard it, because knowledge flows back to those who generate and share the most. In a well-functioning community, sharing is the highest-return strategy.

Running the community internalized this principle for me in a way that reading about it never could. It directly shaped how I approach knowledge sharing in professional contexts: writing and publishing about things I’ve figured out, sharing templates and resources openly, building in public. The instinct to share is a compounding strategy, not a giveaway.

What makes a design community actually self-sustaining?

Growing the community was the first challenge. Sustaining it was harder and more interesting.

A community that depends on its founder for energy and direction isn’t a community—it’s a newsletter with a comment section. The milestone I was watching for was the first time something valuable happened in the community without my involvement: a conversation that I didn’t start, a member who helped another member without me asking anyone to help, a subgroup that formed around a shared interest and ran its own activity. When I saw this happening regularly—around six months in—I knew the community had become self-sustaining.

The specific conditions that enabled self-sufficiency:

Norm setting from the start. The values of the community—generosity, technical rigor, peer-to-peer help without hierarchy—were set explicitly in the onboarding experience and modeled in every event. When the norms are clear and consistently demonstrated, members internalize them and carry them forward without prompting.

Distributed moderation. I brought in co-moderators early: designers who were active in the community and had shown they understood the culture. Distributed moderation means the community doesn’t stall when the founder is unavailable, and it prevents the “parasocial dependency on the founder” dynamic that kills many communities.

Member-generated events. After the first few months, I opened event hosting to community members. Designers who had solved interesting problems could propose and run their own sessions. This shifted the energy source from “founder provides content” to “community generates content.” The sessions run by members were often the best ones—they came from genuine excitement about a problem, not from a sense of obligation.

Low-cost contribution pathways. Not everyone can run an event or answer questions in depth. Making it easy to contribute small things—sharing a job lead, upvoting a helpful answer, welcoming a new member in introductions—created a gradient of participation that let everyone feel ownership without a high barrier to entry.

The connections the community created that lasted

The most lasting outputs of the community aren’t the events or the content—they’re the relationships. Designers who met in the community went on to hire each other, collaborate on client projects, refer each other to opportunities, and build genuine professional friendships across country borders. A community that creates durable connections between its members has produced something that outlives any individual event or conversation.

I’ve maintained relationships from the community that have influenced my professional trajectory in direct ways: introductions that led to roles, collaborators on projects I couldn’t have found any other way, peers who challenged and developed my thinking about design leadership, engineering collaboration, and community itself. The compounding value of these relationships is incalculable, and it came from a simple decision: start a space, set good norms, and be generous with what I know.

The community is still running on its own now, which is the best possible outcome. It doesn’t need me anymore—and that’s exactly what a healthy community looks like.

For how the open-knowledge instinct from the community work eventually connected to open-source contribution and the hybrid design engineering practice, the design engineer: code, 3D printing, and hybrid design practice covers how these threads came together.

For how design leadership works in the LATAM ecosystem more broadly—including what makes nearshore design leaders effective in US startup contexts—nearshore design leadership: why US companies hire in LATAM covers the structural and cultural context in depth.

Key Takeaways

The LATAM design community had a structural gap in 2020: cross-country connection and a space for senior product designers working at the design-engineering intersection were both missing
Discord’s channel structure, mandatory introductions, and bi-monthly live events with an open Q&A format were the specific structural choices that made the community feel like a place where people knew each other
Knowledge is non-rivalrous: sharing it multiplies rather than diminishes it. Running the community internalized this as a compounding strategy, not a giveaway
A community becomes self-sustaining when it has clear norms from the start, distributed moderation, member-generated events, and low-barrier contribution pathways
The most durable outputs of the community are the relationships—cross-country professional connections that led to roles, collaborations, and genuine peer relationships that still compound years later

Engineering concepts for everyday life: redundancy, MVPs, and kanban

Tue, 21 Jan 2025 00:00:00 GMT

The most valuable thing I’ve gained from bleeding into the engineering world isn’t writing better code—it’s thinking in better systems. Redundancy, modularity, continuous improvement, MVPs—these aren’t just software patterns. They’re life patterns, and once you start seeing them, they’re everywhere. The engineering world didn’t invent these ideas, but it formalized them in ways that are immediately practical the moment you step back and look at your life as a system worth designing. If you’re a designer learning to code, pay attention to the frameworks as much as the syntax. The syntax ships features. The frameworks change how you think.

Redundancy isn’t paranoia—it’s infrastructure

Redundancy in software means designing systems so a single point of failure doesn’t take down the product. You run multiple database replicas, multiple application servers, multiple network paths—so when one fails (and it will), the others absorb the load and the user never knows. The failure is expected and planned for. The system doesn’t have resilience despite failure; it has resilience because failure is assumed.

I apply this to my physical environment with the same principle. My backpack has a spare cable, a second charging brick, a second pair of headphones, a backup pencil and lip balm. Everything I need to grab and go, plus a spare of anything critical. The same setup lives at home, one version in my car, one at my office. I never think about whether I have what I need because the system already solved that problem. A single missing charger doesn’t derail the morning. The redundancy absorbs the failure.

This isn’t obsessive behavior—it’s infrastructure design applied to daily life. The question to ask is: what are the single points of failure in my daily system? Where would one missing thing cause a cascade of friction? Then: add redundancy there. Keep a second set of the things that fail most painfully when missing. The goal isn’t to carry everything everywhere—it’s to eliminate the category of “I don’t have what I need” from the system.

The MVP approach to decisions about physical things

Minimum viable product thinking is useful far beyond software. The principle is: ship the smallest thing that tests the assumption, learn from real usage, then invest in the full version based on what you actually learned.

Applied to physical environment decisions—furniture, workspace setup, home improvement—this principle saves significant money and produces better outcomes than committing to the “final vision” upfront.

Example: I wanted to upgrade my home office setup. The instinct was to plan the ideal desk, monitor arm, lighting rig, and storage system and buy everything at once. The MVP approach: buy the cheapest version of each element first. A basic desk surface, an inexpensive monitor arm, a simple desk lamp. Use it for six weeks. Then identify specifically what’s bothering you—not what you imagined might bother you, but what actually does. Is the desk height slightly wrong? Is the monitor arm wobbling? Is the lamp casting shadows in the wrong place? Now invest in the upgrade you actually need instead of the one you imagined.

The savings are real. The outcome is better. And the process mirrors exactly what makes software products good: testing assumptions with real usage before committing to the full implementation.

Modularity means parts that can change independently

Modular architecture in software means components that can be replaced without rebuilding the whole system. You can upgrade the database without rewriting the application. You can swap the payment provider without changing the checkout flow. Each piece has a clear interface and limited dependencies on other pieces.

In a physical workspace, modularity means: design each element so it can be replaced or upgraded independently without requiring you to rebuild everything around it. A monitor on an arm with a standard VESA mount can be replaced with a different monitor without changing the arm or the desk. A desk surface on adjustable legs can be changed without replacing the legs. Storage that doesn’t depend on custom installation can be rearranged or swapped.

The opposite of modularity is the “matched set” trap: furniture and equipment bought as a cohesive system where changing one element means changing everything. You buy the desk, the matching hutch, the coordinating chair mat. When the desk wears out in three years, you feel stuck replacing the whole set because the pieces only look right together.

Design your physical environment with interfaces and dependencies in mind, the same way you’d design software components. What are the specs that matter for each piece? (Monitor arm: VESA 100x100 or 75x75. Desk surface: at least 60” wide and 30” deep for the monitor and keyboard configuration.) What are the pieces that are hard to replace (the desk itself, because it’s large and expensive) versus easy to replace (the chair, the lamp, any cable management)? Invest more durability in the hard-to-replace pieces and treat the rest as modular.

How do you apply kanban to household tasks and family systems?

Kanban—the practice of visualizing work in progress and limiting work in flight to improve flow—originated in Toyota’s manufacturing system and became ubiquitous in software development. The core insight is that making work visible and setting explicit limits on how much is in progress at once produces more throughput than trying to do everything simultaneously.

Applied to household management, the same principles work with remarkably low setup cost. A physical kanban board near the front door (or kitchen, or wherever the household’s natural information hub is): three columns—Backlog, In Progress, Done. Cards are sticky notes. Limit in progress to whatever the household can actually complete this week.

The specific ritual I’ve found most useful: Sunday evening, reset the board. Move Done items to a “completed this week” pile (or trash them). Move what’s most important from Backlog to In Progress, but keep the In Progress column short—five items maximum. Each family member can see what’s in progress, what they’re responsible for, and what’s coming next. No one needs to be reminded about the trash because it’s on the board. No one needs to manage their own list because the board is the shared system.

For families with kids, the board has an additional benefit: it teaches the system itself. Children who grow up seeing work managed visually—who understand that tasks have states, that there’s always a queue, that finishing something moves it along the board—are learning a mental model that will serve them in software, in project management, and in any domain where work is complex and continuous.

The event-driven notification system made of Post-its

The reminder system I use for household scheduling is built entirely from Post-its—and it works on the same principle as event-driven messaging in software. In a pub/sub system, a publisher emits events and subscribers receive the ones they care about. There’s no central coordinator managing who needs to know what; the subscription model handles it.

Here’s the setup: every Sunday night, I place the week’s Post-its on a board near the front door. Trash goes out Tuesday. Library books are due Wednesday. Soccer cleats need packing Thursday. Each note is color-coded by owner—blue for me, yellow for my wife, green for the kids—so a glance tells you what’s yours and what’s coming. When a task is done, the note comes off. Recurring tasks get a fresh note the next Sunday. Dead simple. Zero dependencies on batteries, Wi-Fi, or an app subscription.

The principle is the same as the server monitoring LED setup I run in the kitchen—more on that in a moment: the system pushes information to you passively. You don’t have to remember to check a calendar or open an app. The notification is ambient and present in the environment you already move through. The physical act of removing a Post-it has the same satisfying completion signal as checking off a to-do in any digital system.

Ambient monitoring: turning status into environment

In software, monitoring dashboards give you system health at a glance—green means healthy, amber means degraded, red means critical. The best monitoring systems are designed so you absorb the system state passively. A glance at the dashboard, not a deep read.

I’ve extended this principle to the kitchen with a programmable RGB LED strip under the cabinets. Color schedules are tied to days of the week and events. Monday morning the strip glows blue—recycling day. Wednesday it pulses amber—medication refill day. Thursday evening it shifts to green—grocery delivery tomorrow, clear the fridge tonight. Red means something urgent: a deadline, a permission slip due at school, an appointment that requires preparation.

My family doesn’t check a calendar or an app to know what the day requires. They walk into the kitchen, see the ambient color, and have the context. The status is broadcast into the environment. No one has to subscribe to the information—it’s just there.

This is the monitoring mindset applied outside the server rack: design status information into the environment so it’s passively available rather than actively requested. The best monitoring systems are the ones you absorb without effort. That principle translates to physical spaces as directly as it does to software dashboards.

What these frameworks have in common

Every framework described here—redundancy, MVP iteration, modular design, kanban, event-driven notification, ambient monitoring—shares the same underlying principle: design the system to handle expected failure and continuous change gracefully, rather than optimizing for a single static ideal state.

Software systems that are designed for resilience and change are better systems than those designed for a specific nominal state. Physical environments and household systems that are designed the same way are better systems for the same reasons. The frameworks translate because the underlying problems are the same: managing complexity, reducing cognitive load, handling failure gracefully, and maintaining clarity about what’s in progress and what matters.

If you’re learning to code as a designer, the frameworks are the part worth internalizing deeply. The syntax you can look up. The system thinking stays with you everywhere you go.

For more on how engineering thinking applies to design practice and the technical skills that matter most, running your own servers as a designer covers how infrastructure context changes design leadership, and the design engineer: code, 3D printing, and hybrid design practice makes the broader case for building across the full stack.

Key Takeaways

Engineering frameworks (redundancy, MVPs, modularity, kanban) are life patterns that transfer directly from software to physical environments and daily systems
Redundancy: identify the single points of failure in your daily system and add a backup at those points—not everywhere, just where a failure is most disruptive
MVP thinking applied to physical purchases: buy the cheap version first, use it for six weeks, then invest in the upgrade that solves what actually bothered you, not what you imagined would
Modularity in physical environments means designing with clear interfaces—parts that can be replaced independently without rebuilding the surrounding system
Ambient monitoring (programmable lighting, physical boards, color coding) brings the passive status-broadcast model from software into physical spaces, reducing the cognitive overhead of remembering what needs attention

The design engineer: code, 3D printing, and hybrid design practice

Tue, 07 Jan 2025 00:00:00 GMT

I design products for a living. I also 3D-print functional objects, manage Linux servers, write GitHub Actions pipelines, rebase git branches, and build AI-assisted workflows. None of these things disqualify me from being a designer—they make me a better one. The best design leaders I’ve worked alongside are hybrid practitioners who move fluidly between strategy and execution, between pixels and production code, between digital and physical. The industry has started calling this profile “design engineer,” but the label matters less than the underlying principle: the more of the stack you understand from direct experience, the better your design decisions become across all of it.

What the design engineer role actually means

Design engineer is a term with several competing definitions, which makes it worth clarifying how I use it. In some companies, it means a software engineer who specializes in UI implementation—someone who bridges design systems and front-end engineering. In others, it means a designer who can write production-quality code. In both definitions, the emphasis is on the code side.

I use the term more broadly: a design practitioner who has developed fluency across multiple technical domains, applies that fluency in their design practice, and leads design teams that are expected to collaborate across those domains. The technical skills aren’t a separate job; they’re the context that makes the design work more grounded.

The skills I’m describing compound with each other in specific ways:

Git and CI/CD fluency means you can participate in the engineering workflow directly—reviewing PRs, committing fixes, setting up automated deployments. This eliminates the translation layer between design intent and production output that causes most of the fidelity loss in shipped products.

Infrastructure knowledge means you understand the constraints that engineering is working within: what a new service costs operationally, what a database query does to response time, what the deployment pipeline looks like. Design decisions made with this context are better-scoped and more honest about their implementation cost.

3D printing and physical making means you’ve experienced the unforgiving feedback of physical constraints: tolerances, material behavior, structural loads. This develops a relationship to constraints—as primary design data, not obstacles—that transfers directly to digital product design.

AI fluency means you can move faster through the parts of the design process that benefit from it—research synthesis, code scaffolding, content generation, documentation—without losing the judgment layer that makes AI output worth using.

How do these skills actually compound?

The compounding is the interesting part. Skills that seem unrelated in an individual produce unexpected combinatorial value in a leader.

When you understand CAD tolerances, you understand the cost of hand-waving over technical specifications in digital product design. The instinct that says “we should nail this down before proceeding” develops from experience with what happens when you don’t in a medium where the consequences are immediate and tangible.

When you understand CI/CD pipelines, you understand why “just ship it and fix it later” has a real operational cost. You’ve set up pipelines, watched deploys fail, debugged rollbacks. This makes you a more credible participant in release planning conversations.

When you understand AI code generation, you understand both its power (compressing the execution time of well-specified work) and its limitation (it has no judgment about what’s actually good). This makes you a better evaluator of AI-generated outputs and a more calibrated advocate for where AI should and shouldn’t be used.

When you understand server infrastructure, you understand why engineering teams push back on features that require new services or real-time data. You’ve provisioned a server, set up monitoring, managed a failed deployment. The pushback isn’t conservative—it’s experienced.

Each of these domains reinforces the others. The designer who understands all of them sees product development as a more complete system and makes decisions with more complete context.

What hybrid design practice looks like day to day

The hybrid design practice isn’t practiced separately from the regular design work—it’s integrated into it. Here’s what that integration looks like concretely:

In sprint planning, I can flag the design implications of technical architecture decisions because I understand enough of the technical landscape to see them. When an engineer says “we could build that as a new service or as part of the existing monolith,” I can contribute to that decision from a design perspective because I understand what the tradeoffs look like at the infrastructure level.

In PR reviews, I review front-end pull requests for visual and interaction fidelity directly—not by describing what I see in a comment thread, but by checking out the branch, running it locally, and comparing against the design in the browser. I can suggest specific CSS fixes because I can read the CSS.

In design explorations, I use AI tools to generate code scaffolds and layout variations faster than I could produce them manually, then apply design judgment to the output. The exploration space is wider, but the judgment layer is still human.

In physical prototyping, I model and print quick-turn prototypes for ergonomic testing—device stands, controller grips, desk accessories—to test physical form ideas at scale before committing to more expensive production processes.

In documentation, I use AI-assisted prompt patterns to generate first drafts of component documentation, then review and edit. The documentation exists and is maintained, rather than being perpetually deferred.

None of these require being expert-level in any of the adjacent skills. They require functional fluency—enough to participate credibly and add value, not enough to replace the engineers, operators, or specialists in each domain.

How do you develop this kind of hybrid practice?

The honest answer: slowly and deliberately, over years, through projects that push you into adjacent domains.

The pattern I’d recommend:

Start with git. Of all the technical skills that matter for design leadership, git literacy has the highest immediate return on investment. It directly improves your ability to collaborate with engineering and your credibility in engineering contexts. It takes a few days to become functionally fluent. For a practical breakdown of workflow scripts and process design that earns engineering trust, git workflow scripts: designing processes that earn engineering trust is a practical starting point.

Add CI/CD. Once you’re comfortable with git, set up a simple GitHub Actions workflow for a personal project. Understanding how automated deployment works changes how you think about the production environment. The concepts take a weekend to grasp.

Try 3D printing. Buy an entry-level printer and design something you need. The investment is modest and the learning is immediate. The physical constraint experience develops faster than you’d expect—a dozen prints changes your relationship to tolerance and precision. For how to approach the first projects, from Figma to filament: why I 3D print as a product designer covers the right starting approach.

Deploy something yourself. Set up a VPS, deploy a project, manage it for six months. You don’t need to do anything exotic—a static site with a CI/CD deployment is sufficient. The experience of owning the infrastructure changes your understanding of the operational context engineering works in.

Use AI tools systematically. Not casually, but as a practiced workflow. Build a library of prompts that reliably produce useful outputs. Learn where AI helps and where it doesn’t. The fluency develops from systematic use, not occasional experimentation.

What this practice means for how you lead design teams

The leadership implication of hybrid design practice is often underrated. Design leaders who are hybrid practitioners lead differently.

They hire differently. They value technical fluency in design candidates—not as a prerequisite, but as a signal of engineering collaboration competence. They look for designers who are curious about the technical side of what they’re building, not just the visual side.

They collaborate differently. Engineering teams treat a design director who participates in PRs, who understands infrastructure constraints, who can deploy a prototype, as a peer rather than a stakeholder. That relationship produces better product outcomes than a stakeholder relationship.

They prioritize differently. Design leaders who understand implementation complexity prioritize more honestly. They know when a design is easy to implement and when it’s expensive. They can advocate for design quality with accurate assessments of the tradeoff, not just aesthetic preference.

They develop their teams differently. They encourage IC designers to develop technical fluency not for its own sake, but because it reduces the friction between design decisions and production outcomes. They model the practice themselves.

Key Takeaways

The design engineer profile is a practitioner who has developed fluency across multiple technical domains and applies that fluency in their design practice—not a separate job, but an enriched version of design leadership
The skills compound: CAD tolerance experience changes how you handle technical specifications; CI/CD experience changes how you evaluate implementation cost; infrastructure experience changes how you participate in architecture conversations
The day-to-day integration is in the work itself: PR reviews, sprint planning, design explorations, prototyping, documentation—the technical fluency makes each of these more effective
Develop the hybrid practice gradually: start with git, add CI/CD, try 3D printing, deploy something yourself, use AI systematically
Design leaders who are hybrid practitioners hire differently, collaborate differently, prioritize more honestly, and develop their teams differently—the practice changes the leadership, not just the individual output

How I structure remote design teams for US startups

Wed, 05 Apr 2023 00:00:00 GMT

US startups often need senior design leadership without the cost and rigidity of a full in-house team. Over the past 15 years I’ve led and scaled remote design teams for product companies in the US while based in LATAM. The goal is always the same: structure the team so that design is accountable, aligned with engineering and product, and able to ship on time without depending on in-person coordination. The teams that succeed at this share a set of structural conditions. The ones that fail tend to violate the same few principles, usually around ownership clarity and communication predictability.

Why remote design teams fail at startups—and how to prevent it

Remote design team failures at startups cluster around three patterns. Understanding them upfront lets you build against them.

The accountability vacuum. In a remote team without explicit ownership models, design work falls into a shared responsibility zone where everyone is loosely accountable and no one is specifically responsible. A feature that nobody owns inevitably gets under-prioritized, inconsistently executed, and shipped with gaps. The fix is simple but requires discipline: every design outcome—every product area, every design system domain, every cross-cutting concern—has a named owner on the design team.

The async-only trap. Some remote teams overcorrect on async communication, eliminating synchronous touchpoints entirely to maximize flexibility. This works for execution but breaks for alignment. Design decisions that require shared judgment—design direction, prioritization, cross-functional tradeoffs—degrade when they’re handled exclusively through comments and docs. You need a minimum viable synchronous layer: design reviews with real-time feedback, pairing sessions for complex problems, standups or their equivalent for awareness.

The handoff-first culture. Remote teams that never see each other in person can develop a culture of handoffs: design produces artifacts, engineering implements, feedback flows back through tickets. This feels like it’s working until it’s clearly not—when production fidelity is low, when engineering makes design decisions silently, when the design file and the codebase have diverged for six months. The fix is making design participation in engineering’s process an explicit expectation, not an optional practice.

The ownership model that scales

The single most impactful structural decision for a remote design team is how ownership is assigned. I use two models depending on team size and product complexity.

Product area ownership (5+ person teams). Each designer owns a product area end-to-end: they’re responsible for every design decision in that area, the relationship with the engineering team that ships it, and the quality of the shipped output. Product area ownership creates deep context and clear accountability. The risk is siloing—designers in their own areas can develop divergent visual languages and interaction patterns over time. The mitigation is design system ownership and regular full-team critique.

Concern-based ownership (2–4 person teams). In smaller teams, I combine product coverage with cross-cutting concern ownership: one designer owns design systems, another owns accessibility, another owns the end-to-end user journey across product areas. This creates multiple accountability layers without requiring a large team. Every decision gets evaluated against at least two ownership lenses.

In both models, the ownership map is explicit and visible—posted in Notion, documented in Figma, reviewed quarterly. New team members shouldn’t have to infer what they own. It should be written down.

How do you build time-zone overlap that actually enables real-time collaboration?

Time-zone overlap is the infrastructure of remote collaboration. The minimum viable overlap for a design team working with US-based product and engineering is four hours of daily synchronous availability. Most LATAM-to-US pairings have six to eight hours, which is generous. The question is whether that overlap is used effectively.

The principles I apply:

Protect overlap hours for synchronous work. Design reviews, pairing sessions, stakeholder presentations, and cross-functional alignment calls all happen during the overlap window. Documentation, execution work, and async communication happens outside of it. If overlap hours are consumed by email and documentation, you’ve negated the benefit of the overlap.

Set explicit availability windows. Every designer on the team posts their daily availability in Slack, including any days where their window is reduced. This makes capacity visible without requiring a formal check-in system.

Match sync frequency to decision stakes. Not everything needs to be synchronous. A quick question gets an async answer. A design direction call needs a synchronous session. The calibration of sync vs. async is a skill the team develops over time—but it starts with making the principle explicit: synchronous time is for decisions that require shared judgment, async is for everything else.

Use standups as a blocker surface, not a status report. The design team daily standup (15 minutes, live or async video) is specifically for surfacing blockers and flagging upcoming dependencies. Not for reporting what you did yesterday. Designed this way, the standup creates actual value instead of becoming a meeting that could have been a Slack message.

The communication stack for a distributed design team

The right communication stack is the infrastructure that enables everything else. Here’s what I use with remote design teams supporting US startups:

Figma — source of truth for design. All work-in-progress, shipped designs, and design system components live here. The design file is always in the direction of current truth, even if production has briefly outpaced it.

FigJam — collaborative thinking space. Problem-framing sessions, design jams, retrospectives, brainstorming. The space where the team thinks together, not just executes together. For how this extends to cross-functional collaboration, design as the creative hub covers the rituals in depth.

Loom — async video for design reviews. A 3-minute Loom walking through a design decision is faster to record than a written comment and more effective than a comment thread for anything that requires spatial explanation. Every design review PR gets a Loom.

Linear — project management shared with product and engineering. Design tasks live in the same system as engineering tasks so dependencies are visible to both sides. Campaign and launch work shared with marketing runs through shared Linear projects.

Slack — ambient communication. Not a decision-making tool. Everything that needs a record goes in a doc, a Linear ticket, or a Figma comment.

GitHub — for design engineers and design directors who work directly in code. PR reviews for UI work, branch preview deployments, and version history for anything coded.

What good remote design operations look like at Series A

By Series A, a remote design team should operate with enough infrastructure that design work is predictable and legible to the rest of the company. These are the markers:

Engineering can answer “when will design be done with X?” by looking at Linear, not by asking
Product can look at the design file and understand what’s in progress, what’s shipped, and what’s in the design backlog
The design system is documented in Figma and referenced by both design and engineering in their daily work
Design reviews happen on a regular cadence with a consistent format that non-designers can participate in
New designers onboard to explicit ownership areas with documented context, not through informal knowledge transfer

This level of operational maturity doesn’t require a large team. A three-person design team with good systems operates more predictably and produces better output than a five-person team without them.

How do you hire well for a remote design role at a startup?

Hiring for remote design at a startup has different requirements than hiring for in-office roles at larger companies. The skills that matter most are less visible in portfolio presentations.

Self-direction. Can this person set their own daily priorities and deliver against them without external scaffolding? Remote design roles at startups require a level of self-management that’s genuinely different from structured office environments. The best interview signal is asking for specific examples of how they’ve navigated ambiguity and competing priorities without clear direction.

Communication clarity. Remote communication amplifies both strengths and weaknesses. Someone who writes and speaks with precision is dramatically more effective in an async context than someone who relies on visual cues and informal in-person clarification. Evaluate writing quality in the application materials, not just in a live interview.

Technical fluency. Designers who can review their own work in a browser, read code, and work in a developer environment create far less friction in remote engineering collaboration. This doesn’t mean everyone on the team needs to code, but the design lead should.

Portfolio breadth appropriate to the stage. For early-stage startups, designers who’ve only worked on large-team projects may struggle with the scope of ownership remote startup roles require. Look for evidence of owning outcomes end-to-end, not just executing within a defined scope.

For the leadership structure that makes nearshore remote design work at the senior level, nearshore design leadership: why US companies hire in LATAM covers the engagement model and what to look for when hiring.

Key Takeaways

The three failure modes for remote design teams are: accountability vacuum, async-only trap, and handoff-first culture—all are structural, not personal
Assign explicit ownership: every design outcome has a named owner; this is the single most impactful structural decision for a distributed design team
Four hours of daily time-zone overlap is the minimum viable synchronous layer; protect those hours for decisions that require shared judgment
The communication stack matters: Figma for source of truth, Loom for async reviews, Linear for shared project visibility, GitHub for code-adjacent work
By Series A, remote design should be legible—engineering and product can see what design is working on, what’s shipped, and what’s blocked, without asking