el mejor momento para probar una idea es lo antes posible

Artemio: Hola, ¿qué tal? Bienvenidos a Cuando El Río Suena, el podcast en el que invitamos a expertos y profesionales del mundo de la tecnología y de la innovación para que compartan con nosotros sus mejores insights en este camino en el que nos encontramos las personas que estamos aquí en este podcast y toda su audiencia, que es el de construir un negocio saludable de internet. El día de hoy me acompaña mi socio Rodrigo Salmerón, como ya es costumbre, ¿cómo estás, Ro?

Rodrigo: ¿Qué tal? Muy bien

Artemio: Qué gusto, hermano, un día más de grabación, el sol no nos acaricia los rostros porque ahora cerramos las cortinas y montamos nuestro bellísimo estudio. Por favor, vayan a YouTube a ver cómo nos quedó nuestro background y la producción que preparamos para ustedes en video.

Y también, el día de hoy nos acompaña Laura Angulo. ¡Hola, Laura! ¿Cómo estás?

Laura: Muy bien, gracias.

Artemio: ¿Desde dónde te estás conectando geográficamente en este instante?

Laura: Desde Bogotá, Colombia.

¿Cuál es el pitch de elevador de Liftit?

Artemio: Fantástico. Laura es parte de Liftit. Para arrancar y para estar todos en la misma página, Laura, ¿podrías contarnos cuál es el pitch de elevador de Liftit?

Laura: Es algo muy pegadizo que normalmente lo utilizamos cada vez que nos hacen esa pregunta. Somos la startup que hace la logística simple a nivel LATAM, eso sería el pitch.

Artemio: ¿Y eso qué implica? Porque vimos en su sitio web que hacían servicios de primera milla, última milla, storage. ¿Nos podrías contar un poquito más de estos servicios que tienen?

Laura: De manera general, Liftit es una startup enfocada totalmente en la logística, pero esa logística involucra muchos stages, desde la primera milla, mediana milla y la última milla. Estamos a nivel LATAM en más de cinco países, pero nuestro foco ideal es el desarrollo de productos y la tecnología. ¿Cómo los productos y la tecnología nos pueden ayudar a que esa logística sea mucho más sencilla para llegar al cliente final o a esos clientes intermedios que están dentro de ese proceso logístico y que muchas veces no sabemos que existen? Ahí estamos nosotros.

Artemio: Ustedes están en estos cinco países. Si yo estoy en un pueblo recóndito de México, tengo mi negocio que necesita de un componente de logística, ¿ustedes podrían ayudarme a llevar mis productos al Perú o a alguno de los otros países en los que están ustedes? ¿O funcionan regionalmente?

Laura: Funcionamos regionalmente. Por ejemplo, también estamos en México, entonces hacemos la logística de grandes empresas como Mercado Libre, a quien nosotros le hacemos todos esos procesos, si tú haces un pedido dentro de Mercado Libre, seguramente llega alguien de Liftit para entregarte tu pedido.

¿Cuál es el papel de la Head of Product Design de Liftit?

Artemio: Creo que no había dicho cuál es tu posición en Liftit, Laura es Head of Product Design y es lo que te trae a la mesa el día de hoy a compartir a ver qué es lo que puedes darle a nuestra comunidad de valor y qué es lo que podemos abstraer de tu cabeza.

Rodrigo: Para esto, te queríamos preguntar, ¿cuál es tu papel como Head of Product Design ahí en Liftit? ¿Qué es lo que haces todos los días?

Laura: Lo que hago todos los días es de todo un poco, sobre todo porque el producto que nosotros hacemos siempre va a ser el producto final que se le entrega al usuario. En nuestro caso es la app que usan los conductores, el sistema que utiliza el cliente, como lo son los planeadores de rutas. Internamente, también manejamos diferentes tipos de productos, entre ellos, hasta los que menos piensas, todos los productos financieros, lo que sean sistemas contables, lo que nos ayuda a realizar una facturación de manera automática, que pueda agilizar los procesos de liquidar a los Lifters (que son los conductores) y, como hay de todo, hay de todos los temas por abarcar.

Puede que sea un día bastante ajetreado, pero es sustancioso a final de cuentas. Ya depende en qué nos enfoquemos, lo que queramos hacer de nuevas funcionalidades o enfoques dentro de temas específicos, y eso es mi día a día. A final de cuentas, ya depende de cómo se manejen y lo que queramos sacar. Siempre, cuando utilizamos una metodología ágil, todos para allá, pero se intenta lograr lo que se pueda dentro de una metodología.

