← Volver al listado de tecnologías ← Índice de Impeccable

Contenido y adaptación: clarify, adapt, optimize

Por: Artiko
impeccableclarifyadaptoptimizecontenido

Contenido y adaptación: clarify, adapt, optimize

En el capítulo anterior trabajamos el movimiento y el deleite: animaciones, microinteracciones y onboarding. Eran capas que se aplican sobre una interfaz que ya existe. Ahora damos un paso atrás para mirar algo que muchos equipos tratan como un detalle de última hora y que, sin embargo, es la mitad de la experiencia: el contenido y su capacidad de adaptarse.

Este capítulo cubre tres comandos de Impeccable que comparten una idea de fondo: una interfaz no se termina cuando los píxeles encajan, sino cuando el mensaje es claro, cuando ese mensaje sobrevive al cambio de dispositivo o idioma, y cuando llega rápido a la persona que lo necesita. Esos tres frentes son, respectivamente, clarify, adapt y optimize.

Recuerda que en Impeccable todos los comandos se invocan con la misma forma: /impeccable <comando> <target>, donde el target puede ser un componente, una página o una ruta del proyecto. Cada comando lee su guía de referencia interna (los archivos reference/clarify.md, reference/adapt.md y reference/optimize.md del skill) y aplica un proceso sistemático en lugar de una opinión improvisada.

El contenido es diseño, no un afterthought

Antes de entrar en los comandos conviene fijar la filosofía, porque explica por qué estos tres comandos existen y no son simplemente “pasar el texto por un corrector”.

Cuando diseñamos solemos rellenar las maquetas con texto de relleno (Lorem ipsum) y dejamos las palabras reales para “cuando esté el diseño”. El problema es que el texto no es contenido decorativo: es la parte de la interfaz con la que la persona realmente piensa. Un botón que dice Submit y otro que dice Crear cuenta ocupan el mismo espacio, pero comunican cosas distintas. Una jerarquía visual impecable puede arruinarse con un titular ambiguo, y la mejor animación del mundo no salva a un mensaje de error que dice Error 403: Forbidden.

flowchart LR
    A[Contenido del mensaje] --> B{¿Es claro?}
    B -->|clarify| C[Mensaje legible y específico]
    C --> D{¿Sobrevive al contexto?}
    D -->|adapt| E[Funciona en cada dispositivo / idioma]
    E --> F{¿Llega rápido?}
    F -->|optimize| G[Experiencia percibida y accesible]
    G --> H[Diseño realmente terminado]

La secuencia del diagrama es deliberada. No tiene sentido optimizar el peso de una página cuyo mensaje todavía confunde, ni adaptar a móvil un texto que en escritorio ya falla. Por eso el orden mental recomendado es: primero claridad, después adaptación, después optimización.

clarify: claridad del contenido y del mensaje

clarify es el comando que ataca el texto de la interfaz: microcopy, etiquetas, errores, estados vacíos, navegación y la jerarquía de la información. Su guía de referencia parte de una idea muy concreta: el texto poco claro genera tickets de soporte y abandono. Es decir, la ambigüedad tiene un coste medible.

Propósito y target

El proceso de evaluación

Según el reference, antes de reescribir nada clarify evalúa el texto buscando seis problemas concretos:

  1. Jerga sin explicación.
  2. Ambigüedad (frases que admiten más de una interpretación).
  3. Voz pasiva donde la activa sería más directa.
  4. Problemas de longitud (demasiado largo o demasiado corto).
  5. Falta de contexto (el texto no dice qué pasará después).
  6. Tono inadecuado para la situación.

Solo cuando esos problemas están identificados pasa a la estrategia de mejora: definir el mensaje principal, la acción requerida, el tono apropiado y las restricciones antes de redactar la nueva versión.

Principios fundamentales

La guía resume su criterio en principios que se aplican a todo el copy:

Y su lista de prohibiciones es igual de tajante: nunca uses jerga sin explicar, nunca culpes a la persona usuaria, nunca escribas en pasiva por defecto, nunca asumas conocimiento técnico y nunca cambies la terminología “por variar” (la consistencia léxica importa más que la riqueza de vocabulario).

Ejemplos de transformación

El reference incluye casos canónicos que muestran el antes y el después:

Error message:
  Antes:  "Error 403: Forbidden"
  Después: "You don't have permission to view this page. Contact your admin."

