Una lista de comprobación de consistencia de UI que realmente se puede ejecutar

La lista estándar hace preguntas como "¿es consistente la apariencia y sensación de la interfaz?" y "¿se usan las etiquetas de forma consistente?". Esas son reformulaciones del objetivo. La persona que realiza la auditoría tiene que convertir cada una en algo comprobable, y lo hará de forma diferente cada vez, lo que hace que la auditoría en sí sea inconsistente.

Una comprobación necesita tres cosas para valer la pena: un elemento específico que observar, una forma de observarlo y una condición que decida si se aprueba o falla. Todo lo siguiente tiene las tres.

Cinco minutos, no requiere juicio y encuentra una proporción sorprendente de desviaciones reales. Cada una de estas debería terminar en CI una vez aprobada; una comprobación que solo se ejecuta durante las auditorías permite que la desviación se acumule entre ellas.

1. 1

   Valores de color literales fuera del archivo de tokens

   La comprobación de mayor rendimiento. Cualquier valor hex en un componente significa que se omitió la capa de design tokens, y significa que ese color no puede cambiarse de forma centralizada.

   Copy

   grep -rn --include='*.tsx' --include='*.css' -E '#[0-9a-fA-F]{3,8}\b' src \
     | grep -v 'tokens\|globals.css'

2. 2

   Grosores de fuente fuera de su rango

   El grosor es donde la jerarquía revierte silenciosamente a los valores predeterminados del framework. Si su sistema define 400 y 600, cualquier valor superior es una desviación, independientemente de cómo se vea.

   Copy

   grep -rn --include='*.tsx' -E 'font-(bold|extrabold|black)|font-weight:\s*[78]00' src

3. 3

   Valores de espaciado fuera de la escala

   Las salidas de emergencia de valores arbitrarios son donde muere el ritmo. Un p-[13px] no es nada; cuarenta de ellos son un segundo sistema de espaciado que nadie acordó.

   Copy

   grep -rn --include='*.tsx' -E '\b(p|m|gap|space)-\[[0-9]+px\]' src

4. 4

   Valores de radio

   El radio se desvía más que cualquier otra cosa porque cada autor de componentes elige lo que parece correcto de forma aislada. Cuente los valores distintos en uso; más de tres o cuatro es un hallazgo.

   Copy

   grep -rhoE 'rounded-[a-z0-9]+|border-radius:\s*[0-9]+px' src -r \
     --include='*.tsx' --include='*.css' | sort | uniq -c | sort -rn

5. 5

   Propiedades que su sistema prohíbe

   Cualquier cosa que nombre su lista de prohibiciones. Si dice que la elevación nunca es una sombra, esta comprobación lo hace cumplir. Si no tiene una lista de prohibiciones, ese es el hallazgo: escriba una primero.

   Copy

   grep -rn --include='*.tsx' --include='*.css' -E 'box-shadow|shadow-(sm|md|lg|xl)|gradient' src

La cuarta comprobación tiene un matiz importante: contar los valores de radio distintos le informa sobre la consistencia, no sobre la corrección. Tres valores usados deliberadamente —6px en controles, 12px en contenedores, completo en avatares— es un sistema. Tres valores que resultan ser 6, 8 y 10 es una desviación que no ha sido detectada.

Aquí está el error de todo proceso de auditoría. Revisar una pantalla por sí sola le indica si es internamente coherente. No le dice nada sobre si coincide con las otras pantallas, porque no puede mantener las otras pantallas en su cabeza con suficiente precisión.

Por lo tanto, abra tres pantallas terminadas de la misma superficie lado a lado: tres pantallas de aplicación o tres páginas de marketing, nunca una mezcla. Comparar un panel de control con una página de aterrizaje produce diferencias que se supone que deben estar ahí.

Las últimas tres filas son donde el trabajo de consistencia suele ser más débil, y no es por descuido: los estados vacíos, de carga y de error se escriben bajo presión de tiempo, de forma individual y por quien sea que estuviera trabajando en ese archivo. Además, son precisamente lo que ve un usuario frustrado.

Las seis filas anteriores son donde se concentra la deriva. Esta es la lista completa, agrupada para que pueda completarla de una sola vez. Cada elemento tiene una condición de aprobación en lugar de una pregunta.

• Cada color en cada pantalla se resuelve en un rol con nombre. Falla si algún componente contiene un valor literal.
• El color de acento aparece en los mismos tipos de elementos en todas las pantallas. Falla si es un botón en una pantalla y un encabezado en otra.
• Los colores de estado aparecen solo para estados. Falla si el color de éxito se utiliza de forma decorativa en cualquier lugar.
• Cada color del modo claro tiene una contraparte en el modo oscuro que ha sido elegida, no derivada. Falla si cualquier superficie es una inversión directa.

• Cada tamaño en pantalla es un paso de la escala. Falla si encuentra un tamaño que no lo sea.
• Los pesos se mantienen dentro de la banda declarada. Falla en cualquier peso superior, por muy bien que se vea.
• El mismo nivel semántico se ve igual en todas partes: cada título de página coincide con todos los demás títulos de página. Falla si dos pantallas distinguen su título de forma diferente.
• Los números en columnas son tabulares y están alineados. Falla si los dígitos no se alinean entre filas.

