Código, oficio y la historia detrás de las carpetas anidadas

Hoy nos entusiasma presentar las carpetas anidadas, una función muy esperada que ayuda a los equipos en crecimiento a mantener sus archivos organizados a medida que generan más contenido y afrontan proyectos cada vez más complejos. A simple vista puede parecer una mejora menor, pero desarrollarla implicó replantear desde cero el modelo de contenido y permisos de Figma: desde el explorador de archivos y los controles de admin hasta el uso compartido, los permisos y la infraestructura principal.

Cuando empezamos este proyecto, hace un año, seguimos un proceso tradicional de desarrollo de producto: el equipo de Producto definió los requisitos, Diseño dio forma a la experiencia y el equipo de Ingeniería comenzó a desarrollar una vez que todo estuvo claro. Pero, a mitad del proyecto, el contexto cambió. Por un lado, estábamos desarrollando nuevas capacidades nativas de IA, lo que obligó a repartir nuestros recursos. Por otro, herramientas como Figma Make, el servidor MCP de Figma, las habilidades del agente, el prototipado sobre bases de código y los agentes con reconocimiento de contexto hicieron que convertir una idea en algo tangible fuera mucho más rápido. De repente, podíamos empezar a construir desde cualquier lugar: a partir de un prototipo, de código o incluso de un boceto escrito en Slack.

Para adaptarnos a estos cambios y lanzar las carpetas anidadas, adoptamos una nueva forma de trabajar:

• El código primero: a medida que escribir código se volvió más rápido y accesible, empezamos a validar ideas creando solicitudes de extracción (PR, pull requests) en lugar de perdernos en debates teóricos.
• Redistribuimos las responsabilidades: abordamos cada problema con flexibilidad: los ingenieros tomaban decisiones de diseño, nuestro diseñador escribía código y nuestra gerente de producto dejó la ejecución diaria para centrarse en cuestiones estratégicas de mayor alcance.
• Cambiamos las entregas al desarrollo por conversaciones: al difuminar los límites entre los distintos roles, todos aprendimos y enseñamos. Compartir conocimientos que antes cada uno protegía nos permitió generar la confianza que el trabajo necesitaba.

Así fue como vivimos estos cambios desde tres perspectivas: ingeniería, diseño y producto. En conjunto, muestran cómo nuestro equipo fortaleció la colaboración, combinó distintas habilidades y mantuvo el foco en ofrecer la experiencia —o la solución— adecuada.

Ethan Adams, ingeniero de software, sobre cómo ganar velocidad poniendo el código primero

A los pocos meses de empezar este proyecto, me di cuenta de que el proceso tradicional de desarrollo de producto nos iba a llevar demasiado tiempo. Era como estar a mitad de un examen final, levantar la vista y descubrir que solo quedaban cinco minutos: teníamos que movernos más rápido.

En lugar de debatir los requisitos del producto ("¿Quién debería tener acceso a X?") en interminables hilos de Slack o reuniones, empezamos a usar el código como punto de partida para la conversación. Esas conversaciones habían sido valiosas cuando escribir código era costoso y llevaba mucho tiempo, pero ahora vivimos en la era de los agentes. En vez de preguntarnos si una idea funcionaría, simplemente creábamos una pull request (PR) para demostrarlo.

Fusionábamos el código siempre que no rompiera nada. Eso nos permitió plasmar ideas rápidamente y compartirlas con nuestros colaboradores de distintas áreas en un entorno de prueba real y en vivo. ¿El código no estaba perfecto? No pasaba nada. ¿Le faltaba funcionalidad? No importaba. ¿Había vacíos en la lógica? Ya los resolveríamos más adelante. En la práctica, este enfoque nos permitió avanzar mucho más rápido y nos dio más confianza para apostar por las propuestas que finalmente elegíamos. Una demostración funcional en tu propia base de código supera a un documento de requisitos del producto (PRD), una y otra vez.

