Solucionar conflictos de variantes y overrides en Figma
Diagnostica combinaciones duplicadas, textos perdidos, iconos anidados y fallos de tamaño con un procedimiento reproducible.
Empieza con una instancia nueva y cambia una entrada cada vez. Separa valores duplicados y opciones no admitidas; revisa nombres, jerarquía y bindings; comprueba aparte el tamaño. Prueba la reparación en instancias personalizadas antes de publicar la actualización.
Para solucionar conflictos de variantes y overrides, reproduce una transición concreta en una instancia nueva antes de modificar la biblioteca. Compara los valores, la capa afectada y las personalizaciones antes y después del cambio. Un conjunto de valores duplicado, una combinación que el producto no admite, un override conservado y un problema de tamaño necesitan soluciones distintas. Cambiar varios controles a la vez dificulta distinguirlos.
La guía utiliza un botón ficticio de exportación cuyo texto, tamaño, icono y aspecto de carga interactúan de forma inesperada. El método también sirve para alertas y otros componentes anidados. Si necesitas repasar la creación de variantes, consulta nuestra guía de variantes de Figma y estados UI. Este procedimiento de diagnóstico es una recomendación editorial basada en la documentación enlazada; cada biblioteca puede necesitar comprobaciones adicionales.
Registra una transición que falle
Crea una página de diagnóstico con una instancia nueva, una copia que conserve la personalización problemática y el resultado esperado. Los controles de propiedades de instancia reúnen las opciones expuestas, pero también pueden existir cambios en otras propiedades de las capas. Registra ambos: ver un panel aparentemente correcto no demuestra que la instancia esté intacta.

Parte del botón de exportación con tamaño mediano, estado listo y sin icono. Cambia el texto por «Exportar facturas seleccionadas», activa el icono y pasa al estado de carga. Imagina que el texto vuelve a su valor genérico. Repite la secuencia en una instancia nueva cambiando únicamente el texto. Si también falla, la visibilidad del icono probablemente no es el desencadenante. Si funciona, añade ese cambio y repite. Esta secuencia controlada informa mejor que recorrer todas las opciones hasta recuperar el aspecto deseado.
Anota el componente de origen, la biblioteca, los valores iniciales, la personalización, una sola acción y los resultados esperado y observado. Identifica la capa: «Label pierde el texto al pasar de Ready a Loading» ofrece una reproducción concreta. «Las variantes están rotas» obliga a otra persona a empezar la investigación desde cero. Conserva la copia que falla mientras pruebas cambios en otra.
Una instancia nueva que funciona y una antigua personalizada que falla orientan la investigación hacia el historial de esa instancia. Si el fallo aparece repetidamente sin personalizaciones previas, revisa la definición del componente y la configuración solicitada. Son pistas para decidir qué comprobar después; por sí solas no demuestran un error de Figma.
Separa valores duplicados y opciones no admitidas
La combinación de variante reúne todos los valores de sus propiedades. La documentación de variantes exige una combinación única para cada una. Dos dibujos diferentes con los mismos valores pueden generar un conflicto. Otro problema distinto es que el producto omita una combinación a propósito: no es obligatorio crear todas las posibilidades teóricas.

