Plugins de Figma no funcionan: acceso, selección y red
Identifica la etapa fallida, prueba una selección compatible y distingue acceso, red y resultados en el lienzo antes de repetir un plugin de Figma.
Identifica la etapa fallida, prueba una selección compatible y distingue acceso, red y resultados en el lienzo antes de repetir un plugin de Figma.
Si los plugins de Figma no funcionan, identifica primero si el plugin no está disponible, no arranca, abre pero no descarga datos o se ejecuta sin producir el resultado esperado en el lienzo. Comprueba la cuenta, el editor y la aprobación de la organización antes de modificar el diseño. Después reproduce el fallo con una selección compatible y pequeña. Así acotas el problema sin convertir una pantalla de producción en un experimento.
El siguiente recorrido es una propuesta de diagnóstico, no una afirmación de que todos los fallos tengan la misma causa. Se centra en plugins clásicos empleados al diseñar, con una breve derivación para desarrolladores. Las instrucciones del propio plugin siguen siendo esenciales: importar iconos, transformar textos y exportar código son operaciones con entradas y salidas diferentes. Anota qué promete el comando antes de evaluar su resultado.
Identifica la etapa que falla
Describe el último paso que sí funcionó. «No encuentro el comando» es diferente de «la ventana abre, pero la lista permanece vacía». «La lista carga y Aplicar no cambia nada» constituye un tercer caso. Apunta el comando exacto, la selección y el cambio visible esperado. Una grabación breve suele explicar mejor la incidencia que decir solamente «el plugin está roto».

Usa cuatro comprobaciones: localizar, iniciar, obtener datos externos y modificar el lienzo. Marca cada una como correcta, fallida o no aplicable. Un comando local para renombrar capas puede no consultar ningún servicio. No lo clasifiques como fallo de red solo porque la conexión vaya despacio. Mantén separados un resultado desconocido y un error confirmado.
Si también fallan acciones independientes de Figma, consulta la página de estado del servicio y registra la hora y el servicio afectado si aparece una incidencia. Que esa página esté normal no demuestra que funcione el proveedor de un plugin. Tampoco una incidencia en otra función establece por sí sola la causa. Utiliza el estado como contexto para reproducir el problema.
Cambia una sola cosa en cada intento. Conserva una nota con entorno, tipo de capa, comando, resultado y evidencia nueva. Esta recomendación facilita que otra persona continúe la investigación. Cuando la lentitud afecta al archivo completo, en lugar de a una operación concreta, sigue la guía de diagnóstico del lag de Figma para investigar ese problema específico.
Comprueba el acceso antes de editar
Empieza por la cuenta y el producto que estás utilizando realmente. Confirma la organización y el espacio de trabajo previstos y consulta la compatibilidad en la ficha de Community. Una herramienta disponible en un editor no tiene por qué estarlo en otro. Distingue entre «aquí no está disponible» y «está disponible, pero falla al ejecutarse».
La documentación del manifiesto de plugins define editorType para declarar los editores compatibles. La guía de aprobación explica que puede exigirse autorización y que en Enterprise esta puede variar por espacio de trabajo. Solicita el acceso mediante ese procedimiento; trasladar información confidencial a otro espacio no constituye una reparación.
Revisa la tabla actual de compatibilidad entre asientos y editores en la guía oficial para usar plugins. Poder ver un archivo no implica disponer de todas las funciones. Compara después el estado de la herramienta afectada con el de otra ya aprobada en el mismo editor. Si ambas están ausentes, investiga el acceso antes de sustituir componentes o seleccionar más capas.
Para pedir aprobación, explica la tarea, incluye la URL del plugin e indica qué datos necesita. La guía de gestión en organizaciones describe los controles administrativos. Una solicitud pendiente corresponde a quien revisa el acceso; un caso reproducible en el lienzo corresponde a otro responsable. Separar ambos recorridos evita pedir al desarrollador que «corrija» una restricción deliberada de la organización.
Prepara una prueba de selección pequeña
Prepara un archivo de prueba permitido o una copia claramente aislada del contenido relevante. Emplea textos inventados y un objeto sencillo compatible. Si el comando espera un frame, selecciona uno. Si espera texto, selecciona una capa de texto. Parte del ejemplo documentado por su autor antes de introducir la jerarquía de tu pantalla real.

