GH GambleHub

Lenguaje de interfaz único

1) Qué es un lenguaje de interfaz único y por qué es necesario

El Lenguaje Único de Interfaz (EYA) es un sistema común de conceptos, reglas visuales e interacciones que comparten diseñadores, ingenieros, analistas y autores de contenido.

Objetivos:
  • Consistencia: los mismos componentes y términos en diferentes productos y equipos.
  • Velocidad: ensamblajes rápidos, menos cholivares, más rápido onboarding.
  • Calidad: patrones de consistencia UX, disponibilidad «predeterminada».
  • Escalabilidad: evolución segura sin descomposición en un «zoológico de IU».

2) Capas de un solo idioma

1. Tokens (color, tipografía, dimensiones, sombras, sangrías, radios, animaciones).
2. Componentes (botones, campos de entrada, tablas, gráficos, modales, tostadas, fichas).
3. Patrones (formularios, validación, asistente paso a paso, listas/tablas, notificaciones).
4. Contenido (microcopiratería, terminología, mensajes de error).
5. Iconografía e ilustraciones (familia, estilo, dimensiones y líneas).
6. Disponibilidad y i18n/RTL (reglas de A11y, traducibilidad, localies).
7. Procesos (versiones, gaidrailes, rugidos, linternas, vitrinas y ejemplos).

3) Fichas de diseño (base de la expresividad)

Los tokens son valores denominados que se reutilizan en todos los productos.

3. 1 Estructura de tokens (ejemplo)

json
{
"color": {
"bg": { "base": "#FFFFFF", "subtle": "#F7F8FA" },
"fg": { "primary": "#11131A", "muted": "#656D76" },
"accent": { "primary": "#2F6BFF", "warning": "#FF9F1A", "critical": "#E53935", "success": "#2EAE60" }
},
"space": { "xs": 4, "sm": 8, "md": 12, "lg": 16, "xl": 24, "2xl": 32 },
"radius": { "sm": 8, "md": 12, "lg": 16, "pill": 1000 },
"shadow": { "sm": "0 1px 2px rgba(0,0,0,.08)", "md": "0 4px 12px rgba(0,0,0,.10)" },
"font": { "family": "Inter, system-ui", "size": { "sm": 12, "md": 14, "lg": 16, "xl": 20 } },
"motion": { "duration": { "fast": 120, "base": 200, "slow": 320 }, "curve": { "inout": "ease-in-out" } }
}

3. 2 Neyming tokens

De lo general a lo privado: 'color. accent. primary`, не `primaryBlue`.
Sin atar a una marca en Neuming (una marca es un tema, no el nombre de un token).
Gradaciones: 'fg. muted`, `fg. primary`, `fg. inverse`. No codifique el brillo en el nombre ('blue500') sin el sistema.

3. 3 Tokens-Temas

Claro, oscuro, contrastado: cambiar valores, no nombres.
Los temas son una capa de redefinición, la IU permanece consistente.

4) Componentes: contrato, estado, disponibilidad

Componente = visual + comportamiento + contrato de props + A11y.

4. 1 Ejemplo de contrato de botón

ts type ButtonProps = {
kind: "primary"      "secondary"      "tertiary"      "danger";
size: "sm"      "md"      "lg";
icon?: "plus"      "download"      "trash";
disabled?: boolean;
loading?: boolean;
ariaLabel?: string;
onClick?: (e: MouseEvent) => void;
};

Estados: 'default/hover/active/focus/disabled/loading'.
Disponibilidad: anillo focal, tamaños de target ≥ 40-48 px, 'aria-pressed' para toggle.

4. 2 Garantías de componentes

Dimensiones estables (line-height, paddings).
Disponibilidad desde la caja (rollos/aria, teclado, contraste).
Invariantes: error dentro del campo siempre desde abajo y con 'aria-describedby'.

5) Patrones UX (lógica repetible)