Escribe los valores en filas antes de tocar el dibujo. Dos filas con Size=Medium, State=Ready revelan un duplicado aunque una tenga icono. Decide si esa diferencia requiere una configuración distinta o una propiedad editable de contenido. Asigna valores que expresen una diferencia real o unifica el duplicado tras revisar sus usos. Añadir «Version2» solo oculta un modelo difícil de entender.
Marca después las combinaciones admitidas. Quizá el producto permita listo, cargando y desactivado en tamaño mediano, pero únicamente listo y desactivado en pequeño. Considera «pequeño + cargando» una decisión pendiente que debe resolverse, en lugar de añadir automáticamente otro dibujo. Comprueba si existe esa necesidad, si cabe el contenido y qué debe hacer la implementación cuando se solicita esa combinación.
Utiliza una tabla de reparación con síntoma, evidencia, causa que se está comprobando y siguiente acción. Un aviso de valores duplicados dirige la revisión hacia la identidad de las variantes. Una combinación válida con texto incorrecto lleva a bindings y overrides. Una opción ausente necesita una regla de producto. Separar estos casos evita convertir cualquier problema puntual en una remodelación completa de la biblioteca.
| Síntoma | Evidencia que recoger | Siguiente comprobación |
|---|---|---|
| Aviso de valores duplicados | Combinaciones completas de ambas variantes | Valores de identidad |
| Texto restablecido | Transición en una instancia nueva | Nombres, jerarquía y binding |
| Aspecto inesperado | Resultado antes y después de restablecer el relleno | Override local |
| Fallo en contenedor estrecho | Mismas propiedades en dos anchuras | Relación de tamaño |
Sigue los overrides entre capas equivalentes
Al cambiar de variante, Figma intenta conservar overrides según los nombres de las capas y, para cambios distintos del texto, sus valores originales. En el texto también considera una jerarquía similar. La guía de conservación de overrides explica esas condiciones. Compara las capas equivalentes antes de interpretar la conservación o pérdida de un cambio como algo arbitrario.

En el botón de exportación, localiza la capa de texto de Ready y su equivalente en Loading. Si una se llama Label y la otra Caption, prueba la corrección del nombre en una copia de trabajo. Si difiere la jerarquía, inspecciona también los contenedores. Durante el diagnóstico no cambies todos los nombres de una biblioteca publicada: introducirías otra posible causa y afectarías instancias existentes.
Haz un segundo experimento con el aspecto. Aplica un relleno temporal muy reconocible en una copia, cambia de variante y registra si permanece. Compara los rellenos originales de las capas correspondientes. Conservar una personalización puede resultar tan problemático como perderla si el estado de destino debe comunicar otro aspecto. Define primero el comportamiento esperado para poder juzgar el resultado.
Restablece únicamente la propiedad investigada cuando sea posible y repite la transición. Mantén otra copia sin tocar para comparar. Si restablecer el relleno recupera el estado correcto, incluye esa personalización local en el diagnóstico. Un restablecimiento completo puede arreglar la apariencia a costa de borrar textos e iconos útiles, sin explicar al equipo qué ocasionó el problema.
Inspecciona iconos anidados y bindings
Figma diferencia propiedades de texto, visibilidad booleana, intercambio de instancia y variante en su referencia de propiedades de componentes. Aplica esa distinción al control que falla. Una propiedad llamada «Icon» puede cambiar la visibilidad, sustituir el recurso anidado o seleccionar una variante: el nombre no revela por sí solo la operación.

Sigue cada control expuesto hasta la capa que modifica. En el ejemplo, identifica la instancia del icono, el binding de visibilidad y la propiedad de texto del botón. Activa y desactiva el icono sin sustituirlo; después intercámbialo manteniendo su visibilidad. Si solo falla una operación, has acotado la reparación a un binding o componente anidado concreto.
Comprueba si las propiedades del padre y del hijo describen la misma decisión dos veces. «Status» en un contenedor y «Tone» en la alerta interior pueden ser independientes o representar una sola elección. Escribe la relación prevista. Si el botón de carga siempre debe mostrar un indicador, decide qué componente es responsable de esa regla y qué opciones siguen abiertas para quien utiliza la biblioteca.
Los valores preferidos facilitan encontrar iconos, pero funcionan como sugerencias, no como una regla completa de compatibilidad. Figma permite buscar otras instancias fuera de la lista. Acompaña esa orientación con un espécimen de las dimensiones y la alineación esperadas. Verifica primero el recurso anidado: sustituir todo el conjunto padre resulta prematuro si el problema está en un único icono.
Distingue el redimensionado de las variantes adaptables
Un botón que desborda su contenedor puede tener un problema de tamaño aunque las propiedades de variante sean correctas. La guía de Auto Layout explica relaciones de distribución y tamaño. Diagnostica la geometría por separado para que corregir el estado no oculte un fallo de estructura, ni al revés.

