Circular Design Workshop

Llevaba tiempo sin estar en Valencia, y aunque estaba recién llegada Berlín, no podría faltar a un UX Academy y más si podía ver a gente del mundo UX en la ciudad.
En esta caso era un taller sobre “Circular Design Workshop: Desafíos de diseño en Economía Circular”.

Circular design

El taller se dividía en varias fases. Durante la primera parte un miembro de Ecoembes, una organización medioambiental sin ánimo de lucro que promueve la sostenibilidad y el cuidado del medioambiente a través del reciclaje nos contó los restos a los que se enfrentaban y como usaban la economía circular, una estrategia que tiene por objetivo reducir tanto la entrada de los materiales como la producción de desechos vírgenes, cerrando los flujos económicos y ecológicos de los recursos para inspirar un cambio hacia ese nuevo modelo.

Iniciativas globales como OpenIdeo, también difunden este nuevo paradigma mediante Circular Design Guide, creada en colaboración con la Fundación Ellen MacArthur, también intentan promover este modelo, buscando empresas con un enfoque alternativo, restaurador y regenerativo que generan un nuevo valor y prosperidad económica, social y ecológica a largo plazo.

La idea del taller se basaba que nos proponían un desafío para trabajar sobre diferentes retos centrados en el ciudadano y en el ecodiseño, mediante técnicas de resolución creativa de problemas. Por ello, a continuación Javi Larrea de UX Academy nos contaba en que consistía la técnica de Design Sprint y como la íbamos a implementar en el taller de 2 horas de duración.

Como estábamos bastantes lo siguiente fue dividirnos en grupos, y comenzar el proceso ideación, al principio con una tarea de calentamiento intentando generar en grupo el mayor número de objetos redondos, para posteriormente agruparlos por características y votar los mejores.

Seguir leyendo

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.

Seguir leyendo

Proceso de desarrollo de producto en Ontruck

Continúo con la masterclass de @nachogil (diseñador de producto en Ontruck) y cual es su proceso de desarrollo para diseñar producto diseñado por Javier Escribano. Esta fue de las parte que más me gustaron con la que contaré en el siguiente artículo, por todo lo que me gusta aprender sobre metodologías de trabajo.

No creo en otra forma de desarrollar un buen producto que no sea siguiendo la filosofía Agile. Por ello creo en el trabajo colaborativo entre los diferentes miembros de los equipos, cuya aporte de conocimientos diversos es lo que hace que la suma del TODO sea mayor que cada una de sus partes.

No creo que exista un método perfecto, sino que cada empresa debe encontrar el que mejor se ajusta a su proceso. Pero después de haber pasado por varios tipos de empresas de desarrollo (producto propio, consultorías, startups…) creo que esta forma de trabajar va bastante bien encaminada.

El concepto es muy similar a lo que intentaban implantar en las otras empresas pero por lo que contó Nacho, bien hecho. La diferencia con las otras empresas está en el equipo (desde mi punto de vista). Ontruck está formado por un equipo senior que cree en esa forma de trabajar y tiene claro los objetivos que quiere conseguir.

Plan de producto

Un poco de información: Ontruck tiene un año de vida, 3 aplicaciones (una para los camioneros, otra para las empresas y otra interna para unis los 2 mundos) y están ya cerca de tener un equipo de casi 100 personas.

Formato de trabajo

Su formato de trabajo es el siguiente:

  • Cada año, lo dividen en 4 trimestres.
  • Cada uno con 2 Roadmaps estables de 6 semanas: 5 semanas de trabajo y 1 de reflexión.
  • Cada Roadmap tiene 2 sprints de 2 semanas cada uno de desarrollo de producto y una de estabilización.

Semana reflexión

Esta planificación basada en roadmaps es suficientemente corta para que no cambien las prioridades de negocio y suficientemente larga para poder construir productos/proyectos pequeños.

Seguir leyendo

Metodología de Nacho Gil para diseño de producto

Seguimos con la masterclass de @nachogil (diseñador de producto en Ontruck) y su “awesome design methodology” para diseñar producto. Como él comenta, no hay que  lo más importante es la tenacidad y tener sentido común.

¿Cueces o enriqueces?

Por cada capa de cera que se da al producto se debe quitar 3.

Dar cera, pulir cera.

Cuando hablamos de productos tecnológicos poner es relativamente más económico que si hablamos de productos físicos. No es lo mismo añadir una nueva feature que poner un chalet en el mercado o fabricar una pieza de plástico (CAD/CAM, Molde, Inyeccción…).

