Product Academy 4 THIGA Spain

PRODUCT ACADEMY VOL 4
EL PRODUCT
DESIGN
EN ORGANIZACIONES CON PRODUCTOS DIGITALES
Product Academy
El Product Design
en organizaciones con productos digitales
1
ÍNDICE
Prólogo ......................................................................................................... 3
Acerca de Thiga............................................................................................. 7
Los autores ................................................................................................... 9
Prefacio........................................................................................................10
Introducción................................................................................................11
Capítulo 1: ¿Qué es un Product Designer?................................................ 15
Capítulo 2: ¿Qué es un director de Product Design? ................................ 25
Capítulo 3: ¿Cómo integrar el Product Design

en una organización con productos digitales? ........................................ 35
Capítulo 4: ¿Cómo se puede integrar al Product Designer en

los procesos «ágiles» de Product Management de forma eficaz? .......... 47
Capítulo 5: ¿Por qué crear un Design System

ya no es una opción?..................................................................................59
Glosario........................................................................................................71
2
PRÓLOGO
de Juan Pablo Costanzo
Head of Design en Jeff
«Estoy cansada de escuchar a los diseñadores pedir un lugar en la mesa de

decisiones de las empresas. Como diseñadores, debemos coger una silla y
hacernos sitio en la mesa».
Siempre estoy abierto al buen intercambio de ideas y opiniones sobre diseño, pero
tengo un recuerdo especial de las charlas que mantuve con Erika, Directora de
Diseño de Paypal, hace ya unos años.
Esa conversación me traslada a los comienzos de mi carrera en Silicon Valley.

A principios de los 2000 y en la mayoría de las empresas, la labor de diseño se
percibía como un servicio dentro de otros equipos. Ni siquiera los diseñadores
con más experiencia eran invitados a presentar sus trabajos; ya ni hablemos de
tener voz y voto para intervenir en las decisiones de producto.
Por suerte, el panorama ha cambiado dentro de las organizaciones. Cada vez son
más las compañías que han comprendido el valor de Diseño, mientras que otras
lo están empezando a entender.
Apuesta por el diseño holístico
No se trata de prestigio individual, sino de una convicción: tener una visión más
estratégica y holística en la toma de decisiones. Una convicción que termina
beneficiando a todos, y que en el día a día se materializa en ocupar el asiento que
llevamos tiempo anhelando.
Aunque cada vez más diseñadores tienen ese «codiciado asiento» del que hablaba
mi colega Erika, queda un largo camino para que la profesión esté donde creemos
que merece estar.
La toma de decisiones estratégicas es el día a día de quienes hemos conseguido

hacernos sitio en una organización donde se valora el Diseño en todo su conjunto.
Organizaciones donde llevamos a cabo iniciativas que son clave en la hoja de
3
ruta de un producto, y donde no hubiéramos llegado sin esfuerzo y sin haber
demostrado que los equipos de diseño pueden resolver grandes problemas
mediante procesos bien enfocados.
Habilidades a cultivar
Con este libro, Thiga hace una clara radiografía del rol del Product Designer (o
diseñador de producto), poniendo en relieve que debemos convertirnos en líderes
transversales dentro de los equipos. En las siguientes páginas también describen
cómo llegar a este objetivo: desarrollando las habilidades puramente de diseño,
pero sobre todo, cultivando una base de soft skills como son: el liderazgo, la
colaboración, la comunicación y la moderación, entre tantos otros.
Estas habilidades se pueden aprender, adquirir y perfeccionar a lo largo de

nuestras carreras profesionales. Sin duda, son habilidades que dotan al diseñador
de un rol estratégico, cuya necesidad ya se ha puesto de manifiesto a través de las
compañías tecnológicas de mayor referencia. Como muestra, la conversación que
mantuve recientemente con mi amigo Andrew, Team Lead en Google de Mountain
View (California):
«Juan Pablo, cuando estoy en una reunión en Google, no sé quién es el ingeniero,

quién es el Product Manager o quién es el Product Designer. Se habla de negocio,
experiencia de usuario y tecnología de una forma muy fluida y a un mismo nivel».
Este es un ejemplo de que hay empresas que tienen interiorizada esta filosofía
en la práctica. Otro ejemplo más cercano lo encontramos en Jeff, donde los
diseñadores tienen una visión amplia de UX, creen en una experiencia holística
y colaboran estrecha y continuamente con los Product Managers e ingenieros.
Todo esto para encaminarnos a una profesionalización de nuestro rol en la que
los Product Designers participan en todas las fases de un producto: desde el
Discovery hasta el delivery, de forma iterativa, midiendo su trabajo en función del
éxito de su producto y jamás desde el output de su trabajo.
Actuar como factor de cambio
Hace un tiempo, en Jeff, detectamos que a los squads le faltaba un «framework»

o un marco como guía para la toma de decisiones y para lograr la autonomía.
4
Habitualmente, esta necesidad surge del día a día de los equipos de producto, que
consiste en navegar a través de las necesidades de los clientes, los stakeholders y
de negocio, al mismo tiempo que se sigue la visión del producto.
Sin una guía, la toma de decisiones que sale de cada squad termina siendo
inconsistente. Y ahí radica el riesgo de incoherencia dentro de los productos.
Entonces, el equipo de diseño tomó el liderazgo para desarrollar los Principios

de Product de Jeff, una batería de herramientas que vincula nuestros valores y la
misión con los outcomes que impulsamos. Para lograr esto, pusieron en marcha
una serie de workshops con el objetivo de desarrollar y pulir dichos Principios.
Una vez definidos, los Product Designers se encargaron de difundirlos dentro de
sus respectivos squads, así como de buscar formas de medir el impacto de estos:
Lo que hacemos realmente importa
Entender el impacto que podemos tener a través del diseño es fundamental. Es

muy fácil enfocarse solamente en los píxeles y olvidarnos de la experiencia de
los usuarios. Sin embargo, el diseño tiene una gran influencia en la manera en
la que las personas se comportan y viven sus vidas, y los diseñadores estamos
capacitados para resolver problemas y mejorar la vida de los usuarios a través de
nuestros productos.
Mientras nos encaminamos a la profesionalización, lo habitual será encontrarse

con equipos donde hay que hacerse un hueco, influenciar y actuar como factor
de cambio; esas serán las oportunidades que tendremos de hacernos mejores
diseñadores.
Feliz lectura.
Juan Pablo Costanzo
5
6
SOBRE THIGA
Thiga es una consultoría internacional de Product

Management y Product Design.
Nuestro manifiesto
En Thiga nos gusta ir más allá, aunque no en exceso, solo lo justo y necesario... lo
necesario para estar siempre a la vanguardia y seguir divirtiéndonos con nuevos
desafíos.
Desde nuestros inicios hemos buscado crear vínculos sólidos entre nuestros
equipos y clientes, lo que nos permite ejercer un papel en el Product Design y
Product Management sin dejar nunca de innovar en este campo.
Estamos convencidos de que nuestros empleados son el elemento clave que

marca la diferencia y por eso fomentamos que los thiguys sientan afinidad con
los productos, sin renunciar a sus propias ambiciones, porque es eso lo que nos
hace mejores.
Pasamos gran parte de nuestro tiempo transmitiendo todo lo que sabemos en

distintos campos. Compartimos con regularidad las novedades y las mejores
prácticas del mercado. Nos apasionan tanto las grandes ideas como los pequeños
detalles de la ejecución.
Contamos con la gran experiencia de una consultoría y la mentalidad de una

empresa emergente, y nos enorgullece afirmar que nos tomamos nuestro trabajo
«muy en serio, pero no «demasiado» en serio.
Por todas estas razones, hemos desarrollado un nuevo enfoque para las profe-
siones de consultor, Product Manager y Product Designer.
7
Adoptamos una forma diferente de abordar los problemas de nuestros clientes y
de ayudarles a crear los mejores productos en el mercado digital.
Nuestra labor
Ayudamos a las empresas a construir productos digitales de éxito mediante los

proyectos de consultoría en estrategia y organización de productos; a través de
nuestra escuela de formación Thiga Academy y gracias a la implicación de nues-
tros excelentes Product Managers y Product Designers.
8
LOS AUTORES
Alexandre Irrmann-Tézé, Director general y cofundador de Thiga
Virginie Coux, Product Designer
Mathias Frey, Product Designer
Thomas Vidal, Product Designer
Antoine Barbotin, Product Designer
Romain Monclus, Coach en Product Management
Vanessa Guilloteau, Product Designer
Rémi Taieb, Product Designer
Frédéric Dardion, Product Designer
Nunca hubiéramos podido terminar este libro sin la participación de las thigirls y
los thiguys que organizaron las entrevistas y maquetaron, releyeron y corrigieron
los capítulos. Nuestro más sincero agradecimiento
• Céline Winant-Pateron,
• Claire Bonnet,
• Julien Margoullia,
• Amélie Darcy,
• Fabrice des Mazery.
Muchas gracias también a Juan Pablo Costanzo, que no se lo pensó ni un segundo

cuando le pedimos que escribiera el prólogo de nuestro Product Academy 4 en
español.
9
PREFACIO
Expertos, generosos y apasionados: así es como nuestro equipo se ha definido
siempre. Desde su creación, Thiga se ha comprometido a compartir sus cono-
cimientos tanto con la comunidad de producto como con sus clientes. Hemos
escrito una colección de libros titulada Product Academy sobre los fundamen-
tos del Product Management, el Product Growth, las organizaciones orientadas a
producto y los productos basados en Data Science. También hemos coorganiza-
do importantes eventos de Product Management como la Product Conf en París
y Madrid, así como reuniones de LPCx en París, Lyon, Lille, Aix, Toulouse, Burdeos,
Nantes, Barcelona y Madrid.
Este nuevo libro se centra en el Product Design. Muchos podrían preguntarse si

se trata de una novedad o si estamos explorando un territorio desconocido. No
lo consideramos así. Thiga ha ido adquiriendo toda su experiencia en el Product
Design con naturalidad y de forma gradual, pues este campo está íntimamente liga-
do al Product Management y es perfectamente coherente con nuestra razón de ser:
permitir a nuestros clientes construir los mejores productos digitales posibles. La
experiencia de usuario es el resultado del Product Design, un factor importante para
que un producto, sea cual su tipo de interfaz o naturaleza, tenga éxito.
Además, en todos nuestros proyectos observamos que los equipos de producto

que funcionan bien siempre comentan lo beneficioso que resulta que los Product
Designers trabajen en estrecha colaboración con los Product Managers, a lo
largo de todas etapas del ciclo de vida del producto. La combinación del enfoque
de producto, los preceptos ágiles y los principios de diseño están demostrando
funcionar particularmente bien. Sin embargo, la literatura sobre el Product Design
todavía es escasa y la comunidad ya ha manifestado claramente que quiere mejorar
sus prácticas. Por eso, este libro tiene un doble propósito:
• Definir el papel del Product Designer que aún no está muy normalizado.
• Ofrecer las claves para integrar a los diseñadores en una organización de
producto con eficacia.
Este libro pretende ser accionable, no dogmático. Nuestro pensamiento se basa

en las experiencias de nuestros Product Designers y Product Managers que traba-
jan diariamente en equipos ágiles, así como en entrevistas realizadas en algunas
de las empresas más maduras del mercado: Blablacar, Getaround, Jobteaser, etc
¡Feliz lectura!
Alexandre Irrmann-Tézé
10
INTRODUCTION
Cuando hablamos de diseño experimental, a menudo oímos hablar de Customer
eXperience, Service Design, UX Design o Product Design. La terminología de
todas estas disciplinas es muy amplia y no existe una sola definición oficial. Por
eso, vamos a aclarar y explicar estos términos dándole especial importancia al
Product Design.
Para ilustrar todo lo que puede aportar estas disciplinas, analizaremos un caso en
concreto, el de Uber. Esta conocida empresa de servicios de VTC también ofrece
a sus clientes un servicio de alquiler de patinetes (Jump) y otro de entrega de
comida a domicilio (Uber Eats). Uber gestiona diferentes productos digitales (apli-
caciones móviles, sitios web, etc.) para sus diversos servicios.
Customer eXperience
El objetivo de la CX (o Customer eXperience) es proporcionar una experiencia

homogénea tanto en todos los puntos de contacto en línea y no digitales entre el
cliente y la empresa como en todos los servicios que esta ofrece. El CX Designer,
a cargo de construir la experiencia, se apoya en la plataforma de marca de la
empresa: identidad, misión, valores, etc. A través de todas sus acciones, la CX
busca mejorar los resultados económicos de la empresa gracias a la lealtad de
sus clientes, motivándolos a recomendar sus servicios, etc.
En el caso de Uber, los puntos de contacto son diversos y la Customer eXperience

se plasma en los anuncios en el metro, las conversaciones con los conductores,
las pantallas de la aplicación móvil o incluso en los correos electrónicos que
adjuntan la factura del viaje. En resumen, la CX siempre está presente.
Service Design
El Service Design busca ofrecer la mejor experiencia posible en cada uno de los
servicios ofrecidos por la empresa (Uber, Jump o Uber Eats, en nuestro ejemplo).
Los Service Designers diseñan las interacciones de los clientes, relacionadas con
el servicio en todos sus canales, y no solo se centran en los puntos de contacto no
digitales, sino también en los procesos internos necesarios para ofrecer la expe-
riencia deseada, como cuando se forma a los conductores. El Service Designer
trabaja en estrecha colaboración con otros diseñadores de la empresa en la
mayoría de los puntos de contacto digitales.
11
UX Design
El objetivo del UX Design es crear la mejor experiencia digital posible para el usua-
rio. Los UX Designers trabajan en las funcionalidades relacionadas con un servi-
cio determinado para que sean útiles, utilizables y deseables desde el punto de
vista del usuario. Este es el caso de la funcionalidad de «Seguimiento de pedidos»
en la aplicación móvil Uber Eats, por ejemplo.
Product Design
Cerramos esta introducción con el Product Design. Esta disciplina busca construir
la mejor experiencia posible para el usuario dentro de la cultura de producto. Por
lo tanto, tanto su propósito como sus herramientas son similares a las del UX
Design. Sin embargo, el Product Design se fundamenta en una mentalidad dife-
rente y una perspectiva más amplia: la cultura de producto, también conocida
como pensamiento de producto, que también se aplica al Product Management
e implica muchos cambios en la forma diaria de trabajar. De hecho, la cultura de
producto consiste en: :
• Tener en cuenta los retos comerciales de la empresa, además de las