Formularios: etiqueta izquierda/superior, placeholder ≠ etiqueta, errores cercanos + en el resumen, máscaras de entrada y sugerencias.
Modalkas: un CTA principal, 'Amb' cierra, trampa de enfoque, devuelve el enfoque.
Tablas/listas: ordenar, encabezado sticky, páginas, exportar.
Filtros: botón explícito «Aplicar», restablecimiento, preajustes guardados.
Notificaciones: tost ≤ 3-5 s, pausa cuando se enfoca, 'role =' status/alert '.
Dashboards: top insights → contexto → gráficos → CTA.

6) Terminología unificada y microcopiraiting

6. 1 Glosario

Mantenga un solo glosario de términos empresariales y UX. Cada artículo de la interfaz hace referencia a él.
Para los dobletes es elegir una palabra («monedero» vs «balance»), la segunda como sinónimo en la búsqueda.

6. 2 Reglas de texto

Brevemente y en el caso; evitar la jerga.
Errores - Explicar qué hacer: «Especifique la fecha en formato GGGG-MM-DD».
Encabezados - sustantivos; botones - verbos («Guardar», «Deshacer»).
Unidades consistentes: fecha/hora en UTC o local, monedas con código (EUR, USD).

7) Iconografía e ilustraciones

La familia es isomórfica: ángulo único, espesor de línea, malla 24 × 24.
Estados y semántica: color - secundario; forma/icono + texto - primario.
Escala: los pictogramas no «flotan» en diferentes densidades (1 ×/2 ×/3 ×).

8) Accesibilidad (A11y) y localización (i18n/RTL)

Los componentes pasan WCAG AA: contraste, navegación desde el teclado, enfoque, 'prefers-reduced-motion'.
Cadenas traducibles - en recursos, no en código. Los reproductores y el formato de números/fechas son localizables.
RTL: Replicación de iconos, Orden correcto de Amb, Lógica DnD desde el teclado.

9) Números, fechas, monedas y formatos

Fechas/horas: ISO-8601, punto de tiempo verdadero - UTC; usuario - local.
Moneda: unidades menores/líneas decimales; especificar siempre el código (por ejemplo, "€12,34" o "12. 34 EUR" - por localidad).
Porcentajes: '12,3%' y puntos '+ 1,2 p.p.' distinguir explícitamente.
Redondeo: a descargas significativas; "k/m' para números grandes.

10) Gobierno: roles, artefactos, canales

Design Language Council (DLC): los propietarios de tokens/componentes, afirman RFC.

Artefactos:
  • Biblioteca de componentes (Figma/código) + Directorio en vivo con ejemplos.
  • Documentación: gaidriles, patrones, A11y, contenido-hyde.
  • Chanjlog con fechas, niveles (added/changed/deprecated/removed/fixed).
  • Canales: xink de diseño semanal, canal Slack, showkays de implementación.

11) Versificación y evolución

SemVer para el paquete de componentes: 'MAJOR. MINOR. PATCH`.
MINOR - aditivo: nuevos tokens, props con impagos, nuevos componentes.
MAJOR - breaking: eliminación de props, cambio de semántica → guidas migratorias.
Deprecaciones: avisos, ventana ≥ 90 días, banderas de compatibilidad.

12) Linters y comprobaciones automáticas

UI-linter: colores prohibidos fuera de los tokens, anti-patrones (botón-dive, outline desactivado).
A11y-chequeos: contraste, roles/aria, enfoque, teclado.
i18n-linter: líneas «duras» en el código, reproductores incorrectos.
Pruebas de captura de pantalla: regresiones visuales de los componentes.
Contratos de API de visualización (si los hay): tipos de datos, rangos, firmas.

13) Escaparate de componentes (storybook/sandbox)

Ejemplos en vivo con controles de props, código, estados, verificador A11y.
«Recetas»: formulario de registro, asistente de 3 pasos, tabla + filtros, modalka + brindis.
«Sandbox local»: cambiar de idioma/formatos/RTL.

14) Patrones de Neuming y Estructura

14. 1 Componentes (WEM/semántica, ejemplo CSS)


.btn/basic/
.btn--primary/view/
.btn--danger
.btn--lg/size/
.btn __ icon/part/