Rodrigo: Qué interesante, ¿entonces ustedes tienen interiorizados sus procesos contables y de facturación? ¿Son desarrollos, productos propios de Liftit?

Laura: Sí. También tenemos el ideal de estos productos back office porque son productos que no están directamente con el cliente, sino con nosotros mismos. Utilizamos la tecnología para nosotros mismos para hacer procesos internos, como onbording de Lifters, hacer procesos de estudios de seguridad para las personas nuevas que entran a la aplicación, intentamos utilizar nuestra propia tecnología y también otro tipo de startups que nos apoyen dentro de estos procesos internos.

¿Cómo deciden en Liftit cuál será el siguiente producto a desarrollar?

Artemio: Oye, Laura, esta pregunta que voy a hacer se liga muchísimo a la siguiente que tenemos aquí en nuestro pequeño guion. Me interesa mucho ¿cómo es que ustedes deciden qué producto o qué feature desarrollar después? ¿Esto viene desde el Head of Product o viene en materia de iniciativas de las mismas escuadras de producto? ¿Cómo deciden cuál es el siguiente business challenge a taclear desde la tecnología?

Laura: El Head of Product se compone por tecnología, donde está toda el área de ingeniería, también está la parte de diseño y una parte de producto. Digamos que las tres hacemos una convergencia total y empezamos una pequeña discusión de qué nos puede aportar y cada uno entregando en cada una de las áreas, puede ser un enfoque de negocio, un enfoque del usuario (que es lo que tenemos dentro de diseño) y un enfoque dentro de la funcionalidad misma que se necesita. A veces son conversaciones bastante amplias, intentamos hacer un roadmap que abarque el año completo para decir “estas van a ser las funcionalidades que tenemos en foco y en meta para nuestro año”, y todos nos alineamos dentro de ese proceso para poder lograr.

Como también tenemos esos diferentes tipos de enfoques, siempre van a haber muchos que van a ser simultáneos. Dando un ejemplo, si vamos a sacar una nueva funcionalidad dentro de la app para que el Lifter pueda reconocer geográficamente dónde se encuentra o que la aplicación le diga “ya estás llegando al lugar de destino”, eso también conlleva a que otras funcionalidades dentro de otros productos también salgan. Entonces, si yo saco esa funcionalidad, el cliente también tiene que verlo reflejado en alguna parte dentro de nuestro sistema, nosotros le llamamos el LMS, el Lifter Management System, donde el cliente puede tener una vista de su operación y también eso repercute en nuestra parte financiera de mostrarle cómo es el flete, el proceso, cómo lo podemos liquidar, cuándo se termina el proceso logístico o la entrega. Es una cadena tras de otra y lo que intentamos hacer es que esos productos se vuelvan un sistema.

¿Cómo se conforma el equipo de Producto en Liftit?

Artemio: Qué interesante. Y, para no salirnos de guion, ¿cómo es que se conforma el equipo de producto en la empresa? Porque ahorita mencionaste que tienen estas tres áreas de Producto, me imagino que está retacado de Product Managers; Diseño, lleno de Product Designers; y de Desarrollo lleno de desarrolladores. Cuéntanos un poquito de la pata que tú lideras, ¿cómo está conformado el equipo de Diseño y cómo se distribuyen en su startup?

Laura: Mi equipo de diseño está enfocado en dos cosas: toda la parte de investigación o user research, ellos se encargan desde la investigación de primera categoría, desde que se acercan a los usuarios, tienen una conversación continua con ellos y, como estamos a nivel LATAM, también estamos con toda la tecnología que nos pueda ayudar para tener el contacto con ellos.

Estamos en diferentes países, eso significa diferentes culturas y diferentes formas de ver tanto la logística como el proceso de la tecnología. Siempre estamos súper actualizados y cada uno de esos temas tiene su propio research que lo acompaña y también nos entrega insights para poder respaldar cierto tipo de funcionalidades que tengamos que sacar, ya hablando un poco más de datos cualitativos o cuantitativos, eso nos ayuda a tomar decisiones muy importantes dentro del área.

Y tenemos los UI, o design y toda la parte visual y de diseño, el design system, la creación visual tanto del sistema de LMS, la aplicación, todos los productos que tengamos reflejan lo que hace el UX y el research y lo traen a una parte más visual.

¿Cómo se mantiene el control a lo largo de todos los equipos de Diseño en Liftit?

