Si algo ha cambiado drásticamente en el ecosistema laboral contemporáneo, es la cantidad de títulos que uno se puede adjudicar en un afán de describir sus cualidades y atributos profesionales.

Antes era más sencillo. El título era el de la carrera que tenías, pero gracias a la economía de escala, ahora lo que vale no es lo que sabes, es lo que puedes hacer. Esto es aún más grave en un campo como lo es el Diseño, el cual no es un territorio exclusivo de aquellos que estudiaron una carrera con “diseño” en el título. Dentro de UX abrimos los brazos a diseñadores industriales, ingenieros, psicólogos, estudiantes de literatura, filósofos y tantos campos más.

Seguramente en LinkedIn has visto todo tipo de títulos. Desde lo que se pusieron UX/UI Designers (escoge uno, porfis) hasta los que nos llamamos UX Architects, Design Strategists, Service Designers, CX Designers, UX Ops, IXD, UX Researcher, UX Writer… en fin, títulos hay muchos. Sin embargo hay uno en particular que cada vez empiezo a ver más en mi feed y que creo que es importante comenzar a aclarar y estandarizar antes de que se preste a las mal interpretaciones por las que nuestra disciplina ha pasado desde su masificación: Diseñador de Producto.

Comencemos por lo básico, por entender el equipo al que este diseñador pertenece.

Entendiendo al “equipo de producto”

La revolución tecnológica y la masificación de las herramientas de desarrollo nos ha permitido crear una capacidad de generación de productos digitales que es equiparable a la revolución industrial de principios del siglo pasado. Con la masificación de herramientas tecnológicas viene también una simplificación en el proceso productivo.

El desarrollo que antes solía tomar 3 o 4 años, ahora se puede hacer en 2 o 3 meses. De hecho, la mayoría de las empresas de software sabe que tener un horizonte de desarrollo de más de 6 meses puede causar problemas como que haya librerías depreciadas, cambios en frameworks de implementación, correcciones de bugs en sistemas operativos y varios riesgos más que conllevan que el desarrollo no puede tener ciclos de desarrollo tan largos.

Básicamente, hemos creado líneas de producción de software, que al igual que con sus contrapartes físicas, en vez de hacer esfuerzos titánicos construyendo piezas de software monumentales de manera artesanal, más bien tenemos una secuencia de pasos que incrementalmente da pie a lo que ahora podemos conocer como un producto, que a estas alturas puede ser una app, un servicio, una página, un algoritmo, un visualizador y prácticamente cualquier cosa que pueda ser desplegada en una pantalla.

Este proceso implica que tenemos roles especializados que se encargan de partes específicas del proceso, en vez de supervisar el producto en su totalidad. Por lo general los equipos de producto tienen algunos de estos roles:

• Product Manager: Persona “responsable” del producto en su totalidad, que se asegura de la viabilidad de las entregas y que todo esté funcionando.
• Product Designer: Persona responsable del aspecto estratégico del producto, de entender qué se va a desarrollar y qué objetivo debe cumplir.
• Product Developer: Persona responsable del aspecto táctico del producto, de entender cómo producirlo y cómo hacer eficiente el proceso.

Obviamente hay muchos títulos dentro del desarrollo de producto, pero realmente todos tienen que pertenecer a uno de estas tres “áreas”. O eres parte del equipo que se encarga de ver por el proceso, de la estrategia o de la entrega.

Si hiciéramos el símil con una línea de producción quedaría así:

• El Product Manager es el que supervisa inputs y outputs del proceso, tiene que asegurarse que siempre haya materia prima, que siempre haya demanda de mercado y que los sub-equipos de estrategia e implementación siempre tengan todo lo que necesitan para funcionar. Es una supervisión general de la salud del producto y el proceso que lo entrega.
• El Product Designer es el que tiene que decidir el tamaño y el material que se utilizará, tiene que diseñar los componentes para que puedan ser ensamblados en una línea. Obviamente también es el encargado de asegurarse que lo que sea que se esté diseñando cumple con las expectativas del cliente y del negocio.
• El Product Developer es experto en conocer cada una de las máquinas que compone la línea de producción. Sabe operarlas, diagnosticarlas, identificar problemas y resolverlos. También está en constante comunicación con el Product Designer para poder encontrar eficiencias en el proceso y hacerle recomendaciones sobre mejoras al diseño.