En el código hay nombres monótonos de props: 'size', 'kind',' disabled ',' onClick '.

14. 2 Estructura de archivos de biblioteca


/tokens
/components
/button
/input
/modal
/patterns
/docs
/changelog

15) Anti-patrones

Colores/sangrías «libres» fuera de los tokens.
Tomas de componentes: «ButtonV2», «PrimaryButtonNew».
Playsholder como la única marca de campo.
Desactiva el outline y el «botón dive».
Hover/active/disabled impredecibles.
Términos transliterados en lugar de traducción normal.
Ausencia de guidas migratorias en las actualizaciones.

16) Métricas de calidad de una sola lengua

Coverage: proporción de pantallas que utilizan una biblioteca de componentes.
Índice de consistencia: reutilización de tokens vs estilos «manuales».
A11y Pass Rate: porcentaje de componentes que pasan por WCAG AA.
Defect Escape: defectos de UI/contenido en la venta de 1k commits.
Time-to-Ship: tiempo para implementar la pantalla estándar antes/después del DLS.
Adoption: escaparates DAU, número de PR con componentes/patrones.

17) Lista de verificación de pantalla

  • Se utilizan tokens (color/sangría/radios) en lugar de valores «rígidos».
  • Componentes de la biblioteca; casta - sólo con RFC.
  • Disponibilidad: teclado/enfoque/contraste/rollos/aria.
  • Unidades: Fechas/Monedas/Intereses - por guida de formatos.
  • Microcopi: botones = verbos, errores = acción para corregir.
  • Locali/RTL no rompe el diseño.
  • Estados: loading/empty/error se proporcionan.
  • Se han actualizado las pruebas de regresión visual.

18) Plan de implementación (3 iteraciones)

Iteración 1 - Fundación (2-3 semanas)

Tokens (color/tipografía/espacio/movimiento), componentes básicos (Button, Input, Select, Tooltip, Modal), contenido hyde (tono, etiquetas, errores).
Escaparate (storybook) y A11y-checker, linter de tokens.

Iteración 2 - Patrones y localización (3-4 semanas)

Patrones de formas/tablas/filtros, iconos 24 × 24, RTL/i18n-sandbox, reglas de números/fechas/monedas.
SemVer, chanjlog, proceso RFC/migraciones, autotestas (visual + A11y).

Iteración 3 - Escala y evolución (continua)

Componentes compuestos (Wizard, DataGrid, Chart primitives), tematización (claro/oscuro/contraste), informes de métricas de calidad, auditorías UX regulares.

19) Mini preguntas frecuentes

¿Es necesario «todo a la vez»?
No. Comience con tokens y componentes básicos, luego agregue patrones y procesos.

¿Cómo persuadir a los equipos para que utilicen la EIA?
Muestra las ganancias: velocidad, menos defectos, recetas de pantalla terminadas y A11y fuera de la caja.

¿Qué hacer con las pantallas legacy?
El plan de migración, los estilos de puente a través de tokens, las pantallas prioritarias son los primeros.

Un lenguaje de interfaz único no es sólo una biblioteca de componentes. Es un sistema de reglas y procesos donde los tokens establecen la expresividad, los componentes son el comportamiento y la disponibilidad, los patrones son la repetibilidad de las soluciones, y el gobierno y las métricas son una evolución sostenida. Haga que el lenguaje sea claro, verificable y extensible, y sus productos se vean y funcionen de manera uniforme, rápida y confiable.

Contact

Póngase en contacto

Escríbanos ante cualquier duda o necesidad de soporte.¡Siempre estamos listos para ayudarle!

Telegram
@Gamble_GC
Iniciar integración

El Email es obligatorio. Telegram o WhatsApp — opcionales.

Su nombre opcional
Email opcional
Asunto opcional
Mensaje opcional
Telegram opcional
@
Si indica Telegram, también le responderemos allí además del Email.
WhatsApp opcional
Formato: +código de país y número (por ejemplo, +34XXXXXXXXX).

Al hacer clic en el botón, usted acepta el tratamiento de sus datos.