Saraclip

Always learning about UX, Agile & Psychology

Product design

¿Cómo conocen tus usuarios que servicios pueden acceder en tu página web?

, , ,

En centraldereservas.com no somos muchos comparados con otros grandes del sector. Pero si que hemos tratado de automatizar muchas de las funciones que el usuario puede hacer con la reserva de su alojamiento. 

Para ello se ha desarrollado el área de Mis reservas, un lugar donde los clientes registrados pueden: ver un listado de sus reservas, acceder a ellas, hacer distintas acciones desde anularla a pedir una factura, ver su dinero acumulado en el Monedero, subir valoraciones de sus estancias y participar en sorteos, acceder al área de empresas, entre muchas otras cosas…

Y comparados con la competencia, si que hemos logrado tener muchas más funcionalidades en este apartado, lo cual es un valor añadido para el usuario que reserva con nosotros.

Pero, claro ¿cómo hacer saber todo esto al usuario que llega a nuestra página web? El objetivo principal no es que sepan que hay en la zona interna de Mis Reservas, sino que lancen una búsqueda y reserven, por lo cual no es algo que deba llamar la atención por encima de otras cosas como la caja de búsqueda, las ofertas…

Acceso a la zona interna del portal

Como muchas otras páginas a esta zona privada se accede desde un enlace en la parte superior de la página. La competencia le llama de muchas formas distintas a este apartado:

  • Inicia sesión / Hazte cuenta
  • Mi cuenta
  • Sin nombre solo con icono con un usuario
  • …

Y normalmente al acceder por primera vez tiene pop-ups que llaman la atención al usuario para que se registre y obtenga ventajas, tipo precios más baratos.

Seguir leyendo «¿Cómo conocen tus usuarios que servicios pueden acceder en tu página web?»

Mejores libros sobre investigación UX

, , , , ,

En la charla que dio Luz de León sobre «Metodología: diseño de un plan de investigación» en el pasado evento online #zapatillasfromMars2020 recomendaba los siguientes libros sobre investigación o research:

La charla estuvo genial, organizándose en base a 3 temas, poniendo el ejemplo de una posible investigación para una app sobre el coronavirus:

  1. A menudo se investigan sobre cuestiones de UX que no son necesarias, se hacen ciertos test ya sea porque la empresa quiere vender a todo costa, parece que sino no es un proyecto bien realizado o como protección ante malas decisiones de diseño («x usuarios dijeron que estaba todo bien».
  2. No se investigan las cosas importantes que hacen que un proyecto triunfe o muera porque son estos problemas son los más importantes de detectar y más complicados de investigar.
  3. Es habitual que no se investigue bien. En el proceso de planificación y ejecución se producen muchos fallos que pueden llegar a conclusiones erróneas:
    • Elegir el método correcto y no el que el cliente pueda pagar
    • Calidad de la muestra, no siempre se selecciona bien a los usuarios o en un número bastante representativo
    • Atención a los sesgos (algunos ejemplos que suceden en una investigación: sesgo de confirmación, sesgo del entrevistador, sesgo de representatividad, sesgo de deseabilidad social….)
Seguir leyendo «Mejores libros sobre investigación UX»

Design Toolkit

, , , ,

os dejo está página de la Universidad Abierta de Cataluña (UOC), donde podéis encontrar un montón de recursos, técnicas sobre Diseño, principios, bias… que además puedes filtrar de forma bastante avanzada:

Si seleccionas cualquiera de ellos, te lleva a una página como esta, con una explicación profunda, asi como referencias, cuando usarlo… asi como que elementos cumple dentro de una clasificación de técnicas.

Seguir leyendo «Design Toolkit»

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 «La intuición no aplica en Ontruck»

Método How Might We…?

, , , ,

Se basa en la premisa de que cada problema es una oportunidad para el diseño.

Ideada por Procter & Gamble en 1970, se popularizó como técnica de innovación, cuando IDEO la empezó a utilizar, siendo usada hoy por empresas como Google, Facebook…

Consiste en resolver cada desafío haciendo la pregunta «HMW», que proviene de la frase en inglés «How Might We…?» traducida a: ¿Cómo Podríamos Nosotros….?

HMW, un marco perfecto para el pensamiento innovador

Es decir, la técnica consiste en replantear las preguntas con la intención de convertir esos desafíos en oportunidades de diseño. La forma de hacer la pregunta sugiere que una solución es posible y que se puede solucionar de varias maneras.

Cada palabra de esa pregunta está pensada para que psicológicamente las personas no se bloqueen, ni sientan miedo de proponer cosas, sino en estimular la resolución creativa de problemas.

  1. «How» o Cómo: supone que hay soluciones para esa pregunta, proporcionando la confianza creativa»
  2. «Might» o Podríamos: indica que podemos poner ideas por ahí que podrían funcionar o no, pero que de todos modos, están bien.
  3. «We» o Nosotros: como su significado indica, sugiere que vamos a hacerlo juntos y construyendo sobre las ideas de los demás.

Como ves esto es un testimonio del poder del lenguaje para ayudar a estimular el pensamiento creativo y la colaboración libre. Y es que cuando las personas tratan de innovar dentro de una empresa, a menudo hablan de los desafíos que tienen mediante el uso de un lenguaje que suele inhibir la creatividad en lugar de favorecerla.

Y es que cuando una persona en una empresa tiene miedo a proponer una idea, ya sea porque no se siente escuchada o teme que se rían de ella, es cuando la creatividad y la innovación mueren.

Por ello, es muy importante no llegar a ese punto, creando con técnicas como «HMW…?» el ambiente adecuado para ello.

La importancia de hacerse la pregunta adecuada

Pero hay más en la metodología «HMW…?» que usar simplemente esas tres palabras, como vamos a ver de mano de la persona que lo inventó Min Basadur.

Es necesario guiar a la gente a hacer las preguntas adecuadas de «HMW…?» para centrarse en el problema correcto que es necesario resolver.

Min Basadur, director creativo de Procter & Gamble, tenía que elaborar a principios de 1970, un jabón que compitiese con el popular jabón de Colgate-Palmolive, Irish Spring, cuyo diseño tenía un color verde y una atractiva promesa de «refrescante».

irish-sprint-hwm
Packaging original y actual de Irish Sprint

Basadur pensó que el equipo de P&G hacía la pregunta equivocada («¿Cómo podemos hacer un jabón verde mejor?») y les realizo una serie de preguntas usando HMW, que culminaron con: «¿Cómo podemos crear un jabón más refrescante?», es decir, definiendo el problema correcto.

Seguir leyendo «Método How Might We…?»

Requerimientos de un proyecto

, , , , , ,

Ya sea cuando estaba trabajando para clientes pequeños, a nivel interno de una empresa, o para grandes clientes externos dentro de una consultora, me ha tocado en muchas ocasiones estar con los stakeholders (interesados)de un proyecto, definiendo sus requerimientos. Es decir, la lista de funciones, capacidades o características necesarias que debe tener y los planes para crearlos.

Stakeholders en un proyecto

Según la definición del PMBOK® (Project Management Body of Knoledgement), un requerimiento es la condición o capacidad que debe tener un sistema, producto, servicio o componente para satisfacer un contrato, estándar, especificación, u otros documentos formalmente establecido.

Se deben definir en la fase inicial junto con los stakeholders  implicados para obtener una visión completa y compartida de todas las piezas y poder priorizar en base a los objetivos del proyecto.

Los requerimientos no te indican que diseño debe tener tu producto o como desarrollarlo. Te indican que features, funciones y contenidos se espera que tenga, y como deben los usuarios interactuar con él.

Los requerimientos pueden incluso variar con el tiempo, ya que si el proyecto se desarrolla correctamente, en cuanto el MVP se haya desarrollado y se realicen pruebas con usuarios, los resultados pueden cambiar los requisito iniciales.

Tipos de requerimientos

Existen diferentes tipos de requisitos, casi tantos como implicados haya en un proyecto 😉 En un macronivel obtenemos los siguientes:

Requerimientos de negocio

Definen los objetivos y problemas que la empresa quiere resolver con el producto. Deben estar basados en una necesidad real del usuario, sea esta conocida o no por él.

Requerimientos de los usuarios

Describen las expectaciones de los usuarios y como éste interactuará con el producto. Sino son similares a los requerimientos de negocio, el proyecto irá mal encaminado.

Las técnicas de personas, escenarios y customer journeys sirven de ayuda para definir las funciones, tareas y características que definen los requisitos de usuario.

Requerimientos funcionales

Proporcionan detalle de como debe comportarse un producto y especifican lo que se necesita para su desarrollo.

Requerimientos de calidad

Detallan las características que un producto debe poseer para mantener su efectividad y prever posibles problemas y limitaciones.

En términos de experiencia de usuario, si la calidad del producto no concuerda con las expectativas que el usuario posee sobre él, no funcionará.

Requerimientos de implementación

Se usan para detallar cambios en los procesos, roles en el equipo, migraciones de un sistema a otro…

Escribiendo requerimientos

Para definirlos se recomienda usar una sentencia descriptiva que indique qué debe hacer el sitio o producto o debe permitir hacer a los usuarios, detallándola más adelante al ir avanzando en el proceso e ir obteniendo feedback de los test iniciales.

Seguir leyendo «Requerimientos de un proyecto»

Scroll hacia arriba