- Barron Webster, con más de 8 años de experiencia diseñando productos de IA, ocupa en Figma el primer rol de “diseñador de modelos” del mundo, lo que marca la aparición de un nuevo puesto híbrido donde los diseñadores colaboran directamente con los LLM
- El trabajo central del diseñador de modelos es compensar las limitaciones de los modelos fundacionales e introducir nuevas herramientas y formas de pensar en las organizaciones de diseño para crear funciones de IA
- A diferencia del diseño tradicional de UI, en el diseño de productos de IA primero hay que prototipar el comportamiento del modelo y luego diseñar la UI; de lo contrario, existe el riesgo de crear una interfaz que no coincida con su funcionamiento real
- La construcción de sistemas de evaluación (Evals) es clave para el control de calidad en productos de IA, y se necesitan herramientas para que los diseñadores puedan manipular y ejecutar casos de evaluación con ciclos rápidos de retroalimentación
- En la era de la IA, es indispensable que los diseñadores comprendan a fondo la estructura de entrada y salida de los modelos y tengan la capacidad de entender el sistema completo; ya no deben ser solo creadores de UI, sino participantes en la toma de decisiones
Introducción a Barron Webster
- Es un diseñador que ha estado profundamente involucrado en productos de IA durante más de 8 años, con una perspectiva que le permite ver más allá del ciclo de hype
- En Google Creative Lab participó en el diseño de Teachable Machine, lanzado en 2017, la primera herramienta que permitía a consumidores entrenar modelos de IA
- Después trabajó en funciones de IA en Replit y contribuyó a su crecimiento de startup a unicornio
- Recientemente se unió a Figma como el primer diseñador de modelos del mundo
El rol del diseñador de modelos
- Forma parte del equipo de investigación de IA de Figma y cumple dos misiones principales
- Resolver situaciones donde incluso sacar el máximo rendimiento posible de un modelo fundacional no es suficiente
- Como los datos de Figma tienen un formato propietario que los modelos fundacionales no manejan bien, trabaja para cerrar esa brecha
- Introduce en la organización de diseño nuevas herramientas y una mentalidad AI-first
- Figma es una gran empresa y muchos diseñadores no tienen experiencia diseñando experiencias de IA
- Diseñar funciones de IA es distinto del diseño tradicional de productos
- Su objetivo es crear herramientas para que los diseñadores puedan prototipar la esencia de una función de IA al inicio del proceso, sin tener que volverse ingenieros
- Si se diseña la UI de una función que no se ha experimentado directamente, existe el riesgo de crear una interfaz para un caso perfecto que no encaje con el funcionamiento real
El futuro de las herramientas de diseño para IA
- La herramienta que más espera es una que permita a los diseñadores manipular y ejecutar casos de evaluación con ciclos rápidos de retroalimentación
- Si una función de IA no funciona en un archivo de Figma, debería poder agregarse de inmediato como caso de prueba
- También debería ser posible ajustar el system prompt o probar otros modelos al instante
- El problema actual es que el ciclo de retroalimentación es demasiado lento
- La clave de toda buena herramienta de diseño es eliminar o reducir el ciclo de retroalimentación
- Gran parte del trabajo de construir conjuntos de evaluación sigue siendo limpieza manual de datos
- También está pensando cómo diferenciar las funciones de IA en Figma
- Al ser una plataforma de diseño, se esperan resultados mejor diseñados que los de Claude Code o Cursor
- La clave está en una estrategia de evaluación bien dirigida y en encontrar proxies de buen diseño
- Esto también plantea una pregunta filosófica al nivel de una escuela de arte
La entrada de Barron al mundo de la IA
- Clase Computer Utopias de RISD en 2014-2015: antes de los LLM, cuando la investigación en machine learning estaba centrada en clasificadores
- Los modelos de clasificación de imágenes eran lo más interesante y eran la base de cosas como los filtros faciales de Snapchat o la búsqueda de imágenes de Google
- La moderación de contenido y los sistemas de recomendación eran temas centrales
- Fue la era dorada de Facebook, Twitter y Cambridge Analytica, cuando la invención del feed algorítmico abrió nuevo material para diseñar
- Google Creative Lab entre 2016 y 2018: trabajó en Google Lens, Google Assistant y Teachable Machine
- Casi todos los proyectos consistían en aplicar innovaciones de modelos
- Los modelos se usaban no para generar texto, sino para ordenar o anotar contenido existente
- También promovió el caso de un agricultor japonés de pepinos que clasificaba pepinos con TensorFlow
La experiencia en Replit
- Trabajó allí más de 3 años, empezando cuando no existían funciones de IA y encargándose de evaluar cómo aplicar IA
- Conforme los modelos mejoraban, buscaba cómo añadir funciones de IA confiables mientras aprovechaba sus nuevas capacidades
- Comenzaron con funciones manuales básicas (explicar código seleccionado con IA, generar código en archivos existentes)
- Tras cada lanzamiento, se repetía el ciclo de aumento en las expectativas de los usuarios
- Se permite generar snippets de código → piden archivos o proyectos completos
- Se puede generar todo → piden ediciones específicas
- Se pueden hacer ediciones específicas → piden empezar desde cero
- El patrón era probar una función con el modelo actual → si no funciona, esperar → volver a intentarlo cuando salga un nuevo modelo fundacional
- Restricciones del producto en un entorno de programación
- Aunque el modelo escriba bien código, hace falta saber cómo editar en el lugar correcto
- Hasta Sonnet 3.5, los modelos eran débiles para manejar números de línea
- Fue necesario desarrollar parches temporales para precisión de edición, evitar duplicación de contenido y reemplazar funciones
- Gran parte de ese trabajo quedaba obsoleto 6 a 12 meses después con nuevos modelos
Un caso de cambio hacia la validación por parte del usuario
- Cuando el agente de Replit crea archivos y escribe código automáticamente, un gran problema técnico era probar la aplicación construida por el agente
- Por ejemplo, verificar si una página de login funcionaba
- El enfoque desde ingeniería fue: levantar un sandbox, construir una función de screenshots y alimentar esas imágenes a un modelo multimodal para decidir dónde hacer clic o escribir
- En esencia, implementar una especie de uso de computadora por parte del modelo
- La propuesta de Barron y otro ingeniero fue: mostrarle el sitio al usuario y pedirle que lo pruebe directamente
- Eso trasladaba la validación y el testing al usuario y evitaba por completo un problema técnico muy complejo
- Si hay alguien enfocado no en el problema técnico sino en el problema del usuario, muchas cosas pueden omitirse o simplificarse
Encontrar product-market fit
- En la estrategia tradicional previa a la IA, primero se hacía un plan, se partía de una base existente de usuarios y se definía cómo expandirse a nuevos mercados o categorías
- Con la rapidez de los cambios en IA, la estrategia de Replit se volvió mucho más reactiva
- Tenían un fuerte product-market fit en educación, especialmente tras la enseñanza remota durante la pandemia
- La mejora de las funciones de IA generó un dilema
- Los desarrolladores independientes y hackers preferían la IA
- Los profesores se oponían porque podía permitir que los estudiantes evitaran el aprendizaje básico
- Cuando lanzaron el agente de Replit, no estaba claro para qué usuario era
- Más que un proyecto de arriba hacia abajo, fue más exitoso lanzar la función y observar la reacción
- Después del lanzamiento, las conversaciones permitieron identificar a los usuarios: personal de operaciones en empresas tecnológicas, que necesitaba recolectar datos de ventas o construir dashboards (similares a usuarios de Zapier o Retool)
Sistemas de evaluación (Evals)
- En sus primeros dos años, Replit casi no hizo evaluaciones; en ese momento todavía no era una práctica tan extendida
- Con el agente empezaron a usar evaluaciones más activamente, sobre todo como métrica de desarrollo de producto
- Cuando salía un nuevo modelo, revisaban su desempeño en evaluaciones de programación para decidir si valía la pena probarlo en la app
- En Sandbar dedicaron mucho tiempo a escribir evaluaciones sobre la personalidad del modelo
- Además de benchmarks generales de la industria, construir evaluaciones propias del producto se volvió un nuevo trabajo de diseño
- Flujo de trabajo: escribir un prompt → ajustarlo → crear evaluaciones → revisar rendimiento → combinarlo con pruebas manuales y feedback subjetivo
- Sin evaluaciones, aumenta mucho el trabajo manual necesario para verificar si la IA funciona
- Ejemplos de evaluaciones en Sandbar
- Si no sabe la respuesta, debe hacer una sola pregunta de aclaración, concreta y específica, en lugar de alucinar
- No debe hacer más de dos preguntas a la vez
- Las respuestas deben mantenerse breves, con ciertas excepciones
Las dificultades de las evaluaciones
- La complacencia (sycophancy) es uno de los temas más difíciles al escribir evaluaciones
- Se trata de la idea de que, cuando corresponde, el modelo debería contradecir al usuario
- Decidir qué tasa de fallos es aceptable termina siendo una decisión de producto y diseño, y parte de la filosofía del producto
- Muchas veces, un mal resultado en evaluación se debe no a una caída real del desempeño, sino a una evaluación mal escrita
- Ejemplo: en una evaluación de “debe ser muy conciso”, si el usuario dice “mi mamá murió”, una respuesta como “qué mal” podría obtener una puntuación alta, aunque no sea la respuesta deseada en la práctica
- Las evaluaciones sirven sobre todo para prevenir regresiones y comprobar si se cumplen ciertas propiedades
- Son similares a la cobertura de pruebas en programación
- Algo como el desarrollo guiado por pruebas (TDD) en la programación tradicional sigue siendo raro en la ingeniería de IA
- Es decir, escribir primero las evaluaciones y luego el código que las apruebe
- Existe la posibilidad de un futuro trabajo como diseñador de evaluaciones
- Similar al papel de un sistema de diseño que crea dashboards para que los equipos entiendan el desempeño de la IA
Ideas de funciones de IA en Figma
- Está considerando la idea de “crítica de diseño como servicio”
- Pedirle a la IA una crítica de diseño
- Esto abre preguntas interesantes sobre la personalidad de ese sistema
- Ofrecer actitudes seleccionables (por ejemplo, estilo “Dieter Rams”) vs. definir un valor predeterminado
- Enfocarse en accesibilidad o contraste (feedback más objetivo) vs. apuntar a un alcance más amplio
- Aún no está claro cuánto de esto llegará a la experiencia real del producto
Hacia dónde deberían evolucionar las herramientas de evaluación
- Espera herramientas que reduzcan la velocidad de iteración necesaria para crear evaluaciones
- Hoy, todo el que trabaja con evaluaciones debe hacer básicamente lo mismo
- Conectar mapeos, formatos, pipelines e interfaces donde se pueda ver toda la salida en un solo lugar
- Las herramientas para texto son bastante buenas, pero siguen faltando para otros formatos
- Existen plataformas de evaluación parecidas, como Design Arena
- Ahí la gente vota por la mejor salida deseada en pruebas ciegas comparativas lado a lado
- Le gustaría hacer algo similar directamente dentro de archivos de Figma
- Incluyendo comentarios y señalamiento de problemas
- Debería permitir crear sets de prueba rápidamente, ejecutarlos de una vez, recibir 100 respuestas e iterar en 30 segundos
- Hoy todas las piezas existen, pero toma demasiado tiempo
El papel del diseñador en la generación de modelos
- Ha experimentado dos enfoques: entrenar desde cero vs. fine-tuning
- Al entrenar desde cero: la mayor contribución del diseñador es avisarle a la organización dónde están las necesidades más grandes y las fricciones más fuertes de los usuarios
- En Replit, entrenaron un modelo personalizado para errores de código comunes y simples en Python
- Más que en el entrenamiento mismo, participó en definir el problema y entender cómo aplicar el modelo entrenado al producto
- En fine-tuning: ya existe un modelo, un producto y evaluaciones, y se quiere mejorar el rendimiento
- Quien escribe prompts, evaluaciones y habla con usuarios tiene mayor claridad sobre si se están cumpliendo las expectativas
- Cuando la ingeniería de prompts llega a su límite, el siguiente paso es el fine-tuning
- El rol clave de traducción del diseñador es recordar las suposiciones del usuario
- Los ingenieros o diseñadores que trabajan muy de cerca con el modelo pueden olvidar que el usuario no conoce los detalles
- Hace falta usar el “tonto interior” para comunicar qué intentaría un usuario ingenuo que no conoce las características del modelo y dónde se trabaría
Consejos para diseñadores de productos de IA
- Lo más sostenible y de mayor impacto es invertir bastante tiempo por adelantado en entender de verdad las entradas y salidas del modelo
- Qué es el prompt, qué información del usuario entra, qué herramientas puede invocar y qué evaluaciones existen
- Desarrollar intuición sobre qué ocurre al ajustar esos controles
- No se debe convertir en un fabricante de UI para salidas que no se entienden en profundidad
- Si le dicen “el modelo da esto, diseña la interfaz”, puede hacerlo, pero no podrá proponer mejoras basadas en insights de usuario
- Además, quedará trabajando de forma demasiado reactiva a cambios futuros del modelo
- Hay que ser parte de la toma de decisiones sobre si una función nueva es realmente deseable, no solo un receptor pasivo
- Para diseñadores no familiarizados con código esto puede ser difícil
- Hace falta una interfaz como Langsmith o aprender a ejecutar directamente el entorno de desarrollo
Los casos de mayor impacto
- El agente de Replit: convenció al equipo de pedirle al usuario que verificara directamente si la aplicación generada funcionaba
- Al enfocarse en la ruta más simple de validación por parte del usuario, se ahorró mucho esfuerzo
- El lanzamiento de LaMDA (uno de los primeros LLM de Google): dedicó mucho tiempo a probar el modelo de distintas formas para ver qué funcionaba mejor
- En ese momento aún no lo llamaban “prompting”, pero intentaban que hiciera tareas distintas de forma confiable
- Un demo donde se podía hablar con Plutón o con una de sus lunas fue el resultado de descubrir, tras muchísimos intentos, lo que mejor funcionaba
- Sin experimentación amplia no habría sido posible elegir una estrategia de manera intencional
El prompting en diseño
- La pregunta “¿los diseñadores deben hacer prompting?” tiene una naturaleza distinta a “¿los diseñadores deben programar?”
- En programación, la respuesta es bastante verificable: ¿se puede construir XYZ con la técnica ABC? Preguntárselo a un ingeniero es bastante equivalente a saberlo directamente
- El comportamiento de los modelos de IA es inherentemente más subjetivo y más sutil
- No hay sustituto para entender ese material directamente y en profundidad
¿Sigue siendo diseño?
- Se trata de diseñar comportamientos, y puede que nunca quede perfecto, lo cual está bien
- Requiere una mentalidad distinta a la del diseño de UI, donde se controlan todos los píxeles y se recompensa la perfección
- Sigue implicando hacer mockups y usar herramientas de diseño
- En Figma, crea casos de evaluación, revisa salidas y corrige lo que se siente extraño
- Es algo casi terapéutico, como un fidget spinner
- Si le dan un mockup de un sitio web y 30 minutos, puede pasarse feliz corrigiendo la tipografía
- Es el tipo de trabajo que nunca termina mientras la función no se elimine, porque siempre se puede mejorar
Aún no hay comentarios.