necesidades de los usuarios. El Product Designer crea una experiencia
que satisface tanto las necesidades de los usuarios como los objetivos
estratégicos de la empresa. En sus consideraciones, contempla la visión a
largo plazo de la empresa.
• Adoptar una visión global de producto a la hora de tomar decisiones. Y es

que no hay que olvidar que una funcionalidad es el subconjunto de un todo
coherente —es decir, el producto— con una propuesta de valor global. El
Product Designer piensa constantemente en el impacto que pueden tener
las nuevas características. Se asegura, por ejemplo, de que no se acumulen
demasiadas características si esto perjudica la promesa final del producto.
• Colaborar de forma ágil con otros expertos, como los Product Managers,
los desarrolladores, etc. El Product Designer comprende las cuestiones y
problemas de las distintas partes involucradas en el producto; participa en
la construcción de su trabajo, les da visibilidad e integra las limitaciones de
cada uno.
• Trabajar en equipos de producto orientados a resultados. Como el resto del

equipo, el Product Designer implica una inversión a largo plazo. Experimenta
continuamente para maximizar el valor generado (resultado). Para un
12
Product Designer, poner una nueva funcionalidad (salida a producción) en
producción no es un fin en sí mismo.
• Seguir la lógica del MPV. El Product Designer no busca la perfección en
el User Research o en el diseño de las características del producto. Su
nivel de implicación depende del riesgo y del retorno de inversión de cada
característica.
CUSTOMER
experience
PRODUCT
Design
UX
Design
UI
Design
SERVICE
design
Representación de las disciplinas del diseño según la experiencia de Albina Chola
En resumen: el Product Design es una evolución del UX Design basado en la

cultura de producto. Esta disciplina está en auge, y por eso te ayudaremos en los
próximos capítulos a sacarle partido y te acompañaremos para integrarlo dentro
de una organización de producto.
13
CAPÍTULO 1
¿QUÉ ES UN PRODUCT
DESIGNER?
Qu’est-ce qu’un Product Designer ? / 15

El Product Design es una nueva disciplina que se ha ganado su hueco por dere-
cho propio que se ha convertido en una nueva profesión (Product Designers).
Este capítulo se centrará en dos cuestiones muy sencillas: ¿qué es un Product
Designer y cuáles son sus habilidades?
En Thiga, consideramos que la característica principal de un Product Designer

es contar con gran abanico deProduct Designer
competencias. Estas competencias le permiten
Framework
construir un producto con un enfoque iterativo que recoge toda la experiencia del
Product Designer para utilizarla frente a los desafíos de la empresa.
Concepción
Facilitación
User Research Soft Skills
Product Ownership Desarrollo

y Analytics
UX Writing
Nivel de
competencia necesario
Framework del Product Designer
Basándonos en esta convicción, hemos creado un modelo de competencias

completo que abarca ocho áreas diferentes. Dentro de este ámbito de competen-
cias, cinco de ellas nos parecen fundamentales :
• User Research (Investigación de usuarios).
• Facilitación.
• Concepción.
• UI Design.
• Soft skills del Product Designer.
16
Esta base es imprescindible para que el Product Designer pueda realizar su traba-
jo. De hecho, un diseñador que se especializa en User Research sin tocar el resto
de habilidades puede resultar un perfil muy útil en una empresa, pero no será
considerado como un «Product Designer» según nuestro modelo.
En el núcleo de este ámbito añadimos tres competencias más que creemos que
son muy útiles, aunque no esenciales, para ser un Product Designer:
• UX (o Content) Writing.
• Product Ownership y análisis.
• Programación.
Más allá de todas estas habilidades, el Product Designer domina la cultura de

producto y evoluciona con facilidad en un equipo de producto. Eso es lo que lo
distingue de un diseñador tradicional.
Las hard skills del Product Designer

User Research
User Research es el arte de comprender las necesidades del usuario para mejo-
rar el valor del producto. El Product Designer debe tener una formación mínima
en ciencia cognitiva, sociología, psicología y antropología para llevar a cabo las
actividades de investigación en las mejores condiciones. El User Research permi-
ten al Product Designer identificar y anticipar los sesgos de comportamiento de
su objetivo. El abanico de herramientas del Product Designer para llevar a cabo
esta investigación es amplio y mezcla métodos cualitativos y cuantitativos. Es
importante prestar atención y conocer las técnicas de observación, entrevistas y
pruebas de usuario.
.
Observación
Durante una sesión de observación, el Product Designer se pone en el papel de un

espectador. Este ejercicio puede parecer difícil, pero gracias a su experiencia, es
capaz de adoptar una postura no intrusiva. En el marco de esta práctica, el Product
Designer debe definir un protocolo de observación: hacer hipótesis, determinar
¿Qué es un Product Designer? / 17

un objetivo, ubicación, etc. Para estructurar el proceso, puede crear una guía de
observación. A menudo, se basa en modelos conocidos, como AEIOU o POEMS.
Entrevistas
En primer lugar, para llevar a cabo las entrevistas, el Product Designer debe selec-
cionar los perfiles de usuario más adecuados. Esta selección es crucial, puesto
que tendrá un fuerte impacto en los resultados finales. Por eso no debemos
subestimar este proceso. Un Product Designer también puede escribir cuestio-
narios en línea o guías de entrevistas. Cuando realiza entrevistas (individuales
o en grupo), adopta una actitud empática, pero neutral y anticipa el sesgo de
la respuesta. Siempre existe el riesgo de que las respuestas del usuario varíen
sustancialmente según la forma de formular las preguntas.
.
Pruebas de usuario
Además de las observaciones y entrevistas, la tercera forma de contacto con los

usuarios es a través de las pruebas en las que el usuario prueba el prototipo o
el producto de forma autónoma. El Product Designer define las hipótesis que se
van a probar, selecciona un panel de usuarios para probar el producto y diseña y
anima los escenarios de prueba. Por este motivo, el Product Designer debe domi-
nar las diversas herramientas de prueba que han proliferado en el mercado en los
últimos años.
El Product Designer recurre a observaciones, entrevistas y pruebas de usuario

para tomar decisiones informadas y destinadas a mejorar el producto. En general,
el diseñador desarrolla tres entregables claves del User Research (investigación
de usuarios): perfiles o persona, jobs to be done y experience maps. La produc-
ción de entregables requiere una gran capacidad de retrospección y síntesis, pues
estos entregables contribuyen a describir claramente la experiencia del usuario,
tanto sus puntos débiles como sus expectativas. También se requiere un pensa-
miento crítico para cuestionar los resultados y hacerlos evolucionar con el tiem-
po. En un enfoque ágil, siempre es necesario iterar sobre las hipótesis que se han
de probar. ¡Lo que es realmente estimulante de esta investigación de usuarios es
que nunca se termina! Por lo que no se trata de una frenética investigación policial
que busca descubrir la verdad en el menor tiempo posible.
18
Facilitación
La facilitación es un conjunto de técnicas que ayudan a un grupo a alcanzar un

objetivo, mejorando así su eficacia. En el contexto del Product Design, la facili-
tación incorpora los objetivos de ideación (hacer que las ideas surjan en torno
al producto) y concepción (desde la idea hasta la realización). También requiere
buenas habilidades de comunicación. Además de dominar los talleres de UX, un
Product Designer debe comprender las dinámicas de grupo y ser diplomático y
pedagógico para llevar a cabo estos talleres.
Para poder hacerlo:

• Deberá identificar a todas las partes necesarias en los diferentes talleres
(por ejemplo: el técnico, el comercial, el personal de marketing, miembro del
equipo legal).
• Acompañará a los participantes a lo largo de las actividades, dándoles las
indicaciones necesarias.
• Deberá hacer gala de cierta pedagogía y capacidad de animación.
El Product Designer conoce y aplica las buenas prácticas para garantizar que el
taller funcione sin problemas y cumpla los objetivos. Sabe cómo distribuir equi-
tativamente el turno de palabra entre los participantes para fomentar la contribu-
ción colectiva.
Recordemos que el reto de los talleres de concepción conjunta es conseguir que

las personas que han perdido el hábito o que nunca lo han tenido trabajen juntas.
Fomentar su compromiso es el mayor desafío para el Product Designer. El Product
Designer debe identificar con antelación los riesgos vinculados al taller, ya sean
cuestiones políticas, fricciones personales en el grupo o el efecto HiPPO (Highest
Paid Person’s Opinion). Por último, se adapta en caso de problemas logísticos
imprevistos.
Concepción
Adentrémonos ahora en el corazón del diseño. El Product Designer toma los

hallazgos del User Research como punto de partida para:

• Convertirlos en problemáticas.
• Sacar a la luz las experiencias y funcionalidades potenciales (ideación)
• Construir rutas de usuario, flujos de trabajo, la arquitectura de la información,
las interacciones y las interfaces.
Analicemos ahora en detalle las habilidades de concepción: ideación, evaluación

de UX, arquitectura de la información, flujos de trabajo y diseño funcional.
Ideación
La ideación consiste en confiar en el User Research para obtener ideas concretas

de los productos o funcionalidades que van a convertirse en prototipos. Existe dos
métodos de ideación:
• El que transforma las sugerencias de los usuarios en ideas gracias a los
talleres de brainstorming, mindmapping, what if, etc.
• El que permite materializar las ideas en forma de pantallas: talleres de
creación tipo 6to1, Crazy 8, Big Idea, etc.
Evaluación UX
Recordemos que el Product Designer está iterando constantemente sobre su

producto y aplicando los principios de la cultura de producto de la empresa.
Evalúa constantemente la experiencia del usuario con el producto. Para ello, se
rige por una serie de reglas ergonómicas, como los criterios de Bastien y Scapin
o las diez reglas de usabilidad heurística de Jakob Nielsen. De este modo, puede
auditar regularmente su producto para identificar áreas de mejora.
Arquitectura de la información
Todo Product Designer sabe priorizar la información presente en sus interfaces:

la disposición de los elementos de una página (títulos, subtítulos, textos, anota-
ciones, etc.), la estructura de árbol de un sitio web, etc. Para ello, puede utili-
zar métodos como el card sorting y dirigir talleres que le permitan construir las
mejores interfaces posibles.
Cuanta más experiencia adquiera, mayor será la diversidad de contenidos que

podrá manejar y más variada será la naturaleza de las interfaces:
20
sistema embebido, smartwatch, asistente de voz, automatización...
Workflows
Para comprender e ilustrar todas las interacciones del usuario dentro de un

producto, el Product Designer debe ser capaz de mapear todos los user journeys
(o recorridos de usuario) utilizando representaciones de User flow, Wireflow o
Taskflow. Estos recursos, especialmente útiles en la fase de concepción, también
permiten a los equipos de desarrollo aprender nuevos caminos y funcionalidades
con más facilidad.
Concepción funcional
Basándose en todo el trabajo previo, el Product Designer crea los wireframes de

una interfaz web o una aplicación móvil y produce un prototipo funcional sencillo
que permite simular las secuencias de pantalla con las interacciones propuestas,
utilizando las principales herramientas de prototipado del mercado. Lo normal es
que un Product Designer senior tenga experiencia en crear wireframes en dife-
rentes interfaces digitales, y algunos se especializan en nichos como las inter-
faces de IoT.
UI Design
La concepción requiere pocas habilidades de UI porque el trabajo gira en torno a

prototipos low fidelity. Sin embargo, para los high fidelity sí se necesitan buenas
habilidades de diseño de UI, pues luego se utilizan como apoyo en la fase de
experimentación. Esta disciplina consiste en el arte de diseñar la capa gráfica de
un producto digital. El Product Designer plasma la identidad de la marca y le da
sentido, estructurando las pantallas y los componentes gráficos en un conjunto
coherente y estético.
Visual Design
El Product Designer debe aplicar los principios fundamentales del diseño (equili-
brio, contraste, jerarquía, proximidad, repetición) para aportar claridad y armonía
a sus composiciones. Aplicará, mejorará o creará la carta gráfica de su producto.
Por lo tanto, estas habilidades requieren nociones de ergonomía y accesibilidad.

Interaction Design
El Product Designer define las diferentes interacciones entre el usuario y el

producto: animaciones al hacer scroll o pasar sobre los elementos, microinte-
racciones, etc. Diseña prototipos interactivos precisos que permiten probar el
producto en condiciones casi reales.
Guidelines
Con el fin de colaborar con los demás miembros del equipo de producto y técni-
co, el Product Designer materializa sus elecciones en directrices compartidas o
bibliotecas de componentes; o bien participa en la creación de un Design System
(al que dedicamos un capítulo entero al final de este libro).
Y para poner el broche de oro
En las empresas orientadas al producto, el Product Designer forma parte del

equipo de producto más amplio, donde colabora estrechamente con los Product
Managers, los analistas de datos, los responsables de QA (Quality Assurance o
análisis de calidad), el personal técnico (desarrolladores, managers de inge-
niería y operaciones) y el equipo de marketing. Por eso, las empresas piden a los
Product Designers habilidades cada vez más específicas. No las consideramos
como un requisito previo imprescindible, pero queremos integrarlas en su caja de
herramientas. He aquí algunas:
• Product Ownership y análisis, que incluye el conocimiento de los frameworks