Rodrigo: Aquí te queríamos preguntar, nos cuentas que hacen esta planeación anual entonces ya tienen un poco previstos en qué funcionalidades, features o challenges van a estar resolviendo durante el año. Si están haciendo research todo el tiempo, van sacando nuevos insights, van descubriendo cosas nuevas, ¿cómo le haces para mantener el control a lo largo de todos los equipos de diseño con esto? Ya tienes una planeación pero, al mismo tiempo estás consiguiendo nueva data valiosa que hay que, de alguna forma, integrar en el workflow, ¿cómo haces esto?

Artemio: También cada equipo está muy concentrado en el feature o en el challenge que está resolviendo y me imagino que tú tendrás de repente la cabeza por todos lados, ¿cómo mantienes este control?

Laura: Es cierto, tenemos todo al mismo tiempo pero, de igual manera, tenemos que ser muy ordenados porque nosotros debemos tener ya la información lista antes de que esa nueva funcionalidad entre dentro de la planeación. Digamos que nosotros debemos reconocer ese proceso de investigación, ver qué necesita el usuario, centrarnos desde el usuario mismo y su necesidad. A veces también el usuario no sabe qué quiere pero podemos llegar a lo que realmente necesita.

Tendemos a estar mucho más adelantados que la planeación misma. Cuando ya estamos dentro de la planeación, nosotros ya hemos hecho ese proceso o estamos terminando ese proceso de investigación, entonces siempre estamos mucho más adelantados que el proceso de encontrar la funcionalidad o la necesidad y resolverla porque hay problemas y no todos los problemas son de diseño y debemos saber en cuál podemos contribuir nosotros para hacerle la vida más fácil a nuestros clientes y también a nuestros usuarios internos, que también son muy importantes para nosotros.

Artemio: Entiendo. Precisamente como mencionas, casi siempre hay implicaciones que no tienen que ver meramente con el diseño o con su usabilidad y tienen que considerar un chorro de cosas, hasta si la gente de finanzas le hace sentido los recursos que se van a emplear en esa iniciativa, si desarrollo es capaz o conoce las tecnologías cuando se pone truculenta la cosa, pueden ser mil cosas las que paren o detengan una idea.

¿Cómo es el proceso de generación y validación de ideas en Liftit?

Artemio: Algo que nos gusa mucho hacer aquí en el estudio de producto es siempre comunicar las ideas de diseño desde prototipos y probar, ver si funcionan o no funcionan y eso mostrarlo a los stakeholders identificados. ¿Esto es algo que hacen ustedes en esta parte de research? ¿O no realmente? ¿Cómo es su proceso de validación o generación de ideas? Tal vez un pasito antes de decir “se va a hacer esto”, y es el “okay, existe esta idea desde el lado de diseño”, ¿cómo comunican ustedes esto? ¿Hacen prototipos o meramente se pone sobre la mesa, se aprueba y ya van a hacer un prototipo?

Laura: Ese es el camino feliz, ojalá todo fuera así, pero no. Nosotros tenemos un proceso interno que se llama el Álbum de Problemas. El Álbum de Problemas es que nuestro proceso de investigación siempre parte de un problema, pero tenemos que saber si ese problema es de diseño. Entonces, los chicos ya llegan con la idea de “tenemos este problema”, nos sentamos en la mesa a ver si realmente corresponde a un problema de diseño. ¿Cómo sabemos si es un problema de diseño? Porque debe tener tres factores importantes: una población que debe estar afectada, el problema como tal, que es una necesidad; y el lugar donde está ese problema.

Si ese problema se enfoca, por ejemplo, en que el área financiera de Liftit en Colombia tiene problemas para sacar las facturas de tal cliente, ya tenemos los tres stages y vemos cómo, es ese proceso de facturación de Colombia, cuáles son los usuarios, el contexto y el problema aquí es poder generar la factura, ya sea porque el sistema contable no está conectado o porque está conectado pero no se visualiza nuestra factura dentro del sistema o no está automatizado, puede haber muchos factores.

Nosotros empezamos a buscar cuáles son las causas de ese problema y cuáles son las consecuencias. Si ya tenemos causas, un problema y una consecuencia, tenemos una línea de investigación. En esa línea de investigación podemos formular las hipótesis y el objetivo para poder resolver ese problema y ya está totalmente enfocado a nuestra área y es un problema de diseño.

Rodrigo: Y cuando detectan que no es un problema de diseño, ¿qué hacen? ¿Lo pasan al área correspondiente o continúan buscando?

