Convenciones de nombres en Figma: guía práctica para diseñar y entregar

Seguidores Online » Redes Sociales » Convenciones de nombres en Figma: guía práctica para diseñar y entregar

Cuando un diseño de Figma va a terminar en manos de un desarrollador, un buen sistema de nombres deja de ser un capricho para convertirse en una necesidad. Una nomenclatura clara, coherente y predecible reduce fricciones, mejora la comunicación y evita errores tontos en prototipo y código.

Si vienes de trabajar “para ti” y ahora te toca entregar a ingeniería o mantener un proyecto heredado, seguramente te preguntes por dónde empezar. La clave está en combinar buenas prácticas de programación con lo que Figma ofrece (incluida su IA para renombrar en bloque) y documentar un criterio sencillo para capas, marcos, pantallas y componentes.

Por qué importan las convenciones de nombres en Figma y en programación

Las convenciones de nomenclatura son el abecé de la legibilidad: permiten entender de un vistazo qué es cada cosa, aunque la persona que lea no comparta idioma, cultura o estilo. En desarrollo se aplican a variables, tipos, funciones y todo identificador del código; en Figma, a capas, grupos, marcos e instancias.

Seguir una convención facilita aprender y profundizar en sintaxis y semántica, porque reduce la carga cognitiva: no tienes que descifrar cada nombre, solo reconocer patrones. Esto, llevado al diseño, hace que navegar por el árbol de capas sea más rápido y que el traspaso a código sea más fluido.

Una regla de oro es la coherencia: elige una palabra por concepto y no la cambies. Si usas “get” para obtener datos, no alternes con “retrieve” o “bringBack”; si nombras “Botón principal”, no lo mezcles con “Btn primario” más adelante. La repetición intencional ayuda a la gente (y a las herramientas).

La legibilidad prima sobre el ahorro de caracteres. Un nombre autoexplicativo es más fácil de buscar y mantener que uno críptico. “label_first_name” es más claro que “lblFname”, y lo mismo aplica a “Card/Title” frente a “CrTtl”.

Abreviar no es pecado, pero conviene acordarlo. Usa abreviaturas consistentes y compartidas (btn, img, bg, hdr) donde aporten valor, y evita inventarte siglas distintas para la misma cosa. Para un botón puedes preferir “first_btn” en lugar de “first_button” si todo el equipo lo asume y documenta.

En programación existen notaciones muy extendidas que puedes reflejar en Figma para alinear con desarrollo: camelCase, snake_case, PascalCase y kebab-case. Adoptar una de ellas, o un híbrido contextual, permite que los nombres de Figma se parezcan a los de la base de código.

camelCase empieza en minúscula y pone mayúscula en cada palabra siguiente: firstName, countStudents(). Es común en Java, PHP, C# y en muchos lenguajes orientados a objetos. Se siente natural para propiedades y métodos.

snake_case separa palabras con guiones bajos: first_name, compute_mean(). Es típico en C++, Perl, Python o R. Facilita la lectura horizontal y es cómodo para tokens con varias palabras.

PascalCase inicia cada palabra en mayúscula: FirstName, ReverseName(). Se usa a menudo en contextos de orientación a objetos, especialmente útil para nombres de tipos o entidades principales.

kebab-case separa con guiones: first-name, compute-mean(). Es menos usado en código, pero aparece en rutas, nombres de archivos y CSS; conviene reservarlo para esos casos si lo empleas.

Además, piensa en “metadatos” dentro del nombre cuando ayudan: indicar el propósito o complejidad de un método o variante con un sufijo o prefijo puede ahorrar vueltas. Lo mismo en Figma con estados: “Button/Primary/Disabled”.

Ojo al detalle por lenguaje: en Java las clases e interfaces empiezan en mayúscula, mientras métodos y variables en minúscula; en Python las convenciones no igualan a Java; en C cambian de nuevo. Reflejar estas diferencias en Figma mejora el match semántico al exportar o mapear componentes.

Cuando pasas de Figma a código, no respetar estas reglas compromete la integridad y entendimiento del trabajo, incluso para quien lo creó. Evita sorpresas renombrando tarde y sin criterio.

Prácticas de nombres para capas y componentes en Figma (y cómo ayuda Figma AI)

Al heredar un archivo o preparar un traspaso a desarrollo, es normal encontrarse con capas sin nombre, duplicados y convenciones mixtas con “/”, “-” y “_”. Define un esquema mínimo y aplícalo de arriba abajo a pantallas, marcos, componentes, variantes y capas clave.

