Empieza por las necesidades reales. Céntrate en el producto y en la historia del usuario.

Cuando empecé en el sector, trabajaba en una empresa muy pequeña donde aprendí por mi cuenta lo justo de HTML y CSS para poder manipular plantillas de WordPress. Aparte de eso, me mantuve muy alejado de la programación. Incluso pensé en crear mi propio plugin para Figma, pero como no entendía bien la parte técnica, al final no lo hice.

¿Mi sitio web con mi portfolio? Lo creé con Framer, un creador de sitios web sin código. Nunca imaginé que abriría un IDE y escribiría algo yo mismo.

Y entonces llegó este año. El auge de las herramientas de programación basadas en LLM fue como descubrir un continente nuevo. Empecé poco a poco, pidiendo a la IA que escribiera un script que sincronizara los cambios de mis archivos de iCloud y los guardara automáticamente en un disco externo.

Pero recientemente, un punto débil en el proceso de desarrollo de productos en mi trabajo me empujó a emprender algo más grande: crear un plugin de Figma desde cero.

Digamos que trabajar con IA es una relación de amor-odio. Te ayuda muchísimo... y, a veces, te hace tropezar igual de rápido.

Esto no es un tutorial. Es una mirada entre bastidores a cómo un diseñador (yo) decidió dejar de esperar a que alguien más creara algo y trató de hacerlo por su cuenta con la ayuda de la IA. Desde la configuración de GitHub hasta la depuración a través de los chats de ChatGPT, así es como se sintió realmente crear y lanzar un complemento de Figma desde cero.

Antes del código, prepara el escenario

Los entornos de desarrollo son importantes, incluso para un pequeño plugin de Figma.

¿Por qué elegí un plugin de Figma como mi primer producto «lanzado» real?

Lo único que hay que hacer es hacer clic con el botón derecho en Figma, seleccionar «nuevo plugin...» en el menú de desarrollo, seguir unas cuantas instrucciones y ¡listo! Figma genera automáticamente una carpeta de inicio con todo lo básico ya configurado. No tuve que tomar ninguna decisión sobre la pila tecnológica. Simplemente... funcionó.

Por defecto, utiliza TypeScript para la lógica y, si el plugin tiene una interfaz de usuario, es HTML/CSS estándar. Limpio y minimalista.

Esto es lo único que hice «manualmente» antes de empezar:

  1. Instalé VS Code y abrí la carpeta del complemento.
  2. Instalé la extensión GitHub Copilot para VS Code (también conocido como mi programador AI).
  3. Instalé Node.js + npm para poder ejecutar scripts de compilación.
  4. Me aseguré de que la compilación de TypeScript estuviera activada, para que mis cambios en .ts se convirtieran automáticamente a .js, que es lo que realmente ejecuta el navegador.

Un poco de configuración, unos cuantos plugins de VS Code, una pizca de conjuros en la terminal... y voilà: ¡ya podemos empezar a desarrollar!

El control de versiones también es importante

¿Nunca has usado GitHub? No te preocupes, no llegas tarde a la fiesta.

Si nunca has tocado Git o GitHub, no pasa nada. No estás atrasado. Y, sinceramente, con ChatGPT, aprenderlo ahora es más fácil que nunca. Puedes pedirle que te explique el control de versiones utilizando analogías de cualquier campo que tú conozcas mejor. Así es exactamente como lo aprendí yo.

La cuestión es que el desarrollo de software no es como el trabajo de diseño en Figma.

En Figma, tenemos páginas y páginas para guardar flujos, diseños alternativos, exploraciones extrañas e ideas a medio hacer que quizá resucitemos más adelante. Siempre puedo indagar en algún rincón misterioso que solo yo conozco y recuperar algo.

¿Pero con el código? Es diferente.

Normalmente se trabaja directamente sobre la última versión. Y cuando se trabaja con IA (especialmente al principio), las cosas pueden descarrilarse muy rápido. Un sistema de control de versiones te permite volver a empezar desde cero cuando las cosas se complican, y créeme, se complicarán.

Y no, no es necesario vivir en la terminal para usar Git. Herramientas como GitHub Desktop o SourceTree de Atlassian te ofrecen una interfaz limpia y visual. No tienes que memorizar comandos, puedes gestionar tus confirmaciones, ramas y fusiones como un profesional.