Laura: Son procesos que también, cuando vemos que existen, los comunicamos a las demás áreas. Y, el área que tiene ese problema, normalmente ya lo tiene interiorizado y ellos tratan de escalarlo. Cuando llega a nosotros es cuando revisamos si podemos hacer algo y, en caso de que no sea directamente de diseño sino que sea una integración con una plataforma o con el cliente, ya pasa a ingeniería y así vamos viendo dentro de cada uno de las áreas correspondientes. Lo importante es que se vea ese problema y que se tenga en cuenta.

Artemio: 100%, siempre es mejor tener los problemas sobre la mesa que escondidos abajo de la almohada o ahí abajo del tapete, donde sea que se te ocurra.

¿Qué es lo más valioso que ha aprendido Laura Angulo de los usuarios de Liftit?

Rodrigo: Laura, retomando la conversación, queríamos preguntarte, ustedes hacen un trabajo muy serio de UX research que no para y que están buscando todo el tiempo aprender más de sus usuarios. ¿Nos podrías contar algo valioso que hayan aprendido específicamente de los usuarios de Liftit? Que digan “esta es la razón por la que estamos haciendo la investigación”.

Laura: Cuando yo entré a Liftit hace más o menos tres años, el proceso de investigación apenas comenzaba, era el proceso de transformación de la misma tecnología. Liftit también es una startup bastante reciente y su crecimiento ha sido exponencial y, así como tan rápido tenía que crecer, también la tecnología tenía que crecer con ella. Eso hizo que el equipo de diseño empezara a tener ese reconocimiento porque, para la creación de un producto, se necesita todo un proceso o una metodología que, en nuestro caso, es totalmente centrada en el usuario. Es cierto que no sabemos, a veces el usuario sabe qué necesita, a veces no, y ahí está nuestra tarea de encontrar realmente su necesidad, resolver su problema y, desde diseño mismo, encontrar esa solución.

Tengo anécdotas bastante curiosas. Hemos tenido, enfocado más a la parte financiera porque a veces tiende a ser la parte más complicada porque involucra números, siempre tenemos y estamos acostumbrados a tener un proceso totalmente manual, es decir, por ejemplo, si tenemos una base de datos donde queremos sacar las facturas, normalmente utilizamos el Excel para poder tener esa base de datos u otra plataforma, pero siempre es centrado en todos los días una persona sentada imprime hojas para sacarme cuántas facturas podemos hacer porque se factura por servicio o por la recopilación de ese tipo de servicio. Y, si tenemos clientes que hacen cinco mil, 20 mil, 10 mil servicios, se imaginarán lo complejo que es llevarlo y también que una misma persona la lleve.

Cuando yo vi el proceso por primera vez, me sorprendió demasiado porque eran personas que se levantaban desde las 3:00am para revisar el proceso de facturación y que se terminara como a las 10 de la noche para poder cobrarle al cliente con tiempo y también recibir esa paga del cliente al que le estuviéramos haciendo la facturación.  Ahí me di cuenta de que mi objetivo, porque yo entré como UX Research Jr, era hacer que esas personas pudieran dormir. Ahí comenzó el enfoque hacia áreas back office donde era interno, era nuestro mismo proceso pero, aún así, necesitábamos de tecnología para poder automatizar o hacerle la vida más simple a ellos, esa es la anécdota que siempre se me ha quedado grabada y siempre digo que tengo que hacer dormir a Constanza, que es la Head de la parte de Cumplidos y es la que se encarga de los servicio finalizados, que tengan la constancia de que se ha terminado el servicio para poder pagarle al Lifter, ese servicio debe estar terminado y también conseguir la parte de facturación. Es el proceso más importante y el más tedioso que teníamos dentro de Liftit. Hoy en día lo tenemos un poco más sistematizado, creamos un producto enfocado a Constanza y a su equipo para que pudieran hacerlo sin imprimir, resaltar, sacar y empezar desde las 3:00am y terminar a las 12:00pm del día siguiente para cumplir la fecha. Porque, en un proceso de contratación, si uno no cumple las fechas, se va al siguiente mes de pago y también el Lifter merece su pago de acuerdo con las fechas estipuladas en cada uno de los países, entonces ellos lo hacen por ellos y nosotros lo hacemos por ellos.

