CodeGym /Cursos /ChatGPT Apps /Diseño visual: temas, colores, tipografía, espaciados y b...

Diseño visual: temas, colores, tipografía, espaciados y bibliotecas listas para usar

ChatGPT Apps

Nivel 8 , Lección 3

Disponible

1. Contexto: tu App — invitada en la casa de ChatGPT

Antes de dibujar botones y elegir tipografías, conviene asumir la realidad: el usuario no abre «tu sitio», está dentro de ChatGPT. ChatGPT ya tiene sus:

esquema de color,
fuentes y tamaños,
espaciados y composición de los elementos.

Tu widget se muestra dentro de ese entorno, normalmente en un iframe. De ahí una conclusión importante: visualmente, la App debe parecer una extensión natural de la interfaz de ChatGPT, no un banner traído de 2008.

Las guías oficiales de OpenAI van justo de esto: no romper los colores y fuentes del sistema, añadir solo acentos de marca moderados y seguir la tipografía base y la rejilla de la plataforma.

En sentido práctico, esto implica tres cosas.

Primero, el fondo, el color base del texto y la tipografía estándar —todo debe heredarse de ChatGPT o de variables del sistema, no «yo soy artista y así lo veo».

Segundo, si quieres «tu estilo», debe concentrarse en los acentos: botones principales, badges, estados destacados. Pero no un fondo arcoíris ni la fuente personalizada Comic Sans —aunque te apetezca mucho.

Tercero, los modos inline y fullscreen de una misma App deben parecer parte del mismo mundo: mismos colores de CTA, mismos radios y espaciados de tarjetas, misma tipografía. El usuario no debe sentir que al pasar de inline a fullscreen ha llegado a otro producto.

Luego veremos por capas: colores y temas, tipografía, espaciados y rejilla, y después cómo Tailwind y shadcn/ui ayudan a ensamblarlo todo.

Insight

La sandbox de ChatGPT no solo limita la funcionalidad de tu widget, también le añade sus estilos.

Primero — la etiqueta raíz HTML

Original del sitio:

<html lang="ru">

En la sandbox:

<html lang="en-US" data-theme="light" class="light" style="--safe-area-inset-top: 0px; --safe-area-inset-bottom: 0px; --safe-area-inset-left: 0px; --safe-area-inset-right: 0px;">

Segundo — los estilos CSS nativos, para que tu widget se parezca más a ChatGPT:

<style>
  html,body,#root{-webkit-font-smoothing:antialiased;-moz-osx-font-smoothing:grayscale;margin:0;padding:0}
  html,body{font-family:-apple-system,BlinkMacSystemFont,Segoe UI,Roboto,Oxygen,Ubuntu,Cantarell,Helvetica Neue,Arial,sans-serif!important}
  button,input,textarea,select{font-family:inherit}
  html{background-color:#fff}
  html.dark{background-color:#212121}
  html.mobileSkybridge.dark{background-color:#000}
  @supports (font: -apple-system-body){html.mobileSkybridge{font:-apple-system-body}}
</style>

Mejor recordarlo: habrá menos sorpresas.

2. Temas y colores: vivimos en universos claro y oscuro

Temas claro y oscuro

La interfaz de ChatGPT ya soporta tema claro y tema oscuro. Tu widget se muestra dentro de uno de ellos, y el usuario puede cambiar entre ambos en cualquier momento. Por tanto, fondos blanco/negro codificados a fuego —potencialmente son una mina.

Imagina un widget que pinta fondo blanco y texto negro. En tema claro es pasable. En tema oscuro —es un foco en los ojos. La situación inversa con fondo negro en tema claro no es mejor. Por eso las recomendaciones oficiales aconsejan no hardcodear colores, sino apoyarse en el tema/variables del host.

En Apps SDK el entorno suele darte un API o variables CSS para el tema actual. En la documentación aparecen opciones como window.openai.theme y el uso de variables CSS estándar de ChatGPT. Además, siempre puedes usar prefers-color-scheme y las utilidades dark: en Tailwind.

La idea es algo así: tu widget debe ajustar automáticamente, según el tema del host, aspectos como:

fondo de las tarjetas (ligeramente más claro/oscuro que el fondo base),
color del texto (contraste suficiente),
bordes, sombras y estados hover.

Ejemplo de un wrapper simple para tema con Tailwind:

// components/AppShell.tsx
export function AppShell({ children }: { children: React.ReactNode }) {
  return (
    <div className="bg-background text-foreground">
      {/* bg-background/text-foreground son redefinidos por el tema */}
      {children}
    </div>
  );
}

Donde bg-background y text-foreground no son clases estándar de Tailwind, sino alias a variables CSS de tu sistema de diseño (por ejemplo, de shadcn/ui), que a su vez están vinculadas al tema claro/oscuro de ChatGPT.

Colores del sistema frente a acentos de marca

OpenAI lo dice bastante claro: los colores del sistema de ChatGPT no se deben cambiar. Texto base, paneles estándar del chat, fondo —todo debe permanecer en los colores generales de la plataforma. Tu campo de juego —los acentos dentro del widget: botones CTA (call to action — acción principal), badges, elementos pequeños.

En la práctica de GiftGenius, esto significa que:

el fondo de la tarjeta de regalo está cerca del del sistema,
el texto usa el color habitual, como el del chat,
el color de marca de GiftGenius se usa para el botón principal «Elegir regalo» y, quizá, para el badge de descuento.

Se puede imaginar una tabla:

Elemento	Qué hacer	Qué evitar
Fondo del widget	Heredar de ChatGPT	Usar un degradado de marca llamativo
Texto principal	Heredar el color del sistema	Hacerlo de color/ gris hasta volverlo ilegible
Botón CTA principal	Usar el color de acento de marca	Ponerle un «arcoíris» y 5 colores
Botones/enlaces secundarios	Cercanos a los enlaces del sistema	Hacerlos tan llamativos como el CTA
Sombras/bordes	Suaves, minimalistas	Bordes neón gruesos

Mini‑ejemplo con Tailwind para el color principal:

// styles/globals.css (fragmento)
:root {
  --gift-accent: 222 84% 56%; /* hsl */
}

.dark {
  --gift-accent: 222 84% 64%; /* un poco más claro para tema oscuro */
}

// components/GiftButton.tsx
export function GiftButton({ children }: { children: React.ReactNode }) {
  return (
    <button className="rounded-md bg-[hsl(var(--gift-accent))] px-4 py-2 text-sm font-medium text-white hover:opacity-90">
      {children}
    </button>
  );
}

No tocas el fondo de todo el widget, pero aplicas con cuidado tu color al botón CTA principal.

Contraste y WCAG sin fanatismo

Aunque no te vayas a examinar de WCAG, hay una pauta sencilla: el texto debe ser legible. Cuanto más pequeño el tamaño, mayor debe ser el contraste. En cursos de accesibilidad recomiendan mantener el contraste del texto respecto al fondo no por debajo de ~4.5:1 para el cuerpo del texto. No vamos a profundizar aquí en los estándares: nos basta con una guía práctica —contraste suficiente entre texto y fondo.

En la práctica:

no uses texto gris claro sobre fondo gris claro por «elegancia»;
evita texto gris oscuro sobre fondo casi negro en tema oscuro;
compruébalo al menos a ojo: si entornas los ojos —al usuario también le dolerá.

Ponte una regla: incluso el texto secundario (etiquetas, ayudas) sigue siendo legible, solo un poco menos acentuado en color y tamaño, pero no «fantasmal».

3. Tipografía: fuentes del sistema, jerarquía y algo de sentido común

Fuentes del sistema en lugar de tu propia familia

Las guías oficiales animan a usar fuentes del sistema de la plataforma, como SF Pro, Roboto y análogas, y no colar tu webfont. Y la razón no es solo el rendimiento, sino que tu App debe verse como un elemento nativo de la interfaz.

En una app Next.js, lo más fácil es hacer que todo dentro del widget herede la pila de fuentes del sistema. En Tailwind esto suele venir ya como font-sans. Si quieres ser más explícito:

// app/layout.tsx (fragmento)
export default function RootLayout({ children }: { children: React.ReactNode }) {
  return (
    <html lang="en">
      <body className="font-sans antialiased">
        {children}
      </body>
    </html>
  );
}

No hace falta cargar 3 familias desde Google Fonts. Para el GiftGenius didáctico, una tipografía estricta del sistema se verá más cuidada que, por ejemplo, Lobster.

Jerarquía de tamaños

Bastan unos pocos niveles de tipografía: título de bloque, subtítulo/parámetro clave, cuerpo de texto y leyenda.

Para una tarjeta inline de GiftGenius, por ejemplo, es cómodo acordar estos niveles:

Rol	Clase de Tailwind	Ejemplo
Título de la tarjeta	`text-base font-semibold`	Nombre del regalo
Parámetro clave	`text-sm font-medium`	Precio o categoría
Descripción	`text-sm text-muted-foreground`	Descripción breve
Leyenda/detalles	`text-xs text-muted-foreground`	Envío, tienda

Mini‑componente de tarjeta:

// components/GiftCard.tsx
type GiftCardProps = {
  title: string;
  price: string;
  description: string;
};

export function GiftCard({ title, price, description }: GiftCardProps) {
  return (
    <div className="rounded-lg border bg-card p-4">
      <h3 className="text-base font-semibold">{title}</h3>
      <p className="mt-1 text-sm font-medium text-emerald-600">{price}</p>
      <p className="mt-2 text-sm text-muted-foreground">{description}</p>
    </div>
  );
}

Aquí:

no hay un H1 enorme;
toda la información es compacta;
la jerarquía se percibe por tamaño y peso de la fuente.

Alineación y longitud de línea

Una interfaz de chat suele ser estrecha, especialmente en inline. Así que no hace falta complicarse con una tipografía rebuscada: alineación normal a la izquierda y longitud de línea de 40–60 caracteres es bastante cómoda.

Hábitos útiles:

no centres textos largos en la tarjeta —son más difíciles de leer;
no escribas TODO EN MAYÚSCULAS;
no bajes el cuerpo de texto de 14 px (en Tailwind es text-sm) sin una razón de peso.

En caso de duda, recuerda: leerá una persona cansada en el móvil en el metro, no tú con tu monitor perfecto de 27".

4. Espaciados, densidad y rejilla

Si colores y fuentes son las «pinturas», los espaciados son el aire. Sin ellos, hasta las tarjetas más cuidadas se convierten en una papilla.

OpenAI recalca en sus recomendaciones: los elementos no deben «pegarse», conviene tomar espaciados y radios de un sistema de diseño o framework UI (Tailwind, shadcn/ui, etc.), y minimizar el scroll horizontal.

Principio «respirar»

El patrón más simple: usar una escala única de espaciados (por ejemplo, paso de 4 px o 8 px) y no inventar cada vez un tamaño «propio». En Tailwind ya viene integrado: p-2, p-3, p-4, gap-3, etc.

Ejemplo de rejilla pequeña para una lista de regalos en inline:

// components/GiftListInline.tsx
export function GiftListInline({ children }: { children: React.ReactNode }) {
  return (
    <div className="flex flex-col gap-3">
      {children}
    </div>
  );
}

Cada tarjeta está separada con gap-3, tiene sus p-4 internos, y con eso basta para que la lista no parezca un bloque interminable.

Columnas: inline frente a fullscreen

En las guías de UX para Apps SDK se recomienda en un widget inline ceñirse a 1–2 columnas de tarjetas, y en fullscreen puedes permitirte 2–3 si el ancho lo permite.

La razón es simple: en el chat el ancho es limitado, especialmente en móvil, y dos columnas ya están en el límite de legibilidad. En fullscreen obtienes casi toda la pantalla y puedes colocar el contenido con más densidad.

Esquema orientativo:

flowchart LR
  subgraph Inline
    A[1 columna
pantalla estrecha]
    B[2 columnas
en escritorio]
  end

  subgraph Pantalla completa
    C[2 columnas
escenario principal]
    D[3 columnas
para rejillas/catálogos]
  end

Implementación en Tailwind para GiftGenius:

// components/GiftGrid.tsx
export function GiftGrid({ fullscreen, children }: { fullscreen?: boolean; children: React.ReactNode }) {
  const base = fullscreen ? "grid-cols-2 md:grid-cols-3" : "grid-cols-1 sm:grid-cols-2";

  return (
    <div className={`grid gap-4 ${base}`}>
      {children}
    </div>
  );
}

En modo inline das una columna en móvil y dos en pantallas más anchas. En fullscreen empiezas con 2–3 columnas según el ancho.

Evitar el scroll horizontal

El chat es, por naturaleza, vertical. El usuario está acostumbrado a desplazarse hacia abajo, no de lado. Por eso:

intenta que tablas y tarjetas entren en el ancho del contenedor;
no des anchos fijos como width: 600px; a un elemento que vive en un contenedor flexible;
usa max-w-full, overflow-x-auto solo como «último recurso», no como defecto.

Para las tarjetas de GiftGenius conviene usar w-full y dejar que la rejilla decida cuántas caben por fila.

5. Adaptabilidad dentro del contenedor de ChatGPT

En frontend «normal» tienes control total del viewport. En ChatGPT ese control es limitado: tu widget está dentro del contenedor del chat, con su tamaño y sus reglas. Apps SDK ofrece varios puentes útiles: altura máxima, safe area para los recortes de pantalla, tipo de dispositivo, etc.

maxHeight y las limitaciones verticales

En modo inline, ChatGPT puede limitar la altura del widget para que no «se coma» toda la pantalla. Hooks como useMaxHeight() te permiten saber cuánto espacio puedes ocupar honestamente y colgar scrolls internos donde haga falta.

Pseudocódigo:

// Pseudocódigo, no es un API real:
const maxHeight = useMaxHeight();

return (
  <div style={{ maxHeight, overflowY: "auto" }}>
    <GiftGrid>{/* ... */}</GiftGrid>
  </div>
);

Así evitas que el widget choque con el borde inferior de la pantalla y que los mensajes del chat «se vayan» a otra vida.

safeArea y dispositivos móviles

En móviles pueden existir recortes, barra de estado, paneles del sistema. Apps SDK permite obtener la safeArea y ajustar los espaciados para que nada se esconda bajo el «notch» del teléfono.

A nivel de CSS puedes añadir padding extra:

// Pseudocódigo
const { top, bottom } = useSafeArea(); // supongamos que devuelve { top: 8, bottom: 16 }

return (
  <div style={{ paddingTop: top, paddingBottom: bottom }}>
    {/* contenido */}
  </div>
);

Para esta lección nos interesa el principio: el widget debe respetar el limitador de altura y la zona segura, o el UX se convierte al instante en «haz tres scrolls más para ver el botón».

6. Tailwind y shadcn/ui: no reinventar los botones desde cero

Escribir toda la UI a mano con CSS puro hoy ya es casi deporte hardcore. En el contexto de ChatGPT Apps es mucho más sencillo tomar una biblioteca probada y ajustarla a los requisitos de la plataforma. En el curso nos apoyamos en Tailwind y shadcn/ui como stack base.

Tailwind como diccionario de espaciados y colores

Tailwind ofrece un conjunto cómodo de utilidades:

espaciados (p-4, gap-3),
tamaños (text-sm, text-base),
colores (text-muted-foreground, bg-card), que en shadcn/ui y sistemas similares ya están conectados a variables CSS del tema.

Esto encaja perfecto con los requisitos de ChatGPT:

no inventas espaciados arbitrarios,
defines tamaños de texto de forma consistente,
no rompes los colores del sistema, sino que usas tokens acordados de antemano.

shadcn/ui como conjunto de componentes pulcros

shadcn/ui (y bibliotecas parecidas) proporcionan Card, Button, Input, Tabs, etc., ya ajustados al tema de Tailwind. Esto acelera mucho montar una interfaz cuidada y minimalista, especialmente para las tarjetas de GiftGenius.

Ejemplo de GiftCard usando shadcn/ui:

// components/GiftCardShadcn.tsx
import { Card, CardContent, CardHeader, CardTitle } from "@/components/ui/card";
import { Button } from "@/components/ui/button";

type GiftCardProps = {
  title: string;
  price: string;
  description: string;
};

export function GiftCardShadcn(props: GiftCardProps) {
  return (
    <Card>
      <CardHeader>
        <CardTitle className="text-base">{props.title}</CardTitle>
      </CardHeader>
      <CardContent className="space-y-2">
        <p className="text-sm font-medium text-emerald-600">{props.price}</p>
        <p className="text-sm text-muted-foreground">{props.description}</p>
        <Button className="mt-2">Elegir regalo</Button>
      </CardContent>
    </Card>
  );
}

Lo importante aquí no es shadcn en sí, sino los principios:

el título no es gigantesco;
la descripción se lee bien;
el botón está maquetado según el sistema de diseño común, no «a su bola».

Ajuste para ChatGPT

En un proyecto real puedes ajustar la paleta al estilo minimalista de ChatGPT: fondo claro, sombras suaves, radios discretos. El plan del módulo propone apoyarse en un sistema de diseño existente, no crear tu propio universo.

Enfoque sencillo:

tomar la base de shadcn/ui;
dejar la fuente del sistema;
configurar uno o dos colores de marca en los tokens primary / accent;
asegurarse de que tanto inline como fullscreen usan los mismos tokens.

Así obtienes un núcleo visual coherente sin esfuerzos innecesarios.

7. Lenguaje visual de GiftGenius: lo juntamos todo

Sistematicemos qué podemos considerar ya «lenguaje visual» para nuestro hipotético GiftGenius.

Primero, el esquema de color. Fondo y texto se heredan de ChatGPT; el color de acento —discreto pero visible— se aplica a los botones CTA y, quizá, a los badges de descuento. En tema oscuro ese acento es un poco más claro para mantener el contraste.

Segundo, tipografía. Fuente del sistema, tamaños text-sm para el texto base y text-base para los títulos de las tarjetas. Cursiva y versales se usan poco, solo cuando aportan. Los encabezados en el asistente fullscreen un paso más arriba, pero todavía sin gritar con text-4xl.

Tercero, espaciados y rejilla. En modo inline la lista de regalos —una o dos columnas con gap-3/gap-4, cada tarjeta con p-4. En fullscreen —2–3 columnas, los pasos del asistente con espacios suficientes entre formularios y botones. Nada de scroll horizontal en los escenarios principales.

Pequeño esquema para las pantallas de GiftGenius:

graph TD
  A[Inline: lista de regalos] --> B[GiftCard
colores/tipografía/CTA]
  A --> C[GiftGrid 1-2 columnas]

  D[Pantalla completa: asistente de selección] --> E[Paso 1
formulario]
  D --> F[Paso 2
filtros/rangos]
  D --> G[Paso 3
confirmación]
  
  B --> H[GiftButton
acento de marca]

Cuarto, compatibilidad con el contexto del host. Todos los elementos se portan bien al cambiar entre tema claro/oscuro, respetan maxHeight y no se esconden bajo la safe-area. Los colores no compiten con ChatGPT, y los botones CTA lucen iguales en todas partes, para que el usuario, por memoria muscular, sepa dónde pulsar.

Este conjunto de decisiones ya hace tu app presentable no solo para programadores, sino también para usuarios reales o product managers: habrá algo que discutir además de «aquí tenemos MCP, y allí el Agents SDK».

8. Accesibilidad (Accessibility Guidelines, WCAG AA)

Ya mencionamos por encima WCAG al hablar del contraste entre texto y fondo en la sección 2.3. Allí nos interesaba una guía práctica —no matar la legibilidad. Ahora miremos la accesibilidad un poco más en grande: cómo se ve la misma interfaz para quien no la percibe con la vista, y para la propia ChatGPT en modo de voz.

WCAG AA — es un nivel del estándar de accesibilidad del conjunto internacional de reglas WCAG (Web Content Accessibility Guidelines), que describe cómo hacer sitios e interfaces accesibles para personas con diferentes limitaciones de visión, motricidad, aspectos cognitivos, etc.

La idea principal de WCAG AA — convertir una interfaz de «teóricamente accesible» en realmente usable. Este nivel incluye decenas de requisitos que influyen directamente en la calidad de la interacción. Entre ellos —el umbral de contraste texto/fondo de alrededor de 4.5:1, del que ya hablamos, y también requisitos sobre tamaños de áreas clicables, estados de foco, errores en formularios, etc.

Una capa aparte —soporte de tecnologías de asistencia, incluidos los lectores de pantalla. El nivel AA exige semántica correcta: que los encabezados sean encabezados, las listas —listas, los botones —botones, y que los elementos interactivos tengan roles correctamente asignados y textos alternativos. Esto permite a usuarios que trabajan con VoiceOver, TalkBack o NVDA comprender plenamente la estructura y el sentido de la interfaz.

Screen reader (lector de pantalla)

Screen reader (lector de pantalla) — es un programa que vocaliza y/o estructura el contenido de la pantalla, permitiendo a personas con discapacidad visual usar un ordenador, smartphone o aplicaciones web.

Pero un screen reader no es solo «un programa que lee texto en voz alta». Es un sistema completo de interacción con la interfaz que convierte la representación visual del sitio o app en una navegación sonora y estructurada accesible.

ChatGPT, screen reader y WCAG AA

Si tu widget está marcado según los principios de WCAG AA (roles correctos, encabezados, etiquetas de botones), es comprensible no solo para los lectores de pantalla, sino también para ChatGPT en modo de voz. El usuario habla con ChatGPT, y el modelo, apoyándose en esa misma estructura semántica, puede «hacer virtualmente» lo mismo que una persona: encontrar elementos de la interfaz, pulsar botones, seguir enlaces, etc.

Según los requisitos de ChatGPT Store, el soporte del estándar WCAG AA es obligatorio para cada aplicación. Cada widget y cada tool deben tener descripciones de la máxima calidad y detalle, y el marcado —estar hecho conforme a los estándares WCAG AA: semántica correcta, etiquetas legibles, estados predecibles.

Por tanto, el requisito WCAG AA no es una «funcionalidad aparte para personas con necesidades especiales», sino un principio de diseño base para que ChatGPT Apps pueda trabajar plenamente con tu aplicación, también cuando el usuario se comunica con ella por voz.

Volveremos a los escenarios de voice‑UX, a las diferencias entre diálogo por voz y texto y a los requisitos de ChatGPT Store en otras lecciones de este módulo y en el módulo de publicación de la App. Pero todo se sostiene sobre el fundamento que acabas de ver: modo de voz = multimodalidad + accesibilidad (WCAG AA + lectores de pantalla).

9. Errores típicos del diseño visual de una ChatGPT App

Error nº 1: Fondos blanco/negro y colores de texto codificados a fuego.
El desarrollador pinta fondo blanco y texto negro sin pensar en el tema oscuro. En tema claro aún sobrevive, en tema oscuro —se convierte en un foco y arruina el UX. Es más correcto usar los colores del sistema y el tema del host (variables CSS, prefers-color-scheme o el API de Apps SDK), y reservar tus colores para acentos.

Error nº 2: Branding demasiado agresivo.
Aparece un fondo con degradado chillón, fuente personalizada, bordes multicolor. El widget empieza a parecer un banner promocional, no parte de la interfaz de ChatGPT. Las guías piden lo contrario: aspecto minimalista y «nativo», con uso cuidadoso del color de marca solo en elementos clave, por ejemplo, en los botones principales.

Error nº 3: Falta de jerarquía tipográfica.
Todos los textos con el mismo tamaño y peso, o al revés —tres niveles de títulos en una tarjeta pequeña, además en versales. El usuario no entiende qué es lo principal: nombre, precio o descripción. Mejor acordar de antemano 3–4 niveles y ceñirse a ellos: título, parámetro clave, cuerpo de texto, leyenda.

Error nº 4: Elementos pegados sin espaciados.
Las tarjetas están pegadas entre sí, el texto al borde, los botones pegados al texto. En escritorio aún pasa, en móvil se convierte en ruido visual. Se recomienda usar una escala única de espaciados (por ejemplo, las clases de Tailwind p-4, gap-3) y no escatimar en aire.

Error nº 5: Intentar meter 4–5 columnas en modo inline.
El desarrollador sigue mentalmente en una página de ecommerce y monta en el chat una parrilla de cuatro tarjetas estrechas. En pantallas anchas es discutible, en móvil —directamente ilegible, aparece scroll horizontal. En un widget inline suele bastar con una o dos columnas; deja la tercera para fullscreen.

Error nº 6: Ignorar las limitaciones de altura y la safe‑area.
El widget dibuja una lista gigante sin scroll interno y sin tener en cuenta maxHeight, así que los botones quedan «debajo del fondo de la pantalla». O los elementos se esconden bajo el recorte del móvil. Conviene usar los datos de altura máxima y zona segura para repartir bien altura y espaciados internos.

Error nº 7: Apariencia inconsistente de botones y tarjetas entre inline y fullscreen.
En inline el botón es verde y redondeado, y en fullscreen —azul y cuadrado. El usuario pierde la sensación de producto único. Hay que extraer los estilos base de botones y tarjetas a un componente/tema común y usarlo en todos los modos.

Error nº 8: Fuente «de autor» y florituras decorativas.
Conectar una webfont pesada «para que quede bonito» rompe la consistencia visual con ChatGPT y a veces empeora el rendimiento. Las recomendaciones de la plataforma dicen usar fuentes del sistema y tipografía cuidada. Si quieres expresarte como diseñador, mejor trabaja los iconos y el microcopy, no una revolución tipográfica.

Anterior Lección anterior

Siguiente Siguiente lección

Comentarios

TO VIEW ALL COMMENTS OR TO MAKE A COMMENT,
GO TO FULL VERSION