Una secuencia útil puede incluir una forma, una etiqueta, una instancia y un frame compuesto, siempre que el comando admita esas entradas. Que un plugin de texto falle sobre un rectángulo no aporta evidencia útil. Registra el tipo de nodo seleccionado, no solo su nombre visual: una capa llamada Botón podría ser un frame, una instancia o un grupo de contornos.
Modifica una propiedad estructural cada vez. Por ejemplo, conserva «Continuar» y compara una etiqueta independiente con la equivalente dentro de una instancia. Si la primera prueba funciona y la segunda falla, has delimitado una diferencia que merece comunicarse. Eso no demuestra que todas las instancias sean incompatibles; ofrece al autor una frontera concreta para investigar.
Guarda una referencia anterior y revisa el destino exacto después de ejecutar. Evita desvincular una biblioteca completa para conseguir que pase la prueba. Si dudas de la pertenencia de las capas o del recorte, la guía de límites y recorte de frames ayuda a comprobar la entrada. Buscas la selección mínima que reproduce un fallo significativo, no rediseñar toda la pantalla.
Separa errores de red y del lienzo
Cuando la ventana abre pero no carga contenido remoto, separa tres preguntas: ¿se intentó una petición?, ¿estaba permitida?, ¿devolvió el servicio una respuesta utilizable? Un selector vacío no permite resolverlas. Conserva el mensaje mostrado y la hora del intento para que la investigación tenga un punto de referencia concreto.

La guía de peticiones de red de Figma distingue restricciones de dominio aplicadas mediante Content Security Policy y requisitos CORS del navegador. Un rechazo CSP no equivale a una respuesta HTTP de autenticación ni a un servidor inaccesible. Recoge el mensaje real antes de proponer una solución. Como usuario, envía esa evidencia al autor en vez de editar la configuración de un plugin publicado.
Si desarrollas la herramienta, compara el destino fallido con el alcance de red declarado e inspecciona redirecciones y otros hosts de recursos. Confirma método, estado de respuesta y formato esperado. Prueba con un endpoint sin datos de clientes y excluye credenciales de grabaciones e informes. Que una petición funcione fuera de Figma sirve como comparación, pero no prueba que el contexto del plugin tenga los mismos permisos.
En una red gestionada, pide al administrador responsable que contraste ese destino y esa hora con su política. Evita recomendar una desactivación general del firewall. Si la herramienta utiliza una cuenta externa, compruébala siguiendo la documentación del proveedor. Iniciar sesión en Figma no establece el estado de otra sesión. Anota también si siguen funcionando los comandos locales que solo modifican el lienzo.
Revisa cambios parciales antes de repetir
Antes de repetir, busca resultados parciales. Cuenta capas nuevas, inspecciona elementos renombrados y compara el destino con la referencia anterior. Un comando puede fallar después de cambiar parte del contenido. Ejecutarlo otra vez sin mirar puede dificultar el diagnóstico, especialmente cuando una importación introduce una nueva copia en cada intento.

Las operaciones de texto requieren una comprobación específica. La guía de texto de la API de Figma distingue fuentes ausentes y fuentes que el plugin todavía no ha cargado, además de valores de fuente mixtos. Que una etiqueta sea visible no garantiza que pueda editarse de cualquier forma. Indica si funciona una etiqueta sencilla y falla otra con estilos mezclados.
Si desarrollas el plugin, recoge la excepción de la operación mínima y comprueba que se espera la carga de fuentes necesaria. Si solo lo utilizas, facilita nombres de familia y estilo cuando sean relevantes, sin distribuir archivos tipográficos. Para problemas que también impiden editar texto manualmente, continúa con la guía de reparación de fuentes ausentes.
Repite sobre una copia nueva con idéntica selección. Compara tanto apariencia como estructura: una etiqueta generada dentro del padre equivocado puede parecer inexistente porque queda fuera de la zona prevista. Describe lo que hay después del intento, en lugar de deducir el éxito porque la ventana desaparezca. El cierre automático es una observación, no un justificante de finalización.
Usa EmviUI para concretar la comparación
Un componente existente ayuda a concretar la prueba. La colección de botones mostrada ofrece variaciones visibles de texto, icono y superficie. Usa un ejemplo pequeño con licencia adecuada en tu archivo de Figma para definir qué debe conservar una transformación. La captura no revela la jerarquía interna ni demuestra compatibilidad con ningún plugin.

