Este es el complemento de "Dev o Diseñador, ¿Por Qué Elegir Si Puedes Ser Ambos?". Ese post trata sobre la decisión de carrera. Este trata sobre cómo se ve una vez que ya la tomaste. Las ventajas reales, los desafíos reales de los que nadie te advierte, y los patrones operativos que te mantienen lejos del burnout o de ser silenciosamente subestimado.
La mayoría de las descripciones de trabajo te piden ser una cosa. Diseñador. Developer. Desarrollador front-end. Investigador UX. La suposición organizacional es que estas son disciplinas separadas que colaboran a través de un handoff definido: diseño produce specs, desarrollo las implementa, QA valida. El modelo de línea de ensamblaje del software.
Nunca encajé limpiamente en ese modelo. Yo diseño la interfaz y luego la construyo. Pienso en el comportamiento del usuario mientras escribo TypeScript. Abro Figma y VS Code en la misma sesión. Por mucho tiempo pensé que esto era una desventaja: que estaba demasiado disperso para ser excelente en cualquiera de las dos. Más de una década después lo veo diferente. Pero tampoco voy a pretender que ha sido perfectamente positivo. Hay costos reales en este camino.
Las ventajas reales
Sin fricción de handoff
El handoff de diseño a desarrollo es una de las fuentes de desperdicio más caras y más subestimadas en los equipos de software. Llegan diseños que son técnicamente impracticables. Los developers implementan algo ligeramente diferente a lo diseñado porque un detalle no se especificó. Las revisiones van y vienen. Los casos borde no están cubiertos en el diseño así que el developer toma una decisión por su cuenta.
Cuando hago ambas cosas, esa fricción desaparece. Sé durante la fase de diseño si una interacción es factible y cuánto costará construirla. No diseño micro-animaciones que tomarán tres días implementar en CSS por un beneficio marginal para el usuario. Hago esos tradeoffs en tiempo real, con contexto completo. El resultado: lo que diseño, lo construyo. Lo que construyo, coincide con lo que diseñé.
Mejores decisiones técnicas
Entender principios de diseño cambia cómo escribo código. Cuando estoy arquitectando una librería de componentes, pienso también desde la perspectiva de un diseñador: ¿qué variaciones necesitará el equipo de diseño? ¿Qué estados, vacío, cargando, error, éxito, deshabilitado, requerirá cada componente? ¿Qué tokens de espaciado deberían exponerse como inputs vs hardcodearse?
He visto librerías de componentes construidas puramente por developers que son técnicamente limpias pero prácticamente inutilizables para diseño. Cada prop es un parámetro técnico, no una decisión de diseño. Cada variación requiere un cambio de código. Una perspectiva híbrida significa que construyo con el caso de uso de diseño en mente desde el principio.
Prototipado más rápido
Cuando necesito validar una idea de diseño, no la mockeo en Figma y espero a que un developer la esboce. Escribo un prototipo en Angular. Me toma aproximadamente el mismo tiempo que me tomaría construir un frame de alta fidelidad en Figma, y el resultado es interactivo, maneja casos borde reales, y puede darse a usuarios reales para testing. El feedback que obtengo es mucho más cercano al comportamiento real.
Los desafíos reales
El cambio de contexto es costoso
Los modos cognitivos de diseño y desarrollo son genuinamente diferentes. El pensamiento de diseño es expansivo: estás generando posibilidades, considerando usuarios, explorando sistemas visuales. El pensamiento de desarrollo es convergente: estás estrechando hacia una implementación correcta, resolviendo ambigüedad, gestionando restricciones.
Cambiar entre estos en el mismo día es agotador de una manera específica. He aprendido a agruparlos. Hago trabajo de diseño por la mañana cuando mi cerebro está fresco y más generativo. Hago desarrollo en bloques enfocados cuando me he asentado en un modo concentrado. Mezclarlos en una sola sesión produce resultados mediocres en ambos.
Ser subestimado en ambos campos
Esto es lo que nadie te dice: cuando haces ambas cosas, algunos especialistas en cada campo van a descontar sutilmente tu expertise en el suyo. Los diseñadores puros pueden asumir que tu sentido del diseño está comprometido por el pragmatismo técnico. Los developers puros pueden asumir que la calidad de tu código sufre porque pasas tiempo en preocupaciones 'blandas' de diseño.
He estado en reuniones donde un diseñador UX puro está explicando algo sobre flujos de usuario que yo conozco muy bien, pero como mi título dice desarrollador me posicionan como la persona técnica que necesita ser educada en UX. Es una experiencia frustrante. La solución no es pelear en la reunión: es establecer credibilidad a través del output con el tiempo. Pero toma más tiempo del que debería.
La pregunta de la profundidad
Hay momentos de duda genuina sobre la profundidad. ¿Soy tan hábil en Angular como alguien que ha dedicado el 100% de su carrera a ello? ¿Soy tan hábil en investigación UX como alguien que se ha enfocado exclusivamente en eso? Probablemente no, en términos absolutos puros. Lo que tengo en cambio es un tipo diferente de profundidad: profundidad en la intersección. Entiendo cosas que los especialistas de cualquier lado no ven porque no han vivido en la superposición.
Si eso es más o menos valioso depende enteramente del contexto. En una organización grande con equipos dedicados de diseño y desarrollo, la profundidad pura puede ser más valorada. En un equipo de producto que necesita a alguien que pueda moverse rápido a través de toda la capa de interfaz, el híbrido es a menudo la persona más valiosa en la sala.
Cómo era el rol híbrido en BMO
En BMO estuve en un rol de Senior Software Developer (Angular). Mi background en UX/UI se manifestaba de maneras específicas y prácticas: levantaba los problemas de accesibilidad en un diseño antes de empezar a construirlo. Trabajaba dentro del design system del banco, que pertenecía a otro equipo. Cuando llegaba un diseño con estados faltantes, los señalaba proactivamente en lugar de implementar una spec incompleta. Revisaba componentes tanto con un lente de calidad de código como de consistencia visual.
No es un split 50/50. En una gran empresa, la función de diseño está más separada. Pero el background moldea cómo trabajo incluso cuando estoy puramente en modo developer, y eso me hace un mejor colaborador con el equipo de diseño que alguien que nunca ha trabajado en su lado de la mesa.
Tácticas operativas que realmente importan
Después de años operando en esta posición, estas son las prácticas específicas que me han mantenido efectivo en lugar de agotado. Son tácticas, no filosofía.
- Agrupa tus modos. Trabajo de diseño por la mañana cuando el cerebro es generativo. Implementación en bloques de la tarde cuando es convergente. Mezclarlos dentro de una sola hora produce resultados mediocres en ambos.
- Señala tu rol principal en cada reunión. Los diseñadores puros y los developers puros descontarán sutilmente tu expertise en su campo si no lo haces. Abre con aquello para lo que te contrataron, luego deja que la segunda habilidad aparezca a través de lo que detectas que ellos pasaron por alto.
- Mantén un portfolio público que muestre ambos. La mayoría de los candidatos muestra uno u otro. Mostrar wireframes con rationale junto a código de producción es la señal más clara de que el híbrido es real, no aspiracional.
- Elige entornos que recompensen la superposición. Los equipos de design systems, las startups de producto, las consultoras boutique y las empresas de herramientas para developers pagarán por el híbrido. Las grandes empresas con escaleras de especialistas profundas no lo harán, excepto en roles específicos como Design Engineer o UI Engineer.
- Pon un límite de tiempo a la exploración de nuevas herramientas y frameworks en ambas disciplinas. El híbrido se amplía más rápido que cualquier especialista, lo que significa que puedes terminar siendo superficial en todas las direcciones. Un presupuesto fijo por trimestre evita que la exploración se coma la profundidad.
La interfaz entre diseño y desarrollo es donde viven los problemas más interesantes. Decidí vivir ahí.
Referencias
- Nielsen Norman Group. From Confrontation to Collaboration: The Developer-Designer Relationship. https://www.nngroup.com/articles/developer-designer-relationship/
- IDEO. Design Thinking. https://designthinking.ideo.com/
- Smashing Magazine. Bridging the Gap Between Designers and Developers. https://www.smashingmagazine.com/2021/10/bridging-gap-between-designers-developers/