• Cada valor de espaciado es un paso de la escala. Falla en cualquier valor arbitrario.
• Los valores de radio distintos son pocos y cada uno tiene un propósito establecido. Falla si no puede explicar por qué existe 8px junto a 6px.
• La elevación se indica de la misma manera en todas partes. Falla si se utilizan sombras y bordes simultáneamente para la misma función.
• El ritmo de la sección es consistente: el espacio entre un encabezado y su contenido es el mismo en cada pantalla. Falla en cualquier variación sin motivo.

• Una sola implementación por componente. Falla si dos archivos definen una tarjeta.
• Las acciones primarias son idénticas y se ubican en la misma posición relativa. Falla si una pantalla la coloca a la izquierda y otra a la derecha.
• Las acciones destructivas son visualmente distintas y coherentes en todo el sistema. Falla si la acción de eliminar se ve como la de guardar en cualquier lugar.
• Los elementos interactivos tienen un estado de enfoque visible y es el mismo en todas partes. Falla si falta algún anillo de enfoque o si este diverge.
• Los estados desactivados son visualmente distintos del contenido atenuado. Falla si el usuario no puede distinguir un control no disponible de un texto con menor énfasis.

• Los estados vacíos utilizan un único tratamiento en todo el producto. Falla si aparece una ilustración en un lugar y una frase en otro.
• La carga utiliza un único mecanismo. Falla si aparecen un skeleton, un spinner y un destello en blanco en tres pantallas distintas.
• Los errores aparecen en el mismo lugar y con el mismo tratamiento. Falla si aparecen en línea en un sitio y como toast en otro.
• El texto de error indica qué salió mal y qué hacer. Falla si el mensaje se limita a pedir disculpas.
• El contenido largo se trunca de la misma manera en todas partes. Falla si en un lugar se ajusta el texto y en otro se usan puntos suspensivos sin una regla que lo justifique.

• Un mismo concepto tiene un único nombre en todas partes. Falla si la interfaz dice "proyecto" en un lugar y "espacio de trabajo" en otro para referirse a lo mismo.
• Los botones nombran la acción que realizan y la confirmación la refleja. Falla si aparece "Enviar" seguido de "Sus cambios han sido guardados".
• El uso de mayúsculas sigue una única regla para etiquetas, encabezados y botones. Falla si se mezclan el formato de título (Title Case) y el de oración (Sentence Case).
• Las fechas, horas y números utilizan un único formato. Falla si hay dos formatos de fecha en un mismo producto.

El primer elemento de este grupo causa más confusión real al usuario que cualquier inconsistencia visual mencionada en este artículo. Dos nombres para un solo concepto obligan al usuario a mantener dos modelos mentales y le impiden saber si se trata de lo mismo.

Una vez al trimestre, audite el sistema en lugar de la interfaz. La pregunta no es si se siguieron las reglas, sino si las reglas podían seguirse.

La primera fila es la que debe revisarse con más rigor, porque una regla con matices parece una regla exhaustiva. Si sus directrices contienen salvedades, las superficies que describen esas salvedades requieren documentos independientes; la gobernanza cubre la versión estructural de esto.

Dos cosas, en direcciones opuestas, y ambas cambian la forma en que debe ejecutar esta lista de verificación.

La validación mecánica se vuelve más importante, ya que el volumen de código ha aumentado pero la capacidad de revisión no. Un agente que produce cuarenta pantallas entre revisiones reproducirá cualquier inconsistencia cuarenta veces antes de que alguien la detecte. Las comprobaciones automatizadas son lo único que escala a ese ritmo.

La revisión comparativa también cobra más importancia, y por una razón más sutil. Un agente es extremadamente consistente *dentro* de un archivo y no tiene memoria entre sesiones, por lo que su resultado es un conjunto de pantallas internamente coherentes que difieren entre sí. Ese es precisamente el modo de fallo que la revisión por archivo no puede detectar.

La causa raíz suele estar en el origen. Analizamos 299 archivos DESIGN.md escritos para dar pautas de diseño a los agentes: el 86% especifica los colores como hex raw sin rol semántico, el 76% no establece prohibiciones de ningún tipo, el 69% no define un modo oscuro, el 57% no nombra motivos y el 44% no contiene ningún valor de tamaño concreto en ninguna parte. El 54% depende de al menos un adjetivo vago: "limpio" en el 39%, "moderno" en el 36%.

Un archivo así deja sin resolver las decisiones de densidad, jerarquía, elevación y estados vacíos, por lo que el modelo las toma de cero en cada pantalla. Los hallazgos de inconsistencia frente a esas pautas son reales, y corregirlos pantalla por pantalla no servirá de nada. Cómo escribir pautas que sí funcionen.

Si dispone de veinte minutos en lugar de un día:

1. Busque con grep los valores hex fuera del archivo de tokens. Cada coincidencia es un hallazgo.
2. Busque con grep los grosores de fuente (font weights) que superen su rango. Cada coincidencia es un hallazgo.
3. Cuente los valores de radio distintos. Si hay más de cuatro, analice por qué.
4. Abra tres pantallas de una misma superficie. Compare la densidad, la jerarquía y la elevación.
5. Observe específicamente sus estados vacíos, de carga y de error. Aquí es donde la inconsistencia será más evidente.
6. Compruebe si sus pautas incluyen una lista de prohibiciones. Si no es así, esa es la solución que evitará la siguiente ronda de errores.

Los pasos del uno al tres son automatizables hoy en día y no deberían volver a ejecutarse manualmente. Los pasos cuatro y cinco requieren una persona y merecen media hora recurrente. El paso seis es el que decide si tendrá que repetir todo esto el próximo trimestre.