¿Cómo se usa el mapa en la búsqueda de un alojamiento?
En www.centraldereservas.com llevamos unas semanas mejorando el proceso de búsqueda de alojamiento con el mapa. El verano de 2022 conseguimos dar una gran salto y mostrar una vista combinada de alojamientos y mapa (antes teníamos la vista listado o la vista mapa).
El objetivo del cambio fue aprovechar que cada vez tenemos pantallas más grandes lo que nos permite la vista combinada de varios elementos, pudiendo elegir el usuario la vista que más le gusta para ver los resultados.
Google Hotels y Airbnb, muestran esta vista cuando un usuario busca un alojamiento. Nosotros por motivos de negocio no podemos ofrecerla directamente sino que deben pasar previamente por la vista listado.
¿Qué sucede cuando el usuario está con el mapa?
Pero vamos a centrarnos en qué pasa una vez que el usuario ha abierto el mapa. Normalmente se muestra con un nivel de zoom que engloba todos los alojamientos de la búsqueda seleccionada. Por ejemplo si hago una búsqueda en nuestra web de «La Manga del Mar Menor» veré lo siguiente:
Pero si te mueves un poco a ver alguna población cercana ves el vacío en el mapa, 
cuando la competencia vemos que muestra una mejor experiencia de usuario, presentando resultados o al menos indicándole al usuario qué sucede.
En nuestra web si quieres ver algún resultado, tienes que ir lanzando la búsqueda de población en población lo cual es un proceso lento y tedioso para usuarios y agentes.
Qué hace la competencia
Google Hotels, Airbnb y Booking tienen lo que para mi es ideal: al mover el mapa automáticamente van apareciendo los markers con los precios en las nuevas zonas, aunque no sea donde hayas buscado. Aunque no todos funcionan de la misma forma:
Seguir leyendo «¿Cómo se usa el mapa en la búsqueda de un alojamiento?»Damn, I´m Ops designer
Hoy he asistido al evento Damn, I´m Ops designer organizado por Redbility en Madrid. Aparte del Diseña Forum (allá por el 2013) era mi primer evento puro de diseño, ya que los que suelo asistir son más de experiencia de usuario, de metodologías agiles o de producto.
El cartel prometía con los tech leads de grandes empresas de España: Vodafone, Telefónica, Inditex, Ikea, CaixaBank, Basco Sabadell… y por eso me animé a ir.
Todo el congreso se basa en un término que yo (para ser sincera) no había escuchado hasta que oí hablar del evento (aunque desde que nació Nia mi tiempo va dedicado a otros temas: crianza respetuosa, Montessori, educación en positivo…)
Un rol, el Design Operations (DesignOps), más pensado para empresas grandes (aquí Nielsen lo explica muy bien). Lo que más me gusta es la definición del goal-: «el objetivo de DesignOps es establecer procesos y medidas que respalden soluciones escalables para estos retos, de modo que los diseñadores puedan centrarse en diseñar e investigar.»
#damnimops Alex de Fuenmayor re-definiendo el concepto de #designops y hablando de lo importante: entregar VALOR. pic.twitter.com/TQP8Pa1QBf
— SaraClip (@saraclip) March 30, 2023
Y cuando habla de los retos, se refiere a estos 4:
- Crecer y evolucionar los equipos de diseño
- Encontrar y contratar a personas con las aptitudes adecuadas
- Crear flujos de trabajo eficientes
- Mejorar la calidad y el impacto de los diseños.
Con los 2 primeros de momento no me ha tocado lidiar, ya que aunque en mi empresa el equipo de desarrollo ha crecido, el equipo de visual (y con ello me refiero a diseño que no UX) de momento sigue igual (imaginar como vamos…), pero con los 2 últimos me siento muy identificada, ya que forma parte de mi ADN de trabajo.
Osea que ha sido una sorpresa el ver que parte de las funcionalidades del rol, las tengo integradas en mi forma de actuar. Como decía otro ponente:
“Uno es muy crítico en su propia casa” esto me suena…. ☺️ Turno de la mesa redonda en #DamnImOPS
— SaraClip (@saraclip) March 30, 2023
Y es que muchas veces pensamos que hacemos menos cosas de las que verdaderamente estamos haciendo. Pero bueno el síndrome del impostor siempre está ahí je je!
Seguir leyendo «Damn, I´m Ops designer»¿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:
- 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».
- 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.
- 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….)
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.
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.
Ese plan siempre comienza con un MVP (Minimuml Viable Product) que si se puede hacer sin pintar pantallas y sin tirar código mejor.
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.
- «How» o Cómo: supone que hay soluciones para esa pregunta, proporcionando la confianza creativa»
- «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.
- «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».
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.
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.
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.