La intuición no aplica en Ontruck

Seguimos con los post de la masterclass de @nachogil (diseñador de producto en Ontruck) en Factorystartup tocando ahora el tema de cómo realizan el proceso de diseño de producto.

Nacho nos cuenta el proceso de 8 pasos que siguen con cada nuevo desarrollo o proyecto basado en las características del producto de Ontruck.

Los 3 productos de Ontruck no son para cualaquier usuario. Es decir, no es un producto genérico tipo Facebook o Gmail. Con lo cual, el equipo de producto no es usuario de su producto, por lo que basan su aprendizaje en ser humildes y escuchar.

Eso les obliga a construir el producto que necesitan nuestros usuarios.

1. Comprender

  • Las ideas o problemas proviene de cualquiera.
  • Lo primero que hay que hacer es entender el problema.
  • No se piden soluciones, se plantean problemas. Las soluciones están sesgadas por la persona que las propone. Por cómo ve el problema, por cómo le afecta.
  • Nos importan los problemas, no las soluciones. Los problemas son más fáciles de compartir y discutir.
  • Observamos a los usuarios para comprender sus necesidades.

Y dijo esta frase que más valdría que muchas personas que cuestionan el coste de la UX y los métodos de research (investigación) deberían tener en cuenta:

Perder 1 día en ver y hablar con varios clientes te evita gastar 1 mes en desarrollo.

Clarito, ¿no?

2. Divergir

Una vez definido el problema, en una sesión de 2 horas, se reune todo el equipo (desarrollo, diseño y producto) e intentan pensar en soluciones obvias. El objetivo es intentar no seguir esas ideas, y generar entre todos la mayor capacidad de innovación.

Crazy Eights

Para ello, para diverger, y generar el mayor número de posibles soluciones, aplican técnicas para divergir y encontrar otras ideas, como Crazy Eights, Mapas mentales, Mapas de empatía,  How Might we…? o simplemente coger post-its y poner ideas y luego clasificarlas…

3. Decidir

En esta etapa el objetico es de las ideas viables que entran en scope clasificarlas y quedarse con una. Para ello:

  • Se decide el alcance del proyecto (scope).
  • Siempre se orientan a reducir el desarrollo. Mínimo desarrollo posible en todo (minimal waste, puro lean!), tanto en diseño como en código. Si puedes falsear la solución con algo manual, comprueba que es la adecuada y ya invierte el tiempo en hacerlo.
  • Se comparte con Tech, QA, Operaciones, Ventas y Mkt.
  • El resultado suele ser un plan para dividir el proyecto en varias fases.

Desarrollo de producto Lean

Ese plan siempre comienza con un MVP (Minimuml Viable Product) que si se puede hacer sin pintar pantallas y sin tirar código mejor.

Para ellos lo más importante es el flujo de interacciones y procesos para que todos estén alineados con el caso de uso a resolver. Eso lo desarrollan comenzando con una pizarra y los pasan a Draw.io en un modelo BPMN (Business Process Modeling Notation). Gracias a eso toda la empresa trabaje con los mismos flujos en esa plataforma, mapeando toda la compañía en capas.

BPMN

Por ejemplo, la capa de visual, tiene un botón que lanza hacer “X” en la capa de Desarrollo porque usa no se que cosa de un servidor, que activa la capa de Marketing que lanza un email a cliente.

El modelo BPMN es un mapa de la empresa y sus procesos.

En Ontruck es tan importante que tienen una persona de ingeniería de procesos dedicada a ello, implantandolo.

Y es que ahorra muchos problemas relativos al crecimiento del producto. Te hace pensar, ¿si cambio e introduzco una feature nueva, ¿qué pasa? Está todo registrado y disponible para mirarlo al alcance de todos.

En ese momento se deciden los KPI a mejorar y medir.

4. Prototipar

Solo después de haber reducido el alcance y haber implementado el proyecto en fases se comienza a diseñar, siempre con el pensamiento de mínimo desperdicio.Sino es necesario un prototipo no se hace. De hacer lo mínimo posible para probar esa hipótesis.

Prototipar

Lo hacen en papel, y de ahí a Sketch, y los prototipos de flujos básicos en Marvel.Para documentar con front usan Zeplin y siempre se comprueba con desarrollo que es factible.

5. Testear

Prueban todas las nuevas funcionalidades con usuarios internos y externos, visitando con el prototipo clientes, conductores y operaciones (internos).

Cómo imaginereís son visitas súper útiles para obtener descubrimientos, comentarios e impresiones generales, y siempre vuelven con aprendizajes.

6. Construir

