Cómo poner nombre a las cosas en diseño y código sin volverte loco.

Hay un problema que aparece en casi todos los proyectos digitales y del que casi nadie habla abiertamente: no sabemos poner nombres. O los ponemos demasiado genéricos y luego nadie entiende qué es qué, o los hacemos tan específicos que el día que cambia algo hay que reescribir medio sistema.

Smashing Magazine publicó hace unos días una guía práctica sobre este tema. La hemos leído con atención y aquí recogemos lo que nos parece más útil para equipos de diseño y desarrollo que trabajan en castellano.

El problema de fondo: el lenguaje moldea el pensamiento

Cuando un equipo no comparte un vocabulario común, las conversaciones se complican. ¿Ese elemento es un modal, un diálogo o una ventana emergente? ¿El color es gris azulado, pizarra o slate? Las discusiones sobre nombres parecen triviales hasta que generan errores reales en producción o malentendidos entre diseño y desarrollo.

Un buen nombre tiene que cumplir varios criterios a la vez: ser corto, tener significado claro, ser conocido por todo el equipo y, en la medida de lo posible, no describir propiedades visuales que pueden cambiar.

Recursos para nombrar clases, funciones y propiedades

Uno de los recursos mencionados en la guía original es Classnames, un sitio que agrupa palabras por temáticas para inspirar nombres de clases HTML, propiedades CSS o funciones JavaScript. Lo interesante es que va más allá de los términos técnicos habituales e incluye vocabulario de ámbitos como la naturaleza, la arquitectura, el teatro o la moda.

No es un generador automático. Es más bien un catálogo para cuando te quedas en blanco o quieres salir de los nombres de siempre (wrapper, container, item) y buscar algo más descriptivo y menos genérico.

Cómo nombrar colores de forma coherente

Nombrar colores es especialmente complicado porque dos personas pueden ver el mismo tono y llamarlo de formas completamente distintas. Para esto existe un repositorio mantenido por David Aerne que, en el momento de publicación de la guía, contiene más de 30.000 nombres únicos de colores, recogidos de múltiples referencias y contribuciones de usuarios.

El repositorio incluye un selector de color y búsqueda por nombre. Es una referencia útil tanto para sistemas de diseño como para documentación de tokens, donde la coherencia en el lenguaje importa mucho.

Capas, grupos y componentes: estructura antes que creatividad

Javier Cuello ha documentado un conjunto de buenas prácticas para nombrar capas, grupos y componentes de forma consistente y escalable. Su propuesta parte de una idea sencilla: un buen nombre tiene estructura lógica, es breve, significativo y no depende de propiedades visuales.

Esto último es importante. Si llamas a un componente boton-azul y luego el botón pasa a ser verde en una variante, el nombre se convierte en un problema. Mejor boton-primario o boton-accion, que describe su función, no su aspecto.

Cuello también detalla cómo tratar casos concretos: tamaños, colores dentro del sistema, agrupaciones y componentes compuestos. Son decisiones pequeñas que, acumuladas, determinan si un sistema de diseño escala bien o se convierte en un laberinto.

Tokens de diseño: el reto de nombrar a escala

El caso más complejo es el de los tokens de diseño, especialmente cuando hay que hacerlos funcionar en varios productos distintos. La guía menciona el trabajo del equipo de Intuit, que se enfrentó al reto de construir una taxonomía de tokens flexible y reutilizable entre diferentes líneas de producto.

No hay una solución universal, pero la dirección que suele funcionar es separar los tokens por niveles: primero los valores primitivos (el color exacto, el tamaño exacto), luego los tokens semánticos que describen su función (color de fondo principal, tamaño de texto de cuerpo) y finalmente los tokens específicos de componente si hacen falta.

Cuantos más niveles de abstracción, más flexible el sistema. El coste es que también es más difícil de documentar y mantener, así que hay que calibrar según el tamaño real del proyecto.

Lo que hemos aprendido de todo esto

Nombrar bien no es una tarea de cinco minutos al principio del proyecto. Es una práctica continua que requiere acuerdo entre personas, documentación accesible y voluntad de revisar nombres cuando dejan de ser útiles.

Recomendamos dedicar al menos una sesión corta al inicio de cada proyecto para alinear el vocabulario del equipo. No hace falta un documento extenso: basta con una lista compartida de términos acordados y un criterio claro para añadir nuevos.

Los recursos que hemos mencionado aquí no resuelven el problema solos, pero ayudan a tener más opciones sobre la mesa y a tomar decisiones más conscientes.

Fuente original

Smashing Magazine: A Practical Guide To Naming Things