ágiles (Scrum, Kanban), la redacción de User Stories, el roadmapping y
análisis de datos de producto. En algunas organizaciones, un Product
Designer debe ser capaz de leer e interpretar los datos de rendimiento, de
las características de su producto o de los tests A/B que realiza. Debe estar
familiarizado con las principales herramientas de análisis cuantitativo,
poder definir métricas procesables, y realizar el análisis cualitativo a lo largo
de todo el proceso del producto.
• Programación, lo que incluye integración de HTML/CSS, animación y diseño
de interacción.
• UX writing, que incluye la estrategia de contenido en el producto y su
ejecución.
22
Más allá de estos conocimientos fundamentales o know-hows, el Product
Designer debe tener una visión global que integre la estrategia de la empresa.
Durante las etapas de concepción y User Research debe tener en cuenta el obje-
tivo de negocio. De hecho, el vínculo entre el diseño y negocio es mucho más
estrecho en una empresa orientada a producto. Cuanto más veteranos son los
Product Designers, más importante es su contribución a la estrategia de produc-
tos en su vida cotidiana.
Soft Skills: unas habilidades que ahora

son esenciales
Las profesiones de diseño han ido evolucionando de la mano de un reequilibrio
entre las soft y las hard skills. Para llevar a cabo el User Research, generar
ideas dentro de un grupo o participar en un stand-up diario, el Product Designer
necesita echar mano de cualidades que van más allá de una mera capacidad
técnica para crear una interfaz. Un excelente diseñador no tiene por qué ser un
buen comunicador, ¡ni viceversa!
El Product Designer ideal es:

• Empático: la empatía es el reconocimiento y la comprensión de los
sentimientos y emociones de otra persona, así como de otros estados no
emocionales, como sus creencias. Un Product Designer entiende tanto
los problemas como las motivaciones de sus usuarios, pero también las
necesidades de los miembros del equipo con los que trabaja. Esto implica
tanto una capacidad de abstracción como una cierta humildad.
• Colaborativo: se asegura de que su trabajo esté perfectamente integrado
con el del resto del equipo de producto y que sea complementario al Product
Manager. Un Product Designer sabe cómo llegar a un acuerdo e integrar
múltiples restricciones en su diseño.
• Buen comunicador: el Product Designer se expresa de forma clara y concisa,
intercambia y comparte fácilmente con los diferentes expertos con los
que trabaja (desarrolladores, Product Manager, partes interesadas). Sabe
transmitir información con claridad, escuchar y reformular opiniones. Con
su discurso, lleva la voz de los usuarios y difunde la cultura del Product
Design en la empresa.

• Agile: se adapta a cualquier tipo de organización objetivo y comparte los
valores de la agilidad.
• Curioso: el Product Design es un campo que evoluciona de una forma
increíblemente rápida. Un buen Product Designer debe mantenerse al de
las tendencias que podrían influir en el producto o llevar a cambiarlo. Debe
buscar información de forma proactiva y mantenerse alerta constantemente.
Para terminar, no podemos hablar del papel y las habilidades del Product Designer
sin mencionar su grado de responsabilidad. Porque si el diseñador tiene el poder
de crear una gran experiencia de usuario, ¡también tiene la capacidad de conver-
tirla en algo adictivo! Por lo tanto, diseñar un buen producto no es solo crear
engagement, sino también anticipar las consecuencias de su diseño. ¿Cuáles son
los desencadenantes psicológicos o motivacionales activados por la interfaz?
¿Cuáles podrían ser los efectos perjudiciales para el usuario o su entorno? ¿Qué
hay del medio ambiente? Un Product Designer es un guardián que debe hacerse
estas preguntas para prevenir o curar la «miopía» del equipo de producto.
Y hablando de responsabilidad: a continuación estudiaremos más de cerca al

responsable del equipo: ¡el director de Product Design!
Recursos para saber más:
Design Kit Ideo: Design Kit es la plataforma de IDEO.org para aprender el diseño
centrado en el usuario; un enfoque creativo para resolver los problemas más
difíciles.
Blog de Thiga: ¿Pueden los jobs-to-be-done ayudarte a hacer mejores User

Persona? Un artículo que describe esta herramienta, que a menudo se utiliza mal,
hasta el punto de que a veces se vuelve contraproducente. Explora el enfoque
«Jobs to be done» para guiar la creación de tu persona.
Blog de Thiga: Pequeña guía de observación para Product Managers honestos.

En este artículo, Ayessa Loutfi habla de la observación in situ como un instrumen-
to eficaz y una habilidad para (re)descubrir comportamientos reales, problemas
recurrentes, estrategias de evitación y fenómenos inconscientes de los usuarios,
así como para identificar formas de mejorar el producto.
24
CAPÍTULO 2
¿QUÉ ES UN HEAD OF
PRODUCT DESIGN?
Qu’est-ce qu’un Head of Product Design ? / 25

Después de explorar las habilidades que deben tener los Product Designers, ahora
analizaremos quién los dirige: ¡el Head of Product Design!
Este capítulo está destinado a:

• CPOs o CEOs que buscan un Head of Product Design y desean afinar sus
criterios de búsqueda.
• Heads of Product Design que quieren evolucionar en su cargo.
• Diseñadores que aspiran a ser Head of Product Design y que desean conocer
las habilidades clave que deben dominar.
¡Atención! Con el término «Head of Product Design» nos referimos al responsable

de todos los diseñadores (Product Designers y perfiles especializados en UX
Writing, User Research, etc.). Se trata del puesto de diseño más alto en la organi-
zación de producto. Algunas empresas emplean un título diferente y se refieren a
esta persona como VP Design, VP Product Design o Design Director.
Un buen Head of Product Design debe dominar estas cuatro áreas fundamentales:
• La gestión del equipo de diseño.
• La estrategia de producto y la visión creativa.
• La evangelización en torno al valor del diseño.
• La cultura del diseño.
Analizaremos en detalle cada una de estas áreas para que todas queden muy
claras.
26
Gestión del equipo de diseño
El ser humano es el núcleo alrededor del que orbita un Head of Product Design,
pues dedica gran parte de su tiempo a seleccionar personal y a construir un
equipo de diseñadores de alto nivel para luego hacerlo crecer. También supervisa
el grado de compromiso del empleado, al igual que un Product Manager lo hace
con sus usuarios. Para ello, podrá aprovechar el famoso framework «AARRR», tan
aclamado dentro del Product Growth, pero adaptado para este contexto particular:
• Adquisición: seleccionar y contratar a las personas con el perfil adecuado

para garantizar una cohesión en el equipo y hacer frente a los desafíos que
se plantean en la empresa.
• Activación: garantizar una correcta incorporación e integración de cada
nuevo perfil.
• Retención: gestionar la motivación, el aprendizaje y la evolución profesional
de los Product Designers.
• Ingresos (revenue): por un lado, administrar el presupuesto y los salarios;
por el otro, evaluar el impacto del equipo de diseño en la empresa.
• Referenciado (viralidad): fortalecer el atractivo de la empresa en el seno de
la comunidad de diseño mediante acciones de marca de los empleadores.
• Y por último, la renuncia (dimisión): cuando no se puedan evitar las marchas,
ya sean voluntarias o no, tanto en lo concerniente a la propia persona que
abandona la empresa como en lo relacionado con los equipos de diseño y
producto.
Para cada diseñador del equipo, el Head of Product Design define las habilidades
(soft y hard skills) y conocimientos necesarios para el puesto. Esas habilidades
dependen en gran medida de la tipología del producto (aplicación móvil,
plataforma, SaaS B2B, etc.), de la fase del ciclo de vida del producto (pre/post
introducción al mercado) y del nivel de madurez del resto del equipo. Puede
basarse en un framework específico, como el de Thiga (véase el capítulo 1), para
representar los niveles de habilidad actuales y deseados de cada persona.
También coordina el plan de desarrollo de habilidades de su equipo (plan de

formación, coaching, emparejamiento, tutoría, etc.). Su seguimiento se puede
registrar en un documento ad hoc. En Thiga, por ejemplo, cada thiguy tiene su hoja
de registro compartida con su responsable.
¿Qué es un Head of Product Design? / 27

Extracto de la hoja de registro de un Product Designer de Thiga
User Rese
Evolución dese
User Research Nivel 1
3
Soft skills Ideación Nivel 2
2
Nivel 3
Ideació
0
Facilitación UI Design Evolución des
Nivel 1
Nivel 2
Nivel 3
Product Ownership Desarrollo
& Analítica
UX Writing UI Desig
Evolución des
Nivel 1
Habilidades adquiridas Habilidades deseadas

Nivel 2
Nivel 3
PO y Analí
Evolución des
Nivel 1
Nivel 2
Nivel 3
28
Extracto de la hoja de registro de un Product Designer de Thiga (continuación)
Estudio Observaciones/
User Research secundario Zona de inmersión Entrevistas Persona y EX map
Evolución deseadas:
Nivel 1
ación Nivel 2
Nivel 3
Arquitectura Concepción
Ideación Evaluación UX de la información Workflows Funcional Pruebas de usuario
UI Design Evolución deseada:
Nivel 1
Nivel 2
Nivel 3
esarrollo
Interaction Herramientas y
UI Design Visual Design Design Guidelines workflows
Evolución deseada:
Nivel 1
deseadas
Nivel 2
Nivel 3
Product
PO y Analítica Agilidad Ownership Analítica
Evolución deseada:
Nivel 1
Nivel 2
Nivel 3

El aprendizaje en pareja es esencial y es importante hacer hincapié en él. El
Product Design Manager puede, por ejemplo, dedicar cierto tiempo a que los
diseñadores participen en una práctica en equipo.
LA PREPARACIÓN DE UNA PRÁCTICA DE DISEÑO

EN EQUIPO TIENE MUCHAS VENTAJAS.
En particular, permite:
• Compartir las buenas prácticas.

• Ampliar las habilidades de los Product Designers y traducirlas
en conocimientos específicos de perfiles especializados
(por ejemplo: User Research).
• Desafiar los logros de cada uno.
• Mantener cierta coherencia entre los métodos
y las herramientas utilizadas.
• Colaborar en cuestiones transversales.
Para que los Product Designers sigan progresando y no caigan en la rutina, el

Head of Product Design también puede proponer rotaciones de los productos
entre ellos (cambiándolos de grupo cada año, por ejemplo).
El Head of Product Design también debe proponer trayectorias profesionales

adecuadas para su equipo. Por ejemplo:
• Ruta «full-stack»: perfecciona las habilidades como Product Designer o
permite ascender de Product Designer a Lead Product Designer.
• Ruta de «especialización»: la persona se transforma en User Researcher, UX
Writer, DesignOps, etc.
• Ruta de «gestión de personas»: permite pasar de diseñador a Product Design
Manager (en una organización de producto de gran envergadura puede haber
varios directores de Diseño de Producto. En tal caso, un vicepresidente de
Product Design se encarga de supervisarlos).
30
Ojo, porque la gestión de personas no requiere las mismas habilidades que el
Product Design, especialmente en el caso de las soft skills. Los mejores Product
Designers no son necesariamente los mejores Head of Product Design. Para saber
desempeñar este puesto, el Head of Product Design debe formarse en tareas de
gestión y aceptar que sus prácticas se pongan en cuestión. Debe entender, por
ejemplo, que su tipo de gestión tiene que adaptarse a la capacidad y motivación
de los miembros de su equipo. También debe ser capaz de proponer un marco
para las decisiones, sin tomarlas él mismo.
Estrategia de producto y visión

creativa
Gracias a su visión creativa, el Head of Product Design discute con el CPO la
visión y la estrategia de producto o incluso la estrategia global de la empresa.
Representa al usuario e introduce conocimientos clave en el proceso de pensa-
miento estratégico.
Por eso, es esencial un buen entendimiento con el CPO. Hay que crear química entre
ellos. Para ello, el Head of Product Design debe ser empático, entender lo que está
en juego para el CPO y posicionarse como su complemento. Retarle, sin llegar a
pisar su terreno, y asesorarle para que pueda tomar la mejor decisión posible.
El CPO y los directores de producto deben interpretar la colaboración con el Head

of Product Design como una oportunidad para obtener nuevas ideas y detectar
oportunidades de productos, haciendo converger así las necesidades de los
usuarios y de la empresa con inteligencia
Evangelización sobre el valor del

diseño
¡El Head of Product Design es el embajador del diseño, tanto dentro como fuera
de la empresa!

Dentro de la empresa
El diseño crea valor tanto para el producto como para la empresa en su conjunto.
Ese es el mensaje clave del Head of Product Design y de su equipo. Su misión
es despertar el interés y unir a todas las partes interesadas sin intervenir direc-
tamente. Si tiene éxito a la hora de implementar este modelo, discutir con los
diseñadores cualquier decisión estructural se convertirá en algo natural y se refle-
jará del mismo modo en todas las partes involucradas. Para asentar el diseño
en el funcionamiento general de la empresa, es necesario basarse en hechos y
demostrar cómo contribuye al logro de los objetivos estratégicos. Por ejemplo, el
Head of Product Design y su equipo pueden destacar la mejora de las métricas de
utilización del producto tras rediseñar una funcionalidad clave; presentar nuevas
oportunidades de negocio a través de la detección de hechos previamente desco-
nocidos; mostrar los casos de éxito de empresas similares con una cultura de
diseño muy asentada, etc
Los diseñadores podrán apoyarse en la confianza generada con los Product

Managers y desarrolladores para convencer a la Dirección.
Fuera de la empresa
La evangelización también tiene lugar en la comunidad, en conferencias y

reuniones donde el Head of Product Design comparte los éxitos y fracasos de su
equipo. Así, el atractivo de la empresa aumenta y termina por atraer a diseñadores
con talento: esa es la auténtica arma secreta actual
La cultura del diseño

Es importante que el Head of Product Design cree una cultura y organización de
Product Design satisfactoria para su equipo. Esto se traduce, por ejemplo, en la
aplicación de métodos, procesos, conjuntos de herramientas, rituales, etc.
La cultura del diseño se construye a partir de la colaboración del CPO y los diseña-
dores, y debe permitir que la visión se ejecute sin dificultades. Para ello, está total-
mente integrada en la empresa y está en contacto permanente con los demás
equipos de diseño de la empresa (CX, Service Design, etc.).
32
“TENER UNA MENTALIDAD DE PRODUCTO”,
TAMBIÉN REQUIERE CONSIDERAR A LA EMPRESA
COMO UN PRODUCTO.
El Head of Product Design debería, por ejemplo:
• Tomarse el tiempo necesario para comprender los principales