Aunque tenía libertad para tomar decisiones de producto como ingeniero, seguí apoyándome en nuestra gerente de producto, Sachi Shah, como una socia estratégica con quien compartir la responsabilidad. Antes, nuestra colaboración seguía un modelo en cascada: ella definía un requisito y yo lo implementaba. Esta vez fue más bien un ciclo de validación: empecé con una propuesta, fusionar los prototipos en staging, recopilé el feedback de Sachi, pulí los detalles y, por último, desplegué el producto terminado.

Cai Charniga, diseñador de producto, sobre pasar de los píxeles a las solicitudes de extracción

Tengo una confesión: mi número de solicitudes de extracción en este proyecto fue bastante bajo. Dos, quizá tres. No fue que de un día para otro me convirtiera en ingeniero.Lo que pasó fue que todos empezamos a asumir responsabilidades que antes pertenecían exclusivamente a otra persona.

En este proyecto, los ingenieros tenían un gran instinto para estructurar la información y un profundo conocimiento de cómo funcionan los complejos permisos empresariales en una herramienta como Figma. Por eso, era habitual que me propusieran flujos y ajustes de diseño. Cuando cuentas con un sistema de diseño sólido que establece límites claros y existe la confianza suficiente para que las personas tomen decisiones, un ingeniero puede profundizar en una funcionalidad de diseño y llevarla a un nivel de gran calidad. Eso significó que, cuando alguien estaba al límite de su capacidad, el trabajo no se detenía esperando a que la persona "adecuada" pudiera retomarlo.

Por ejemplo, estábamos trabajando en los flujos para compartir carpetas: cómo debía comunicar el cuadro de diálogo para compartir la herencia de permisos a los usuarios con acceso de visualización o edición, y cómo gestionar los casos más complejos en los que esa herencia se rompe. La ingeniera de software Jenny Yu intervino y preparó algunos diseños. A partir de ahí, incorporé a Molly Rosen Marriner, nuestra redactora UX, y entre los tres desarrollamos las propuestas de Jenny sobre el lienzo de Figma Design: Jenny se aseguraba de la solidez técnica del flujo, Molly afinaba el lenguaje relacionado con los permisos y yo daba forma a la jerarquía visual.

Y también ocurría al revés. Hubo ocasiones en las que retomé un cambio, me adentré en el código y descubrí todo lo que ocurría detrás de escena. Era tanto que volvía al equipo y decía: "Sinceramente, esto no debería estar en mis manos". Saber hasta dónde llega tu experiencia también es una forma de habilidad. Aun así, creo que todo diseñador debería intentar abrir una solicitud de extracción. Cuando Ethan me dio acceso a CoderBox, nuestro entorno aislado para crear entornos de código al instante, entendí cuánto tardaban en compilarse ciertos cambios antes siquiera de poder previsualizarlos. Eso despertó en mí más empatía que cualquier entrega al desarrollo.

Los ingenieros podían asumir parte del trabajo de diseño y yo podía adentrarme en el código. Eso me permitió profundizar donde realmente importaba y explorar muchas más iteraciones de la UI de las carpetas de las que el antiguo modelo de entrega al desarrollo habría permitido.

Sachi Shah, gerente de producto, sobre cambiar el control por la confianza

Con esta nueva forma de trabajar, lo primero que tuve que dejar atrás fue la idea de que el pensamiento de producto debía provenir exclusivamente del PM. Mi trabajo pasó a consistir en conectar a las personas adecuadas con los problemas adecuados, darles espacio para avanzar y saber cuándo volver a intervenir.

Jenny Yu se convirtió en una de mis principales aliadas para reflexionar sobre aspectos clave de la gestión de contenido, como la forma en que las personas mueven, duplican y transfieren carpetas dentro de Figma. Ricky Zein, también ingeniero de software, asumió la responsabilidad de la experiencia para usuarios individuales y equipos pequeños, cuyas necesidades suelen ser distintas de las de los clientes empresariales. Y los científicos de datos Patrick Kehinde Jr. y Eric Aberbook analizaron cómo el nuevo modelo de permisos afectaría a cada grupo de usuarios. Gracias a eso pudimos poner a prueba nuestras hipótesis y centrarnos en los riesgos más importantes.