El catálogo de componentes de EmviUI aporta referencias visuales de botones, campos y otras piezas. Para este ejercicio elige un botón y redacta una condición de aceptación: cambiar la etiqueta conservando icono, dimensiones y relación de componente prevista. Es una tarea de prueba propuesta, no una afirmación de que cualquier herramienta de terceros admita el kit.
Compara las versiones antes y después. Si el plugin cambia la etiqueta pero elimina un icono, puede haber completado su operación sin cumplir tus criterios de aceptación. Refleja esa distinción en el informe. EmviUI permite concretar el resultado de interfaz; no concede aprobación, repara servicios externos ni valida la implementación de la herramienta.
Envía una reproducción al responsable
Envía la evidencia según la primera comprobación fallida. Las restricciones de acceso corresponden al revisor de la organización. Un fallo reproducible de una herramienta corresponde al contacto de soporte de su desarrollador. Una incidencia general de Figma requiere el canal de la plataforma. Incluye suficiente información para evitar otra ronda de «¿qué archivo y qué acción?».
La documentación de depuración de Figma explica cómo abrir la consola de desarrollo e inspeccionar mensajes del plugin. Si soporte solicita esa evidencia, captura el fallo relevante y oculta tokens, texto privado y peticiones ajenas. No necesitas interpretar cada línea del registro para conservar la que corresponde a tu reproducción.
Prepara el informe con esta lista:
- URL de Community y nombre del comando.
- Editor, navegador o aplicación de escritorio y hora.
- Selección pequeña compatible y pasos exactos.
- Resultado esperado y resultado observado.
- Mensaje de error y cambios parciales en el lienzo.
- Resultado de la misma prueba en otro entorno permitido.
Termina con una pregunta concreta: «¿Admite este comando texto con estilos mixtos dentro de una instancia?» facilita una respuesta útil. «¿Podéis arreglar nuestro archivo?» abre un trabajo mucho más amplio. Comparte una reproducción depurada por el canal acordado. Mantén el archivo original con sus responsables habituales mientras el ejemplo reducido sirve para investigar.
Al comparar entornos, conserva cuenta, archivo y selección y cambia únicamente el cliente permitido. Anota la versión del navegador o de escritorio cuando esté disponible. Si el resultado cambia, presenta el contraste como evidencia, sin declarar una reparación permanente. Recupera las condiciones originales antes de probar una segunda hipótesis.
Verifica la recuperación en la tarea original
Superar una prueba pequeña inicia la recuperación. Repite el comando original sobre una copia aislada de la selección real, compara el resultado con la condición de aceptación y revisa las relaciones de componentes que puedan depender de él. Confirma que puedes continuar la tarea sin necesitar una reparación manual oculta después de cada ejecución.
Conserva la entrada que funciona y una nota del cambio que resolvió el problema. Si fue una aprobación, identifica el espacio; si fue una corrección del autor, anota la versión cuando esté disponible; si era una fuente, registra el requisito reparado. Así una repetición futura no comienza de nuevo con una suposición sin evidencia.
Si la herramienta sigue fallando, guarda el caso reducido y utiliza una alternativa manual documentada para terminar el diseño inmediato. No presentes ese rodeo como una reparación del plugin. Obtener una reproducción fiable y un responsable puede ser un resultado útil mientras llega la solución. Las mismas comprobaciones permitirán comparar el próximo intento con el anterior.
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.