Así es como lo he estado utilizando:

  • La versión pública y en vivo del complemento, la que se ejecuta en Figma, es siempre la rama principal.
  • Cada vez que trabajo en una nueva función o corrijo un error, me ramifico desde la rama principal para no estropear la producción. Nombro las ramas como quiero, como proj-export-setting para los cambios relacionados con las configuraciones de exportación.
  • Después de una serie de cambios (por ejemplo, ajustes en la interfaz de usuario, ajuste del formato de salida CSV o pulido del texto de la experiencia de usuario), confirmo esos cambios.
  • A continuación, envío las confirmaciones al repositorio remoto (también conocido como GitHub en la nube).
  • Una vez que todo parece estar bien y funciona correctamente, abro una solicitud de extracción (PR) para fusionar la rama con la principal. GitHub también me permite crear una etiqueta de lanzamiento para realizar un seguimiento del historial de versiones.

Así que sí, una vez que tienes tu entorno de desarrollo configurado y el control de versiones funcionando correctamente, por fin llega la parte divertida:

💥 Es hora de hablar. Con la IA. (¡Vamos!) 🎤✨

Ahora viene la parte divertida: hablar con la IA

Mantén la modularidad. Define bien las especificaciones. Cuenta una buena historia de usuario.

Aquí tienes la versión resumida:

Toma todo lo que tienes en la cabeza, cada detalle de tus especificaciones, y explícaselo a la IA con la mayor claridad posible. Cuanto más específico seas, mejor será el resultado.

Piensa en ello como si estuvieras trabajando con un nuevo ingeniero en tu equipo.

A veces, cuando falta algo en las especificaciones, te hacen preguntas para aclarar dudas. Pero otras veces... simplemente improvisan. Y tú no te das cuenta de que algo ha salido mal hasta que el control de calidad lo detecta más tarde. ¿Te suena familiar? 😅

Hablar con la IA es exactamente así.

Excepto que la IA es el tipo de ingeniero que es demasiado bueno para rellenar los huecos por sí mismo. Si le das instrucciones vagas, es posible que obtengas algo totalmente fuera de lugar.

Pero esta vez, tú eres el control de calidad.

Tú eres el que tiene que detectar las lagunas, las lecturas erróneas y las suposiciones extrañas. Por lo tanto, cuanto más preciso seas desde el principio, menos depuración necesitarás más adelante.

Y dado que la mayoría de los productos son en realidad un conjunto de pequeños módulos reutilizables que funcionan juntos, he descubierto que lo mejor es hablar con la IA de una tarea en cada vez: en pequeñas dosis, centrándose en un tema concreto y con un alcance limitado. De esta forma, es más fácil construir, depurar y evolucionar más adelante.

Tomemos esta imagen (o mi caso de uso PoC) como ejemplo

En mi cabeza, imaginé que todas las etiquetas de anotación aparecían al lado del nodo de texto seleccionado que está más cerca del marco más externo. ¿Por qué? Porque no quería que las anotaciones cruzaran el marco y cubrieran la interfaz de usuario real. Simple, limpio, no intrusivo.

🪄 Así es como se veía mi solicitud:

Quiero activar la función de anotación con el comando del complemento «annotate».

Característica principal

Cuando se selecciona un nodo de texto, el complemento debe tomar su layerName y utilizarlo para crear una anotación. Si no se selecciona ningún nodo de texto, mostrar un mensaje emergente: «Selecciona un bloque de texto para anotar».

El componente de anotación debe incluir

Una etiqueta de texto, una línea de 2 píxeles y un vector circular de 4x4.

El texto de la etiqueta debe utilizar el layerName del nodo de texto seleccionado y estar envuelto en un diseño automático configurado para ajustarse al contenido, con un relleno de 2 píxeles y 4 píxeles.

El color del texto de la etiqueta debe ser #FFF, y el fondo, la línea y el vector deben ser #333.

Lógica de colocación (para el diseño de la interfaz de usuario)

Si la anotación se coloca a la izquierda, el diseño debe estar alineado horizontalmente en el centro, sin espacio:

Etiqueta → Línea → Punto. Si está a la derecha, invierte el orden. Para la parte superior, apila verticalmente: Etiqueta → Línea → Punto. Para la parte inferior, invierte el orden de nuevo.

El vector circular debe alinearse con el centro del lado del nodo de texto seleccionado. La etiqueta debe mantener siempre un espacio de 60 píxeles con respecto a la capa principal más externa.