Las tres partes son fundamentales, porque cada una tiene una responsabilidad definida y algo que los obliga a rendir cuentas. Si el producto tiene defectos en el ensamblaje, es responsabilidad del Designer ajustar el diseño. Si el producto tiene defectos de fabricación, el Developer tiene que revisar si alguna máquina no está funcionando como debe. Por último, si el producto no se vende, es responsabilidad del Product Manager el identificar qué se debe cambiar en la estrategia del producto para obedecer al cambio de demanda en el mercado.

¿Qué hace realmente un Diseñador de Producto?

Lo más importante es entender que el Diseñador de Producto es un elemento ESTRATÉGICO. Por definición, el Diseñador de Producto no genera entregables que van de cara al cliente.

Si, un diseñador de producto puede, por ejemplo, diseñar la imagen de un empaque, o la etiqueta. Pero esa etiqueta va a ser impresa por un Developer. Básicamente, siempre habrá al menos un paso intermedio entre el Diseñador y el entregable final, porque alguien se tiene que asegurar que ese entregable de Diseño de traduzca en algo final. En productos digitales, el Designer puede hacer la interfaz, pero finalmente el encargado de implementar será un Developer, que lo subirá al servidor, montará el HTML, le pondrá tags, eventos, links a los botones, entre muchas otras cosas que ya no son responsabilidad directa del Diseñador.

Como responsable del aspecto estratégico, el Product Designer realmente tiene que ver por dos cosas:

• Que lo que se esté haciendo cumpla con los objetivos de negocio y las necesidades del cliente.
• Que sus entregables sean posibles de implementar por el equipo responsable de la ejecución.

Voy a traducir estas dos grandes responsabilidades en algunas “cualidades” que distingue al Diseñador de Producto de otros tipos de roles de diseño:

1. El Diseñador de Producto es un generalista

Una de las habilidades más valiosas de un Diseñador de Producto es la capacidad de poder entender cómo funcionan distintos perfiles, industrias, plataformas y herramientas. Tiene que tener la capacidad de hacer entendimiento analítico y cuantitativo de un reporte de gastos o de un funnel, así como poder entender cualitativamente las expectativas y necesidades de un mercado objetivo o de indicadores macroeconómicos que indiquen un cambio en los patrones de consumo de una industria.

Ser un Diseñador de Producto con experiencia en una sola industria, en un solo canal, con un solo tipo de metodología de implementación limita la capacidad de acción y de herramientas que puede tener a su alcance para resolver un problema específico. Eso no quiere decir que no tengas tus industrias, productos o segmentos favoritos o los que entiendas mejor. El punto es que un Diseñador debe tener la CAPACIDAD de poder trabajar en territorios poco familiares , con segmentos o mercados poco comunes, porque tiene una sólida experiencia aplicando diversas metodologías de diagnóstico y análisis para determinar una solución óptima, sin excusa a la poca familiaridad.

Esta cualidad es mucho más importante cuando el resto del equipo es especialista únicamente en una industria o segmento. Si el Product Manager o el Product Developer solo han trabajado en un tipo de producto, el Diseñador es el responsable de traer mejores prácticas de otros segmentos o de identificar oportunidades que el resto del equipo puede no ver.

2. El Diseñador de Producto sabe traducir negocio a humano.

La diferencia fundamental entre Diseño y Arte es que el Diseño debe resolver un problema. Así que por definición, todos los que hacemos diseño debemos enfocarnos en identificar qué problema vamos a resolver.

Para poder identificar qué problema vamos resolver, un Diseñador de Producto debe ser experto en entender tanto los problemas que puede enfrentar un negocio, como los problemas que puede enfrentar un ser humano.Esta es una gran diferencia con los diseñadores “puros” de UX. Un Diseñador de Producto debe saber leer un reporte financiero, debe conocer indicadores de competencia, macroeconómicos, debe entender cómo funciona una estrategia de comunicación, cómo funcionan los canales de distribución. Debe saber qué es posible hacer en Android, en Apple o en Web, debe estar familiarizado con tecnologías emergentes, startups y entidades regulatorias locales e internacionales.

Así como un Diseñador de Producto debe saber qué plástico puede ser tóxico o qué es posible realizar con una máquina dentro de la línea de producción, un Diseñador de Producto digital debe conocer qué es posible hacer con los frameworks que utilizan sus desarrolladores. Debe conocer tiempos, implicaciones, impactos y riesgos de cada recomendación y ajuste que se hace.

No solo se trata de saber qué color tiene que ser un botón. El Diseñador de Producto conoce perfectamente el mercado y las alternativas que tienen los consumidores, así como los modelos de negocio detrás de esas alternativas. Sabe cuánto cuestan, por qué cuestan eso y el impacto que eso puede tener en su producto. El Diseñador de Producto es dueño de la visión del producto actual y mientras que los resultados del producto mismo y la visión a largo plazo son responsabilidad del Product Manager, es responsabilidad del Designer entender cómo llegar a esos resultados de la mejor manera e informar a los demás equipos de las recomendaciones para hacerlo.

Un Diseñador de Producto que no puede explicar el modelo de negocio de su producto o que no entiende la contribución que hace una pantalla o un botón al modelo de negocio, no es un Diseñador de Producto que genere valor a su equipo. Nuestro trabajo no es hacer un Homeromóvil con todo lo que quiere tanto el negocio como el usuario, nuestro trabajo es hacer un producto que resuelve una necesidad dentro de limitantes de costo, tiempo y mano de obra que tenemos disponible.

3. El Diseñador de Producto es parte de un proceso, no es el centro de él

La cantidad de veces que he escuchado “es que mi equipo no me hace caso” o “es que mi jefe dice que no le importa mis hallazgos” es una de las principales razones por las que estoy escribiendo esto.

Un Diseñador de Producto, como ya explicamos al principio, es parte de un proceso, es una pieza dentro de la línea de producción. Cómo el Diseñador adquiere una visión de necesidades de los clientes y de los objetivos de negocio, es muy normal que a veces sintamos que nosotros somos el centro de la propuesta de valor de un producto y nos olvidamos que hay otros roles que también tienen responsabilidades, necesidades y problemas a resolver dentro del proceso de producción.

Por ejemplo, si está padre que Slack haya actualizado su Sistema de Diseño y que nosotros deberíamos hacer lo mismo, pero si el equipo de Ingeniería actualmente está batallando con migrar toda su infraestructura de Cisco a AWS, tu sugerencia ahorita no es de prioridad, porque independientemente del Sistema de Diseño, si no tenemos back no existimos, punto. En Startups me tocaba mucho ver que había que enfocar esfuerzos a la siguiente ronda de inversión, por lo que había que preparar una serie de documentos que relegaban la prioridad de algunos esfuerzos tácticos, pero un buen Diseñador de Producto debe saber que sin inversión no hay producto.

Si tu equipo “no te hace caso” ese es el problema que tienes que resolver primero, porque lo primero que uno debe asumir es que no te están haciendo caso porque hay algo más prioritario que atender que probablemente podrías estar ayudando tú. Siguiendo con el ejemplo en la línea de producción, a lo mejor el Diseñador quiere agregar una cámara más al dispositivo, pero el equipo de ingeniería está fallando en lograr que el equipo sea a prueba de polvo, lo que quiebra las pantallas. Un Diseñador de Producto no solo se cruza de brazos y se queja de que no quieren su brillante idea, porque los clientes lo necesitan. Hay puntos mas cruciales que requieren de su intervención y participación que, además, son su responsabilidad.

El equipo de ejecución depende de un buen trabajo de Diseño, porque ellos van a enfrentar sus propias dificultades llevando tu trabajo a un entregable final. Si además tienen que lidiar con Diseño mal hecho, no se está haciendo un buen trabajo de Diseño de Producto.

4. El Diseñador de Producto es parte del equipo y sus entregables deben servirle a los demás.

Los usuarios de tu trabajo de diseño es el equipo de Product Management y el equipo de Product Development, no Dribble y no Behance, ciertamente no suelen ser otros Diseñadores. De la misma manera en la que eres parte del equipo y tu principal responsabilidad es para con tu producto, tus entregables deben ser utilizables para el equipo que debe interpretar tu trabajo estratégico y generar un entregable táctico.

Imaginemos que estoy diseñando una pieza para una línea de producción. Hago un sketch muy bonito, le pongo colores, fondos con gradientes. Todo super bonito, recibe muchos likes en #DesignTwitter. Pero tu equipo de ingeniería seguramente lo va a ver y no va a entender qué hacer con eso.