Rodrigo: Qué interesante, Laura, porque nos contabas que tenían interiorizados estos procesos contables y de facturación y yo no había terminado de entender por qué, porque casi siempre las startups se centran en la tecnología que es core para lo que hacen y en logística no necesariamente la facturada me vino a la mente, claro, esto es parte del producto más core, pero ahora que nos cuentas esto, tienen este enfoque de herramientas internas y yo creo que eso es algo que se pueden llevar nuestros escuchas, algo muy valioso, que luego, para que realmente su producto grande, el de usuario final, sea escalable, hace falta que los fierros que están detrás de eso también tengan este grado de automatización y también reducir el error humano muchísimo porque nada es más propenso a errores que marcar una hoja impresa con un highlighter.

Artemio: Y me gusta mucho que, en una etapa temprana de una startup, se te invita un buen a estar muy cerca de tu usuario y, muchas veces, llegas a olvidar o a no considerar que este usuario también pueden ser las personas que ejecutan los procesos en tu empresa y, de hecho, esto es fundamental una vez que la empresa empieza a escalar, ya que, al principio, todos traemos este chip de do things that don’t scale de Y Combinator, pero luego un ejercicio muy saludable en cualquier empresa es ver qué procesos son altamente repetitivos y qué de ahí puedes comenzar a automatizar o a apalancarte de tecnología para hacerlos mucho más efectivos. Creo que esta historia que nos cuentas es un vivo ejemplo de esto.

¿Cómo fue el proceso de desarrollo del producto de facturación que hicieron en Liftit?

Artemio: A mí me encantaría preguntarte ¿cómo fue el proceso de desarrollo de ese producto? Porque, de hecho, tienen ahí una gran ventaja, que es que no tienen que salir a buscar usuarios, está muy diseñado al líder de un equipo. Muchas veces aquí en el estudio a nosotros nos gusta mucho, por ejemplo cuando se trata de herramientas internas o de clientes B2B o servicios que no son para la masa, nos gusta mucho seleccionar seis usuarios finales, diseñar la solución acorde a como ellos piensan, cómo se comportan, sin tratar de clavarnos en particularmente qué necesita cada uno, sino ellos como un grupo, pero este tipo de proyectos son los que son más fáciles de controlar, el resultado tiende a ser muy fructífero. Me encantaría que nos contaras un poquito ¿cómo fue que desarrollaron eso? Igual y un poquito del camino y cómo al final dijeron “ya estuvo, lo que sigue”.

Laura: Un producto nunca está al 100%, siempre está en una constante actualización. Pero nosotros utilizamos una metodología de diseño centrada en el usuario que tiene tres etapas muy grandes. La primera etapa es el proceso de investigación donde nosotros recolectamos esa información directamente con el usuario y hacemos técnicas de recolección, puede ser un cuestionario, una entrevista, un focus group, todo lo que nos ayude a tener la información directamente de ellos y que sea de la forma más amena posible porque existen una cantidad de usuarios infinita, desde el que le encanta hablar hasta aquel al que hay que sacarle las palabras. Entonces hay que combinar esos procesos tanto de observación de la actividad que ellos desarrollan y también preguntarle directamente cómo les va dentro de esa actividad. Obviamente, también hacemos un proceso paralelo que es encontrar esa información que ya existe, porque si nosotros tenemos un problema de diseño, si alguien no lo ha solucionado, debe haber información que me ayude a solucionar ese problema. Es la mezcla dentro de lo interno con lo externo o lo que alguien ya realizó en algún momento.

Cuando ya tenemos la información suficiente, ya determinada por una cantidad de usuarios, de pronto cuando son equipos muy pequeños, como es el caso de la parte de Cumplidos, teníamos un equipo bastante pequeño pero enfocado en diferentes países, entonces teníamos Cumplidos para México, Cumplidos para Ecuador, Cumplidos para Brasil, Cumplidos para Chile y para Colombia, entonces tenemos usuarios diversificados, con culturas diferentes, con procesos, que pueden ser el mismo pero lo realizan de manera totalmente diferente. Entonces teníamos una chica en Ecuador que le gustaba trabajar mucho más de noche y, por ejemplo, en Colombia les gustaba mucho más madrugar. Entonces los timelines eran diferentes, el proceso es el mismo pero la forma de contactarse para cumplir, que un Liftit no me mandó el POD (es como la foto que toman cuando se termina el servicio y te entregan un paquete, una factura o la firma del cliente), pero si no lo tenemos, no sabemos, a parte de que la aplicación nos dice que se ha terminado el servicio, debemos tener esa constancia legal de que se ha terminado..