Lógica de colocación (para decidir el lado)

Calcula el espacio entre el nodo de texto y su marco principal. Elige el lado con el espacio más pequeño: izquierda, derecha, arriba o abajo. Si todos los espacios son iguales, elige la derecha por defecto.

Divida el código en dos utilidades independientes

Una para crear y organizar el componente de anotación y otra para calcular la posición.

Esa indicación incluía los elementos esenciales:

  1. Lo que quiere construir, cómo funciona y cuáles son los criterios de aceptación
  2. Cómo interactúa el usuario con ello y qué comentarios recibe
  3. Casos extremos (como qué ocurre si no se selecciona nada)
  4. Y una idea aproximada de cómo debería ser la interfaz de usuario

Cuanto más incluyas, más contexto tendrá la IA para crear realmente lo que tienes en mente. Y menos idas y venidas necesitarás antes de que funcione como habías imaginado.

Has creado un módulo... ¿Y ahora qué?

Es hora de pedirle a la IA que realice un taller de viabilidad.

En mi cabeza, este complemento siempre estuvo pensado para admitir cuatro funciones principales.

Tres de ellas implicarían la interfaz de usuario y la interacción con el usuario, mientras que una se activaría únicamente mediante un comando.

Pero la pregunta es: ¿cómo se pasa de un único PoC (prueba de concepto) funcional a un plugin con un alcance real? ¿Cómo se escala sin romper lo que ya se ha construido?

Fue entonces cuando empecé a pedirle a la IA que me ayudara a evaluar la viabilidad.

🪄 Así era mi prompt:

Tengo algunas funciones más importantes que quiero añadir a continuación:

1. Los usuarios deben poder introducir manualmente el nombre clave de la anotación, en lugar de utilizar el nombre de la capa del nodo de texto.

2. Después de crear varias anotaciones (posiblemente docenas), necesitaré una interfaz de usuario para ver y gestionar todas las anotaciones, que muestre campos como el nombre clave, el contenido y las etiquetas, y que permita editar el nombre clave y las etiquetas.

3. El concepto de «etiquetas» será definido por el usuario y deberá establecerse antes de crear cualquier anotación.

Basándote en la prueba de concepto actual (con alineación y etiquetado automáticos), evalúa la viabilidad y propone un plan para ampliar gradualmenteesto a una MVP v1, sin reescribir ni romper la lógica central.

Para cada nueva función, sugiere cómo se podría añadir de forma limpia al código base actual. Si hay partes que deben dividirse en módulos más pequeños para facilitar el mantenimiento, o áreas que podrían necesitar una refactorización, indíquelo.

Este tipo de indicaciones ayudan a la IA a pasar de ser un «ejecutor» a un «planificador».

Empieza a pensar en términos de estructura, extensibilidad y diseño del sistema, no solo en la implementación. Lo estás invitando a participar en el proceso de reflexión inicial sobre el producto.

Y cada vez que quieras crear una nueva función, este tipo de conversación estructurada permite a la IA analizar lo que ya has creado y sugerir el camino más seguro y limpio para seguir adelante. A veces, incluso recomienda dividir las cosas aún más o identificar los primeros signos de código espagueti antes de profundizar demasiado.

Cuando el alcance crece, las pruebas se vuelven más difíciles

Incluso un plugin «sencillo» puede sorprenderte.

Solo es un plugin de Figma, ¿no?

¿Cómo podría tener errores?

Sí... Estaba muy equivocado 😅

En cuanto el conjunto de funciones empezó a crecer y los datos comenzaron a fluir entre TypeScript y HTML, empezaron a aparecer errores por todas partes. Hacía clic en algo y... nada. O peor aún, lo incorrecto. Y la mitad de las veces no tenía ni idea de por qué fallaba ni dónde buscar.

Fue entonces cuando me di cuenta de lo crucial que es dejar que la IA ayude con la depuración:

Leer los registros de errores, ayudar a estructurar los casos de prueba y dar sentido al cableado invisible que hay detrás.

Así que le pedí a la IA que revisara el código base y añadiera sentencias console.log() en cada punto de flujo de datos e interacción con el usuario.

Pero no solo registros aleatorios, sino registros con suficiente contexto para que la IA pudiera ayudarme más tarde a razonarlos.

Y, sin embargo, a veces ni siquiera eso era suficiente.