Coloca la misma instancia configurada dentro de un contenedor ancho y otro estrecho. Mantén constantes el estado, tamaño, icono y texto. Anota la primera anchura en la que aparece el problema y revisa por separado contenedor, botón, etiqueta e icono. Si falla únicamente el texto largo, comprueba su redimensionado antes de inventar una variante «carga móvil». Nuestra guía de tamaños en Auto Layout anidado desarrolla esta comprobación geométrica.
Repite después la transición original en ambas anchuras. Así respondes dos preguntas controladas: si la anchura por sí sola provoca el fallo y si cambiar de estado lo provoca a una anchura estable. Cuando intervienen ambos factores, conserva las dos observaciones. No describas el problema como adaptable hasta saber qué cambia con el contenedor y qué cambia con la variante.
Una variante adaptable tiene sentido si cambia intencionadamente la composición, por ejemplo cuando una barra horizontal se convierte en acciones apiladas. Define entonces qué ocurre con el texto, los iconos y las transiciones. Si el componente solo necesita crecer con su contenido, añadir otra variante puede aumentar el mantenimiento sin resolver la relación de tamaño defectuosa.
Utiliza EmviUI para preparar el espécimen de reparación
El catálogo de componentes de EmviUI incluye botones, inputs, alertas y toasts, y acordeones. La imagen es un espécimen de alertas y toasts de EmviUI con varios tratamientos visuales. Ayuda a discutir qué diferencias son intencionales; no documenta un fallo de Figma ni demuestra el comportamiento de esos controles en código.

En tu biblioteca de trabajo, prepara una página de revisión con la familia que utiliza el proyecto. Coloca el tratamiento existente junto a una instancia con texto real y otra después de cambiar el tono. Anota qué debe cambiar y qué debe conservarse. Por ejemplo, un mensaje de facturación puede necesitar mantener su redacción al pasar de informativo a error. Decide también si el icono debe cambiar con esa elección semántica.
Partir de una familia de EmviUI aporta una referencia concreta para revisar la interfaz. Aun así, debes inspeccionar los bindings, combinaciones admitidas y overrides del archivo que utilizas. El kit no decide las reglas de estado de tu producto ni repara automáticamente las personalizaciones posteriores. Consulta el alcance de un UI kit frente a un sistema de diseño para situar esas responsabilidades.
Publica la reparación con una comprobación de migración
Valida la reparación tanto en instancias existentes como nuevas. Las recomendaciones de gestión de componentes identifican la eliminación de propiedades, los cambios de nombres internos y la reorganización de variantes como posibles cambios incompatibles. Que una instancia nueva funcione no demuestra que las anteriores conserven sus personalizaciones.
Prepara tres casos de aceptación: instancia intacta, instancia con texto de proyecto e instancia con icono o aspecto personalizado. Repite la transición que fallaba y su inversa. Incluye el contenedor estrecho si la anchura contribuía al problema. Registra lo que debe permanecer y lo que debe cambiar, y compara cada resultado con esa expectativa. Abrir solo la variante más reciente no comprueba el comportamiento reparado.
Para que una actualización llegue a otros archivos, hay que publicar los cambios del componente principal. La guía de publicación de bibliotecas explica cómo revisar los cambios y añadir una descripción. Aprovecha esa descripción para comunicar el síntoma observado, la solución y cualquier acción necesaria. Confirma el resultado en un archivo consumidor antes de cerrar la revisión.
Conserva evidencias cuando el fallo persista
Si el caso simplificado todavía falla, conserva el conjunto mínimo que lo reproduce, la transición exacta y capturas anteriores y posteriores. Distingue observaciones e hipótesis. «El texto se restablece al pasar de Ready a Loading en una instancia nueva» es evidencia; «el icono corrompe la biblioteca» sigue siendo una hipótesis hasta que una prueba controlada la respalde.
Detén los cambios amplios mientras reúnes esa información. Anota la versión de la biblioteca de origen y si el archivo consumidor aceptó la actualización. Ofrece a quien mantiene el componente un criterio concreto, como «el texto de proyecto permanece después de Ready → Loading → Ready en ambas anchuras». Así la siguiente acción resulta clara aunque todavía haya que investigar la causa.
Pablo Mayoral
Diseñador UX/UI y Web con más de 10 años de experiencia. Creador de EmviUI (sistema de diseño en Figma con más de 10k componentes), UImand y Vitamin Bootstrap. Diseñando actualmente productos digitales en CQMRewards.