Button label:
  Antes:  "Submit"
  Después: "Create account"

Empty state:
  Antes:  "No items"
  Después: "No projects yet. Create your first to get started."

Form label:
  Antes:  "DOB (MM/DD/YYYY)"
  Después: "Date of birth"

Ejemplo de invocación y salida

/impeccable clarify src/components/SignupForm.tsx

La salida no es una lista de quejas, sino una propuesta accionable: por cada pieza de texto detectada con alguno de los seis problemas, clarify entrega el texto reescrito, una breve justificación, y cuando aplica una tabla de consistencia para unificar la terminología (por ejemplo, decidir entre eliminar, borrar o quitar y usar siempre el mismo término). Cierra con una checklist de verificación para confirmar la claridad antes del handoff.

adapt: adaptar el diseño a otro contexto

adapt resuelve un problema distinto: tienes un diseño que funciona en un contexto y necesitas que funcione en otro (otro dispositivo, otra superficie, otro idioma, otro breakpoint). La trampa que el reference quiere evitar tiene nombre propio: escalar píxeles en lugar de repensar la experiencia.

“Adaptation is rethinking the experience for the new context, not scaling pixels.”

Propósito y target

Los cuatro pasos de adapt

El reference describe un flujo de cuatro fases que vale la pena conocer:

sequenceDiagram
    participant A as adapt
    participant S as Diseño original
    participant T as Contexto destino
    A->>S: 1. Evaluar el reto (supuestos del origen)
    A->>T: 2. Entender destino (input, pantalla, red, uso)
    A->>A: 3. Planificar estrategia por contexto
    A->>T: 4. Implementar (breakpoints por contenido)
    T-->>A: Verificar en dispositivos reales
  1. Evaluar el reto: identificar el contexto y los supuestos del diseño original, y señalar qué no encaja o no funcionará en el nuevo entorno.
  2. Planificar la estrategia según el destino.
  3. Implementar con técnicas responsivas reales.
  4. Verificar en condiciones reales.

Estrategias por contexto

La guía da pautas concretas para cada superficie:

Reglas técnicas clave

adapt insiste en detectar el método de entrada, no solo el tamaño de pantalla. Un portátil puede tener pantalla táctil y una tablet puede tener teclado, así que el viewport por sí solo miente.

/* Detección por capacidad, no por tamaño */
@media (pointer: coarse) {
  /* dispositivos táctiles: targets más grandes */
  .button { min-height: 44px; min-width: 44px; }
}

@media (hover: hover) {
  /* solo cuando el hover existe de verdad */
  .card:hover { transform: translateY(-2px); }
}

/* Soporte para notch / esquinas redondeadas */
.app-bar {
  padding-top: env(safe-area-inset-top);
}

Para imágenes, la recomendación es usar srcset con descriptores de ancho y sizes, y recurrir a <picture> para art direction cuando el recorte cambia entre breakpoints:

<picture>
  <source media="(max-width: 600px)" srcset="hero-mobile.webp" />
  <source media="(min-width: 601px)" srcset="hero-desktop.webp" />
  <img src="hero-desktop.webp" alt="Panel de control de la aplicación" />
</picture>

El enfoque recomendado es mobile-first: estilos base para móvil y complejidad de escritorio en capas con min-width, para no cargar estilos innecesarios. Y, sobre todo, breakpoints dirigidos por el contenido, no por tamaños genéricos de dispositivo.

Prohibiciones de adapt

Ejemplo de invocación y salida

/impeccable adapt src/pages/pricing.astro

La salida de adapt describe qué supuestos del diseño original se rompen en el contexto destino, propone la estrategia de adaptación adecuada (columnas, áreas táctiles, divulgación progresiva) y entrega el CSS/markup responsivo con media queries por capacidad de entrada, además de una lista de verificación en dispositivos y orientaciones reales.

optimize: optimizar lo que de verdad importa

optimize cierra el trío. Su principio rector es claro y disciplinado:

“Performance is a feature. Identify the actual bottleneck for THIS interface, fix it, then measure.”

La clave es la palabra measure. El reference está construido para evitar la optimización prematura: no se toca nada sin datos que demuestren dónde está el cuello de botella real de esta interfaz concreta.

Propósito y target

Fase de evaluación:

