Una guía práctica para el diseño de código en 2026
Alguien puso un enlace en el hilo, ni la plataforma ni el archivo Figma, en el que puedes hacer clic e interactuar. La conversación pasa de opiniones a comportamientos. esto sigue sucediendo en polvo. Hemos estado experimentando con prototipos como nuestros artefactos de diseño preestablecidos. Las preguntas que nos impulsan son:
¿Qué deberían construir los diseñadores para ayudar a los equipos a tomar decisiones más rápido y al mismo tiempo elevar los estándares de calidad y reducir el desperdicio de implementación?
Aún no tenemos una respuesta final. Este artículo es un informe de campo: lo que hemos probado hasta ahora, lo que parece funcionar y lo que aún está en el aire.
Ejecutar un proyecto de diseño en Dust
Describiré el flujo de trabajo en el orden en que suele ocurrir. No es un proceso estricto, sino más bien una ruta preestablecida que hemos estado probando.
Del “pensar” al “darse cuenta”
Después del análisis inicial y la fase de boceto rápido, cuando necesito tener una idea y probarla, no abro Figma.
Crear un parque infantil
Abro mi entorno de desarrollo, extraigo la última versión de nuestro repositorio y hago una rama. Luego le pido al agente que construya un nuevo prototipo y le describo lo que estoy intentando hacer.
Iterar comportamiento, no imágenes.
Mi principal preocupación en este momento es probar la idea y ver si la interacción se mantiene. Construiré pequeños flujos, crearé prototipos de transiciones y realizaré comprobaciones de integridad en partes a menudo ocultas de pantallas estáticas (cambios de estado, condiciones de error, movimiento, estados vacíos, conceptos básicos de teclado/navegación/accesibilidad).
Puedo utilizar fácilmente datos falsos reales. Pregeneramos una gran cantidad de información (perfiles de personas, imágenes, nombres, correos electrónicos, listas de archivos y carpetas, conversaciones completas…). Si necesito otros nuevos, solo me lleva unos segundos generarlos.
Todo se ejecuta en el navegador, por lo que siempre veo la experiencia a escala 1:1 (a nivel de usuario). Lo que veo es lo que obtiene el usuario.
Utilice el sistema de diseño por defecto, doble cuando sea necesario
En esta etapa, no optimizaré los efectos visuales. Empiezo con el comportamiento y la estructura; una vez que la tendencia persiste, el estilo puede seguir. Este agente se construyó de forma natural en nuestro sistema de diseño (Sparkle), por lo que el prototipo reutilizó nuestros componentes y tokens desde el principio.
Si necesito un nuevo componente o un ajuste, lo hago en una rama y sólo entonces decido qué debería convertirse en un trabajo de sistema de diseño “real”, en lugar de simplemente una exploración local.
https://medium.com/media/56ec6445356d38c3fe402d4ed71afcff/href
Compartir temprano
Compartir es simple: envío la rama a GitHub y abro un PR. Mi prototipo se implementa automáticamente y puedo compartir una URL fácil de abrir. GitHub es el entorno natural para los ingenieros, por lo que la retribución ocurre donde está el trabajo.
Convergencia: reducir las diferencias
A medida que el ciclo iterativo se estrecha y me acerco al resultado final, empiezo a centrarme en:
- Presentamos los nuevos componentes adecuados (nada más)
- Realice los cambios mínimos necesarios en Sparkle
- Limpiar modificaciones inesperadas
Transferencia vía PR
La transferencia del proyecto es sencilla: se realiza a través de relaciones públicas.
Puedo señalar qué ha cambiado en el sistema de diseño, qué es necesario mejorar y qué son “simplemente prototipos”. Los ingenieros pueden reutilizar componentes directamente y utilizar el código del prototipo como referencia, porque se ejecuta en la misma pila con los mismos componentes.
defecto
Antes de comenzar a configurar, nos encontramos con algunas compensaciones honestas:
- Sigue siendo una caja de arena. A menos que lo simulemos, no reproducirá de forma natural retrasos, estados de carga ni peculiaridades del backend del mundo real.
- La retroalimentación no es perfecta.. Los comentarios de vista previa de Vercel pueden ayudar, pero son un poco complicados para nosotros: las capturas de pantalla + Slack siguen siendo los valores predeterminados.
- Ocasionalmente pagará un “impuesto de código”. La mayoría de las veces esto es más rápido que el modelo, pero ocasionalmente pierdes 30 minutos debido a problemas tontos con el entorno o las herramientas. Muchas veces, el resumen de la pantalla del prototipo todavía es vago, o lo que estamos pidiendo aún no es factible.
- Puede causar un pulido prematuro.. Debido a que parece tan rápido, es fácil quedar atrapado en críticas antes de que se resuelva la interacción principal.
- claridad de entrega. Los ingenieros no siempre tienen claro qué deben reutilizar directamente y qué es la creación de prototipos.
configuración
El polvo se ejecuta en React en monorepo. Nuestro sistema de diseño (Sparkle) también está ahí. Sparkle nos ofrece dos lugares de trabajo complementarios:
- libro de cuentos Para construir y documentar componentes (variaciones, interacciones, regresiones visuales) individualmente. Este es nuestro catálogo de componentes.
- patio de juegos Sólo una pequeña aplicación Vite anidada en Sparkle. Es un servidor de desarrollo rápido que se inicia rápidamente, se actualiza instantáneamente mientras se edita y sigue siendo liviano.
Puntos clave: Ambos entornos utilizan las mismas fuentes Sparkle y estilos Tailwind, por lo que los ajustes preestablecidos del prototipo reutilizan componentes y tokens reales.
Comparte fácilmente con Vercel
Vercel es una plataforma en la nube que implementa automáticamente ramas de GitHub en URL instantáneas que se pueden compartir. Para nosotros, si el nombre de la sucursal contiene Sparkle, Vercel implementa automáticamente Storybook y Playground y publica un enlace de vista previa en el PR, por lo que compartir un prototipo ejecutable es básicamente instantáneo.
Hay una cosa que aún no hemos probado: llevar la verdadera interacción de la IA a los prototipos: streaming, comportamiento de los agentes, flujo conversacional. Dado que Dust es un producto de inteligencia artificial, esta es una brecha significativa en nuestro entorno actual. La función sin servidor de Vercel podría ser una forma de desactivarla.
herramientas de codificación
La ventaja de esta configuración es que casi todas las herramientas de codificación de IA funcionarán. Claude Corder, antigravedad, código . Mi herramienta preferida suele ser cursor (para creación de prototipos), pero puedo moverme libremente entre ellos.
Diferencias significativas: lindoque uso y amo mucho en mis proyectos personales, pero aún no combina bien. Por razones de simplicidad, no manejará repositorios tan complejos como el nuestro, ni admitirá la colaboración git de nivel profesional que necesitamos.
¿Qué pasa con Figma?
No crea en esos pegadizos titulares que dicen “RIP Figma”. Figma no se ha ido para nosotros. Todavía lo utilizamos para mapear viajes, esbozar procesos y generar ideas; aguas abajo para gestionar recursos visuales e ilustraciones.
Ocupa un segundo plano en el medio: los pasos que convierten las ideas en lo suficientemente concretas como para ser evaluadas. Ayuda que nunca hayamos pensado en Figma como la verdadera fuente del producto o sistema de diseño. La verdad está en el código.. Esta es una enorme ganancia potencial de eficiencia cuando se pasa primero a la creación de prototipos.
Una nota sobre Figma Make: todavía no nos ha convencido en comparación con nuestra propia configuración. Make está diseñado para producir código a partir de un modelo, lo cual tiene sentido si el modelo es su punto de partida. Pero si primero pasa a la creación de prototipos, no encajará bien en su código base existente.
La siguiente pregunta es: ¿Deberían los diseñadores trabajar en código?
Detrás de toda esta discusión está el viejo debate sobre la alfabetización en tecnología de diseño. ¿Deberían los diseñadores codificar? ¿Hasta qué punto? Esta es mi opinión actual.
Creencia n.º 1: la alfabetización técnica es una habilidad de diseño
Soy diseñador industrial de formación. En diseño industrial, comprender los materiales no es “bueno”. Si no sabes cómo se dobla el plástico, cómo se comporta el aluminio o cómo las limitaciones de fabricación afectan la forma, puedes diseñar un objeto que se vea bien en 3D pero que sea un asco en la mano.
Los productos digitales también se construyen a partir de un material: código de programación. La alfabetización técnica no significa necesariamente codificar, sino comprender cómo se comportan los sistemas digitales y por qué.
Creencia n.º 2: los diseñadores que trabajan con código pueden mejorar la calidad y la velocidad
Tener diseñadores trabajando en código puede ser un verdadero acelerador: circuitos de retroalimentación más estrechos, menos transferencias y menos desalineación entre lo que diseñamos y lo que entregamos.
El problema es que este enfoque no se escala de forma predeterminada. A medida que una organización crece, su oferta de productos se expande, su código base se vuelve más complejo y la fricción aumenta. Contratar diseñadores que puedan diseñar a escala y hacer contribuciones significativas al código de producción no es una estrategia central.
Creencia n.° 3: La relación costo-beneficio de la “codificación de diseñador” ha cambiado
La inteligencia artificial está cambiando el juego de tres maneras:
- Es más fácil. La “necesidad de saber” se está reduciendo y el costo del aprendizaje está cayendo rápidamente.
- Es más rápido. Lo que antes tomaba horas ahora toma minutos. Una vez que tenga una línea de base ejecutable, podrá explorar cambios, estados e interacciones a una velocidad que haga que los modelos estáticos parezcan elevados.
- Es más poderoso. La cantidad que se puede construir con capacidades limitadas es asombrosa: procesos interactivos completos, componentes funcionales, prototipos reales.
No fingiré que esto no requiere ningún conocimiento. Este no es el caso. Pero la relación costo-beneficio se invierte: lo que se puede hacer, la rapidez con la que se puede hacerlo, hace que sea difícil justificar no esforzarse por adquirir las habilidades mínimas requeridas.
¿Cómo se ve el futuro?
Nuestro siguiente paso es cerrar la brecha entre el prototipo y la implementación. Hoy en día, los diseñadores rara vez realizan cambios directamente en el código de producción. Ejecutar una instancia nativa de Dust es pesado y pasar a un entorno de prueba es demasiado lento para iteraciones estrictas.
Esta situación cambia muy rápidamente. Más sobre esto pronto, pero si tienes curiosidad, aquí está. Avances tecnológicos en los que estamos trabajando.
ceremonia de clausura
Sigo volviendo a ciclos históricos más largos. El diseño como práctica diferenciada realmente tomó forma cuando la producción en masa separó un rol que antes pertenecía a una sola persona: el artesano que podía pensar, fabricar y vender objetos. Una vez que la fabricación va más allá del taller y esos roles se fragmentan, se necesita algo que pueda fluir entre las personas y las disciplinas.
Esa cosa es más que una simple forma bonita. esto es unObjetivo: un dibujo, un plano, un conjunto de intenciones ligadas a realidades técnicas. En otras palabras: un modelo del objeto, representado en un formato compatible con la producción.
El diseño de productos digitales hereda esta lógica. Modelos estáticos, especificaciones, procesos: todos ellos son versiones de la misma iniciativa: traducir la intención en un plan que otros puedan implementar.
Pero cuando la codificación (y la creación de prototipos) se vuelve más fácil, no sólo desarrollamos planes más rápido. Estamos recuperando la capacidad de modelar directamente.
Más parecido a la arcilla que al dibujo: das forma, pruebas, sientes, ajustas, a través de un circuito de retroalimentación inmediata. Los artefactos ya no son descripciones de cosas. Comienza a convertirse en una cosa, o al menos en una parte funcional de ella.
El diseño está pasando de experiencias de planificación a modelado: más cerca de la realidad, más temprano y con ciclos de retroalimentación más estrechos.
Investigación de campo: los prototipos son mejores que los modelos Publicado originalmente en colectivo de experiencia de usuario En Medium, la gente continúa la conversación destacando y respondiendo a esta historia.