Dar cera pulir cera

Por ello debemos evitar añadir cosas porque sí. Esto tiene que ver con lo que comentamos en el anterior post sobre “Less is more”.

Mirar fuera

Cuando se tiene alguna duda sobre cierto componente o algún patrón de interacción o simplemente se quieren explorar alternativas, es bueno coger algo de aire fresco y mirar alternativas fuera de tu sector.

Nacho tambien comenta que el se inspira mucho en el mundo físico para diseñar un producto digital, ya que es donde vivimos todos los usuarios.

Donde hay patrón no manda designer

No innoves en cosas que ya existen a no ser q sea el core de tu negocio. Gasta esos recursos en cosas que sean más importantes.

Por ejemplo si debes diseñar un chat, porque tu aplicación debe tener esa funcionalidad, cópialo de las demás. No es core, no aporta nada, hay un patrón, td el mundo sabe usarlo. No inventes la rueda cuando no es necesario. Tira para adelante. Prioriza.

Seguir leyendo

Conceptualización de un proyecto

A la hora de abordar un nuevo proyecto de experiencia de usuario debemos tener muy en cuenta el flujo conceptual. Las partes que lo componen son:

  1. Objetivos: las metas que el cliente desea lograr con el desarrollo del producto
  2. Tareas de usuario: las acciones y funcionalidades que el sitio web va a permitir hacer al usuario.
  3. Interfaz: las pantallas que componen la aplicación. La comunicación entre el sistema y el usuario se realiza a través de los elementtos visuales de la pantalla, sonidos…
  4. Procesos asociados: la serie de pantallas que consiguran el resto de funcionalidades por los que el usuario realiza acciones e interactúa con el sistema.

Sin los objetivos a cumplir claros y detallados, no se pueden establecer que tareas son necesarias para lograrlos, ni comenzar el diseño de la interfaz y los procesos asociados.

Entrevistas con usuarios

Por ello la definición clara y concisa de los 2 puntos iniciales y su entendimiento por parte de todos los integrantes es clave para que un proyecto salga bien.

Porque no tiene sentido comenzar a pensar en las pantallas, la entrada de datos, la interacción… de un problema que no está bien definido, porque seguramente se malgastarán tiempo y recursos.

Lo que sucede es que muchas veces al cliente no le gusta invertir tiempo en la fase inicial de la investigación queriendo ver pantallas (ya sean prototipos o diseño de alto nivel) cuanto antes e iniciando la conversación sobre los objetivos y las tareas a partir de ese momento.

Seguir leyendo

Checklist de arranque de proyecto UX

Muchas empresas antes de empezar el proyecto, mandan al cliente una checklist de preguntas para obtener la máxima información de contexto, y obtener así una primera impresión del proyecto, su naturaleza, su competencia, su historia, responsables, objetivos…

Toma de requerimientos proyecto UX

Imagen extraída del checklist de Olga Revilla

A continuación os dejo un ejemplo de este tipo de preguntas realizado por Olga Revilla en 2009, pero  cuyo contenido sigue siendo actual: Requerimientos iniciales de un proyecto. Son 69 preguntas repartidas en varias categorías:

  • Datos básicos
  • La empresa y su entorno
  • Los usuarios y clientes
  • Misión y objetivos del sitio
  • Tareas
  • Expectativas, requisitos y preferencias
  • Contenidos
  • Requisitos de accesibilidad
  • Recursos humanos disponibles
  • Recursos técnicos disponibles

Estas preguntas son perfectas para una primera toma de contacto y más importante, alinear expectativas con el cliente de lo que espera del proyecto.

Seguir leyendo

Customer Experience y Agile

Una de las charlas que no pude ver en la CAS2017 (por estar coordinando otra de las salas) y que más me ha gustado al verla, fue la titulada: “No hay mejora de Customer Experience sin Agile” de Carlos Iglesias (@CarlosTheSailor)

El secreto es que esta relación no es unidireccional y el concepto más podereoso que espera aportar, es que Customer eXperience (CX) es una palanca para permitirnos introducir la cultura agile en las organizaciones.

Ejemplo Customer Journey Map

Para que explicar la diferencia entre User Experience (UX) y CX, Carlos nos empieza realizando un customer jorney de la típica experiencia de una boda, sacando las risas del público, lo cual ya les deja con ganas de saber más.

Definición Experiencia

Posteriormente pasa a comentar la definición de Experiencia de la RAE, destacando varios aspectos:

  • El tema de sentir
  • La práctica en el tiempo, prologanda
  • Vivido por 1 persona