Había momentos en los que la IA decía:

«Hmm, a mí me parece bien. No puedo reproducir el error. El código parece limpio».

Lo que significa: ahora tú eres el control de calidad.

Tienes que saber qué se supone que hace cada función.

Tienes que escribir tus propios casos de prueba.

Tienes que probar la versión de desarrollo como un usuario real.

Y lo más importante, tienes que documentar los pasos exactos para reproducir un error, para que la IA pueda ayudarte a solucionarlo.

Aquí tienes un ejemplo de cómo lo expresaría yo:

🪄 Así era mi mensaje:

Me apareció el siguiente error en la consola: OOOOXXXXX.

Esto es lo que hice: abrí XXXX, introduje ZZZZ en el campo de entrada, seleccioné C y hice clic en Confirmar.

Comportamiento esperado: debería aparecer un nuevo componente de anotación en el lienzo de Figma.

Resultado real: no se creó nada.

Lo intenté varias veces y el problema se reprodujo de forma constante. Por favor, ayúdame a depurarlo.

Cuanto más contexto proporciones (qué pasó, dónde pasó, qué esperabas, qué pasó realmente), más rápido podrá la IA identificar dónde se produjo el error.

¿Y los errores de la interfaz de usuario? Bueno... los diseñadores están dotados de una vista de lince 🦅👁️

Simplemente haz una captura de pantalla del problema y dile a la IA qué es lo que no te cuadra. Algo así como:

«Este botón debería estar centrado verticalmente, pero está desalineado 4 píxeles».

Es extrañamente satisfactorio convertirse en el control de calidad de tu propio producto creado por IA. La depuración deja de ser una cuestión de «qué ha fallado» y se convierte en averiguar cómo ayudar a tu nuevo compañero robot... a ayudarte mejor.

¿Tengo que diseñar la interfaz de usuario en Figma?

Spoiler: yo no lo hice.

El modo de desarrollo de Figma ahora se puede conectar a MCP, lo que, sinceramente, suena increíble (aunque todavía no lo he probado 🙈). Me encantaría saber cómo lo están utilizando otras personas.

Pero, para ser sincero, para todo este proyecto de plugin, no diseñé ninguna pantalla de interfaz de usuario en Figma. Ni una sola.

Lo que le di a la IA fue básicamente un montón de wireframes que solo yo podía entender 😂

Sin embargo, lo que realmente me ayudó fue que ya había definido un puñado de tokens de componentes desde el principio:

  • Tokens de color
  • Configuración tipográfica
  • Estilos y relleno de botones
  • Estados y comportamientos de los campos de entrada

Así que cuando le pedí a la IA que creara módulos individuales, ya tenía suficiente para acercarse bastante a lo que tenía en mente. El enfoque siempre estuvo en la coherencia y el pensamiento modular, no en maquetas perfectas al píxel.

Dicho esto... como no pulí mucho la interfaz de usuario durante la fase MVP, algunas pantallas acabaron quedando, eh... bastante rudimentarias.

En el ejemplo anterior, utilicé un diseño de tabla para mostrar los datos de las anotaciones. Técnicamente, funcionaba. Pero después de usarlo varias veces, me di cuenta de lo siguiente:

  • Hacía que el análisis de la información fuera más difícil, en lugar de más fácil.
  • Las tablas ocupaban mucho espacio.
  • Cuando se abría la interfaz de usuario del complemento, bloqueaba gran parte del lienzo de Figma, lo que dificultaba la referencia cruzada entre elementos.

Así que, a principios de esta semana, se me ocurrió una idea: ¿Por qué no renovar la interfaz de usuario?

Hice una rápida comprobación de viabilidad con IA y resultó que los cambios necesarios se centraban principalmente en la interfaz de usuario y la capa de renderizado de datos. La lógica central podía seguir siendo la misma. Así que volví al modo «solo hablar», esta vez con un esquema muy básico como referencia visual.

🪄 Así era mi propuesta:

Basándome en el análisis de viabilidad, me gustaría actualizar el diseño de la interfaz de usuario:

• Sustituir la vista de tabla por tarjetas.

• Mantener la misma lógica para las acciones de editar/localizar/eliminar.

• Cambiar los filtros de un menú desplegable a botones de estilo chip.

• Mover las funciones de exportar y buscar a un botón de acción flotante en la parte inferior.

(referencia: imagen a continuación)