Entonces teníamos chicos en Ecuador que les gustaba llamar a los Lifters a preguntarles por qué no está el pedido dentro de la plataforma o por qué no nos lo han mandado; a veces utilizaban WhatsApp. Si tenemos cinco mil servicios y tenemos que llamar a 300 Lifters por WhatsApp, eso es un proceso bastante tedioso. Y también dependía del país. Hay países donde se utiliza más WhatsApp, otros lo hacen por correo electrónico, otros por llamada. A pesar de todo, era bastante diversificado.

El siguiente stage es un proceso de análisis. En ese proceso de análisis nosotros hacemos técnicas que nos ayuden a encontrar el insight necesario. Tenemos técnicas de predicción de errores, técnicas de recolección de insights, ya sea de manera cualitativa, uno sabe cuál es la frase que más se repite y empieza a ser como un quote necesario, la frase como “siempre tengo problemas porque no se sube la foto”, por ejemplo. Si es algo que se repite, empieza a ser un quote bastante importante y llega a ser ese punto de necesidad que nosotros ya tomamos para poder ver cómo hacemos ese proceso creativo y la creación del producto.

Empieza la creación de los temas, de los prototipos, de cómo hacer un flujo de usuario, unas pantallas de alta fidelidad y nuestra etapa favorita es el proceso de testeo.

El proceso de testeo lo dividimos en tres stages bastantes grandes, pero que siempre tenemos en cuenta cuando estamos desarrollando nuestro proceso de un proyecto. El primero es un testeo de valoración. Un testeo de valoración es cuando no tenemos una idea totalmente desarrollada pero tenemos algún gráfico qué mostrarle al usuario, podemos entrar y mostrarle al usuario cómo reflejamos la solución bajo esa investigación y análisis que nosotros desarrollamos. También tenemos un testeo de validación, que es cuando ya tenemos algo bastante completo y ese proceso completo nos ayuda a verlo más hacia el enfoque de usabilidad, empezamos a ver lo visual y el uso de ese producto, cómo ellos interactúan, hacemos pruebas de usabilidad remotas y eso es lo más complejo. Al principio era súper complicado tener ese proceso de prueba de usabilidad y tenerlo concentrado dentro de la prueba de usabilidad porque siempre van a estar en un contexto difícil. Si están dentro de la operación, nos faltaba el camión con el que trabajas o los regresaban porque iban con la caja, se distraían porque lo llamaban, entonces son ese tipo de problemas que tenemos de manera interna que hemos podido sobrellevar con diferentes tipos de herramientas.

Nos gusta mucho utilizar en el equipo prototipos de alta fidelidad en una herramienta como Figma pero que tiene la posibilidad de grabar la pantalla, de que también se graben las acciones que él hace dentro de la pantalla, pero queda totalmente interno para que nosotros podamos hacer un análisis mucho más minucioso porque nosotros hacemos nuestros propios análisis, tomamos los datos, analizamos cuánto tiempo se demora, cuánto tiempo muerto hay en una aplicación, porque el tiempo muerto significa que no entendió o que algo está muy mal porque, si no puede realizar ninguna acción, ahí empezamos a tener esos insights directos dentro del resultado de esas pruebas de usabilidad; también en la cantidad de missclicks que desarrollan dentro de la misma aplicación, si van a realizar una actividad que tiene cinco pasos pero ellos lo resuelven en 20 también tenemos problemas grandes porque la idea es hacerles la vida más fácil, no hacer 20 pasos más de los que ellos deberían hacer.

Y todo eso es bastante divertido porque me parece que tener ese contacto con el usuario, no sólo para decirle “ven, dime tus problemas”, sino “ven, cómo el producto que nosotros pensamos puede resolver tus problemas”, y eso también nos da mucho insight dentro del proceso de usabilidad o de la prueba de usabilidad, esos ingishts siempre están enfocados a lo que nosotros llamamos protocolo de pensamiento manifestado porque ellos dicen todo lo que sienten mientras realizan alguna actividad dentro de la aplicación o del sistema. Es como ir cuestionando el color, si la letra está muy pequeña o muy grande, que también depende del equipo que ellos tengan porque es algo que no podemos controlar, hay personas que tienen pantallas gigantes y se ve la aplicación súper chiquita, o tenemos personas que tienen computadoras muy chiquitas y la pantalla se ve muy grande, entonces tenemos que cuadrar la escalabilidad de esa prueba y lo ideal es hacerlo con un target involucrando todos los países.