Y esto último lo remarca, el tema de vivido por una persona, por un individuo. Porque pasa a explicar el mismo proceso de la experiencia de una boda, pero de SU boda.

Customer Journey Map boda Carlos

Pasa a comentar un tweet de Isidro López (@islomar) leyendo un libro de Foster Wallace “This is water”:

“La misma experiencia puede significar dos cosas totalmente diferentes para dos personas diferentes, dados dos tipos diferentes de creencias y dos maneras diferentes de construir significado desde la experiencia.”

¿Qué quiere decir esto?

No tenemos un cliente, sino muchos.

Tenemos que identificar cuales son nuestros arquetipos de clientes y trabajar de forma separada cada uno, entendiendo su journey, su experiencia completa.

Customer Jorney Map

Esto se hace con un Customer Jorney Map, poniéndo Carlos el ejemplo de uno simplificado en 5 pasos: Descubrimiento (Awareness), Consideración, Compra, Servicio y Post-compra.

Customer Journey Map

En el se identifica una serie de momentos por los que pasa el cliente,  mapeando la experienca en cuanto recuerdos positivos y negativos.

Seguir leyendo

La II Guerra Mundial, Japón y su importancia en la UX

Últimamente he estado leyendo mucho sobre Lean, Agile, Scrum, Kaizen… Y bastantes términos y artículos mencionan Japón, viniendo en muchos casos relacionados con su rápido resurgimiento después de la destrucción que vivió durante la Segunda Guerra Mundial.

Por ejemplo, el framework Scrum fue creado por Ken Schwaber y Jeff Sutherland directamente después de la publicación de Ikujiro Nonaka e Hirotaka Takeuchi de “The New New Product Development Game” en 1986, en la Harvard Business Review (HBR).

Pues bien, Nonaka fue contratado por el gobierno japonés después de la Segunda Guerra Mundial para ayudar a analizar por qué perdieron la guerra.

Otro ejemplo más relacionado con la UX o Experiencia de Usuario es el caso de W. Edwards Deming y su sistema de medios para generar de forma sostenible y económica productos y servicios que satisfagan los requerimientos del cliente (¿te suena?)

William Edwards Deming

Como consecuencia de la II Guerra Mundial, Japón estaba muy dañado, a pesar de diferentes cómites de los países aliados, no había grandes mejoras.

La situación era grave ya que no podía producir la sufciente comida para alimentar a la población, y no podían exportar bienes para ganar dinero para comprar alimentos, ya que la producción industrial era muy mala (patrimonio negativo).

El Dr. Deming (1900-1993) ingeniero y consultor de gestión estadounidense, fue invitado por el directore ecutivo de la a Unión de Científicos e Ingenieros Japonenes, JUSE (Japanese Union of Scientists and Engineers), Qenichi Qoyanagi, para que les diera a los investigadores, líderes empresarios e ingenieros, una serie de conferencias sobre métodos de control de calidad y sus teorías de gestión en agosto de 1950 en Tokyo (Hakone Convention Center).

En ellas animaba a los japoneses a producir con calidad, siguiendo el método de realizar una investigación y mirar a futuro para producir bienes que tuvieran mercado durante mucho tiempo. Al finalizar el verano, había llegado a le gerencia de la mayoría de las grandes compañías, como Sony.

Muchos consideran que Deming fue una de las inspiraciones del milagro económico japonés de posguerra (1950 a 1960) al influenciar con sus ideas la forma de trabajar, entre ellas:

  • Mejorar el diseño de los productos para mejorar el servicio
  • Conseguir el mejor nivel uniforme de calidad de producto
  • Mejorar las pruebas de productos en el lugar de trabajo y en los centros de investigación
  • Aumentar las ventas gracias a los mercados secundarios (glbales)

En resumen el mensaje a los líderes japoneses fue que si invertían en calidad e investigación, la mejora en el diseño y la calidad a la larga reduciría los gastos al tiempo que aumentaría la productividad y la cuota de mercado.

Varios fabricantes japoneses aplicaron sus técnicas y experimentaron niveles de calidad y productividad desconocidos hasta el momento. Combinando el aumento de calidad junto con un coste reducido creó una nueva demanda internacional de productos japoneses.

Seguir leyendo

Eventos en Scrum I

Los eventos se usan en Scrum para crear un patrón constante y minimizar la necesidad de reuniones no definidas.

