Diseño de emails vs. web: Cómo crear layouts que sobrevivan a Outlook

Diseñar emails no es diseñar para la web. Cuanto antes aceptes esa premisa, menos frustración vas a acumular en tu carrera.

Cuando preparás una interfaz web o una landing page, el navegador del usuario (Chrome, Safari, Edge) lee tu CSS moderno con motores como Blink o WebKit. Tenés Flexbox, CSS Grid, variables, animaciones fluidas y un ecosistema listo para resolver layouts complejos en segundos.

En email marketing la realidad es muy distinta. Cuando tu diseño aterriza en la bandeja de entrada de un cliente corporativo que usa Outlook para Windows, no lo abre un navegador web. Lo abre el motor de renderizado de Microsoft Word.

Sí, el mismo programa que usás para redactar un documento de texto es el encargado de procesar tu HTML y CSS. Esto significa que estás diseñando interfaces con tecnología visual conceptualmente congelada en 2007.

A continuación, te comparto la perspectiva y mentalidad que necesitas incorporar para diseñar piezas que se vean impecables, sin importar dónde se abran.

Entender el contexto de visualización

El primer error de un diseñador junior es construir un frame en Figma asumiendo que el lienzo es infinito y flexible. Un email habita en un entorno caótico y fragmentado:

• Dark mode forzado: Clientes de correo que invierten colores de fondo y texto con criterios propios e impredecibles.
• Pantallas móviles reducidas: Donde 600 píxeles de ancho es el estándar de oro tradicional para evitar desbordes en escritorio manteniendo legibilidad en teléfonos.
• Paneles de vista previa: Usuarios que leen el correo en un tercio de su pantalla monitorizada.

Pero el obstáculo real no es la pantalla pequeña; es Outlook. Mientras Apple Mail o Gmail Mobile aceptan bastante bien las reglas modernas de CSS, Outlook ignora atributos básicos como max-width, margin: auto, propiedades de display avanzadas o posiciones absolutas. Si no pensás el layout desde la estructura básica desde el primer segundo en Figma, la maquetación se romperá en fragmentos al llegar a producción.

El cambio de chip: Pensar en cajas y grillas rígidas

Para dominar el diseño de emails tenés que cambiar tu modelo mental. No estás distribuyendo elementos de forma fluida con CSS flex; estás armando una estructura física de cajas encajadas una dentro de otra.

El código que le da vida a esto no usa <div>, usa tablas HTML (<table>, <tr>, <td>). Todo lo que diseñes debe ser traducible a filas y columnas de una tabla estricta. Si un bloque visual no se puede encajar naturalmente en una celda de tabla con ancho fijo, vas a poner en problemas al desarrollador y la pieza se va a romper en Outlook.

Lo que SÍ y lo que NO al diseñar para Email

Para simplificar la entrega de tus archivos a desarrollo o para maquetar vos mismo sin tropiezos, guiate por este filtro:

Lo que SÍ debes aplicar

• Anchos definidos y contenidos en 600px: El estándar para el contenedor principal. Todo lo que exceda esa medida en escritorio corre riesgo de requerir scroll horizontal.
• Estructuras en columnas simétricas: Layouts de 1, 2 o 3 columnas limpias. Si usás columnas asimétricas, asegurate de que sus anchos sumen exactamente el total del contenedor (por ejemplo, 400px + 200px = 600px).
• Tipografías del sistema como fallback obligado: Podés proponer Inter, Roboto o Poppins, pero siempre tenés que definir cómo se ve la pieza si el cliente de correo bloquea la fuente web y recurre a Arial, Helvetica o sans-serif.
• Jerarquía clara entre imágenes y texto: El texto siempre debe ser texto vivo (HTML), no texto exportado dentro de una imagen. Outlook suele bloquear la descarga automática de imágenes por seguridad; si ponés el mensaje principal en una imagen, tu usuario verá un recuadro blanco vacío.
• Uso consciente de padding: Los espacios entre elementos deben pensarse a nivel de celda (<td>), no con márgenes colapsables.

Lo que NO debes incluir

• Flexbox o CSS Grid: No diseñes pensando en que los elementos se van a acomodar solos “mágicamente” de forma fluida en desktop si no hay una estructura modular detrás.
• Posicionamiento absoluto y solapamientos: Elementos que flotan sobre otros o tarjetas superpuestas a fondos complejos son un dolor de cabeza técnico en Word.
• SVG directo: Outlook no soporta código SVG inline ni como archivo de imagen. Todo lo vectorial debe exportarse como PNG o JPG en alta densidad (2x).
• Formularios e inputs interactivos: Campos para escribir dentro del email fallan en la mayoría de los clientes tradicionales. Remití siempre a una landing de destino con un CTA claro.
• GIFs animados pesados o videos embebidos: Outlook solo muestra el primer fotograma de un GIF animado. Si usás GIFs, asegurate de que el primer frame contenga toda la información clave o el CTA.

Cómo construir una entrega profesional

Como diseñador, tu rol no termina al exportar los assets de Figma. Un perfil senior comprende el proceso de ingeniería que viene después:

1. Diseñá en módulos independientes: Mantené tus secciones claramente separadas verticalmente (Header, Hero, Feature 1, Feature 2, Footer). Cada sección debe ser una tabla independiente en el maquetado.
2. Documentá las reglas de apilado (stacking): Especificá cómo deben comportarse las 2 o 3 columnas al pasar a mobile. Por lo general, la columna de la izquierda pasa arriba y la de la derecha abajo. Si necesitás lo contrario, avisale al desarrollador para que aplique condicionales.
3. Optimización de imágenes: Entregá imágenes exportadas al doble de su tamaño de visualización (para pantallas Retina), pero pasadas por herramientas de compresión sin pérdida. Un email con más de 2 MB en imágenes totales arriesga terminar en la carpeta de SPAM.

Diseñar para email no es limitar tu creatividad, es ejercitar la precisión. Cuando aprendés a moverte con elegancia dentro de las restricciones técnicas de Outlook, lográs piezas sólidas, efectivas y técnicamente indestructibles.