Siempre hacemos una escala en estadística de entre 5 y 9 usuarios porque ahí podemos encontrar más del 90% de probabilidad del error, entonces lo replicamos siempre con entre 5 y 9 usuarios y ya cuando son usuarios externos, como los Lifters, que ya hay muchos más, intentamos aumentarla a 15 que es nuestro mínimo estadístico para encontrar ese 90% de probabilidad del error y resolver esos errores que podemos resolver desde antes de pasarlo a ingeniería y que no existan retrocesos con ellos porque, a veces, en mis otros trabajos me pasaba que no había proceso de investigación, que de una se hacía el diseño y se pasaba a tecnología para que ellos desarrollen el producto y, cuando salía al aire, es cuando se daban cuenta de que eso no funciona. El tiempo del equipo de diseño y del equipo de tecnología y producto ahí empieza a tener retrocesos mucho más grandes y eso es lo que tratamos de evitar con este tipo de metodologías, que siempre estén de una manera iterativa y que intentamos encontrar los problemas mucho más grandes dentro de nuestra metodología para que, cuando pasen a tecnología y se desarrollen y ya estén en el momento de producción donde lo utilicen, encontrar las actualizaciones que ayuden a mejorar el producto base y tampoco estoy tan de acuerdo, no sé si se han dado cuenta de que hay tipos de producto que lanzan actualizaciones muy seguidas, que en un mes hacen cinco o seis actualizaciones de cosas que tienen que reparar o cosas nuevas que están intentando introducir en el mercado, haciendo un testeo en línea que también puede entorpecer el proceso actual que ellos tienen y distraerlos del objetivo del producto. Entonces también intentamos que esas actualizaciones sean pensadas, tienen que pasar por un proceso de pruebas, revisar cómo eleva al usuario con el producto ya en producción, qué sienten que les hace falta, y ya planearlas no en tiempos tan largos, sino como en tres meses vamos a sacar una funcionalidad de un filtro, o algo más específico que no hemos visto dentro del proceso inicial pero que les ayuda dentro de su producto.

Rodrigo: Claro, Laura, y, sobre todo, me parece que esto último que dices es valiosísimo para que se lleven nuestros escuchas una pepita de oro. Conforme va avanzando el proceso de desarrollo de una nueva funcionalidad o de un nuevo producto, se va volviendo más grave o más caro en tiempos, recursos, etcétera, cometer cualquier error.

A veces, aunque haya mucha prisa o mucha emoción por sacar algo nuevo, por resolver un problema, es mejor que se tome el tiempo necesario en cada una de las etapas porque lo que se resuelve en investigación ya no se tiene que resolver en diseño y lo que se resuelve en diseño ya no se tiene que resolver en desarrollo, porque, claro, darse cuenta en desarrollo que está mal un flujo o que, como decías, se tienen que echar tres pasos más de los que habíamos pensado, requieren que otra vez vuelva a pasar el feature por todo el proceso para poder nuevamente validarlo, nuevamente hacer las pruebas, volver a desarrollarlo, y eso termina saliendo mucho más caro que si se hace bien desde el principio.

Artemio: Hasta nos respondiste otras preguntas que te queríamos hacer.

¿Cómo funciona la técnica de proyección de errores?

Rodrigo: Ahorita me llamó la atención que mencionaste esta técnica de proyección de errores. ¿Nos podrías contar un poco cómo funciona eso?

Artemio: ¿Es esta de primero probar con nueve y después con 15 usuarios?

Laura: La proyección de errores es una matriz donde se clasifican los errores. Están los errores de acción, de comunicación, de presentación de la información, de feedback. Hay una clasificación de cinco categorías del error. Nosotros revisamos la actividad de cómo ellos lo resuelven y vamos prediciendo qué posibles errores pueden pasar dentro de la actividad inicial. Si tenemos un proceso totalmente manual, volviendo al proceso de facturación, donde ellos tienen que empezar a marcar factura por factura, escribir el número, la cantidad del valor final, donde se involucran mucho los números, hay una monotonía muy grande y procesos de vigilancia reducida porque la cantidad de errores que podemos tener es muy probable y también hay una tolerancia grande al error porque, como es tan monótona, aunque la persona sea perfecta, porque me han tocado personas que se aprenden 20 dígitos y tú se los preguntas y se los saben, pero eso es de uno en un millón y lo ideal es hacerles la vida mucho más fácil a ese tipo de personas.

Nosotros hacemos la proyección, los clasificamos y vemos un poco más cuantitativamente cuántos errores se pueden producir ya sea que se omite información, que no se inserta información, que la información es errónea, que se hace una acción equivocada como que quieren guardan y cancelan. Eso nos toca hacer en un proceso de observación para poder predecir los errores que pueden pasar, y no quiere decir que la persona los haga, pero se puede predecir de acuerdo con la actividad misma.

