¿Cuánto conocimiento técnico necesita realmente un diseñador UX? Una exploración sobre la frontera entre diseño y desarrollo.
Durante años he visto el mismo patrón repetirse.
Diseñadores que producen interfaces impecables, pero que llegan a desarrollo incompletas. Desarrolladores que responden con "eso no se puede". Retrabajo. Frustración. Decisiones que nadie termina de defender.
La pregunta es sencilla: ¿qué debería entender un diseñador sobre tecnología para colaborar mejor sin convertirse en desarrollador?
No busco formar programadores. Busco entender dónde termina el diseño y dónde comienza una mejor conversación.
La mayoría de los problemas que aparecen entre UX y desarrollo no son conflictos de personas. Son problemas de contexto.
Quizá un diseñador no necesita escribir una API. Pero tal vez sí debería entender qué es una API. Quizá no necesita administrar una base de datos. Pero sí comprender que los datos no aparecen por generación espontánea. Tal vez la alfabetización técnica sea una forma de empatía.
Hoy apareció una idea interesante: los Protocolos de Decisión UX. Todavía no sé si terminarán siendo una pieza central o una ocurrencia que desaparecerá dentro de dos semanas.
Por ahora siento que podrían convertirse en uno de los elementos más distintivos del proyecto, pero todavía es demasiado pronto para afirmarlo.
También quedó pendiente definir el nombre oficial de la metodología y cómo medir el avance entre niveles de madurez.
✅ Confirmado El proyecto tendrá un Manifiesto como base. El aprendizaje se organizará mediante un Modelo de Madurez. La voz editorial será conversacional y basada en preguntas.
🧪 Hipótesis Los Protocolos de Decisión UX podrían convertirse en el artefacto más diferencial del proyecto.
❓Pendiente Definir el nombre oficial de la metodología. Diseñar el primer Protocolo de Decisión. Establecer criterios para evaluar el avance entre niveles de madurez.
Se adopta una voz editorial conversacional. Cada capítulo comenzará con una situación real y una pregunta antes de introducir conceptos técnicos.
Los conceptos técnicos generan mayor aprendizaje cuando se presentan como conversaciones reales de trabajo y no como clases teóricas.
Inicialmente pretendia hacer una guia, incluso n curso. Descubri que primero necesito un manifiesto.
- Anticipar restricciones. - Deducir retrabajo. - Defender mejor sus decisiones. - Participar en conversaciones más interesantes. - Construir soluciones más realistas- - Aumentar su influencia dentro del equipo.
Temas pendientes de explorar: modelos mentales para diseñadores, APIs para gente que diseña, estados y flujos, qué debería saber un UX sobre bases de datos, arquitectura explicada sin trauma, design systems y reutilización, cómo discutir con desarrollo sin que sea un debate religioso, y la frase "eso no se puede" con sus múltiples traducciones.
La palabra "framework" me genera cierta incomodidad. Suena demasiado terminada. Por ahora prefiero verlo como un experimento — una especie de mapa para responder una pregunta más grande: ¿cómo dejar de ser un turista dentro del proceso de construcción del producto?
Después de trabajar durante años con sistemas complejos, empiezo a sospechar que muchas fricciones entre UX y desarrollo no provienen de diferencias de criterio, sino de diferencias de contexto. Quizá el problema nunca fue "los desarrolladores no entienden UX". Tal vez los diseñadores tampoco entendemos del todo cómo se construyen las cosas que dibujamos.