Una vez cómodos con las interacciones y los diseños, se hace una revisión con desarrollo para discutir el proyecto y responder a las preguntas que puedan quedar.

Este proceso es rápido, ya que han sido parte del proceso del producto desde el principio por lo que quedan pocas preguntas

Desrrollo se reúne y redacta y estima las User Stories, decidiendo que US se cubren en la 1º fase.

Cada persona de desarrollo y producto es responsable de la calidad del proyecto.

Tienen un Design System (uno para cada plataforma: camioneros, clientes, y operaciones) con todos los elementos de la interfaz creado sen Sketch como símbolos. Hasta los colores y las tipos. Todos los elementos están modularizados.

Actualmente el equipo de front está haciendo el equivalente en React.

7. Lanzar

Una vez validado por producto, se lanza, pero antes se hace una demo a toda la empresa. Esto tienen 2 objetivos:

  1. Explicarlo a Operaciones, ventas y marketing.
  2. Hacer equipo.

La demo la hace gente aleatoria de operaciones o ventas que no conocen la funcionalidad. Por lo que sirve de test con usuarios en vivo y en directo, pidiendo que hagan una tarea.

Esta prueba real verifica si se ha realizado un buen trabajo en producto y sirve para detectar pequeñas cosas que necesitan cambiar antes de implementar.

Este proceso de comunicación que muchas empresas se saltan para mi es vital.

He estado en compañías donde desarrollo implementaba por ejemplo, el pago por PayPal y Call Center no era avisado, informado ni enseñado. Cuando los clientes llamaban, preguntando por ello, atención al cliente se saturó de llamadas esa semana, sin saber qué decir, con el consiguiente mal rollo y desalineamiento entre equipos distintos.

8. Medir

En los días/semanas posteriores al lanzamiento siguen  el progreso de la funcionalidad con 2 enfoques:

  1. Cualitativo: Llamando a clientes o hablar con soporte
  2. Cuantitativo: usando herramientas como Tableau y Amplitud (para sacar datos de mobile).

Si los comentarios no son buenos, consideran una iteración para los siguientes Sprints. Nacho nos recomienda que ojo con saber analizar el feedback, ya que las personas siempre ofrecen resistencia al cambio o puede ser algo proveniente de las necesidades de negocio.

Su reto para 2018 es dejar de diseñar y empezar a pintar flujos e interacciones.

Disponen de equipo de BI que se dedica a la analítica, pero todo el mundo mide. Para no depender de nadie al construir las hipótesis.

No dedicar un minuto a algo que te vaya a ayudar a mejorar el negocio es un recurso perdido.

Producto is the new boss

Nacho nos lanzaba esta pregunta: ¿debe producto liderar una empresa? dando respuestas con las que estoy muy de acuerdo (y de ahí mi interés en ser product manager).

  • Tiene una visión global de la empresa porque habla con todos
  • Es User centered
  • Problem Solve Oriented
  • Tech Conscious
  • No tiene presión de ventas
  • Pone foco a medio y largo plazo
  • Es más cauteloso a la hora de añadir complejidad que otros departamentos (por pura supervivencia)

¿Metodología o resultados?

Nacho acaba con esta frase:

La metodología es el reducto de los mediocres.

Comentando que los resultados son medibles en negocio, las metodologías no. Los resultados pueden ser buenos, malos o regulares, hay que vivir con ello.

Metodologia o resultados

Yo no se si estaba ya muy cansada (eran ya las 19:45) pero no entendí muy bien que querñia decir con esa frase exactamente Es decir, según la RAE, la metodología es un conjunto de métodos que se siguen en una investigación científica.

Metodologia

Entiendo que para obtener un resultado.

Lógicamente, si ese resultado no se obtiene y se excusa en la metodología, mal. Se cambia el método de investigación, se modifíca, se prueba otras cosas. Pero algún método de una forma u otra se usará. Si Nacho u otra persona quiere explicar mejor a que se refiere se lo agradeceré 🙂

Lo importante es hacer y aprender, cuestionar continuamente el por qué. Y eso tiene mucho que ver con la cultura de empresa.

¿Qué esperas de tu plantilla?

Toyotismo (Kansei) vs Fordismo (Taylor)

toyotismo y fordismo

¿Qué sepan apretar un botón o qué proponga como hacerlo?

Yo lo tengo claro. ¿Y tú?

Gracias Nacho por compartir tooooodo este conocimiento que he tenido que dividir en 4 posts 😉

Os dejo los enlaces a los post anteriores:

Nota: todas las imágenes excepto la de la RAE están tomadas durante la presentación de Nacho Gil.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *