Lo que me enseño el libro de Tony Fadell sobre el diseño de producto
Claridad en lo que quieres resolver, narrativa y cuidado en el todo.
Ed. 41
Nota: En el artículo hablo de manera indistinta de clientes y usuarios para quiero referirme a aquellos que usan nuestro producto
Me devoré Build, el libro de Tony (también en versión es español), tiene esa facilidad de contar historias, de decirte como ha sido su vida y al mismo tiempo guiarte y enseñarte del diseño de producto y de los equipos que hace posible esas cosas.
Para que los que no lo sepan, Tony Fadell es conocido por haber trabajado en Apple en el diseñado el iPod, aunque claro, como el mismo lo dice, los grandes productos nunca son autoría de una sola persona, son resultado de la colaboración y el trabajo en equipo. Después de Apple, fundó Nest, que fue vendida a Google por 3200 millones de dólares.
Al final del libro Kindle me entregó de 16 páginas de notas… 119 segmentos subrayados, hay mucho para releer y para siempre tenerlos con un pin mental, por ahora quiero enfocarme en algunas cosas del proceso del diseño de un producto.
Cuando inicias con una idea
“Si no resuelves un problema real, no puedes iniciar una revolución”
Tony es implacable y pragmático, para él, el producto nace de entender una necesidad real y obsesionarte por resolverla, si no resuelves un problema real, tu producto no va a trascender.
No está hablando que tu proyecto deba curar el cáncer, está hablando de que debe de provenir de una necesidad o un problema con el cual los usuarios están lidiando en su día a día, arreglar eso debería ser tu obsesión, permitiéndoles hacerlo de forma más eficiente,
“No me digas qué tiene de especial este objeto. Dime qué cambiará para el cliente”
Cuando estamos desarrollando un producto tendemos a pensar en la solución, nuestra narrativa se basa en describir la tecnología, y sin querer asumimos que esa diferenciación es la historia que hay que contarles a nuestros clientes.
Y la verdad es que poco importa como desarrollamos nuestro producto, si no podemos ser claros en cuál es el beneficio para el cliente, la gente no compra taladros, la gente no quiere hacer hoyos en la pared de forma sencilla, la gente quiere colgar cuadros en su pared, lo demás es solo un medio para lograrlo.
Es ahí donde Tony nos Invita a investigar sobre nuestros usuarios/clientes y asegurarnos de conocerlos, de conocerlo en un sentido demográfico, pero también en un sentido cualitativo, son personas, con problemas, si lo dejas de ver como estadística será más sencillo que tengas empatía y resuelvas problemas de forma más efectiva.
De Cero a Uno.
Y aunque nos invita a tener data para validar y respaldar nuestras decisiones, también deja claro que a veces se trata de un salto de fe, sobre todo cuando tu producto es una versión nueva, cuando no tienes experiencias previas precisas que te garanticen resultados.
“Si un producto es realmente nuevo, no hay nada con que compararlo, nada que optimizar y nada que poner a prueba. En estos momentos es tu responsabilidad como gerente o jefe explicar que el equipo no es una democracia, que es una decisión basada en la opinión y que no vas a llegar a la decisión correcta por consenso. Pero tampoco es una dictadura. No puedes dar órdenes sin explicarte.”
Pero no malentiendas las cosas, se trata de no tener parálisis por falta o sobre exposición de datos, de no tomar decisiones solo porque los datos no garantizan algo de forma factible. La data muestra lo que está mal, pero no siempre nos dice como solucionarlo.
Tony tiende a tener esta ambivalencia y esta mirada holística, a decirte que tienes que ver el horizonte completo si dejar de lado los detalles, no se trata de tener soluciones idealizadas, incapaces de llevarse a cabo, ni soluciones tan poco sofisticadas que apelan a solo lo que se puede hacer ahora y que pasan desapercibidas. Justo es ahí donde el diseño sucede, cuando somos capaces de entender las limitaciones y nuestro objetivo, cuando somos capaces de entender que no todo es perfecto, nunca lo será, pero siempre, también, es perfectible.
Después de lanzar una primera versión de tu nuevo producto, todo se trata de versiones incrementales, es más sencillo entender que necesitamos hacer, porque por fin este producto se enfrentó a los usuarios, es más sencillo crear un roadmap con este feedback, no deja de ser complejo el diseño y lanzamiento de las siguientes versiones, pero es un poco más certero.
El valor de una buena historia
La narrativa o el storytelling está en el núcleo del diseño, no hay forma de llevar a cabo buen diseño si no podemos comunicarlos de forma clara y sencilla.
El diseño puede ser intuitivo y hablar por sí mismo, pero Tony no se refiere a describir lo que nuestro diseño hace, ni a contar historias fantásticas solo para cubrir expectativas que nunca se van a cumplir.
En realidad, habla de un storytelling como una forma de acercarnos con claridad nuestro objetivo como organización que busca crear y desarrollar un producto.
“Todo producto debe tener una historia, un relato que explique por qué tiene que existir y cómo resolverá los problemas de tu cliente.”
Si logramos crear una historia consistente y verdadera sobre nuestro producto, será más sencillo que el equipo tenga claridad sobre lo que se busca cuando haya crisis o ambigüedades.
Si lo hemos asimilado e internalizado y es real, nuestro producto será un reflejo de ello, la experiencia que otorguemos será igual de consistente y ahora no solo nuestro equipo; sino nuestros clientes, serán los que asimilen esta historia y se apropien de ella. Cuando ven el valor en nuestro producto salen a compartirlo con su círculo más cercano y con esta misma historia.
La experiencia como un todo
“El cliente no diferencia entre la publicidad, la aplicación y la atención al cliente. Todo forma parte de tu empresa. De tu marca. Todo es uno.”
Y estas es una de las posturas que más me hizo sentido, que es obvia, pero la olvidamos.
Podemos caer en falsos dogmatismos, vivir en una burbuja, asumirnos como dueños de la experiencia, cuando quizás solo somos habilitadores y responsables de un fragmento que es parte de un sistema más grande.
Pero para el cliente, no hay diferencia, lo mismo da si es el vendedor que lo atendió para obtener el producto, si está abriendo nuestro producto, descargando nuestra app e iniciando sesión por primera vez, si este funciona perfectamente, o si necesita llamar a la gente de soporte para resolver un problema e incluso cuando cancela. Para el cliente es la misma experiencia, y la experiencia completa es lo que hay que mirar.
Es ahí donde hace tanto sentido el hecho de invitarnos a mirar el todo sin perder detalles, e incluso obsesionarnos con conocer esos detalles, cómo lo hace en realidad el usuario y cómo cuido la experiencia completa, estos son detalles aburridos que a veces nos queremos mirar, pero es necesario hacerlo y no solo centrarnos en lo seductor del proyecto.
Si, ya sé, si estás leyendo esto, quizás no eres ni de lejos el director del área o el CEO de donde trabajas, pero tener claro este mindset nos ayudará a entender que es centrado en nuestros clientes y/o usuarios y no centrados en el diseño, la experiencia sucede antes y después de ti, no eres el dueño o protagonista eres un habilitador.
Nos vemos en la siguiente edición…
Quizás podríamos escribir sobre lo que este mismo libro me enseñó sobre los equipos que hacen productos, díganme si les interesaría, ¡Dejen comentarios!
Para Leer 👀
Why do they ignore my awesome design documentation?
¿Por qué nadie lee nuestra documentación? Para aquellos que trabajan en Design Systems y en procesos de Handoff, este artículo es una gran referencia de buenas prácticas para mantener a todo tu team involucrado y hacer documentación eficaz