Empecemos con el primer componente: la tarjeta. Así es como describí el nuevo diseño de la tarjeta.

  1. Fila superior: etiqueta + 3 botones de acción (editar/localizar/eliminar)

2. Centro: nombre clave

3. Parte inferior: contenido

Cuando el usuario hace clic en «editar», la tarjeta pasa al modo de edición.

1. Fila superior: selector desplegable para etiquetas + botón Guardar

2. Centro: campo de entrada del nombre de la clave

3. Parte inferior: contenido (solo en vista previa)

4. El resto de tarjetas deben desactivarse durante el modo de edición.

y así sucesivamente.

Solo hicieron falta cuatro o cinco rondas de indicaciones para que la IA reconstruyera por completo la interfaz de usuario tal y como la había imaginado.

Así que no, no siempre es necesario dibujar la interfaz de usuario.

Si puedes describir claramente cada parte de las especificaciones de tu interfaz de usuario (estilos, diseño, comportamientos, interacciones), la IA puede convertir eso en código con una rapidez sorprendente.

(Por supuesto, si estuviera creando una aplicación web en lugar de un complemento, probablemente seguiría diseñando las cosas en Figma... de lo contrario, acabaría con 20 rellenos ligeramente diferentes en toda la aplicación 😂).

Entonces... ¿qué es exactamente este plugin?

¿Y por qué lo creé?

Todo el plugin se creó siguiendo el mismo proceso:

Hablar con la IA → crear un módulo → probarlo → corregirlo → repetir.

Después de docenas de estas pequeñas iteraciones, finalmente terminé con algo que está (¡casi!) listo para lanzarse. Pero espera, ¿qué es este plugin? 😄

Bueno... es un complemento no oficial de Lokalise Key Annotation para Figma. Lo llamé «Localization Key Annotation». Y, sinceramente, la razón por la que lo creé es muy sencilla: el complemento oficial de Lokalise es... muy difícil de usar. No se adaptaba a nuestro flujo de trabajo ni a nuestras necesidades. Así que hice el mío propio.

Esto es lo que hace (por ahora):

PASO 1Guarda tus proyectos internos de Lokalise

Empieza introduciendo los proyectos relacionados con el desarrollo de tu equipo desde Lokalise, ya sean del lado del cliente, del backend u otros proyectos. Guárdalos localmente.

PASO 2Anota todas tus claves de Lokalise directamente en Figma

Se acabó el tener que adivinar o cruzar referencias manualmente. Solo tienes que marcarlas directamente en tu archivo de diseño, lo que resulta ideal para el traspaso al equipo de desarrollo y aún mejor para la asignación de claves.

PASO 3Utilice el comando «Gestionar» para ver y editar las claves

Este comando abre una lista completa de todas sus anotaciones. Desde aquí, puede:

  • Editar el nombre de la clave
  • Cambiar el proyecto asignado
  • Descargar archivos CSV por proyecto (uno o varios a la vez)

‌                                                            

OTROSReajuste las anotaciones en cualquier momento

Dado que las capas de anotaciones suelen estar bloqueadas para evitar ediciones accidentales, a veces pueden desalinearse durante los cambios de diseño. El comando Reajustar soluciona este problema, volviendo a colocar todo en su sitio con un solo clic.

‌

Esas son las funciones actuales. Si crees que pueden ser útiles para tu equipo, ¡no dudes en probarlas!

E incluso si no utilizas Lokalise, este complemento puede resultarte útil.

Si gestionas tus claves de copia manualmente en JSON (o cualquier otro formato), esto podría ahorrarte mucho tiempo al mantener las anotaciones sincronizadas y ordenadas en tus archivos de diseño.

Reflexiones finales

La verdad es que el Vibe Coding es... un poco adictivo.

Me ahorra mucho tiempo que normalmente dedicaría a hacer clic en elementos repetitivos de la interfaz de usuario y me permite centrarme más en la parte divertida: pensar en cómo se percibe un producto, para qué sirve realmente y cómo podría ayudar a la gente.

Claro, solo era un plugin de Figma.

Pero también fue la primera vez que construí algo real, de principio a fin, con la IA como compañera de equipo.

Y tengo que decir que fue una sensación increíble 😌

Espero poder empezar pronto algunos proyectos nuevos. Puede que no sean grandes. Puede que no sean sofisticados. Pero quiero que sean significativos.

Gracias por leer código en casa.