Eso nos da un mapa general de qué es lo que nosotros queremos evitar. Si sabemos que en un proceso manual donde hay una cantidad de números exageradísima y no todos tienen la capacidad de aprenderse esos números, sabemos que nuestros sistema tiene que otorgarles esos números, esa suma mucho más sencilla, que sea más automática, que él no lo tenga que hacer sino que el sistema lo haga.

Eso nos da requerimientos de lo que debería tener nuestro diseño y cómo deberíamos construirlo y no hablando de manera visual, sino lo mínimo que necesita nuestro producto para que pueda resolver la necesidad de ellos, no sólo lo que ellos dicen, sino predecir también errores futuros que ellos puedan tener, entonces es bastante complementario.

¿Cuáles son los retos más grandes a los que se enfrenta Liftit y su Head of Product Design en los próximos años?

Artemio: Fantástico. Oye, Laura, esta es la última pregunta del programa. Antes que nada, muchísimas gracias por venir a este espacio a compartir todos estos insights, ha sido una conversación súper rica en materia de producto y diseño de producto. Esta es una pregunta que nos gusta mucho, la hacemos en todos y cada uno de nuestros capítulos. Cuéntanos, ante los retos a los que se enfrenta Liftit y tú como su Head of Product Design en los próximos años, ¿qué te quita el sueño?

Laura: Hay un momento en que, cuando hacemos ese tipo de planeaciones, queremos abarcar tantas cosas. Siempre llegan esos enfoques ágiles de que entreguemos ya. A mí lo que me quita el sueño es si será que lograremos terminar la investigación o, cuando tenemos esos procesos de investigación un poco más complejos, que nos toca ir a la operación, nosotros le llegamos de sorpresa a los clientes como equipo de diseño y vamos a la operación, por darte un ejemplo, llegamos a un área que se enfoca bastante en supermercados y llegamos a ver cómo nuestros Lifters usan la aplicación, cómo el cliente usa el sistema. Y son visitas que empiezan a ser procesos a las 3:00am y nosotros nos ponemos la camiseta y vamos a las 3:00am a ver cómo cargan. Y siento que, a veces, no tenemos el tiempo para hacer todo lo que queremos porque estamos enfocados, hay un montón de clientes, hay una cantidad de Lifters bastante grande, y nosotros no olvidamos a nuestros usuarios internos. Como nuestra agenda de investigación es tan amplia, eso es lo que realmente me quita el sueño, ¿será que logramos hacerlo en el tiempo en que nosotros lo planeamos? Y, si no es así, haremos lo posible por hacerlo, obviamente en nuestro horario laboral, porque eso sí es sagrado, todos tenemos una vida privado y es muy importante tener un ambiente laboral en el que nuestro equipo se sienta a gusto, porque eso hace que también tengan amor en el desarrollo del producto mismo. Esos son los retos de un equipo de diseño.

Artemio: Fantástico. Me quedo mucho con todos los retos que tienen y con esta perspectiva de que si tú eres un joven emprendedor que está buscando una idea para desarrollar una startup y levantar estas cantidades considerables de capital para llevarla a cabo y echar a andar estas ideas disruptivas en este espacio, escoge muy bien. Realmente pregúntate qué pasa si soy exitoso con esta idea y qué es todo lo que implica en un lapso de aquí a cinco o diez años, realmente, muchas veces son tareas titánicas, vas a requerir de una aldea de gente para hacer una realidad la idea que tienes, este espacio es para todas esas personas, para que se puedan ahorrar el mayor número de errores posibles para que vean dónde están las prioridades de cada líder, no importa si es Head of Product, Head of Product Design, Chief Technology Officer, si es un founder, échense un clavado ahí en el acervo de capítulos que tenemos, todos son en esta dirección y en pro de brindarles los mejores insights.

Les recuerdo a todos que en cuandoelriosuena.com pueden suscribirse a la newsletter de este programa para que nunca se les olvide o para que nos encarguemos nosotros de recordarles cada que tengamos un capítulo nuevo, cada semana, en lunes, estamos sacando episodios nuevos.

Y, de igual forma, les pedimos con el corazón en mano que, si pueden compartir esto con alguien a quien crean que le va a ser útil o alguien que puede encontrar valioso este espacio, háganlo. Seguimos buscando más escuchas semana con semana.

Muchas gracias, Ro, muchas gracias, Laura, muchas gracias al equipo de producción que hace esto posible. Nos vemos a la próxima.