problemas u obstáculos que frenan la aplicación de la estrategia
de producto. Para ello, debe reunirse directamente con los usuarios
de la empresa, como los diseñadores, los Product Managers, los
desarrolladores, la Dirección, las partes interesadas en el producto,
etc. El objetivo es determinar el reto que hay que superar
• Definir la dirección que debe tomar una nueva organización (el

destino final) y desglosarla en objetivos (por ejemplo, aumentar
la atención, reducir la complejidad, etc.) y luego en criterios que
permitan alcanzar esos objetivos (equivalente a los Key Results del
sistema OKR).
• Establecer un backlog para las iniciativas de empresa.
• Experimentar estas nuevas soluciones organizativas con los equipos

más motivados, medir, iterar e implementar los que funcionen.
Por lo tanto, es importante que el Product Design Manager materialice la cultura

y organización de producto en las prácticas y modos de interacción de los
diseñadores. Debe garantizar, por ejemplo, que los diseñadores tengan tiempo
para experimentar con nuevas ideas y mejorar continuamente el producto
trabajando conjuntamente con los Product Managers y desarrolladores. Además,
se encarga de que los diseñadores gestionen su grado de implicación en cada
tema según el retorno de inversión (ROI) esperado.
Es obvio que el propio Head of Product Design debe mostrar un comportamien-

to ejemplar en términos de mentalidad de producto. Debe encarnar los valores
del producto en su día a día. Las actividades en grupo de diseñadores también
pueden ayudarle a llevar a cabo un diagnóstico organizativo o a identificar ideas

para mejorar, como la revisión del conjunto de herramientas de diseño, la creación
de un Design System, etc.
El refuerzo es también un factor clave en el desarrollo de los equipos. Para ello, el

Head of Product Design debe recordar constantemente a todo el equipo el marco
estratégico en el que se desarrolla su trabajo y definir los niveles de delegación
adecuados. Puede, por ejemplo, otorgar un mayor nivel de delegación a sus Lead
Product Designers para que puedan tomar decisiones estructurales por su cuenta
dentro de su equipo y en equipos en adhesión directa (un grupo, entre otros). En
una empresa de gran envergadura, la responsabilidad de tener un sistema tan flui-
do como sea posible puede delegarse a un perfil exclusivo para ello: el DesignOps.
Ojo: para establecer una organización eficiente, ¡el director de producto debe
tener experiencia práctica como diseñador! Esta experiencia le permitirá hacer el
diagnóstico correcto y conseguir que los equipos se integren dentro de esta nueva
organización. En el siguiente capítulo veremos cómo integrar el Product Design
en una organización de producto de forma detallada.
Recursos para saber más
Building and Leading Design Organisations: en este vídeo, Kristin Skinner destaca
las actividades menos conocidas de un equipo de diseño y sus desafíos.
How to hire your next Head of Design?— what to look for: en este artículo, Supriyo
Roy desmitifica el papel del director de Design y nos indica qué tipo de perfil
buscar.
Entrevistas: 12 questions with Lisa Campana, º of Design at MOO: uno-a-uno con

Lisa Campana, la jefa de diseño de MOO: en esta entrevista, Lisa habla de su papel
como jefa de diseño: su trayectoria profesional, su trabajo en MOO y sus fuentes
de inspiración.
34
CAPÍTULO 3
¿CÓMO INTEGRAR EL
PRODUCT DESIGN EN
UNA ORGANIZACIÓN
DE PRODUCTO?
Comment intégrer le Product Design dans une organisation Produit ? / 35

Los Product Designers, Product Managers y desarrolladores deben trabajar juntos
con eficacia para ofrecer el máximo valor a los usuarios y a la empresa. Es muy
importante encontrar la forma de interactuar adecuada entre estos equipos para
poder asegurar:
• una visión común;
• un proceso de Product Discovery y de Product Delivery bien integrado;,
• una experiencia de usuario sin fisuras; y
• un aprendizaje unificado.
Hemos decidido utilizar una organización de producto como ejemplo para estu-
diar cómo los equipos de Product Design pueden encajar en ella. Se trata de una
plataforma de comercio electrónico en la que los equipos de producto, diseño y
técnico representan a un centenar de personas.
Esta empresa se organiza en grupos dirigidos por Heads of Product, y a su vez

se divide en squads. Los squads están integrados por Product Managers, desar-
rolladores y, si es necesario, otros profesionales como Scrum Masters y QA. El
Chief Product Officer (CPO) se encarga de gestionar la organización de producto
al completo.
Chief
Product Officer
Tribu BÚSQUEDA Tribu COMPRA Tribu ATENCIÓN
Head of Product Head of Product Head of Product
SQUAD SQUAD SQUAD SQUAD SQUAD SQUAD

Catálogo Navegación Carrito Validación Posventa Chat
SQUAD SQUAD SQUAD SQUAD

Clasificación Recomendación Pago Herramientas del
vendedor
Ejemplo de organización de producto
36
Hoy en día distinguimos tres modelos principales de organización de los equipos
de Product Design:
• El modelo centralizado: el equipo de Product Design se agrupa en su propio
estudio interno.
• El modelo descentralizado: los Product Designers se reparten entre los
equipos de Producto.
• El modelo centralizado a nivel de tribu: los Product Designers trabajan para
un grupo entero y, por lo tanto, para varios equipos de Producto.
Este último modelo nos parece el mejor para asegurar una entrega eficiente y, al
mismo tiempo, garantizar una coherencia general en la experiencia del usuario.
Los diferentes modelos de

organización de los equipos de
Product Design
El Product Design en una organización centralizada que
agrupa a los diseñadores en un estudio
Estudio de diseño
Chief Head of Product Design

Product Officer Diseñadores

Catálogo Navegación Panier Validación Posventa Chat

Clasificación Recomendación Pago Herramientas de
venta
Modelo centralizado o estudio interno
¿Cómo integrar el Product Design en una organización de producto? / 37

Un equipo centralizado toma todas las decisiones de diseño, que luego se apli-
carán a uno o más productos.
En este modelo de estudio interno, un Head of Product Design supervisa al equipo.

Tradicionalmente, este modelo tiende a aislar la experiencia como la Investigación
con Usuarios (User Research), la arquitectura de la información o el Visual Design.
Por lo general, estos estudios se realizan en el departamento de marketing, un

departamento técnico o en un equipo «digital» de reciente creación.
Es probable que esta configuración fuera la más común hasta hace poco, pero hoy
en día es un modelo en declive. Podemos encontrarlo en empresas emergentes
que todavía están empezando o en grandes empresas que no han cambiado su
organización, indicador de una organización de Product Design poco madura.
Exploremos las ventanas y desventajas de este modelo:
El modelo centralizado: ventajas

• Fomenta una experiencia de usuario consistente.
• Aclara las responsabilidades de cada uno de los tomadores de decisiones.
• Favorece una cultura común de Product Design.
• Permite que los Product Designers trabajen en varios proyectos.
• Refuerza las actividades de estrategia e investigación.
• Mejora la eficiencia en el trabajo entre los Product Designers y fortalece el
desarrollo de sus habilidades.
• Facilita el trabajo del Head of Product Design para asignar tareas al equipo y
administrar el presupuesto de diseño.
El modelo centralizado: inconvenientes

• Dificulta la comunicación entre los Product Managers y Product Designers.
• Reduce la visibilidad de los Product Designers durante la priorización
y planificación de los equipos de producto, pero también influye en las
restricciones del ROI y en el impacto que los productos pueden tener en los
usuarios.
• Reduce la responsabilidad en la entrega y con ello, aumenta el riesgo de
producir modelos imposibles de implementar, salvo que se modifiquen.
38
• Convierte a los Product Designers en un cuello de botella para la entrega y en
una fuente general de frustración.
• Desarrolla una relación cliente/proveedor con los squads, lo que puede
provocar fricciones.
El Product Design en una organización descentralizada:

integración completa dentro de los equipos de producto
Chief Product Officer
Head of Product Design
Tribu FIND BUY Tribe CARE Tribe
Lead PM Lead PRD

ou PM ou PRD
Lead Dev | Devs | SM | QA

Catalogue Navigation Panier Validation Après-vente Chat

Ranking Recommandation Paiement Boîte à outils
vendeur
El modelo descentralizado
La segunda opción es integrar a los Product Designers dentro de los diferentes

squads. Se centran en un ámbito definido y todos los squads cuentan con las
habilidades necesarias para construir el producto. Cada Product Designer trabaja
diariamente con Product Managers, desarrolladores y todos los demás especia-
listas de su squad.
Como vimos en el Capítulo 2, el Head of Product Design es responsable de todos

los diseñadores de la organización de producto. Responde ante el CPO y permite
que el equipo se haga responsable de la estrategia de producto desde el punto de
vista del diseño.
Algunas organizaciones pueden contar con Product Designers lo suficientemente

experimentados como para hacerse cargo de una parte importante relacionada
con el diseño. Por lo general, nos referimos a ellos como Lead Product Designers.
Sirven de ejemplo para los demás Product Designers, tanto en términos de Hard
como de Soft Skills. Pueden ayudar al Head of Product Design a tomar decisiones
estratégicas a nivel de tribu, apoyar a los Product Designers del equipo y asesorar
a los más novatos (sin ser su superior).
Comparemos las ventajas y los inconvenientes de este modelo descentralizado:
Ventajas del modelo descentralizado

• Promueve la responsabilidad y la participación de los Product Designers
como miembros del equipo de producto por derecho propio.
• Facilita la integración de elementos de la User Research que los mismos
Product Designers realizaron en la etapa de ideación.
• Alinea a los Product Managers, desarrolladores y Product Designers: de esta
manera unos comprenden mejor las necesidades de los otros.
• Reduce el time-to-market y simplifica las iteraciones.
Inconvenientes del modelo descentralizado

• Aumenta el riesgo de una experiencia de usuario fragmentada.
• Provoca ineficiencias, ya que el mismo trabajo se puede realizar varias
veces.
• Tiende a marginar la estrategia y el User Research. Los Product Designers
pueden limitarse a «producir pantallas».
• Tiende a aislar a los Product Designers, que reciben menos comentarios de
sus compañeros, su desarrollo de habilidades se complica y pueden perder
la creatividad.
• Complica la instauración de una cultura de diseño unificada.
• Puede dificultar que los Product Designers trabajen a tiempo completo
dependiendo del ámbito del squad.
Cabe señalar que los inconvenientes del modelo descentralizado pueden miti-
garse mediante el establecimiento de una división de diseño. Es una comunidad
de práctica reducida a Product Designers de una tribu. Dentro de esta comunidad,
los puntos de discusión regulares permiten definir objetivos comunes, compar-
tir resultados de investigación para capitalizar el trabajo ya realizado y coordinar
acciones: todo esto para garantizar la coherencia global de los resultados.
40
Head of Product Design
Chief
Product Officer UX Writer, User Researcher, DesignOps, Design System Lead, etc.
Lead PRD - PRD Lead PRD - PRD Lead PRD - PRD

Catálogo Navegación Carrito Validación Posventa Chat

Clasificación Recomendación Pago Herramientas de
venta
Modelo centralizado a nivel de tribu

Product Design centralizado a nivel de tribu, diseñadores
dedicados a un conjunto de squads
En este modelo que recomendamos, la función de diseño se comparte para toda

la tribu. Por lo tanto, los Product Designers se dedican a un conjunto de squads
que trabajan en temas muy próximos desde el punto de vista de la experiencia del
usuario, como se muestra en el diagrama anterior. En este tipo de organización, el
objetivo es determinar cómo los Product Designers deben distribuir los diferentes
asuntos de la tribu. Hay varias distribuciones posibles: por épica (esto permite
que cada diseñador siga un tema de principio a fin), por persona, para garantizar
la consistencia de la experiencia para un perfil de usuario dado, por sección del
User Journey (por ejemplo: adquisición y activación), o simplemente por squads
(por ejemplo, un Product Designer para dos squads). Como en el modelo anterior,
el Head of Product Design se encuentra por encima de las tribus. Además de los
Lead Product Designers y los Product Designers de todos las tribus, dirige a un
equipo transversal compuesto por perfiles especializados: User Researcher, UX
Writer, DesignOps, por ejemplo.
Veamos las distintas ventajas de esta organización:

• Fomenta una experiencia de usuario coherente: los Product Designers tienen
una visión común con la de sus squads y trabajan en una gran variedad de
temas.
• Favorece la formación de una sólida cultura y comunidad interna de diseño.
La co-localización (trabajar codo a codo) en la tribu permite realizar un
seguimiento más preciso del desarrollo y de la vida profesional diaria de
los Product Designers. Pueden mejorar sus habilidades al trabajar con sus
compañeros y recibir la orientación de mentores que les ayudan a definir su
trayectoria profesional.
• Responsabiliza a los Product Designers como miembros de la tribu.
Integrados en la gestión de la tribu y de determinados squads, no asisten a
todos los rituales de cada squad, sino que se adaptan a las necesidades de
los equipos.
• Contribuye a mejorar la eficacia en el trabajo desde el punto de vista de la
asignación de recursos (algunos squads no siempre necesitan a un Product
Designer a tiempo completo.
Sea cual sea el modelo escogido, para que la experiencia de usuario en un sitio
42
web o aplicación sea óptima debe ser consistente de principio a fin. El usuario no
debe «percatarse» del trabajo de la organización de la tribu.
Por lo tanto, es necesario establecer una gestión global entre las tribus y que quede
asegurada tanto por el Chief Product Officer como por los Heads of Product y el Head
of Product Design.
Para garantizar que la experiencia sea fluida, los Product Designers pueden
preparar una gestión visual específica (a menudo denominada Experience Board).
Cada squad muestra en un tablón las pantallas en las que esperan trabajar en
los próximos sprints, agrupados por perfil o persona. Al consultar esta tabla, los
miembros del squad pueden anticipar las posibles diferencias en la experiencia de
usuario relacionadas con sus respectivos trabajos y garantizar la coherencia de
las rutas para un mismo usuario.
En el primer capítulo, presentamos a los Product Designers como perfiles full-

stack. Sin embargo, a medida que la organización crece, la aparición de perfiles
especializados se convierte en algo esencial.
Los perfiles especializados necesarios

para la excelencia del diseño
En el modelo que recomendamos, estos perfiles se agrupan en un equipo multi-
funcional. En estos perfiles especializados distinguimos, por ejemplo:
• el User Researcher;
• el DesignOps;,
• el UX Writer;
• el Design System Lead.
El User Researcher
En una organización de producto pequeña, el Product Manager y el Product

Designer pueden encargarse del User Research. Sin embargo, cuando la organi-
zación crece, lo mejor es que esta tarea la lleve a cabo un perfil especializado:
el User Researcher. Al no participar en las decisiones de diseño, su análisis será
más neutral. Cabe destacar que el User Researcher debe involucrar a los Product
Managers y Product Designers en sus actividades para evitar el efecto silo.

Los User Researchers llevan a cabo estudios tanto cualitativos (entrevistas,
observación, inmersión) como cuantitativos (cuestionarios, estudios estadísticos,
etc.). Trabajan diariamente con los equipos de datos y de servicio al cliente para
recopilar esta información.
El DesignOps
Al igual que ProductOps, Design Operations (o DesignOps, para abreviar) es una

nueva disciplina que ha surgido en algunas organizaciones de producto. Es el
equivalente de diseño del DevOps, y representa un conjunto de valores, procesos
y herramientas destinadas a reducir el tiempo de comercialización y mejorar la
calidad de los productos.
Asimismo, la función principal de DesignOps es la de establecer procesos de

trabajo eficaces para los diseñadores en la organización de producto. Por lo gene-
ral, de esta responsabilidad se encarga un miembro del equipo de diseño con el
mismo nombre: DesignOps.
Asegura que las mejores prácticas y procesos de diseño sean reconocidos dentro
de la empresa. El DesignOps es responsable de auditar, definir e implementar
un proceso de diseño de producto. Puede facilitar la implementación del Design
System para ganar eficiencia y elaborar fuentes de datos accesibles para todos,
especialmente durante la User Research. En algunas organizaciones grandes su
cometido puede llegar incluso a administrar el presupuesto de los equipos de
diseño y la participación en la selección de personal, incluida la elección de cursos
de formación y de las herramientas de los diseñadores.
Finalmente, el DesignOps destaca el impacto que el diseño puede tener en una

empresa. Por experiencia, la necesidad de integrar un DesignOps en su organiza-
ción se hace notar en varios casos:
• Cuando el equipo de Product Design crece y el Head of Product Design ya no
puede sincronizar a todos los diseñadores.
• Cuando los perfiles de especialistas tienen dificultades para colaborar con
los Product Designers.
• Cuando los diseñadores se dividen en varios equipos y, a veces, se
encuentran en ubicaciones diferentes.
44
El UX Writer
La función del UX Writer es similar a la del redactor, un perfil más conocido. Es

responsable del contenido (comúnmente conocido como redacción) de todo el
producto, desde la etapa de incorporación hasta la de conversión. Su objetivo
es facilitar al usuario la comprensión y conseguir que la experiencia sea lo más
agradable y homogénea posible.
El UX writer es experto en palabras, tiene una excelente pluma y conoce muy bien
a sus usuarios, apoyándose especialmente en el trabajo de investigación del
equipo. Este miembro del equipo es garante del tono de voz de la marca en todas
las plataformas. Además, está totalmente integrado en el trabajo de los equipos
ágiles de Product Designers, Product Managers y desarrolladores, y utiliza sus
herramientas.
El Design System Lead
Normalmente, el Design System Lead es un diseñador con una gran inclinación

hacia la UI (interfaz de usuario) y unos buenos conocimientos técnicos. Es el refe-
rente del Design System. Garantiza la calidad de los componentes y evangeliza a
los equipos sobre los beneficios que este sistema puede aportar. Está a cargo de
definir el plan de lanzamiento del Design System para dar visibilidad a los equipos
sobre los componentes que se integrarán. En esta función, debe trabajar estre-
chamente con los Product Designers de la organización, los equipos de desarrollo
front-end y otras partes interesadas (Product Managers, Marca, UX Writers, etc.).
La elección de los perfiles especializados depende de las habilidades que le falten

al equipo de diseño, la naturaleza del producto y el presupuesto disponible. El
equipo de diseño de Blablacar, por ejemplo, se ha reforzado con la incorporación
de un Interaction Designer, especializado en prototipos avanzados. Este tipo de
perfil permite presentar a los usuarios y equipos internos interfaces que se acerca
lo más posible a lo que finalmente podría desarrollarse. El objetivo es limitar el
esfuerzo requerido de los usuarios para proyectarse en la solución, pero también
evitar los sesgos que algunos Product Designers pueden mostrar durante la etapa
de diseño. De hecho, por lo general, las herramientas utilizadas son limitantes y
pueden degradar la experiencia del prototipo. Si este tipo de perfil es relevante para
Blablacar, lo será mucho más para productos con interacciones más complejas.
¿Cómo intregrar el Product Design en una organización de producto? / 45

Para concluir, cabe señalar que las organizaciones de los equipos de diseño de
producto pueden adoptar diferentes formas. Dependiendo de su contexto, puede
optar por una organización más o menos descentralizada e integrar perfiles espe-
cializados. Sea cual sea el caso, resulta esencial definir claramente la distribución
de roles y responsabilidades entre los diferentes participantes, empezando por el
Product Manager y el Product Designer. Y ese será el tema que abordaremos en
el próximo capítulo.
Recursos para saber más
Design numérique, un référentiel évolutif des métiers (Diseño digital, una base de
datos de oficios en evolución): sin llegar a ser una lista exhaustiva, este recurso
recoge una versión actualizada (de discusión obligatoria) de los roles más impor-
tantes en diseño digital.
How to hire your next Head of Design?— what to look for: en este artículo, Supriyo
Roy desmitifica el papel del director de Design y nos indica qué tipo de perfil
buscar.
Entrevistas: 12 questions with Lisa Campana, º of Design at MOO: uno-a-uno con

Lisa Campana, la jefa de diseño de MOO: en esta entrevista, Lisa habla de su papel
como jefa de diseño: su trayectoria profesional, su trabajo en MOO y sus fuentes
de inspiración
46
CAPÍTULO 4
¿CÓMO INTEGRAR AL
PRODUCT DESIGNER
EN LOS PROCESOS
«ÁGILES» DE PRODUCT
MANAGEMENT DE
FORMA EFICAZ?
Comment le Product Designer peut s’intégrer efficacement

dans les processus de Product Management “agile” ? / 47
Como Head of Product Design, es posible que te encuentres estos problemas:
• Los Product Designers tienen la impresión de que están a expensas de los
Product Managers, o viceversa.
• Aunque tienen el mismo objetivo de desarrollar productos digitales
satisfactorios, las diferencias de perspectiva entre el Product Manager
(business first) y el Product Designer (user first) pueden hacer que
afloren tensiones, especialmente durante las sesiones de priorización de
característica.
• Los Product Designers creen que las reuniones son una pérdida de tiempo o,
por el contrario, que están demasiado aislados y no trabajan con los Product
Managers y desarrolladores lo suficiente
• Los Product Designers son reacios a los sprints, a veces tienen la sensación
de que tienen que producir pantallas todo el tiempo sin tener tiempo de dar
un paso atrás. Pueden sentirse frustrados por el hecho de que, a veces,
experimentan con un producto o una característica sin tener la imagen
completa de la experiencia objetivo.
Probablemente, ya has mirado en muchos libros cómo solucionar estos proble-

mas y no has encontrado nada concluyente. Es normal: la Guía Scrum y otros
libros de referencia explican cómo trabajan juntos los Product Managers, los
desarrolladores y el resto de partes involucradas, pero no aportan información
específica sobre el trabajo con los diseñadores. En este capítulo se expondrán
algunas ideas que puedes poner en práctica.
Las funciones y responsabilidades

entre el Product Manager y el Product
Designer
La calidad de la sinergia entre los Product Managers y los Product Designers
tendrá un efecto determinante en el funcionamiento del producto.
Según hemos ido desarrollado nuestros proyectos, detectamos ciertos fallos en la

colaboración entre el Product Manager y el Product Designer:
• Algunos Product Designers sienten que se les incluye en el ciclo demasiado
tarde y tienen que hacer la capa gráfica de una característica una vez que
todo está decidido.
48
• A menudo, tanto el Product Manager como el Product Designer creen tener
legitimidad para llevar a cabo ciertas actividades de Product Discovery.
En tal caso, lo normal es que las funciones y responsabilidades no estén reparti-

das claramente, es decir que no todos tengan claro su papel. Para aclararlo y crear
un diálogo constructivo, organizar un taller de Diagrama de Venn con Product
Designers y Product Managers podría resultar muy eficaz.
EL TALLER DE DIAGRAMA DE VENN
El objetivo del taller de Diagrama de Venn es establecer una distribución

de funciones y responsabilidades que tenga en cuenta las aptitudes y
deseos de todo el mundo.
Este taller puede llevarse a cabo en colaboración con las personas
involucradas o solo con los responsables. Dura alrededor de 1 hora y 30
minutos. Antes del taller, habrá que:
• Definir los roles que se discutirán en él (aconsejamos no elegir más
de cuatro roles, pues el taller se complicaría demasiado). Por ejemplo:
Product Manager - Product Designer - Lead Product Designer.
• Enumerar todas las actividades de las funciones que se han elegido.
Por ejemplo: crear un prototipo de una funcionalidad, entrevistar a los
usuarios, etc.
Durante el taller:
• El organizador presenta a los participantes los objetivos y la
metodología del taller. 5’
• Los participantes se turnan en silencio para colocar una actividad en el
diagrama basándose en su propia visión ideal de la distribución de roles.
Al final de este paso es posible añadir más actividades, si falta alguna. 15’
• Los participantes vuelven a leer el diagrama y pueden mover las
tarjetas que consideren mal colocadas. 10’
• Se identifican las tarjetas que se han movido para comentarlas en
grupo (tiempo límite de cinco minutos por tarjeta) y para elegir el
círculo al que pertenecen. 30’
• En el caso de las tarjetas que se encuentran en el límite entre dos
círculos (es decir, una actividad compartida) se les debe asignar una
persona responsable. 15’
En conclusión, es importante identificar las actividades que cambian de
área de responsabilidad en función de la situación actual.
¿Cómo integrar al Product Designer en los procesos «ágiles»

de Product Management de forma eficaz? / 49
Actividad 4
Product Manager
Actividad 3
Actividad 5 Product Designer
Actividad 1
Lead Product Designer
Actividad 2
Diagrama de Venn
Este taller probablemente mostrará que algunas actividades son comunes tanto
a los Product Manager como a los Product Designers, como la priorización del
backlog del Product Discovery, la elaboración de benchmarks, la realización de
entrevistas con los usuarios, etc. Al final del taller, su complementariedad debe
valorarse como una oportunidad para todos. La fricción generada por el cruce de
los prismas «user first» y «business first» debe considerarse como una fuente de
valor.
50
El proceso de concepción de Doble Diamante es un método interesante para
visualizar la distribución de los roles del Product Manager y del Product Designer.
Esta es la distribución común entre los actores reconocidos de la comunidad de
diseño:
BUILDING THE RIGHT PRODUCT BUILDING THE PRODUCT RIGHT
Zona de oportunidades Zona de soluciones

Calificación de oportunidades Diseño de soluciones
Responsabilidades Responsabilidades
Visión de producto PM Refinamiento del Backlog PM
Refinamiento del backlog con Product PM & PRD Elaboración del borrador (Sketching) PRD
Discovery
Flujo de usuario PRD
Investigación de usuario PRD
Elaboración de prototipo avanzado PRD
Marco de referencia competitivo PM & PRD
Pruebas de usuario PRD
Análisis de datos PM
UI Design PRD
Investigación de mercado PM
Pruebas y validación PM & PRD
Redacción del planteamiento del problema PM & PRD
UX Writing PRD
Roadmapping PM
Análisis de producto (Product Analytics) PM & PRD
Experimentación (ej: A/B Testing) PM & PRD
PM Product Manager
PRD Product Designer
Reparto de roles entre Product Manager y el Product Designer

Para dejarlo todo claro, es necesario ir más allá y definir el RACI en cada actividad
realizada de forma conjunta:
Actividad Product Product

Manager Designer
Refinamiento del backlog con Product Discovery
Investigación de usuario
Marco de referencia competitivo
Redacción del planteamiento del problema
Pruebas y validación
Análisis de producto (Product Analytics)
Experimentación (ej: A/B testing)
Responsible - persona responsable de llevar a cabo la actividad
Accountable- persona responsable de que la actividad se lleve a cabo
Consulted - persona que da su opinión durante la ejecución de la actividad
Informed - persona a la que se le informa sobre el progreso de la actividad
Matriz RACI
Esta división de funciones y responsabilidades no funciona en todos los contex-

tos. No seas dogmático, el equipo puede auto-organizarse y encontrar por sí
mismo la forma de trabajar que mejor le convenga. Como en un equipo de balon-
cesto, no importa la posición, lo importante es que todos se sientan cómodos con
las tareas que realizan y que la cancha esté bien cubierta.
52
En las empresas más grandes están surgiendo funciones especializadas (como
vimos en el capítulo 3): User Researcher y UX Writer, en particular. La distribución
de roles entre el Product Manager y el Product Designer puede verse afectada de
la siguiente manera:
BUILDING THE RIGHT PRODUCT BUILDING THE PRODUCT RIGHT
Zona de oportunidades Zona de soluciones

Calificación de oportunidades Diseño de soluciones
Responsabilidades Responsabilidades
Visión de producto PM Refinamiento del backlog PM
Refinamiento del backlog con Product PM & PRD Elaboración del borrador (Sketching) PRD
Discovery
Flujo de usuario PRD
Investigación de usuario UR
Elaboración de prototipo avanzado PRD
Marco de referencia competitivo PM & PRD
Pruebas de usuario UR
Análisis de datos PM
UI Design PRD
Investigación de mercado PM
Pruebas y validación PM & PRD
Redacción del planteamiento del problema PM & PRD
UX Writing UW
Roadmapping PM
Product Analytics PM & PRD
Experimentation (ej: A/B Testing) PM & PRD
PM Product Manager UW UX Writer
PRD Product Designer UR User Researcher

El papel de los Product Designers en
los rituales ágiles
En una organización de producto se producen múltiples reuniones: planificación
trimestral de grupos, rituales ágiles de equipos, reuniones de la comunidad de
práctica de Product Design, reuniones de división, etc. Si participan en todas las
instancias, los Product Designers pueden sentir que están perdiendo el tiempo en
demasiadas reuniones. Es necesario resolverlo, especialmente pensando en los
rituales de squads.
La participación de los Product Designers en los rituales de los squads depende
de la organización de Product Design. Examinaremos dos casos (detallados en
el capítulo 3): las organizaciones descentralizadas (es decir, un Product Designer
dedicado por equipo) y las organizaciones centralizadas a nivel de tribu (es decir,
Product Designers dedicados a un grupo)
Caso 1 - Organización descentralizada: un Product Designer

por equipo
Para asegurar la relevancia de su trabajo, es recomendable que el Product

Designer asista a ciertos rituales de Scrum.
Ritual Implicación del Product Designer
Daily stand-up Todos
Refinamiento del backlog Si corresponde
Sprint review Todos
Retrospectiva Todos
Sprint planning Opcional
La presencia del Product Designer en los rituales de Scrum
54
• La daily stand-up: una reunión diaria muy corta que permite intercambiar
información sobre el progreso de las tareas, los bloqueos y los eventos
importantes que se avecinan. Como miembro del equipo, es importante que
el Product Designer asista a este ritual.
• Refinamiento del backlog: este ritual permite al Product Manager presentar

los futuros elementos del backlog al equipo de desarrollo para mejorarlos,
responder a las preguntas, identificar las dependencias, los bloqueos, etc.
Es importante que el Product Designer esté presente en este momento,
especialmente cuando tiene que presentar las maquetas de las futuras
funcionalidades a los desarrolladores y explicar los principios clave de estas.
• Sprint review: la revisión del sprint marca el final de una iteración. En

presencia del equipo y de cualquier otra parte interesada, se presentan
los avances realizados durante el sprint («Demostración»), así como una
actualización del funcionamiento del producto («Examen»). Se trata de una
oportunidad para recibir opiniones o feedback, así que el Product Designer
debe estar presente.
• Retrospectiva: la retrospectiva es un gran momento de intercambio para

analizar y resolver los problemas del equipo en su conjunto. La presencia
del Product Designer es esencial en este punto, puesto que también debe ser
capaz de entender los problemas a los que se enfrentan el resto de miembros
del equipo, transmitir sus propios sentimientos y bloqueos y contribuir a la
mejora continua del equipo.
• Sprint planning: es el ritual de planificación de la siguiente iteración. La

presencia del Product Designer no siempre es relevante ya que trabaja la
mayor parte del tiempo antes del sprint, a menos que las tareas de Product
Discovery se incluyan durante este ritual.
Además de los rituales ágiles, el Product Designer puede establecer rituales de

squad relacionados con el diseño, como una revisión (Design review). Después,
puede presentar su trabajo al equipo y recoger sus comentarios. El Product
Designer también puede facilitar un lugar en común para compartir el aprendizaje
de las actividades de investigación de usuario (User Research), involucrar a los
desarrolladores en las sesiones de prueba de los usuarios, etc.

Caso 2 - Organización centralizada a nivel de grupo: Product
Designers dedicados a una tribu
Tomemos como ejemplo una organización centralizada simple, donde dos

Product Designers se dedican a una tribu compuesta de tres squads. Una solu-
ción puede ser proponer a cada diseñador que se una al squad que abordará la
mayoría de los temas que se le asignen para el próximo trimestre. De esta manera,
cada diseñador podrá compartir la vida de estos squads, mientras contribuye a
los demás de forma puntual.
El Product Designer debe participar en los rituales de daily stand-up, retrospectiva

y sprint review del equipo principal de referencia. En cuanto a los rituales de los
squads secundarios, decidirá entre ambos según la situación y si necesita acla-
rar, presentar o hacer comprender conceptos relacionados con la experiencia del
usuario (maquetas, prototipo, entrega a los desarrolladores).
Si el Product Designer ha estado involucrado y ha trabajado con otro squad en

un sprint, podría ser importante que esté presente en su retrospectiva, pues su
experiencia podría ser útil si ya se han abordado esos problemas en su equipo
principal.
Participa si
Ritual Debe participar
es relevante
No participa
Daily stand-up
Refinamiento
del backlog
Sprint review
Restrospectiva
Sprint planning
Squad de referencia La presencia

Squads del Product Designer en los rituales de Scrum
secundarios
56
Prácticas e instrumentos para una
mejor integración del trabajo de los
Product Designers
Con frecuencia, los Product Designers se ven obligados a utilizar sus propias
herramientas de diseño (que responden a las particularidades de su profesión). El
uso de diferentes herramientas suele generar una sensación de exclusión en los
Product Designers y un intercambio interminable entre los miembros del equipo,
que ralentiza el periodo de time-to-market y, por consiguiente, el time-to-impact.
Por lo general, la inercia generada acaba minando moral del equipo y el funciona-
miento del producto.
Por lo tanto, es necesario emplear herramientas comunes para promover y facili-

tar los intercambios dentro de los squads. El Product Designer debe apropiarse y
utilizar las herramientas empleadas por el resto del equipo, como la herramienta
de gestión de producto (ej: Jira + Confluence), utilizada por el Product Manager y
los desarrolladores para seguir los avances y compartir el contenido de las épicas
y las historias de usuario. También utilizará esta herramienta para completar y
validar los activos de diseño descritos en las historias de usuario. El dúo Product
Manager/Product Designer podrá así revisar las historias de usuario para validar
juntos que la Definition of Ready se respeta desde el punto de vista del diseño. En
particular, la DoR y la DoD pueden incorporar los siguientes elementos :
Definition of Ready Definition of Done

DoR DoD
Conjunto de interfaces (maquetas) Verificación de casos de uso
Casos particulares (lista vacía, campos Pruebas de casos especiales

no completados, etc.)
Cumplimiento de la interfaz y las
Especificaciones detalladas de los interacciones
elementos de animación e interacción
(en forma de prototipo o userflow) Si el nuevo componente es elegible,
transmisión al equipo de Design
Componentes del Design System
utilizados (selector de fechas, tarjetas,
elementos de formulario, etc.)
Definition of Ready y Definition of Done específicas al diseño

Además de estas prácticas, el Product Designer también debe establecer herra-
mientas para facilitar la colaboración con:
• Otros diseñadores (versioning, co-Design o diseño conjunto en tiempo real,
gestión de comentarios),
• Product Managers y partes interesadas (gestión de comentarios),
• Desarrolladores (reparto de elementos).
Si se quiere dar un paso más, también es recomendable establecer sesiones de

emparejamiento o seguimiento entre el desarrollador y el Product Designer para
que cada uno sea consciente de los problemas del otro y que puedan decidir
juntos la mejor manera de integrar los elementos intercambiables. El Product
Designer podrá así involucrar a los desarrolladores en ciertas actividades de
User Research y, de forma inversa, los desarrolladores podrán integrar al Product
Designer cuando desarrollen ciertos elementos del front-end.
En el próximo capítulo veremos que el Design System es una herramienta

que nos permite llegar aún más lejos en la colaboración entre diseñadores y
desarrolladores.
LPCx #3_Collaboration Produit/Design_Julien Pelletier @Heetch: en este vídeo,

Julien da su opinión sobre el reparto de funciones y responsabilidades entre
el Product Manager y el Product Designer y se cuestiona el futuro de estas
profesiones.
LPC 2019_Product Manager ou Product Designer ? Jeremy Barre, Head of Design

@Getaround: Jérémy presenta diferentes puntos de vista sobre los puestos de
Product Manager y Product Designer. Está convencido de que la combinación de
prismas «business first» y «user first» aporta valor a la empresa.
Blog Pendo_The Dynamic Duo - Product Management and UX: el autor da suge-
rencias sobre la mejor manera de manejar la superposición entre las actividades
del Product Manager y el Product Designer.
58
CAPÍTULO 5
¿POR QUÉ CREAR UN

DESIGN SYSTEM YA
NO ES UNA OPCIÓN?
Comment le Product Designer peut s’intégrer efficacement

dans
Pourquoi la les processus
création de Product
d’un Design SystemManagement option?? / 59
n’est plus une “agile”
¿Es el Design System algo más que un concepto de moda? En Thiga creemos
que sí. Aunque se ha escrito mucho sobre sus ventajas (hablaremos de ello más
adelante), muchas organizaciones están experimentando problemas a la hora
de implementarlo.
¿Es el Design System algo más que un concepto de moda? En Thiga creemos
que sí. Aunque se ha escrito mucho sobre sus ventajas (hablaremos de ello más
adelante), muchas organizaciones están experimentando problemas a la hora de
implementarlo.
¿Qué nos ofrece un Design System?

No hace milagros, pero un Design System puede ser especialmente útil si tienes:
• Equipos que no colaboran entre sí o no están ubicados en el mismo lugar.
• Una continua re-creación de elementos ya existentes en el lado del diseño
o desarrollo.
• Una experiencia de usuario con poca coherencia.
Lo que ofrece:
• Compartir y colaborar: los miembros del equipo de producto, diseño o
desarrollo tendrán un lenguaje común que hace los intercambios mucho
más fluidos.
• Eficacia: ¡no desperdicies más recursos! A partir de ahora, los componentes
se diseñan y desarrollan una sola vez. Se aumenta la velocidad de
producción, se reducen los costes de diseño y desarrollo, se acelera el time-
to-market y el time-to-impact.
• Enfoque: permitirá a los diseñadores dedicarse a aquello donde pueden
aportar más valor añadido (User Research, diseño de nuevas características,
etc.) evitando pasar la mayor parte de su tiempo produciendo interfaces.
• Coherencia y calidad: el usuario tiene una experiencia perfecta gracias a
comportamientos de interfaz claramente definidos, más fáciles de procesar
y asimilar cognitivamente.
60
¿Qué es un Design System?
Un poco de historia
La idea de estandarizar la identidad visual de una marca no es nueva. Ya en

1975, el Manual de identidad corporativa de la NASA (“NASA Graphics Standards
Manual”) se convirtió en el primer ejemplo de este tipo de codificación. Incluía
los logotipos, fuentes y colores que los equipos de la NASA podían utilizar, pero
también instrucciones sobre cómo utilizarlos en edificios, papelería, uniformes,
formularios, publicaciones científicas, transbordadores espaciales, etc.
La aparición de los productos digitales ha añadido una nueva dimensión técnica

a la necesidad de un único repositorio de diseño. Los elementos visuales en los
productos digitales actuales están codificados y no simplemente impresos, lo que
también significa que el diseño se actualiza con mucha más frecuencia.
El Design System, una mezcla entre lo tangible y lo intangible
Definición(es): ¿Qué es —o no es— un Design System?
Desde 1975, otras empresas han seguido el ejemplo y ha surgido el concepto

de Design System. Se llama así porque es un conjunto estructurado de recur-
sos visuales que se puede descomponer en elementos y subelementos, como un
sistema lógico o matemático. Estos elementos están interconectados, son reuti-
lizables y los adopta una comunidad de personas que están a su vez conectadas.
Tres expertos en diseño definen el Design System de la siguiente manera:
“Un Design System es un ecosistema de componentes, interfaces, directrices,

arquitectura y procesos para satisfacer los requisitos de un producto u organi-
zación, y construir un resultado deliberado.” — Teresa Mira, Diseñadora senior en
Designit NYC
“Un Design System ofrece una biblioteca de estilo visual, componentes y otras
cuestiones documentadas y publicadas por un individuo, equipo o comunidad
como herramientas de código y diseño para que la adopción de los productos
pueda ser más eficiente y coherente” — Nathan Curtis, cofundador de EightShapes
¿Por qué crear un Design System ya no es una opción? / 61

“Un Design System es la historia oficial de cómo tu organización diseña y
construye productos digitales.” — Brad Frost, diseñador web, consultor y escritor
Como habrás podido comprobar y al contrario de lo que se suele decir, un Design

System no es ni una guía de estilos ni una biblioteca de componentes, o al menos
no solo es eso. Un Design System tiene como objetivo aportar un lenguaje común
entre las diferentes profesiones y equipos de uno o más productos. Centraliza
y pone en perspectiva varios documentos construidos históricamente de forma
independiente (brand book, biblioteca de componentes, código fuente, etc.).
También permite a los equipos ser más autónomos y más eficientes en la
construcción de los productos, a la vez que libera tiempo para centrarse en otras
actividades de alto valor añadido.
Los componentes de un Design System
Un Design System es un sistema basado en elementos tangibles, como el conte-

nido, y en elementos intangibles, como los procesos (Teresa Mira, «7 requisitos de
un Design System holístico», Medium). Esto es todo lo que puede implicar:
Proceso Gobernanza
Activos Principios
de marca de diseño
Biblioteca de
Documentación
componentes
de accesibilidad
desarrollados
Componentes Documentación
gráficos de componentes
Elementos tangibles
Elementos intangibles
Sistema
Representación de un Design System
62
Elementos tangibles:
• Activos de marca (misión, valores, tono de voz, etc.).
• Principios de diseño (o principios de experiencia).
• Componentes gráficos compartidos entre los diseñadores.
• Biblioteca de componentes desarrollados (compartidos entre los
desarrolladores).
• Documentación de componentes (reglas de uso de los componentes).
• Documentación de accesibilidad (por ejemplo, el nivel de contraste entre el
texto y el fondo, los subtítulos de los videos, etc.)
Elementos intangibles:
• Proceso y gestión (presentación de un nuevo componente, actualización de
un componente existente, etc.
Componentes básicos y opcionales
Es verdad que un Design System no suele ser tan completo. Dependiendo de la

cultura, productos y madurez en el diseño, sólo ciertos elementos son relevantes.
Distinguimos tres niveles de madurez (el básico es el más común hoy en día):
Nivel básico Nivel avanzado Nivel experto

- Componentes de
desarrollo.
- Componentes de
- Componentes
desarrollo.
gráficos.
- Componentes de - Componentes
Un Design - Documentación
desarrollo. gráficos.
System se de componentes.
- Componentes - Documentación
compone de: – Principios de
gráficos. de componentes.
diseño.
- Principios de
- Activos de marca.
Elementos
diseño.
tangibles
- Documentación
de accesibilidad.
- Fuentes de los
componentes
desarrollados (Kit
HTML, CSS). Documentos Plataformas de
Se presenta en
- Fichas de diseño. y PDF(s) colaboración
forma de:
- Fuentes de los compartidos. especializadas.
componentes
gráficos (p. ej.,
.sketch, .figma).
Los miembros del Equipo dedicado al La comunidad de
intangibles
Elementos
Hecho por:
equipo de producto Design System colaboradores.
La comunidad de La communauté La comunidad de
Para servir
colaboradores de contributeurs. colaboradores
Niveles de madurez del Design System (inspirado por Nathan Curtis)

Aquí encontrarás algunos ejemplos de Design System para ilustrar los elementos
tangibles presentes en el «nivel experto»:
• Material, de Google: https://material.io/design/
• Polaris, de Shopify: https://polaris.shopify.com/
• Carbon, de IBM: https://www.carbondesignsystem.com/
• Atlassian Design, de Atlassian: https://atlassian.design/guidelines/
product/overview
Si bien la estructura de estos diferentes ejemplos es prácticamente idéntica, algu-

nos de ellos incorporan características específicas para satisfacer sus propias
necesidades:
• Directrices detalladas de interacción y Motion Design.
• Sección «cómo contribuir» para que todos puedan tener la oportunidad de
enviar cambios (adiciones, correcciones de errores, etc.).
• Elementos abiertos externamente como el kit de UI y los principios de diseño.
• Guías detalladas sobre el tono de voz (tone of voice) que se debe seguir.
¿Cómo se implementa?
En Thiga vemos la implementación de un Design System como la creación de un
nuevo producto (y no como un proyecto con fecha de finalización). Como cual-
quier producto, debe satisfacer las necesidades de un grupo objetivo determinado
(desarrolladores, diseñadores, etc.) y aportar valor a lo largo del tiempo.
Claves para empezar bien: definir un Design System
En una lógica de producto, el primer paso es establecer un registro de la forma en

que trabajan los equipos e identificar los problemas que se pueden abordar. Una
vez realizado este diagnóstico, hay que definir y priorizar los objetivos, determinar
el alcance del proyecto y, finalmente, establecer y compartir los criterios para que
el Design System cumpla con los propósitos esperados.
Una vez definidos los objetivos, te aconsejamos que definas un primer alcance para
el Design System. Igual que en el caso de un producto, la limitación del alcance y de
los elementos tangibles que se deben integrar te permitirá entregar e iterar rápida-
mente, con resultados rápidos y correcciones fáciles de aplicar.
64
Con el tiempo, este alcance se irá ampliando, teniendo siempre en cuenta los objeti-
vos fijados y los criterios de éxito.
PRINCIPALES PREGUNTAS QUE DEBEMOS

PLANTEARNOS PARA DEFINIR LA CREACIÓN DE UN
DESIGN SYSTEM
• ¿Qué problemas queremos resolver? ¿Qué desafío queremos

afrontar?
• ¿Qué queremos lograr al crear este sistema? ¿cuáles son nuestros
objetivos?
• ¿Para quién creamos el Design System? ¿Cuál es el alcance
inicial y cuál es el final? ¿Cuántos productos o equipos queremos
alinear?
• ¿Qué vamos a incluir dentro del Design System?
• ¿Cuántos productos se verán afectados por el Design System?
• ¿Qué tecnologías deberíamos utilizar?
• ¿Qué tipo de sistema o grado de coherencia queremos entre los
diferentes productos?
Por ejemplo, no es realista querer abordar todo a corto plazo si se manejan dife-
rentes productos y la cantidad de interfaces existente ya es muy grande. Otro
ejemplo podría darse en el marco de un producto centrado en la comunicación
conversacional: la integración de directrices relacionadas con el tono de voz
normalizará la forma de interactuar con los usuarios y, por lo tanto, serán consi-
derados como un must have (requisito) del Design System. Los componentes
gráficos, por su parte, pueden ser considerados como un nice to have (deseable).
Un requisito previo para definir el alcance del Design System (y convencer a la

gente de la necesidad de tenerlo) puede ser hacer un inventario de lo que ya
existe. Se trata de enumerar los diferentes patrones (componentes funcionales
recurrentes) y activos (elementos de marca, iconos, colores, etc.) que se utilizan
en el producto. Cada miembro del equipo (diseñadores, pero también desarrolla-
dores de front-end, por ejemplo) puede contribuir aportando capturas de pantalla
para catalogar los elementos existentes de manera exhaustiva.

El inventario permitirá a los equipos:
• Visualizar las incoherencias, si las hay,
• identificar los elementos que pueden reutilizarse;
• priorizar lo que se desarrollará primero.
Sentar las bases: principios de diseño y opciones tecnológicas
Los principios de diseño son la primera piedra que se coloca, incluso antes de
entrar en la fase de creación de los activos de UI. Estos principios guiarán e inspi-
rarán a los diseñadores y desarrolladores. Por ejemplo, si uno de sus principios
fundamentales es asegurar la accesibilidad de sus productos, cualquier activo
que no cumpla con el estándar que establezcas tendrá que actualizars.
CENTRARSE EN LOS PRINCIPIOS DE DISEÑO
• Los principios de diseño (también llamados principios de

experiencia) expresan una representación común de lo que es un
buen producto y no se limitan a su apariencia. Expresan lo que
realmente importa a la empresa y ayudan a tomar decisiones.
• Definen una forma de trabajar, apoyan la visión del producto, dan
forma a la cultura y reflejan los valores del equipo.
Algunos ejemplos de principios de diseño conocidos:

Material Google HTML 5
1. Material es la metáfora 1. Compatibilidad
2. Fuerte, gráfica, intencional 2. Utilidad
3. El movimiento como vector de 3. Interoperabilidad
dirección 4. Accesible universalmente
Para inspirarte y ayudarte a construir tus principios de diseño,

puedes visitar principles.design.
66
La cuestión de la elección tecnológica es clave al implantar un Design System,
pero no debería limitarlo. Tu Design System debe ser tecnológicamente agnós-
tico —es decir, estar diseñado de forma independiente de cualquier tecnología—y,
al mismo tiempo, ser compatible con las principales tecnologías punteras. Esto
crea una experiencia reconocible y específica de la plataforma. En pocas pala-
bras, le corresponde a Diseño impulsar el desarrollo, y no al revés. Las consultas
y la cooperación con el CTO y los principales involucrados son esenciales y van
mucho más allá de la primera fase de aplicación.
Establecer una organización alrededor del Design System
Para facilitar la adhesión y mantener un Design System es necesario encontrar

maneras de trabajar de forma multidisciplinar y romper así los límites organizati-
vos (diseño, marca, tecnología, etc.). Esto a menudo requiere adaptar las formas
de trabajo existentes o buscar otras nuevas.
¿Es necesario crear un equipo dedicado al Design System?
La organización que se establece alrededor del Design System es clave para su

escalabilidad. Hay dos opciones de organización:
• Modelo descentralizado o distribuido: varios miembros de los equipos de
producto tienen asignada una pequeña parte de su tiempo para trabajar en
la implementación y potenciación del Design System.
• Modelo centralizado: el Design System está a cargo de un equipo dedicado
exclusivamente a ello.
A menudo es posible probar una combinación de modelos. Por ejemplo, Salesforce

ha designado un equipo central exclusivo al sistema Lightning, con colaboradores
de toda la organización.
Con independencia del modelo de organización elegido, los perfiles profesionales

que deben participar desde el principio son los siguientes:
1. Diseñadores (Product Designers y perfiles especializados)
2. Desarrolladores,
3. Uno o más Product Managers,
4. Otros usuarios de los recursos (marketing, comunicación, etc.),
5. El CPO, en calidad de patrocinador de la iniciativa.

Los Product Designers involucrados en la construcción del Design System deben
destacar en Visual Design, diseño de interacción y arquitectura de la información.
Asimismo, los desarrolladores deben demostrar un claro interés en el desarrollo
de calidad. Puede que convenga nombrar a una persona responsable del Design
System, alguien que esté a cargo de su creación y mantenimiento, y que podrá
evangelizar sobre su interés en toda la organización.
Más allá de la asignación de recursos dedicados al Design System, establecer

una gestión clara es esencial para asegurar que el sistema pueda adaptarse al
cambio. Por ejemplo, es importante responder primero a algunas preguntas sobre
cómo se van a gestionar los cambios: ¿quién valida los cambios en el sistema?
¿Cómo se procesan las solicitudes de nuevos componentes? ¿Qué sucede cuan-
do se detectan errores o regresiones?
¿Cómo podemos hacer que los equipos se involucren?
Más importante que su creación, la clave del éxito de un Design System reside en
la capacidad del equipo para incitar a los interesados a utilizarlo. Dependiendo del
tamaño de la empresa, puede resultar difícil animar a la gente a adoptar un Design
System, que solo acabará adoptándose si se considera útil.
Para que la organización siga la dirección que el equipo ha establecido, es

necesario:
• Mantener una visión y establecer unos principios de experiencia sólidos y
compartidos.
• Conseguir que la directiva apoye su financiación para, por ejemplo, poder
dedicar una cierta capacidad al sistema a largo plazo.
• Demostrar el valor del sistema a través de un entorno de prueba para que los
usuarios puedan probarlo y aprender a manejarlo.
• Reunir los comentarios y sugerencias de los usuarios internos, como lo
harías con cualquier otro producto. Obtener esta retroalimentación es una
buena manera de comprender mejor las necesidades, identificar los posibles
problemas y mejorar el sistema.
• Evaluar la forma en que los usuarios internos utilizan el sistema mediante
entrevistas, observaciones y encuestas periódicas.
68
La comunicación también desempeña un papel fundamental en la adopción del
sistema. En particular, te recomendamos:
• Promover el sistema internamente mediante talleres, presentaciones e
incluso una plataforma de colaboración exclusiva.
• Crear y compartir una nomenclatura para los componentes del Design
System.
• Utilizar herramientas colaborativas de comunicación que incluyan a los
desarrolladores (p. ej., un canal de Slack exclusivo) para compartir los
cambios y conseguir que los usuarios y los diseñadores del sistema sigan
implicados.
• Organizar encuentros formales entre el equipo del Design System, los
usuarios y las partes interesadas para discutir lo que funciona o lo
¿CÓMO SE MIDE EL ÉXITO DE UN DESIGN SYSTEM?
El éxito de un Design System puede medirse tanto externamente (en

relación con los usuarios finales del producto) como internamente
(en relación con los equipos):
KPI relacionados con KPI relacionados con KPI relacionados
los usuarios finales los usuarios internos con la excelencia
del producto operacional
• Mejora de la calidad • Adopción del • Reducción del
y la coherencia de Design System time-to-market y del
la experiencia del por los diversos time-to-impact.
usuario (ejemplo: interesados • Aumento de la
System Usability (tecnología, diseño, productividad de
Scale). etc.). los equipos de
• Reducción del • Satisfacción del desarrollo.
número de errores. equipo con el Design • Aumento del
System (ejemplo: tiempo dedicado a
NPS). Product Discovery.
Con independencia de los indicadores claves de rendimiento (KPI)

escogidos, para poder medir el progreso es necesario antes dar los
primeros pasos de implementar el Design System.

que necesita mejorarse. También permitirá priorizar y crear un plan de
lanzamiento del Design System para que pueda satisfacer mejor las
necesidades de la empresa.
• Compartir los éxitos del Design System de forma factual, es decir, utilizando
métricas.
Como ya has podido comprobar, más allá de un conjunto de componentes gráficos
de referencia, un Design System adquiere una dimensión totalmente nueva si se
integran además otros tipos de documentación (activos de la marca, principios
de diseño, etc.). En su versión exhaustiva, el Design System se convierte en una
valiosa herramienta de comunicación interna que estandariza el lenguaje de su
empresa. También hay que tener en cuenta que para obtener el máximo valor del
Design System, este tiene que considerarse como un producto en sí mismo. Su
utilidad y su plena adopción por parte de los equipos está garantizada solo si se le
asignan recursos, se exponen sus ventajas, se mide su repercusión y se procura
mejorarlo continuamente.
Hackez le Design System: en este libro, Audrey Hacq explica de forma didáctica
cómo configurar un Design System paso a paso.
Nasa Graphic Standard Manual de 1975: manual de normas gráficas de la NASA

por Richard Danne y Bruce Blackburn. Este libro incluye escaneos del manual
original, reproducciones de la presentación original de la NASA y una lista de los
estándares gráficos originales de la NASA.
7 requirements of a holistic Design System: en este post de Medium, Teresa Mira

expone los diferentes componentes de un Design System.
“A design system is…”: Nathan Curtis publica periódicamente estudios sobre la

evolución de los Design System en Twitter.
70
GLOSARIO
Glossaire / 71
6to1: también llamado 6Up. Se trata de un taller creativo que permite a los partici-
pantes presentar rápidamente propuestas de interfaces.
AARRR: este concepto menciona cinco métricas fundamentales que definen las
diferentes etapas de la vida del usuario cuando utiliza un producto, a saber: adqui-
sición, activación, retención, ingresos, referenciación. Representado en forma de
embudo, el AARRR permite identificar los puntos fuertes y débiles del producto.
Pruebas A/B: las pruebas A/B consisten en presentar aleatoriamente diferentes

variantes de una página web o de una aplicación a un segmento de los usuarios
de un producto. Los resultados se analizan según diversos indicadores definidos
previamente con el fin de seleccionar la solución más adecuada y ofrecérsela a
todos los usuarios.
AEIOU: el modelo AEIOU se utiliza con frecuencia en la investigación con usua-

rio. Permite observar el comportamiento de los usuarios en un lugar y contexto
determinados y nos permite considerar los cinco factores externos que pueden
influir en nuestras observaciones: actividades, entornos, interacciones, objetos y
usuarios.
Big Idea: el taller de Big Idea es el último paso de la fase de diseño individual
durante un Design Sprint (después de la tormenta de ideas posterior al Crazy
8). Consiste en detallar dos o tres pantallas en papel. Esto debería permitir a los
participantes votar por las ideas más relevantes que el diseñador prototipará para
luego presentárselas a los usuarios.
Card Sorting: es un taller de creación empleado por lo general en la fase de diseño

de un producto. El mayor interés de este taller es convertir a los usuarios finales
en el punto central de reflexión y de la construcción de la arquitectura de la infor-
mación de un producto digital. Los objetivos principales de este tipo de taller son
la construcción de la estructura de árbol de un sitio o de una aplicación, la prio-
rización del contenido que se mostrará en una página y la categorización de los
elementos de navegación.
Chapter Design: en una organización de productos, una división se refiere a un

grupo de miembros de diferentes equipos que trabajan en el mismo campo o en
la misma tecnología. Una división tiene por objeto el intercambio entre parejas
72
y el intercambio de buenas prácticas. Una división de Diseño reúne a todos los
Diseñadores de un grupo.
Crazy 8: es un taller de creación que invita a los participantes a proponer ocho

ideas en ocho minutos. El objetivo es ir más allá de la idea inicial —a menudo la
menos innovadora— y proponer una gran variedad de soluciones a los distintos
problemas. Este taller se utiliza a menudo en la fase de divergencia de un Design
Sprint.
Customer eXperience: la CX, o Customer eXperience, tiene como objetivo propor-

cionar una experiencia homogénea en todos los puntos de contacto, online y
offline, que el cliente tiene con la empresa y todos los servicios que esta ofrece. A
través de todas sus acciones, el propósito final de la CX es conseguir más benefi-
cios económicos para la empresa mediante la fidelización de clientes, el fomento
de las recomendaciones, etc.
Definition of Done (DoD): es un conjunto de criterios definidos por el equipo que

determina si una historia de usuario o, por extensión, cualquier otro elemento de
una tabla Kanban, se considera que está lista..
Definition of Ready (DoR): es un conjunto de criterios definidos por el equipo que

determina si un elemento está listo para cambiar de etapa (por ejemplo, si una
historia de usuario está lista para ser introducida en un sprint).
Design System: es un conjunto de elementos de diseño y directrices que garan-

tizan una experiencia de usuario coherente respecto a un producto, particular-
mente útil en los casos en que el producto está desarrollado por un gran número
de desarrolladores y diseñadores.
DesignOps: la función principal de los DesignOps es definir procesos de trabajo

eficientes para los diseñadores dentro de una organización de producto.
DevOps: es una mentalidad y un conjunto de prácticas destinadas a mejorar la

colaboración entre los desarrolladores y los equipos de operaciones. DevOps
mejora la capacidad de una organización para entregar iteraciones de un producto
a un ritmo constante.
Glosario / 73
Epic: es un gran conjunto funcional que se puede desglosar en características,
que a su vez se pueden dividir en historias de usuario. Por ejemplo:
• Épica: gestión de la cesta.
• Funcionalidad: añadir artículos a la cesta.
• Historia de usuario: hacer clic en un botón de cada ficha de producto para
añadirlo a la cesta.
Mapa de experiencia: el método del mapa de experiencia se inspira en los mapas

de User Journey, que consisten en identificar los obstáculos y problemas que
el cliente encuentra con un producto o servicio, así como las oportunidades de
mejora e innovación.
HiPPO: el síndrome HiPPO (Highest Paid Person Opinion) se manifiesta cuando

las decisiones se basan en las opiniones de la persona mejor pagada de la organi-
zación —en ausencia de datos o a pesar de datos en sentido contrario—.
Jobs-to-be-done: teorizado por Clayton Christensen y desarrollado en su libro

“Competing against luck», el concepto job-to-be-done (a menudo abreviado como
JTBD) se refiere al propósito por el cual un cliente compra o utiliza un producto,
centrándose en un enfoque «mecánico» de las necesidades del usuario (por ejem-
plo, un usuario no quiere comprar un taladro, primero quiso perforar un agujero).
Los criterios de Bastien y Scapin: en 1993, Dominique Scapin y Christian Bastien

enumeraron todos los criterios ergonómicos dedicados a las interfaces. Todavía
hoy es una referencia en el diseño de interacción.
Las 10 reglas heurísticas de usabilidad de Jakob Nielsen: creadas en 1994 por

Jakob Nielsen, cofundador del Nielsen Norman Group, las 10 reglas heurísticas de
Nielsen son una herramienta de referencia que permite evaluar objetivamente el
uso de una HMI (Human Machine Interface, o interacción hombre-máquina). Los
Product Designers siguen utilizando esta lista con frecuencia para llevar a cabo
una auditoría exhaustiva de una interfaz.
Persona: es un arquetipo que representa a un grupo de clientes o usuarios. La

persona permite generar empatía con sus usuarios. El uso de personas es ahora
una tendencia bien establecida en el campo del desarrollo de productos digitales
a fin de mejorar la ergonomía de los productos.
74
POEMS: es una herramienta utilizada durante la investigación con usuarios, en
particular durante las sesiones de observación, con el objetivo de comprender
cómo es el producto o cómo lo utilizarán los usuarios en un contexto real. Esta
herramienta encauza la observación a través de inco temas: personas, objetos,
entorno, mensajes y servicios.
Product Discovery: las actividades de Product Discovery consisten en identificar

las necesidades de los usuarios, investigar las oportunidades de solución de los
productos y asegurarse de que estas sean las más adecuadas, tanto para el usua-
rio como para la empresa. El objetivo es garantizar la futuras épicas de la forma
más asequible posible mediante métodos inspirados en el Design Thinking y el
Lean Startup.
Product Market Fit: Marc Andreessen, quien ayudó a popularizar el término

Product Market Fit, lo define de la siguiente manera: «Un product market fit surge
cuando te colocas en el mercado con un producto que puede satisfacer dicho
mercado». El producto que reúne estas tres características — comprensión por
parte del usuario, el acto de la compra y el de compartir (boca a boca)— se vende
casi automáticamente. Al alcanzar el Product Market Fit, el esfuerzo requerido
para adquirir nuevos clientes se reducirá considerablemente.
Caso de prueba: define el conjunto de tareas que deben realizarse durante una
prueba de usuario, así como las preguntas que deben hacerse durante la sesión.
El escenario de prueba se define de acuerdo con los supuestos más importantes
que se deben probar.
Scrum: es un método de trabajo iterativo basado en los principios del Manifiesto

Ágil. El método Scrum hace hincapié en principios como la potenciación del equi-
po, la autoorganización y el horizonte jerárquico dentro del equipo, lo que hace
que sea un método difícil de adoptar dentro de una estructura poco preparada.
Service Design: tiene como objetivo ofrecer la mejor experiencia posible en cada
uno de los servicios ofrecidos por la empresa.
Squad: se refiere al equipo de implementación responsable del desarrollo y mejora

continua de un producto o funcionalidad. Incluye al menos a los desarrolladores y
a un director de producto.
Glosario / 75
Task flow: también llamado Flow Chart, el Task Flow es un diagrama que se utiliza
para ilustrar los procesos y flujos de trabajo de los usuarios en una herramienta.
Permite entender el camino típico y las acciones comunes que los usuarios reali-
zan en la interfaz.
Time-to-market: se refiere al tiempo que cuesta llevar un producto o servicio al

mercado. Es el período de tiempo necesario para elaborar un producto/servicio y
ponerlo en el mercado. Es un elemento clave que influye en la rentabilidad y una
herramienta que debe siempre adelantarse a los competidores con una produc-
ción rápida.
Tone of voice: el tono de voz o tone of voice se refiere a la percepción que el

producto enviará al usuario, su perfil o persona: ¿parece serio, divertido o «guay»?
Esto incluye la formulación del contenido que el usuario lee (en el sitio web o la
aplicación) o escucha (en el caso de un asistente de voz). La mayoría de las veces,
este elemento es responsabilidad de los equipos de producto y mediante el traba-
jo de un Product Designer y en los últimos tiempos también del UX Writer, quien
aporta ideas sobre el tono correcto que se debe adoptar en el contexto de la User
Research.
User Researcher: realiza estudios tanto cualitativos (entrevistas, observación,

inmersión) como cuantitativos. Trabaja diariamente con los equipos de datos y de
atención al cliente para recoger estos datos.
UX Writing: el UX Writing o redacción de UX es una disciplina que consiste en

mejorar la forma de diseñar una experiencia trabajando de estratégicamente en
los textos clave de las interfaces, diseñadas por un Product Designer.
Wireflow: inventado por el grupo Nielsen Norman, el término Wireflow se refiere

a la combinación de un wireframe y un flujo de usuario. Este entregable ilustra
un User Journey a través de las interacciones entre los diferentes wireframes en
forma de un diagrama de flujo.
76
Qu’est-ce qu’un Head of Product Design ? / 77
Encuentra nuestra biblioteca en
thiga.co/es
¿Quieres saber más?
Estaremos encantados de hablar contigo sobre producto.
¡Escríbenos a: hola@thiga.co!
Redefiniendo el Product Management.
Thiga España
thiga.co/es

Product Academy 4 THIGA Spain

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Product Academy 4 THIGA Spain

Cargado por

Copyright:

Formatos disponibles

PRODUCT ACADEMY VOL 4

Los autores ................................................................................................... 9

Capítulo 1: ¿Qué es un Product Designer?................................................ 15

Capítulo 2: ¿Qué es un director de Product Design? ................................ 25

Capítulo 3: ¿Cómo integrar el Product Design

Capítulo 4: ¿Cómo se puede integrar al Product Designer en

Capítulo 5: ¿Por qué crear un Design System

«Estoy cansada de escuchar a los diseñadores pedir un lugar en la mesa de

Esa conversación me traslada a los comienzos de mi carrera en Silicon Valley.

Apuesta por el diseño holístico

La toma de decisiones estratégicas es el día a día de quienes hemos conseguido

Estas habilidades se pueden aprender, adquirir y perfeccionar a lo largo de

«Juan Pablo, cuando estoy en una reunión en Google, no sé quién es el ingeniero,

Actuar como factor de cambio

Hace un tiempo, en Jeff, detectamos que a los squads le faltaba un «framework»

Entonces, el equipo de diseño tomó el liderazgo para desarrollar los Principios

Lo que hacemos realmente importa

Entender el impacto que podemos tener a través del diseño es fundamental. Es

Mientras nos encaminamos a la profesionalización, lo habitual será encontrarse

Thiga es una consultoría internacional de Product

Estamos convencidos de que nuestros empleados son el elemento clave que

Pasamos gran parte de nuestro tiempo transmitiendo todo lo que sabemos en

Contamos con la gran experiencia de una consultoría y la mentalidad de una

Ayudamos a las empresas a construir productos digitales de éxito mediante los

Muchas gracias también a Juan Pablo Costanzo, que no se lo pensó ni un segundo

Este nuevo libro se centra en el Product Design. Muchos podrían preguntarse si

Además, en todos nuestros proyectos observamos que los equipos de producto

Este libro pretende ser accionable, no dogmático. Nuestro pensamiento se basa

El objetivo de la CX (o Customer eXperience) es proporcionar una experiencia

En el caso de Uber, los puntos de contacto son diversos y la Customer eXperience

• Tener en cuenta los retos comerciales de la empresa, además de las

• Adoptar una visión global de producto a la hora de tomar decisiones. Y es

• Trabajar en equipos de producto orientados a resultados. Como el resto del

Representación de las disciplinas del diseño según la experiencia de Albina Chola

En resumen: el Product Design es una evolución del UX Design basado en la

Qu’est-ce qu’un Product Designer ? / 15

En Thiga, consideramos que la característica principal de un Product Designer

User Research Soft Skills

Product Ownership Desarrollo

Framework del Product Designer

Basándonos en esta convicción, hemos creado un modelo de competencias

Más allá de todas estas habilidades, el Product Designer domina la cultura de

Las hard skills del Product Designer

Durante una sesión de observación, el Product Designer se pone en el papel de un

¿Qué es un Product Designer? / 17

Además de las observaciones y entrevistas, la tercera forma de contacto con los

El Product Designer recurre a observaciones, entrevistas y pruebas de usuario

La facilitación es un conjunto de técnicas que ayudan a un grupo a alcanzar un

Para poder hacerlo:

Recordemos que el reto de los talleres de concepción conjunta es conseguir que

Adentrémonos ahora en el corazón del diseño. El Product Designer toma los

¿Qué es un Product Designer? / 19

Analicemos ahora en detalle las habilidades de concepción: ideación, evaluación

La ideación consiste en confiar en el User Research para obtener ideas concretas

Recordemos que el Product Designer está iterando constantemente sobre su

Todo Product Designer sabe priorizar la información presente en sus interfaces:

Cuanta más experiencia adquiera, mayor será la diversidad de contenidos que

Para comprender e ilustrar todas las interacciones del usuario dentro de un

Basándose en todo el trabajo previo, el Product Designer crea los wireframes de

La concepción requiere pocas habilidades de UI porque el trabajo gira en torno a

¿Qué es un Product Designer? / 21

El Product Designer define las diferentes interacciones entre el usuario y el

Y para poner el broche de oro

En las empresas orientadas al producto, el Product Designer forma parte del