Un patrón eficaz para componentes en Figma es aprovechar “/” para jerarquía: Componente/Tipo/Estado. Por ejemplo: “Button/Primary/Disabled”. Usa “-” para modificadores granulares (“Button/Primary-IconLeft”) y “_” para tokens técnicos (“color_bg_primary”). Esta separación visual simplifica filtros y búsqueda.

Para pantallas y marcos de nivel superior, conviene prefijar el flujo o feature: Checkout/Address – Desktop, “Auth/Login – Mobile”. Esto facilita localizar todo lo relacionado con un área y entender el contexto de la navegación. La coherencia en el prefijo es la mitad del camino.

En capas internas, nombra lo que aporta significado al prototipo o a la exportación. Un “Frame” sin nombre no dice nada, pero “Card/Header”, “Card/Image”, “Card/CTA” sí. Evita etiquetas genéricas como Rectangle 123 si la capa define estructura o interacción.

Si estás reestructurando un proyecto existente, empieza por los marcos raíz y componentes base. Renombra primero lo que se reutiliza en más sitios (componentes, estilos, variantes) y después baja a subcapas. Así obtienes beneficios inmediatos en navegación y prototipado.

Aquí Figma AI te puede ahorrar horas al asignar nombres contextuales a capas en bloque. Con unos clics, renombra a partir del contenido, posición y relación con otras capas seleccionadas, lo que ordena el archivo y quita ruido manual.

¿Cómo decide los nombres? Figma AI analiza el contenido (texto o imagen), la ubicación y cómo se relaciona una capa con su vecindario dentro de la selección. Si detecta la misma capa sin nombre en varios marcos superiores, renombrará las coincidentes a la vez para mantener consistencia.

Esto es clave para el prototipado: al renombrar capas iguales en marcos superiores, se preserva Smart Animate y el scroll position sin romper vínculos. El sistema entiende que es la misma entidad entre pantallas.

Ten presente que Figma AI solo renombra capas que sigan la convención por defecto de Figma. Si una capa ya fue renombrada, la respeta, incluso si está en tu selección. Así no pisa trabajo previo ni decisiones del equipo.

Tipos de capas que Figma AI sí renombra: Frames, Grupos, Rectángulos y rectángulos redondeados con relleno de imagen, capas de texto e instancias que aún conservan el nombre predeterminado de su componente principal. En instancias, solo renombra el contenedor, ignora subcapas internas.

Tipos que Figma AI no toca: capas ya renombradas, capas ocultas o bloqueadas, y cualquier capa anidada dentro de una instancia. Si quieres cambiar subcapas de instancias, hazlo manualmente o desde el componente principal. Tampoco renombra formas vectoriales individuales (elipses, estrellas, polígonos, redes vectoriales) ni rectángulos/rectángulos redondeados sin relleno de imagen.

Para lanzar el renombrado con IA, selecciona lo que quieres tratar y elige cualquiera de estas rutas. Las tres llevan al mismo sitio:

• Clic derecho sobre la selección y elige “Rename layers (Cambiar nombre de las capas)”.
• Acciones en la barra de herramientas y luego “Rename layers (Cambiar nombre de las capas)”.
• Acciones rápidas y escribe “Rename layers (Cambiar nombre de las capas)”.

Si la selección ya tiene nombres, Figma te avisará con “No es necesario cambiar el nombre de las capas”. Puedes forzar con “Renombrar de todos modos” si buscas homogeneizar o corregir pequeñas inconsistencias.

Una estrategia combinada que funciona muy bien es esta: IA para poner orden masivo y manos para reglas del equipo. Usa Figma AI para obtener nombres base coherentes, y después aplica tu convención en capas críticas (componentes, variantes, estilos) con precisión manual.

Para hacer el traspaso a código más suave, acuerda una tabla mental de equivalencias con desarrollo. Algunas recomendaciones prácticas:

• Mapa de estilos: “color_bg_primary” (Figma) → token “color_bg_primary” (CSS/Design tokens). Evita variaciones innecesarias.
• Componentes: “Button/Primary/Disabled” (Figma) → ButtonPrimary (PascalCase) + prop disabled (código). Jerarquía con “/”, tipos con PascalCase.
• Propiedades: “cardTitle” en Figma para capas de texto si el código usa camelCase. Alineación semántica refuerza el puente.
• Archivos y rutas: reserva kebab-case si el repo lo exige (p. ej. “product-card.tsx”). No mezcles convenciones en el mismo nivel.