Dependiendo de la capacidad técnica de tu equipo, lo más probable es que necesiten esquemas más detallados. Va a depender de ti entender si tienes que crear una librería o un Sistema de Diseño con componentes que ellos puedan utilizar, dónde sepan tamaños de componentes, o pesos, colores en hexadecimal o incluso si hay ya librerías de CSS desarrolladas para saber qué se puede utilizar y qué no.

Un gran ejemplo de esto es en la industria automotriz, en dónde las interfaces suelen diseñarse con 8 o 10 años de anticipación, porque adaptar una línea de producción de autos es un proceso sumamente caro, en dónde tiene que aprovecharse al máximo el material y las piezas que existen. Por eso hay armadoras que aprovechan el mismo tren motriz para toda su gama o los mismos motores. Es por eso que hasta el mismo Tesla se ha dado cuenta que escalar cosas en una línea de producción física es mucho, mucho más difícil que escalar en una línea de producción digital.

Pues, justamente, es trabajo del Diseñador de Producto contemplar todas estas limitantes del equipo de implementación. Aprovechar las herramientas que se tienen y hacer un plan estratégico para arreglar lo que no funciona y agregar valor en iteraciones subsecuentes. Conocer el impacto de agregar nuevas funcionalidades y saber perfectamente qué suma valor y que no, para poder comunicarlo de manera clara y con los entregables necesarios para que el resto del equipo pueda lidiar con los retos de cómo implementar tu visión.

5. El Diseñador de Producto posee el conocimiento, pero elige qué es lo que los demás deben saber.

Si, yo se que es fascinante descubrir que la mayoría de los usuarios no tienen el problema que negocio cree que tienen, o que la mayoría de los usuarios no ven a tu principal competidor como una alternativa. Cuando llevaba Redes Sociales era fascinante ver que había publicaciones que nadie esperaba que tuvieran éxito y que la gente recibía muy bien.

Yo sé lo personalmente fascinante que puede ser descubrir todas esas oportunidades de oro, esas cosas que pueden resolver todos los problemas mundiales en 5 minutos. Sin embargo, un buen Diseñador de Producto entiende perfectamente qué es lo que debe saber él y qué de ese conocimiento deben tener los demás, y eso es porque entiendes las prioridades y necesidades del resto de tu equipo.

Es trabajo del Diseñador ser dueño de la solución a implementar, pero es trabajo del equipo de Implementación asegurarse que esa solución se implemente correctamente y cumpla su objetivo. Tal vez tu desarrollador ahorita no necesita saber que todos tus usuarios son víctimas de un sesgo de anclaje como resultado de una política pública de hace 4 décadas que generó un impacto cultural que derivó en una mala interpretación de un concepto clave en la estrategia de tu producto… Lo único que quiere saber es qué debe decir el texto del micro formato de Facebook para tu sitio.

Un buen Diseñador de Producto sabe plasmar todas esas oportunidades y necesidades potenciales en documentos estratégicos. Sabe definir cuándo es el momento oportuno para agregar nuevas funcionalidades o para esperar a medir el impacto de una nueva implementación, sabe distribuir el conocimiento de su equipo para que todos sepan qué hacer y por qué lo están haciendo. Sabe que el equipo no necesita saber todo, todo el tiempo y en especial, sabe traducir ese conocimiento en lenguaje de producto, no en lenguaje del usuario.

Por ejemplo. Tu identificaste una importante área de oportunidad en la percepción de la experiencia de tu producto. Tu trabajo como Diseñador de Producto no es presentarle esa oportunidad al equipo de implementación, es traducir esa oportunidad en términos del producto, es decir, si hay que generar una campaña con un mensaje en particular, o una idea de una serie de pantallas de onboarding, tal vez en una campaña de correos para los usuarios actuales. Básicamente, para que el equipo de producto se pueda comunicar, debe hablar producto. Si tú hablas usuario y el resto del equipo habla otra cosa, jamás se va a generar una comunicación en común.

Espero que estos consejos te ayuden a entender mejor qué es Diseño de Producto y que habilidades es fundamental que desarrolles para poder identificarte con uno. Ser un Diseñador de Producto es una gran responsabilidad, que más allá de lo rimbombante y bonito que suena el título, implica que se te adjudicará en gran parte el éxito o fracaso del producto, porque un mal Diseño, que implica una mala estrategia, siempre tendrá repercusiones que pueden generar pérdidas millonarias o hasta el fracaso de una empresa completa.

Felices trazos.