Caso de Estudio
Optimización de Promociones
Mi proceso estuvo basado en el Design Thinking, con muchísimas iteraciones entre medio.
La comunicación con el usuario final y stakeholders era directa, por lo que el proceso entre Empatizar, Definir e Idear estuvo sujeto a muchas iteraciones.
A continuación más detalles de cada uno de los pasos.
Caso de Estudio
Optimización de Promociones
Mi proceso estuvo basado en el Design Thinking, con muchísimas iteraciones entre medio.
La comunicación con el usuario final y stakeholders era directa, por lo que el proceso entre Empatizar, Definir e Idear estuvo sujeto a muchas iteraciones.
A continuación más detalles de cada uno de los pasos.
Caso de Estudio
Optimización de Promociones
Mi proceso estuvo basado en el Design Thinking, con muchísimas iteraciones entre medio.
La comunicación con el usuario final y stakeholders era directa, por lo que el proceso entre Empatizar, Definir e Idear estuvo sujeto a muchas iteraciones.
A continuación más detalles de cada uno de los pasos.
Haz Scroll para ver todo el proceso 😉
Empatizar
En el inicio del proceso, me enfoqué en entender el problema y solución actuales. A partir de esa etapa de descubrimiento y conversación con los usuarios antiguos, surgieron las primeras conclusiones iniciales que dieron paso al objetivo del proyecto:
Fanáticos de los resultados
Los usuarios reportaban estar muy contentos con la inteligencia detrás del producto.
Muy Incómodo
Debido a una pobre experiencia, los usuarios no estaban haciendo un uso completo de la plataforma. Llevaban a cabo tareas puntuales y usaban funcionalidades de carga masiva para hacer la gestión con otros softwares (excel) y luego llevarla a la plataforma para utilizar la inteligencia y resultados.
Poca Flexibilidad
Los usuarios estaban llenos de ideas para incluir en la plataforma que harían su día a día mucho mas óptimo. Sin embargo, había poco o nada de tiempo dedicado a escuchar e implementar estas ideas.
Al mismo tiempo, desarrolle un User Persona a tener en mente al momento de diseñar, basado en usuarios actuales, potenciales y algunas suposiciones debido al poco tiempo y esfuerzo destinado al research.
Empatizar
En el inicio del proceso, me enfoqué en entender el problema y solución actuales. A partir de esa etapa de descubrimiento y conversación con los usuarios antiguos, surgieron las primeras conclusiones iniciales que dieron paso al objetivo del proyecto:
Fanáticos de los resultados
Los usuarios reportaban estar muy contentos con la inteligencia detrás del producto.
Muy Incómodo
Debido a una pobre experiencia, los usuarios no estaban haciendo un uso completo de la plataforma. Llevaban a cabo tareas puntuales y usaban funcionalidades de carga masiva para hacer la gestión con otros softwares (excel) y luego llevarla a la plataforma para utilizar la inteligencia y resultados.
Poca Flexibilidad
Los usuarios estaban llenos de ideas para incluir en la plataforma que harían su día a día mucho mas óptimo. Sin embargo, había poco o nada de tiempo dedicado a escuchar e implementar estas ideas.
Al mismo tiempo, desarrolle un User Persona a tener en mente al momento de diseñar, basado en usuarios actuales, potenciales y algunas suposiciones debido al poco tiempo y esfuerzo destinado al research.
Empatizar
En el inicio del proceso, me enfoqué en entender el problema y solución actuales. A partir de esa etapa de descubrimiento y conversación con los usuarios antiguos, surgieron las primeras conclusiones iniciales que dieron paso al objetivo del proyecto:
Fanáticos de los resultados
Los usuarios reportaban estar muy contentos con la inteligencia detrás del producto.
Muy Incómodo
Debido a una pobre experiencia, los usuarios no estaban haciendo un uso completo de la plataforma. Llevaban a cabo tareas puntuales y usaban funcionalidades de carga masiva para hacer la gestión con otros softwares (excel) y luego llevarla a la plataforma para utilizar la inteligencia y resultados.
Poca Flexibilidad
Los usuarios estaban llenos de ideas para incluir en la plataforma que harían su día a día mucho mas óptimo. Sin embargo, había poco o nada de tiempo dedicado a escuchar e implementar estas ideas.
Al mismo tiempo, desarrolle un User Persona a tener en mente al momento de diseñar, basado en usuarios actuales, potenciales y algunas suposiciones debido al poco tiempo y esfuerzo destinado al research.
Definir los Objetivos
Tras conversar y empatizar con los distintos usuarios y en pro de encontrar soluciones que los beneficiaran tanto a ellos como a los objetivos comerciales de la empresa, decidimos enfocarnos en los siguientes objetivos.
Mejorar la experiencia de usuario
El foco básico y primordial de esta nueva fase de PB. No podemos aprender nada de nuestros usuarios si partimos de una experiencia llena de errores, malas practicas y pobre funcionamiento.
Encontramos varios puntos clave a trabajar sobre este aspecto:
Mala estructura: Los patrones utilizados en las distintas secciones de la plataforma no permitían acceder fácilmente a toda la información presente. Esto repercutía negativamente en los mejores aspectos de la misma, como lo eran la inteligencia detrás de la plataforma que entrega resultados tan relevantes para el usuario.
Uso puntual: La incomodidad generada por los patrones incorrectos, sumado a tiempos de carga muy largos, poco feedback de parte de la plataforma sobre errores y pasos a seguir, entre otros; resultaban en que el usuario interactuara con PB lo menos posible, estructurando su trabajo en otras aplicaciones y haciendo un uso muy puntual que solo le entregara los resultados deseados, los cuales luego exportaba de la plataforma. Esto podía resultar en un futuro abandono de la plataforma.
PB version 1
Estandarizar la Plataforma
Si bien el trabajo previo había sido hecho a la medida de cada cliente, existían muchos puntos de encuentro entre todos. La solución entregada era la misma y los problemas estaban pareciendo ser bastante similares.
Crear una plataforma base para todos lo usuarios, intentaría cumplir los siguientes puntos
Avanzar en una dirección conjunta: tomar los insights, comentarios y observaciones de distintos usuarios, nos permitiría probar y filtrar posibles buenas soluciones a problemas recurrentes y avanzar en conjunto hacia un producto más robusto.
Soluciones Probadas: cada nuevo usuario partiría de un producto ya testeado y validado por otros usuarios con problemáticas y situaciones similares, asegurando una mejor adopción del producto.
Punto de Partida para el Desarrollo: mucho tiempo estaba siendo invertido en generar plataformas especificas para cada cliente, y ese mismo tiempo de desarrollo podía aprovecharse en mejoras y features que beneficiaran a más usuarios. Tener un punto de partida en común a la hora de desarrollar PB para nuevos usuarios, permitiría distribuir los esfuerzos del equipo de mejor manera.
Transición Delicada
Los usuarios usualmente son resistentes al cambio, incluso cuando ese cambio implica una mejora de su rutina. Se mantendrían funcionalidades claves para los usuarios actuales, aunque esto no implique un aporte sustancial para la nueva plataforma, en pro de hacer el proceso de adaptación lo más amigable posible para los usuarios antiguos.
Definir los Objetivos
Tras conversar y empatizar con los distintos usuarios y en pro de encontrar soluciones que los beneficiaran tanto a ellos como a los objetivos comerciales de la empresa, decidimos enfocarnos en los siguientes objetivos.
Mejorar la experiencia de usuario
El foco básico y primordial de esta nueva fase de PB. No podemos aprender nada de nuestros usuarios si partimos de una experiencia llena de errores, malas practicas y pobre funcionamiento.
Encontramos varios puntos clave a trabajar sobre este aspecto:
Mala estructura: Los patrones utilizados en las distintas secciones de la plataforma no permitían acceder fácilmente a toda la información presente. Esto repercutía negativamente en los mejores aspectos de la misma, como lo eran la inteligencia detrás de la plataforma que entrega resultados tan relevantes para el usuario.
Uso puntual: La incomodidad generada por los patrones incorrectos, sumado a tiempos de carga muy largos, poco feedback de parte de la plataforma sobre errores y pasos a seguir, entre otros; resultaban en que el usuario interactuara con PB lo menos posible, estructurando su trabajo en otras aplicaciones y haciendo un uso muy puntual que solo le entregara los resultados deseados, los cuales luego exportaba de la plataforma. Esto podía resultar en un futuro abandono de la plataforma.
PB version 1
Estandarizar la Plataforma
Si bien el trabajo previo había sido hecho a la medida de cada cliente, existían muchos puntos de encuentro entre todos. La solución entregada era la misma y los problemas estaban pareciendo ser bastante similares.
Crear una plataforma base para todos lo usuarios, intentaría cumplir los siguientes puntos
Avanzar en una dirección conjunta: tomar los insights, comentarios y observaciones de distintos usuarios, nos permitiría probar y filtrar posibles buenas soluciones a problemas recurrentes y avanzar en conjunto hacia un producto más robusto.
Soluciones Probadas: cada nuevo usuario partiría de un producto ya testeado y validado por otros usuarios con problemáticas y situaciones similares, asegurando una mejor adopción del producto.
Punto de Partida para el Desarrollo: mucho tiempo estaba siendo invertido en generar plataformas especificas para cada cliente, y ese mismo tiempo de desarrollo podía aprovecharse en mejoras y features que beneficiaran a más usuarios. Tener un punto de partida en común a la hora de desarrollar PB para nuevos usuarios, permitiría distribuir los esfuerzos del equipo de mejor manera.
Transición Delicada
Los usuarios usualmente son resistentes al cambio, incluso cuando ese cambio implica una mejora de su rutina. Se mantendrían funcionalidades claves para los usuarios actuales, aunque esto no implique un aporte sustancial para la nueva plataforma, en pro de hacer el proceso de adaptación lo más amigable posible para los usuarios antiguos.
Definir los Objetivos
Tras conversar y empatizar con los distintos usuarios y en pro de encontrar soluciones que los beneficiaran tanto a ellos como a los objetivos comerciales de la empresa, decidimos enfocarnos en los siguientes objetivos.
Mejorar la experiencia de usuario
El foco básico y primordial de esta nueva fase de PB. No podemos aprender nada de nuestros usuarios si partimos de una experiencia llena de errores, malas practicas y pobre funcionamiento.
Encontramos varios puntos clave a trabajar sobre este aspecto:
Mala estructura: Los patrones utilizados en las distintas secciones de la plataforma no permitían acceder fácilmente a toda la información presente. Esto repercutía negativamente en los mejores aspectos de la misma, como lo eran la inteligencia detrás de la plataforma que entrega resultados tan relevantes para el usuario.
Uso puntual: La incomodidad generada por los patrones incorrectos, sumado a tiempos de carga muy largos, poco feedback de parte de la plataforma sobre errores y pasos a seguir, entre otros; resultaban en que el usuario interactuara con PB lo menos posible, estructurando su trabajo en otras aplicaciones y haciendo un uso muy puntual que solo le entregara los resultados deseados, los cuales luego exportaba de la plataforma. Esto podía resultar en un futuro abandono de la plataforma.
PB version 1
Estandarizar la Plataforma
Si bien el trabajo previo había sido hecho a la medida de cada cliente, existían muchos puntos de encuentro entre todos. La solución entregada era la misma y los problemas estaban pareciendo ser bastante similares.
Crear una plataforma base para todos lo usuarios, intentaría cumplir los siguientes puntos
Avanzar en una dirección conjunta: tomar los insights, comentarios y observaciones de distintos usuarios, nos permitiría probar y filtrar posibles buenas soluciones a problemas recurrentes y avanzar en conjunto hacia un producto más robusto.
Soluciones Probadas: cada nuevo usuario partiría de un producto ya testeado y validado por otros usuarios con problemáticas y situaciones similares, asegurando una mejor adopción del producto.
Punto de Partida para el Desarrollo: mucho tiempo estaba siendo invertido en generar plataformas especificas para cada cliente, y ese mismo tiempo de desarrollo podía aprovecharse en mejoras y features que beneficiaran a más usuarios. Tener un punto de partida en común a la hora de desarrollar PB para nuevos usuarios, permitiría distribuir los esfuerzos del equipo de mejor manera.
Transición Delicada
Los usuarios usualmente son resistentes al cambio, incluso cuando ese cambio implica una mejora de su rutina. Se mantendrían funcionalidades claves para los usuarios actuales, aunque esto no implique un aporte sustancial para la nueva plataforma, en pro de hacer el proceso de adaptación lo más amigable posible para los usuarios antiguos.
Idear
Reestructuramos la experiencia del usuario en la plataforma, aprovechando su base técnica, mientras manteníamos la versión anterior para clientes existentes y lanzábamos la nueva versión para clientes nuevos, lo que nos permitió comparar ambas.
Trabajé en colaboración con diferentes roles para validar esquemas y diseños, manteniendo reuniones regulares para alinear con los objetivos comerciales y recoger comentarios de las partes interesadas. Este enfoque iterativo, centrado en la colaboración, viabilidad y retroalimentación constante, nos permitió crear una plataforma centrada en el usuario y en línea con los objetivos, resolviendo problemas y tomando decisiones informadas en el proceso.
Journey Map
Desarrolle un Journey Map basado en las necesidades del usuario pero tomandome ciertas libertades para generar suposiciones con respecto a como sería la respuesta emocional de los usuarios en cada paso.
Este Journey Map es una guía de como nos gustaría que funcione la aplicación, puedes usar el mouse para moverte horizontalmente y ver todos los pasos y perfiles involucrados.
En este caso, consideré 3 perfiles claves definidos por los distintos usuarios: Editor, Aprobador y Negociador.
El Editor es el usuario que crea las promociones y las envía a revisión.
El Aprobador recibe las propuestas del editor y se asegura que estén alineadas con los objetivos del equipo de pricing.
El Negociador lleva la propuesta a los clientes correspondientes e intenta tener una respuesta positiva sobre la misma.
Flujo de las Promociones
En la primera versión del proyecto tenían aproximadamente 8 fases por las que se movía la promoción. Tras conversar con los usuarios se entendió que muchas de las fases no estaban siendo usada como se pensaba y que las estaban saltando.
Debido a esto, resumimos las fases a 4 claves:
En Edición
Primera fase donde los usuarios estructuran la promoción.
En Revisión
Fase de filtro donde usuarios con mayor rango deben revisar y validar la propuesta generada en la fase anterior y decidir si avanza o no.
Negociación
Se toma la propuesta revisada y se va a negociar con el cliente correspondiente si desea tomar la promoción y llevarla a cabo.
Ejecución
Fase donde las promociones están a espera de ser ejecutadas, una vez que cumplen sus fechas correspondientes, terminan su ciclo.
Wireframes
Antes de desarrollar prototipos más detallados, realice varios bosquejos primero a mano y luego en formato de wireframes de muy baja fidelidad para optimizar los tiempos de trabajo.
Idear
Reestructuramos la experiencia del usuario en la plataforma, aprovechando su base técnica, mientras manteníamos la versión anterior para clientes existentes y lanzábamos la nueva versión para clientes nuevos, lo que nos permitió comparar ambas.
Trabajé en colaboración con diferentes roles para validar esquemas y diseños, manteniendo reuniones regulares para alinear con los objetivos comerciales y recoger comentarios de las partes interesadas. Este enfoque iterativo, centrado en la colaboración, viabilidad y retroalimentación constante, nos permitió crear una plataforma centrada en el usuario y en línea con los objetivos, resolviendo problemas y tomando decisiones informadas en el proceso.
Journey Map
Desarrolle un Journey Map basado en las necesidades del usuario pero tomandome ciertas libertades para generar suposiciones con respecto a como sería la respuesta emocional de los usuarios en cada paso.
Este Journey Map es una guía de como nos gustaría que funcione la aplicación, puedes usar el mouse para moverte horizontalmente y ver todos los pasos y perfiles involucrados.
En este caso, consideré 3 perfiles claves definidos por los distintos usuarios: Editor, Aprobador y Negociador.
El Editor es el usuario que crea las promociones y las envía a revisión.
El Aprobador recibe las propuestas del editor y se asegura que estén alineadas con los objetivos del equipo de pricing.
El Negociador lleva la propuesta a los clientes correspondientes e intenta tener una respuesta positiva sobre la misma.
Flujo de las Promociones
En la primera versión del proyecto tenían aproximadamente 8 fases por las que se movía la promoción. Tras conversar con los usuarios se entendió que muchas de las fases no estaban siendo usada como se pensaba y que las estaban saltando.
Debido a esto, resumimos las fases a 4 claves:
En Edición
Primera fase donde los usuarios estructuran la promoción.
En Revisión
Fase de filtro donde usuarios con mayor rango deben revisar y validar la propuesta generada en la fase anterior y decidir si avanza o no.
Negociación
Se toma la propuesta revisada y se va a negociar con el cliente correspondiente si desea tomar la promoción y llevarla a cabo.
Ejecución
Fase donde las promociones están a espera de ser ejecutadas, una vez que cumplen sus fechas correspondientes, terminan su ciclo.
Wireframes
Antes de desarrollar prototipos más detallados, realice varios bosquejos primero a mano y luego en formato de wireframes de muy baja fidelidad para optimizar los tiempos de trabajo.
Idear
Reestructuramos la experiencia del usuario en la plataforma, aprovechando su base técnica, mientras manteníamos la versión anterior para clientes existentes y lanzábamos la nueva versión para clientes nuevos, lo que nos permitió comparar ambas.
Trabajé en colaboración con diferentes roles para validar esquemas y diseños, manteniendo reuniones regulares para alinear con los objetivos comerciales y recoger comentarios de las partes interesadas. Este enfoque iterativo, centrado en la colaboración, viabilidad y retroalimentación constante, nos permitió crear una plataforma centrada en el usuario y en línea con los objetivos, resolviendo problemas y tomando decisiones informadas en el proceso.
Journey Map
Desarrolle un Journey Map basado en las necesidades del usuario pero tomandome ciertas libertades para generar suposiciones con respecto a como sería la respuesta emocional de los usuarios en cada paso.
Este Journey Map es una guía de como nos gustaría que funcione la aplicación, puedes usar el mouse para moverte horizontalmente y ver todos los pasos y perfiles involucrados.
En este caso, consideré 3 perfiles claves definidos por los distintos usuarios: Editor, Aprobador y Negociador.
El Editor es el usuario que crea las promociones y las envía a revisión.
El Aprobador recibe las propuestas del editor y se asegura que estén alineadas con los objetivos del equipo de pricing.
El Negociador lleva la propuesta a los clientes correspondientes e intenta tener una respuesta positiva sobre la misma.
Flujo de las Promociones
En la primera versión del proyecto tenían aproximadamente 8 fases por las que se movía la promoción. Tras conversar con los usuarios se entendió que muchas de las fases no estaban siendo usada como se pensaba y que las estaban saltando.
Debido a esto, resumimos las fases a 4 claves:
En Edición
Primera fase donde los usuarios estructuran la promoción.
En Revisión
Fase de filtro donde usuarios con mayor rango deben revisar y validar la propuesta generada en la fase anterior y decidir si avanza o no.
Negociación
Se toma la propuesta revisada y se va a negociar con el cliente correspondiente si desea tomar la promoción y llevarla a cabo.
Ejecución
Fase donde las promociones están a espera de ser ejecutadas, una vez que cumplen sus fechas correspondientes, terminan su ciclo.
Wireframes
Antes de desarrollar prototipos más detallados, realice varios bosquejos primero a mano y luego en formato de wireframes de muy baja fidelidad para optimizar los tiempos de trabajo.
Design System
El Design System que desarrollé se basó en el concepto de Atomic Design, que organiza los componentes de diseño en niveles atómicos, moleculares y de organismos para su reutilización y coherencia.
A continuación un detalle de lo que incluí en cada sección:
Atomos: acá detalle el nivel más basico de todo el sistema, incluye colores, tipografías, iconos, logos, espaciados. Cabe destacar que a lo largo de todo el sistema estuvo planteado bajo una retícula de 8pts.
Moléculas: incluye componentes pequeños que van a ser utilizados en muchas diferentes secciones, tales como botones, listas desplegables, componentes para tablas, inputs, alertas, tooltips, etc.
Organismos: componentes más especificos y estructurados, tales como modales, pantallas de alertas, modales de ingresos de información o formularios, etc. En este caso genere una sección especifica de componentes para esta aplicación.
Átomos
Sistema de Color
Tipografía
Montserrat
Íconos
Contacto
Acciones
Flechas
Gráficos
Elementos
Símbolos
Moléculas
Botones
Default
Hover
Disabled
Para el botón, desarrolle un componente que estaba conectado a los iconos, permitiendo variaciones sobre el mismo componente de una manera rápida.
Input
Tabla
Organismos
Módulo de Creación
Toolbar
Tarjeta de Resumen
Design System
El Design System que desarrollé se basó en el concepto de Atomic Design, que organiza los componentes de diseño en niveles atómicos, moleculares y de organismos para su reutilización y coherencia.
A continuación un detalle de lo que incluí en cada sección:
Atomos: acá detalle el nivel más basico de todo el sistema, incluye colores, tipografías, iconos, logos, espaciados. Cabe destacar que a lo largo de todo el sistema estuvo planteado bajo una retícula de 8pts.
Moléculas: incluye componentes pequeños que van a ser utilizados en muchas diferentes secciones, tales como botones, listas desplegables, componentes para tablas, inputs, alertas, tooltips, etc.
Organismos: componentes más especificos y estructurados, tales como modales, pantallas de alertas, modales de ingresos de información o formularios, etc. En este caso genere una sección especifica de componentes para esta aplicación.
Átomos
Sistema de Color
Tipografía
Montserrat
Íconos
Contacto
Acciones
Flechas
Gráficos
Elementos
Símbolos
Moléculas
Botones
Default
Hover
Disabled
Para el botón, desarrolle un componente que estaba conectado a los iconos, permitiendo variaciones sobre el mismo componente de una manera rápida.
Input
Tabla
Organismos
Módulo de Creación
Toolbar
Tarjeta de Resumen
Design System
El Design System que desarrollé se basó en el concepto de Atomic Design, que organiza los componentes de diseño en niveles atómicos, moleculares y de organismos para su reutilización y coherencia.
A continuación un detalle de lo que incluí en cada sección:
Atomos: acá detalle el nivel más basico de todo el sistema, incluye colores, tipografías, iconos, logos, espaciados. Cabe destacar que a lo largo de todo el sistema estuvo planteado bajo una retícula de 8pts.
Moléculas: incluye componentes pequeños que van a ser utilizados en muchas diferentes secciones, tales como botones, listas desplegables, componentes para tablas, inputs, alertas, tooltips, etc.
Organismos: componentes más especificos y estructurados, tales como modales, pantallas de alertas, modales de ingresos de información o formularios, etc. En este caso genere una sección especifica de componentes para esta aplicación.
Átomos
Sistema de Color
Tipografía
Montserrat
Íconos
Contacto
Acciones
Flechas
Gráficos
Elementos
Símbolos
Moléculas
Botones
Default
Hover
Disabled
Para el botón, desarrolle un componente que estaba conectado a los iconos, permitiendo variaciones sobre el mismo componente de una manera rápida.
Input
Tabla
Organismos
Módulo de Creación
Toolbar
Tarjeta de Resumen
Prototipo
Utilicé Figma para el diseño de los prototipos, aprovechando su facilidad de uso y capacidad para la transición diseño-código.
Home
En el home mantuvimos la estructura planteada en los wireframes, 4 columnas donde cada futuro cliente puede vaciar sus fases deseadas.
Cada tarjeta dentro de las columnas representa una promoción o catálogo, y cuenta con indicadores de:
Tipo de promocion, puede ser sell in o sell out.ROI y Uplift, indicadores de performance de la promoción.
SKU, número de productos ingresados en la promoción.
Cadena a la que está dirigida.
En la parte principal de cada fase agregamos un filtro para poder ubicar promociones más facilmente.
Tarjetas de Resumen
Contiene un resumen un poco más extenso de la promocion, los botones para acceder a ella o duplicarla y la ultima actividad que ha tenido la misma. Esta tarjeta se despliega haciendo click sobre cualquiera de las tarjetas en el home.
Módulo de Creación
Este modulo es el primer paso a la hora de crear un catálogo o promoción.
Acá el usuario selecciona valores que no son modificables y que indican los datos a cargar desde el backend para cada promoción.
Estos datos son la cadena, el nombre y el tipo de promoción.
Es un modulo que debe llenarse paso a paso, con la posibilidad de ampliar los pasos a futuro de ser necesario y cuenta con alertas que van indicando al usuario si comete algún error o si le falta ingresar algún valor.
Gestión del Catálogo
Los productos se cargan en forma de columnas, por defecto viene vacío y el usuario va ingresándolos desde la barra de herramientas a la derecha, que cuenta con distintas secciones.
Simulación del Catálogo
En esta vista se vacía el mayor valor de la aplicación. Acá se muestran los resultados de la simulación, tanto a nivel producto como a nivel general.
A su vez, agregamos indicadores que muestran que tan buenos son los resultados de la misma y si surgió algún error.
Prototipo
Utilicé Figma para el diseño de los prototipos, aprovechando su facilidad de uso y capacidad para la transición diseño-código.
Home
En el home mantuvimos la estructura planteada en los wireframes, 4 columnas donde cada futuro cliente puede vaciar sus fases deseadas.
Cada tarjeta dentro de las columnas representa una promoción o catálogo, y cuenta con indicadores de:
Tipo de promocion, puede ser sell in o sell out.ROI y Uplift, indicadores de performance de la promoción.
SKU, número de productos ingresados en la promoción.
Cadena a la que está dirigida.
En la parte principal de cada fase agregamos un filtro para poder ubicar promociones más facilmente.
Tarjetas de Resumen
Contiene un resumen un poco más extenso de la promocion, los botones para acceder a ella o duplicarla y la ultima actividad que ha tenido la misma. Esta tarjeta se despliega haciendo click sobre cualquiera de las tarjetas en el home.
Módulo de Creación
Este modulo es el primer paso a la hora de crear un catálogo o promoción.
Acá el usuario selecciona valores que no son modificables y que indican los datos a cargar desde el backend para cada promoción.
Estos datos son la cadena, el nombre y el tipo de promoción.
Es un modulo que debe llenarse paso a paso, con la posibilidad de ampliar los pasos a futuro de ser necesario y cuenta con alertas que van indicando al usuario si comete algún error o si le falta ingresar algún valor.
Gestión del Catálogo
Los productos se cargan en forma de columnas, por defecto viene vacío y el usuario va ingresándolos desde la barra de herramientas a la derecha, que cuenta con distintas secciones.
Simulación del Catálogo
En esta vista se vacía el mayor valor de la aplicación. Acá se muestran los resultados de la simulación, tanto a nivel producto como a nivel general.
A su vez, agregamos indicadores que muestran que tan buenos son los resultados de la misma y si surgió algún error.
Prototipo
Utilicé Figma para el diseño de los prototipos, aprovechando su facilidad de uso y capacidad para la transición diseño-código.
Home
En el home mantuvimos la estructura planteada en los wireframes, 4 columnas donde cada futuro cliente puede vaciar sus fases deseadas.
Cada tarjeta dentro de las columnas representa una promoción o catálogo, y cuenta con indicadores de:
Tipo de promocion, puede ser sell in o sell out.ROI y Uplift, indicadores de performance de la promoción.
SKU, número de productos ingresados en la promoción.
Cadena a la que está dirigida.
En la parte principal de cada fase agregamos un filtro para poder ubicar promociones más facilmente.
Tarjetas de Resumen
Contiene un resumen un poco más extenso de la promocion, los botones para acceder a ella o duplicarla y la ultima actividad que ha tenido la misma. Esta tarjeta se despliega haciendo click sobre cualquiera de las tarjetas en el home.
Módulo de Creación
Este modulo es el primer paso a la hora de crear un catálogo o promoción.
Acá el usuario selecciona valores que no son modificables y que indican los datos a cargar desde el backend para cada promoción.
Estos datos son la cadena, el nombre y el tipo de promoción.
Es un modulo que debe llenarse paso a paso, con la posibilidad de ampliar los pasos a futuro de ser necesario y cuenta con alertas que van indicando al usuario si comete algún error o si le falta ingresar algún valor.
Gestión del Catálogo
Los productos se cargan en forma de columnas, por defecto viene vacío y el usuario va ingresándolos desde la barra de herramientas a la derecha, que cuenta con distintas secciones.
Simulación del Catálogo
En esta vista se vacía el mayor valor de la aplicación. Acá se muestran los resultados de la simulación, tanto a nivel producto como a nivel general.
A su vez, agregamos indicadores que muestran que tan buenos son los resultados de la misma y si surgió algún error.
Desarrollo
Parte importante de mi labor en este proyecto consistió en ser el Product Owner de la aplicación.
Esto me llevo a tomar labores como:
Coordinar el desarrollo front end con colaboradores internos y externos a la organización, haciendo entrega de archivos y documentación que facilitara la labor de los desarrolladores.
Desarrollar la documentación o “Wiki” del producto, que luego sería validada con stakeholders y con el CTO de la organización para tener un punto de base referencial para todas las decisiones de desarrollo.
Trabajar en conjunto con Ingenieros de datos para que disponibilizaran al equipo Back End los datos necesarios para nutrir la aplicación.Definir sprints y tareas con criterios de aceptación suficientemente claros para lograr los objetivos a tiempo.
Identificar el MVP, de esta manera logramos cumplir con tiempos de desarrollo acotados que entregaran primeras versiones del producto las cuales incluían funcionalidades básicas lo suficientemente bien desarrolladas.
Product Wiki
Desarrolle una wiki donde se podía ir a buscar información sobre cualquier sección de la plataforma.
Esta wiki no es directamente para el usuario, si no para el equipo de desarrollo. Los puntos que se encontraban fuera de mi alcance los valide con los profesionales correspondientes para evitar confusiones.
La Wiki documentaba cada sección e indicaba que debía hacer cada componente, cuando deben saltar alertas, el flujo de las fases, Journey Map, etc.
Era nuestra biblia.
Sprints y Tareas
Utilizamos metodologías agiles a través de sprints, tareas y tableros Kanban.
Además, teniamos daily stand ups donde nos poníamos al día y coordinabamos las siguientes tareas.
Yo me encargue de redactar todas la tareas e indicar la dedicación que tomarían, los equipos responsables, la importancia que tenían de acuerdo a los objetivos del proyecto y los criterios de aceptación.
Cabe destacar que estos procesos no se usaban y fui uno de los que insitió en usarlos para este proyecto.
Entregables y Recepción de Comentarios
Hicimos entregar paulatinas tanto al CEO de la organización como a un cliente que esperaba el producto.
Realizamos una primera con un MVP y posterior a eso fuimos añadiendo features y secciones y a la vez recibiendo comentarios de ambas partes.
Estos comentarios los recepcionaba, definía su importancia y los convertía en tareas a trabajar posteriormente.
Conclusiones
Este proyecto fue de una intesidad alta, tanto por la complejidad como por los tiempos destinados.
Aún no está cerrado, por lo que no puedo generar conclusiones tan precisas.
Sin embargo, la recepción de los usuarios ha sido tremendamente positiva, especialmente en el sentido de que ha resultado en extensiones de convenios de trabajo con distintos clientes, ya que los mismos se encuentran motivados en seguir haciendo crecer esta aplicación.
El trabajo hasta ahora ha resultado en inspirar a los usuarios antiguos para seguir explorando soluciones de software en el mundo del pricing y para mi, eso es un éxito rotundo.
En lo persona podría concluir que ha sido un empujon profesional enorme para mí, tanto desde el área de product designer como product owner, espero poder seguir participando en proyectos de este estilo.
Desarrollo
Parte importante de mi labor en este proyecto consistió en ser el Product Owner de la aplicación.
Esto me llevo a tomar labores como:
Coordinar el desarrollo front end con colaboradores internos y externos a la organización, haciendo entrega de archivos y documentación que facilitara la labor de los desarrolladores.
Desarrollar la documentación o “Wiki” del producto, que luego sería validada con stakeholders y con el CTO de la organización para tener un punto de base referencial para todas las decisiones de desarrollo.
Trabajar en conjunto con Ingenieros de datos para que disponibilizaran al equipo Back End los datos necesarios para nutrir la aplicación.Definir sprints y tareas con criterios de aceptación suficientemente claros para lograr los objetivos a tiempo.
Identificar el MVP, de esta manera logramos cumplir con tiempos de desarrollo acotados que entregaran primeras versiones del producto las cuales incluían funcionalidades básicas lo suficientemente bien desarrolladas.
Product Wiki
Desarrolle una wiki donde se podía ir a buscar información sobre cualquier sección de la plataforma.
Esta wiki no es directamente para el usuario, si no para el equipo de desarrollo. Los puntos que se encontraban fuera de mi alcance los valide con los profesionales correspondientes para evitar confusiones.
La Wiki documentaba cada sección e indicaba que debía hacer cada componente, cuando deben saltar alertas, el flujo de las fases, Journey Map, etc.
Era nuestra biblia.
Sprints y Tareas
Utilizamos metodologías agiles a través de sprints, tareas y tableros Kanban.
Además, teniamos daily stand ups donde nos poníamos al día y coordinabamos las siguientes tareas.
Yo me encargue de redactar todas la tareas e indicar la dedicación que tomarían, los equipos responsables, la importancia que tenían de acuerdo a los objetivos del proyecto y los criterios de aceptación.
Cabe destacar que estos procesos no se usaban y fui uno de los que insitió en usarlos para este proyecto.
Entregables y Recepción de Comentarios
Hicimos entregar paulatinas tanto al CEO de la organización como a un cliente que esperaba el producto.
Realizamos una primera con un MVP y posterior a eso fuimos añadiendo features y secciones y a la vez recibiendo comentarios de ambas partes.
Estos comentarios los recepcionaba, definía su importancia y los convertía en tareas a trabajar posteriormente.
Conclusiones
Este proyecto fue de una intesidad alta, tanto por la complejidad como por los tiempos destinados.
Aún no está cerrado, por lo que no puedo generar conclusiones tan precisas.
Sin embargo, la recepción de los usuarios ha sido tremendamente positiva, especialmente en el sentido de que ha resultado en extensiones de convenios de trabajo con distintos clientes, ya que los mismos se encuentran motivados en seguir haciendo crecer esta aplicación.
El trabajo hasta ahora ha resultado en inspirar a los usuarios antiguos para seguir explorando soluciones de software en el mundo del pricing y para mi, eso es un éxito rotundo.
En lo persona podría concluir que ha sido un empujon profesional enorme para mí, tanto desde el área de product designer como product owner, espero poder seguir participando en proyectos de este estilo.
Desarrollo
Parte importante de mi labor en este proyecto consistió en ser el Product Owner de la aplicación.
Esto me llevo a tomar labores como:
Coordinar el desarrollo front end con colaboradores internos y externos a la organización, haciendo entrega de archivos y documentación que facilitara la labor de los desarrolladores.
Desarrollar la documentación o “Wiki” del producto, que luego sería validada con stakeholders y con el CTO de la organización para tener un punto de base referencial para todas las decisiones de desarrollo.
Trabajar en conjunto con Ingenieros de datos para que disponibilizaran al equipo Back End los datos necesarios para nutrir la aplicación.Definir sprints y tareas con criterios de aceptación suficientemente claros para lograr los objetivos a tiempo.
Identificar el MVP, de esta manera logramos cumplir con tiempos de desarrollo acotados que entregaran primeras versiones del producto las cuales incluían funcionalidades básicas lo suficientemente bien desarrolladas.
Product Wiki
Desarrolle una wiki donde se podía ir a buscar información sobre cualquier sección de la plataforma.
Esta wiki no es directamente para el usuario, si no para el equipo de desarrollo. Los puntos que se encontraban fuera de mi alcance los valide con los profesionales correspondientes para evitar confusiones.
La Wiki documentaba cada sección e indicaba que debía hacer cada componente, cuando deben saltar alertas, el flujo de las fases, Journey Map, etc.
Era nuestra biblia.
Sprints y Tareas
Utilizamos metodologías agiles a través de sprints, tareas y tableros Kanban.
Además, teniamos daily stand ups donde nos poníamos al día y coordinabamos las siguientes tareas.
Yo me encargue de redactar todas la tareas e indicar la dedicación que tomarían, los equipos responsables, la importancia que tenían de acuerdo a los objetivos del proyecto y los criterios de aceptación.
Cabe destacar que estos procesos no se usaban y fui uno de los que insitió en usarlos para este proyecto.
Entregables y Recepción de Comentarios
Hicimos entregar paulatinas tanto al CEO de la organización como a un cliente que esperaba el producto.
Realizamos una primera con un MVP y posterior a eso fuimos añadiendo features y secciones y a la vez recibiendo comentarios de ambas partes.
Estos comentarios los recepcionaba, definía su importancia y los convertía en tareas a trabajar posteriormente.
Conclusiones
Este proyecto fue de una intesidad alta, tanto por la complejidad como por los tiempos destinados.
Aún no está cerrado, por lo que no puedo generar conclusiones tan precisas.
Sin embargo, la recepción de los usuarios ha sido tremendamente positiva, especialmente en el sentido de que ha resultado en extensiones de convenios de trabajo con distintos clientes, ya que los mismos se encuentran motivados en seguir haciendo crecer esta aplicación.
El trabajo hasta ahora ha resultado en inspirar a los usuarios antiguos para seguir explorando soluciones de software en el mundo del pricing y para mi, eso es un éxito rotundo.
En lo persona podría concluir que ha sido un empujon profesional enorme para mí, tanto desde el área de product designer como product owner, espero poder seguir participando en proyectos de este estilo.