Todos los eventos son “time boxeados”, es decir, tienen una duración máxima, pudiendo acabarse, siempre que se logre el objetivo del evento.

La idea es evitar el desperdicio de tiempo

El Sprint es un evento “contenedor“para todos los demás eventos, siendo cada uno de ellos una oportunidad formal para inspeccionar y adaptar algo. Y es que los creadores de Scrum,Jeff Sutherland y Ken Schwaber, diseñaron estos eventos para conseguir la máxima transparencia e inspección.

Scrum events

Existen 5 eventos diferentes:

  1. Sprint
  2. Sprint Planning, o Planificación del Sprint en castellano
  3. Daily Scrum, normalmente llamada Daily
  4. Sprint Review, o Revisión del Sprint
  5. Sprint Retrospective, o Retrospectiva del Sprint

He estado en algunas empresas que unifican Sprint Planning con Sprint Review, llamándo al evento “Syncro” o “Planificación” (adaptan Scrum a lo que han visto que mejor le funciona).

1. El Sprint

El Sprint es la base del Scrum. Es un periodo de tiempo de 1 mes, 3 o 2 semanas, durante el cual se crea un incremento de producto, utilizable y potencialmente liberable. Lo ideal es que siempre tengan la misma duración.

Para entender el párrafo anterior, debemos ver cada Sprint como un proyecto con un horizonte no mayor a un mes. Y al igual que un proyecto, el Sprint se utiliza para lograr algo. Cada Sprint tiene una definición de lo que se va a desarrollar, un diseño y un plan flexible que guiará su construcción, el trabajo y el producto resultante.

Un nuevo Sprint comienza inmediatamente después de la conclusión del Sprint anterior.

Un sprint está formado por el Sprint Planning, las Daily Scrums, el trabajo de desarrollo, Sprint Review y Sprint Retrospective.

Consideraciones a tener en cuenta durante el Sprint

  • No se realizan modificaciones que pongan en peligro el Sprint Goal.
  • Los objetivos de calidad no disminuyen.
  • El alcance (scope) puede ser clarificado y renegociado entre el Product Owner y el Developmente Team a medida que se descubren las cosas.

La limitación máxima de un mes es para minimizar riesgo y desperdicio. Si es más tiempo, en el mundo tan cambiante en el que estamos, la definición de lo que se está construyendo puede quedarse obsoleta, aumentando además la complejidad de lo creado.

Seguir leyendo

Product Manager

He estado trabajando bastante tiempo con empresas tecnológicas. En cada una tenía un nombre diferente, pero con el tiempo y hablando con la gente me he dado cuenta que se pueden aglutinar bajo uno solo: Product Manager.

Y es que uno de mis principios desde que realicé la carrera de Diseño, ha sido crear productos que la gente adore: bonitos, funcionales y usables, y sean sostenibles para la empresa.

Porque para construir un buen producto o servicio digital, el equipo o persona encargado de su Road Map, debe tener un conocimiento mixto de negocio, tecnología y experiencia del usuario (UX).

product_manager

Aunque como es imposible saber de todo, debe ser experto en al menos uno (en mi caso UX), ser apasionado por los 3 y haber trabajado en los 3 en general.

  • Negocio: no hay que olvidar que alguien tiene que pagar la fiesta. El Product Manager se centra en la optimización de un producto para alcanzar los objetivos comerciales mientras se maximiza el retorno de la inversión.
  • Tecnología: es muy complicado definir qué construir si se desconoce como se va a hacer y más importante, los recursos requeridos.
  • Experiencia del usuario: el Product Manager es la voz del usuario dentro de la empresa: debe hablar constantemente con los usuarios, testear el producto, analizar datos, detectar y priorizar los problemas a solucionar…. .

Funciones del Product Manager

Se debe establecer una visión del producto, investigando constantemente el mercado (informes de investigación, tendencias…), los usuarios (comentarios, atención al cliente, investigación etnográfica…) y el problema a resolver (mapas de empatía, customer journeys, análisis cuantitativo y cualitativo…).

Esa visión debe ser conocida por todo el equipo.

Si se realiza bien, cada miembro del equipo, desde ventas hasta desarrolladores, debe ayudar a crearla y sentirse parte de ella. Todos deben remar en la misma dirección.

Una parte importante es el establecimiento de las prioridades a desarrollar, el Road Map, el cual no es un documento definitivo, sino que puede variar dependiendo de la investigación que se vaya haciendo (recuerda que estamos en un mundo de constante cambio y es imposible predecir nada a futuro).

Seguir leyendo