Cuando dudes entre claridad y brevedad, escoge claridad. La legibilidad es un multiplicador de velocidad para todo el equipo: encuentras antes, cambias con menos riesgo y prototipas sin perder interacciones.

Ejemplos de coherencia en funciones y métodos ayudan a ilustrarlo. Si defines un método que devuelve un nombre, evita alternar verbos para lo mismo. Mantén un único término por operación:

getName() { /* ... */ }
// en lugar de mezclar con: retrieveName() o bringBackName()

En variables, evita nombres crípticos. Más caracteres pueden significar más claridad:

String label_first_name; // preferible a lblFname

En abreviaturas, sé consistente y explícito. first_btn es aceptable si “btn” es una abreviatura acordada. Si no, opta por “first_button”.

En Figma, replica esa disciplina con jerarquías y estados. Un patrón recomendable:

Card/Title
Card/Image
Card/CTA
Button/Primary/Default
Button/Primary/Hover
Button/Primary/Disabled

Para proyectos heredados, organiza por fases: 1) marcos superiores; 2) componentes base; 3) variantes; 4) capas relevantes; 5) limpieza de restos (capas ocultas/bloqueadas). Esto minimiza roturas y mantiene prototipos estables.

Errores comunes que conviene evitar y cómo esquivarlos: cámbialos por hábitos sanos:

• Inconsistencia verbal: get vs retrieve. Solución: elige y documenta un verbo por acción.
• Criptografía en nombres: lblFname. Solución: usa términos completos y significativos.
• Abusar de “Rectangle 23”: Solución: renombra capas estructurales y de interacción.
• Renombrar instancias internas con IA: no funciona. Solución: edítalas en el componente principal.
• Ignorar capas ocultas/bloqueadas: la IA las saltará. Solución: desbloquea/visibiliza lo que deba renombrarse.

Un apunte práctico sobre prototipos: mantener el mismo nombre entre pantallas para la misma pieza visual mejora Smart Animate. No cambies “Avatar” por “UserPhoto” en otra pantalla si son la misma entidad; deja que la animación haga su magia.

También ayuda etiquetar claramente estados y variantes. Usa sufijos de estado (Default, Hover, Pressed, Disabled) y colócalos al final para mantener agrupadas las familias de componentes en el panel de capas.

Más ideas útiles de “metadatos” en nombres, cuando suman: añade el tamaño si define el diseño (Card/L, Card/M), o el contenedor si condiciona el layout (Modal/Header, Modal/Body). No satures, pero aporta contexto cuando evita dudas.

Si el código del equipo ya sigue una convención, alínate con ella. La convergencia entre Figma y repositorio es un acelerador del handoff: menos traducción mental, menos errores de mapeo.

Y recuerda que puedes intercalar notaciones por ámbito: camelCase para capas que correspondan a props, PascalCase para nombres de componentes, snake_case para tokens de diseño y kebab-case para rutas/archivos si procede. La clave es no mezclar varias en el mismo nivel.

Si vas a renombrar en bloque, prepara la selección como si fuera una “consulta”. Selecciona marcos superiores que representen pantallas y deja fuera instancias cuyas subcapas no quieras tocar. Luego ejecuta “Rename layers” desde cualquiera de las rutas disponibles.

Cuando Figma muestre “No es necesario cambiar el nombre de las capas”, decide si merece la pena aplicar “Renombrar de todos modos”. Úsalo para unificar términos o arreglar minúsculas/mayúsculas que se te hayan escapado en lotes anteriores.

Para equipos, documenta en una página del archivo las reglas básicas: jerarquía con “/”, abreviaturas permitidas, notación para estados, y relación con tokens/props de código. Unas 10-15 líneas bien pensadas evitan semanas de desorden futuro.

Finalmente, practica el “re-nombrado temprano”: cuando crees un componente, nómbralo bien desde el minuto uno y aplica el patrón a sus variantes. Corregir nombres tarde cuesta más que hacerlo al crear, igual que en el código refactorizado.

Todo esto puede sonar a detalle, pero el impacto se nota en velocidad, calidad y disfrute del trabajo. Un árbol de capas que “se lee solo” te permite dedicar energía a lo importante: resolver problemas de usuario y construir mejor producto con ingeniería.

Mirado con perspectiva, un sistema de nombres cuidado une dos mundos: el de quienes diseñan y el de quienes programan. Cuando ambos hablan el mismo idioma en capas, componentes y tokens, el traspaso es suave, el prototipo no se rompe y el código respira limpio.