Dominios de optimización:

  1. Rendimiento de carga (imágenes, JavaScript, CSS, fuentes).
  2. Rendimiento de renderizado (layout thrashing, optimización del DOM).
  3. Rendimiento de animación (aceleración por GPU, objetivo de 60fps).
  4. Técnicas específicas del framework.
  5. Optimización de red.
  6. Objetivos de Core Web Vitals.

Ejemplos del reference

Tres patrones aparecen como ejemplos canónicos. El primero evita el layout thrashing agrupando lecturas antes de las escrituras para no forzar reflows:

// Mal: lectura/escritura intercaladas fuerzan reflows
elements.forEach((el) => {
  const w = el.offsetWidth; // lectura
  el.style.width = w + 10 + "px"; // escritura -> reflow
});

// Bien: primero todas las lecturas, luego todas las escrituras
const widths = elements.map((el) => el.offsetWidth);
elements.forEach((el, i) => {
  el.style.width = widths[i] + 10 + "px";
});

El segundo, optimización de imágenes con formatos modernos, srcset y carga diferida:

<img
  src="photo.webp"
  srcset="photo-400.webp 400w, photo-800.webp 800w"
  sizes="(max-width: 600px) 400px, 800px"
  loading="lazy"
  alt="Fotografía del producto"
/>

El tercero, animaciones que se apoyan en transform y opacity para usar la GPU en lugar de propiedades que disparan layout:

/* GPU-friendly: no provoca reflow */
.toast {
  transition: transform 200ms ease, opacity 200ms ease;
}
.toast--hidden {
  transform: translateY(8px);
  opacity: 0;
}

Reglas: lo que sí y lo que no

Sí:

No:

Conviene subrayar la regla de accesibilidad: en Impeccable, optimizar nunca justifica degradar la accesibilidad. El rendimiento percibido y la accesibilidad se tratan como parte de la misma calidad, no como objetivos en competencia.

Herramientas de monitorización

El reference apunta a un conjunto concreto: Lighthouse de Chrome DevTools, WebPageTest, seguimiento de Core Web Vitals, analizadores de bundles y plataformas RUM (Real User Monitoring).

Ejemplo de invocación y salida

/impeccable optimize src/pages/index.astro

optimize empieza por la fase de evaluación: reporta el cuello de botella medido (por ejemplo, un LCP alto por una imagen hero sin srcset), propone el arreglo del mayor problema primero, lo aplica con las técnicas del dominio correspondiente y vuelve a medir para confirmar la mejora. La salida es, por tanto, un ciclo medir → arreglar → medir, no una lista de optimizaciones genéricas.

Tabla comparativa

Aspectoclarifyadaptoptimize
FocoClaridad del texto y del mensajeAdaptar la experiencia a otro contextoRendimiento percibido y real
Pregunta que responde¿Se entiende?¿Funciona en este dispositivo/idioma?¿Llega rápido y accesible?
Target típicoMicrocopy, botones, errores, estados vacíosMóvil, tablet, escritorio, impresión, emailPáginas y componentes con coste de carga/render
Principio centralEspecífico, activo, contextualRepensar, no escalar píxelesMedir el cuello de botella real, luego arreglar
Técnicas claveVerbo + objeto, consecuencias, consistencia léxicaBreakpoints por contenido, pointer/hover, srcsetCore Web Vitals, GPU, lazy load, batching de reflows
Prohibición destacadaJerga, culpar al usuario, pasivaOcultar funciones en móvil, depender del hoverOptimizar sin medir, lazy load above-the-fold
Invocación/impeccable clarify <target>/impeccable adapt <target>/impeccable optimize <target>

Cómo encajan los tres en tu flujo

Estos comandos rara vez se usan aislados. Una secuencia habitual sobre una landing page sería:

/impeccable clarify src/pages/landing.astro    # primero el mensaje
/impeccable adapt src/pages/landing.astro      # luego que sobreviva a cada contexto
/impeccable optimize src/pages/landing.astro   # y por último que cargue rápido

El orden importa porque cada paso parte del resultado del anterior: adaptar un copy confuso solo multiplica la confusión en más pantallas, y optimizar el peso de una imagen que adapt va a sustituir por una versión responsiva es trabajo perdido. Igual que el detector de 44 reglas actúa como red de seguridad determinista, estos tres comandos actúan sobre la dimensión que ninguna regla automática puede juzgar del todo: si el contenido comunica.

Resumen

Siguiente: Live browser iteration: el comando live

← Volver al listado de tecnologías ← Índice de Impeccable