Dejar de ocuparme de la ejecución diaria me dio más tiempo para centrarme en la pregunta estratégica que había detrás del proyecto: ¿seguía siendo importante una mejor organización de archivos en un mundo centrado en la IA o las carpetas estaban perdiendo relevancia a medida que mejoraba la búsqueda con IA? Creamos artefactos que nos ayudaron a entender que las carpetas podían ser aún más importantes a medida que las personas generaban más trabajo, ya que ofrecían una estructura y un contexto más ricos para que la búsqueda con IA pudiera recuperar la información. Pero lo que más nos ayudó fue tomar distancia y construir una cartera equilibrada de apuestas. Además de las carpetas anidadas, nuestro equipo trabajó a toda velocidad para lanzar las habilidades del agente de Figma, otra pieza de la estrategia de IA nativa de Figma. Aunque parezca contradictorio, dedicar menos tiempo a gestionar cada detalle del producto me dio más margen para definir una hoja de ruta en la que las necesidades fundamentales de los clientes y las nuevas experiencias nativas de IA pudieran avanzar en paralelo.

Dentro del propio proyecto, el lugar donde más necesitaba reenfocar mi atención era en los clientes. Me encargué de liderar el programa de acceso anticipado (EAP) y fuimos muy resolutivos. En Config, me colé en los happy hours junto con Ayush Mehra, nuestro gerente de Ingeniería, para presentarles en frío el nuevo sistema de organización de archivos a los clientes. Convencimos a varias personas de unirse al programa de acceso anticipado en ese mismo momento. A partir de ahí, seguimos ampliándolo. Las comunidades de Friends of Figma en Jaipur, Barcelona, Mumbai y Lahore fueron de las primeras en adoptar la función. También me puse en contacto con líderes de comunidades de todo el mundo y con personas en X que habían expresado un interés especial por la organización de archivos, entre ellas Ilya Miskov, un diseñador que había participado en una de nuestras primeras conversaciones de descubrimiento.

El feedback de los clientes nos mostraron cómo se comportaban las carpetas anidadas en organizaciones reales, con archivos desordenados y hábitos ya establecidos. Nos ayudaron a detectar errores, perfeccionar la experiencia y reducir el riesgo de migrar a los clientes a un modelo de contenido completamente nuevo.

Pasar tiempo con los clientes me dio una claridad sobre el producto que nunca habría conseguido solo escribiendo especificaciones. Cambiar el control por la confianza implicó centrarme en el trabajo para el que estaba mejor preparado y, al mismo tiempo, confiar en que los demás hicieran lo mismo.

Esta forma de trabajar solo funciona cuando el equipo confía en los demás. Sinceramente, difuminar los límites entre los roles fue incómodo. Hubo momentos en los que nos pisamos los talones, cruzamos límites sin querer o intentamos hacer cosas que nunca antes habíamos hecho. Esa incomodidad formó parte de encontrar una nueva forma de trabajar, y solo pudimos superarla porque habíamos invertido en las relaciones que sustentaban nuestro trabajo. Con el tiempo, dejamos de aferrarnos tanto a nuestros ámbitos de especialidad y empezamos a enseñarnos mutuamente aquellos aspectos de nuestro craft que antes cada uno reservaba para sí.

Mantuvimos la confianza y el contexto mediante rituales compartidos: sesiones semanales para detectar errores, sincronizaciones entre equipos, trabajo en pareja entre diseño e ingeniería y celebraciones de los principales hitos, incluido el lanzamiento interno para todo Figma. Esos ritmos nos mantuvieron alineados con un mismo objetivo: cumplir una promesa muy esperada por los clientes sin comprometer la calidad.

Las carpetas anidadas se implementarán gradualmente para todos los usuarios durante las próximas semanas. Visita nuestro Centro de ayuda para obtener más información sobre cómo empezar.