Experiencia de usuario

Optimizar un test con usuarios

Continuación del post anterior «Experiencias de realizar tests con usuarios«

Hoy en día, con los recursos tecnológicos actuales, lo más caro de un test con usuario es el tiempo empleado en decidir que testear y en hacer el recruiting.

Lo primero nadie lo puede hacer por tí, ya que:

Nadie conoce mejor el negocio que tu equipo o tú.

Por lo que piensa bien que testear y haz el mínimo trabajo necesario para comprobar esas asunciones. Partiendo de que nada es válido hasta que se comprueba, gastar el menor tiempo y número de recursos en validar una idea hará que la empresa sea más proclive a seguir testeando.

Por eso como comentan también en el libro UX Lean ( y también por experiencia propia) es mejor externalizar esa parte, ya sea que una empresa busque los usuarios presenciales o en remoto (en la herramienta de testeo que busca también los usuarios u otra de BBDD).

Preparar un test con usuarios

Imagen sacada del libro Sprint, donde se ve a M. Margolis de Goggle Ventures realizar un test con usuarios.

Si hacemos el test presencial, soy de las que opinan que, para evitar que el se pierda tiempo generando documentación extra, lo ideal es que el equipo lo presencia en directo en una habitación continua. Para ello, en un mismo día se convocan a todos los candidatos (unos 5) y se reservan las 5-8 horas de todo el equipo para que vean en directo los resultados de lo que se ha trabajado previamente.

Si es una empresa del tipo «alguien llamado X» decide (que no está en el equipo), invitarlo también a que los vea en directo.

Es asombroso como alinea ideas ver a los usuarios teniendo problemas con algo que antes parecía tan claro.

O como de claro es ver que una idea sobre la que se tenía dudas, consigue sacar sonrisas y encantar a los usuarios. Ese subidón, es una recompensa al trabajo bien hecho.

Lógicamente si el test de usuario lo realiza una empresa externa, lo más normal es que se genere un informe de usabilidad donde se reporten las incidencias y su grado de gravedad. Al estar contratado externalmente estos test suelen ser mucho más costosos que los in-house y los informes muchas veces no los suele leer nadie. Aparte de que es mucho más complejo concienciar e implicar al equipo de esta forma.

Reclutar a los participantes correctos y realizar una correcta sesión de test con usuarios no es fácil. La persona encargada deba trasmitir confianza y confortar.

Es un arte guiar una buena sesión de test con usuarios.

Sonreír, trasmitir una buena postura corporal, realizar preguntas generales al inicio (la famosa «Small talk» inglesa), que generen una situación cómoda, que permitan al usuario sentirse como con un amigo, para ser honestos, abiertos y críticos.

Seguir leyendo «Optimizar un test con usuarios»

Experiencias de realizar tests con usuarios

Vamos a hablar de la técnica más fiable (pero menos usada) para comprobar si algo funciona o se entiende: el famoso TEST CON USUARIOS (Síiiiiii, en algún lugar muy muy remoto de la galaxia existen!!)

Tanto en el ámbito digital para comprobar si las propuestas de navegación, contenidos o funcionalidad son adecuadas, como en el ámbito físico, para ver si un concepto se entiende, como demuestran en el libro Sprint Design, los test con USUARIOS REALES permiten averiguar si DE VERDAD funciona lo que hemos creado.

Te voy a decir una gran verdad, raro es encontrar una empresa que los haga de manera regular

Tristemente, debo decir que a día de hoy la mayor parte de las empresas (me atrevería  decir el 90-95%, por lo menos digitales) no los realiza. Y ya no digo de hacerlos de manera regular como comentan (y apoyo) en en libro UX Lean.

Y no porque sean caros, que no tienen porque serlo ( y más con la tecnología actual)

O yo creo que no lo son dado todo lo que se pueden ahorrar. Sino los hacen es porque nunca los han hecho y los ven como algo imposible, y no tienen a nadie que tire del carro y les convenza y les impulse a hacerlo.

Test con usuarios

Ejemplo de test con usuarios (Imagen extraída del libro de Steve Krug «Don´t make me think»)

También cuando se trabaja en empresas de tipo consultoría o agencias, los timing no están pensados para realizar test con usuarios, y de hecho, es de las primeras cosas que se quitan de los presupuestos UX (o no se llegan a incluir).

Psst… Sin usuarios no hay UX

Tristemente, debo decir que a veces los que «venden» esos proyectos, tienen cero o ninguna formación o experiencia en UX para poder hacerle entender al cliente lo que de verdad puede necesitar, que a lo mejor es probar la idea con un prototipo y no vender 400 horas de desarrollo en algo que no funciona. Pero si, dile eso a un comercial (luego se quejará de que el cliente se va a otro lado).

Por experiencias vividas, es más fácil conseguir hacerlos si están dentro de la empresa y convences de su valor al CEO, que estar en una empresa externa y tener que pasar por 20 capas de directivos que los vendan por ti.

Un consejo: gánate primero la confianza con tu trabajo previo. Así es más fácil convencer que lo que vas a hacer (el test con usuarios) vale la pena (la inversión de tiempo y recursos).

Si estás dentro de una empresa pequeña (y normalmente menos dinero) es más fácil convencer al CEO que es un grave error gastar muchísimo dinero en desarrollar aplicaciones y servicios web en base a la experiencia previa de un grupo de diseñadores, pudiendo haberlo probado con un prototipo, que cuesta bastante menos dinero con usuarios reales.

Pero si formas parte de una gran empresa es mucho más complicado convencer a toda la cadena jerárquica de los beneficios de los test con usuarios.

Debes estar en una posición que permita «mover los hilos» para ser escuchado.

De hecho a veces, parece que se tiene un pavor a hablar con las personas que van a usar la aplicación. A mi me ha pasado incluso que NO me dejaban hablar con los usuarios al inicio del proyecto, y eso que eran usuarios propios de la empresa al ser una aplicación interna.

Podemos saber mucho de un negocio, y tener muy claras ciertas cosas, pero no es hasta que se prueba con usuarios reales, que de verdad podamos ver si está funcionando o no.

Si te gusta el tema, sigue leyendo mi siguiente post de consejos para optimizar un test con usuarios.

Principios Lean UX para guíar la organización de equipos

Los principios en los que se basa Lean UX se agrupan en 3 bloques. Cada uno sirve para guiar:

  1. La organización de equipos
  2. El proceso
  3. La cultura

Gracias ellos iremos viendo las ventajas que conlleva implementar Lean UX en tu organización y como esta se modificará conviertiendose en un lugar abierto, transparente, que aprovecha el conocimiento y la entrega de todos para conseguir los mejores resultados.

En ellos se basarán las herramientas y técnicas para lograr mejorar la colaboración, lograr entregar mejores productos y servicios de forma más rápida y con el menor gasto de recursos usando los conocimientos de todos los implicados y basando las decisiones en pruebas reales.

Y es que como dice Jeff Gothelf en su libro Lean Startup: «Get out of the deliverables business», en castellano: olvidémonos de centrar el negocio en las entregas y centrémonos en los que de verdad importa, hacer disfrutar a nuestros clientes con una experiencia memorable.

Principios Lean UX para guíar la organización de equipos

Equipos multifuncionales

Con esta palebreja lo que se refiere es que los equipos deben estar formados por aquellas personas con conocimientos necesarios en ese momento del proceso: desarrolladores, product management, testers, diseñadores visuales y de interacción, gestores de contenidos, marketing…

Para crear un gran producto es necesaria la suma de todos los conocimientos y la colaboración entre todas las disciplinas.

El todo es mayor que la suma de sus partes

Cuando un equipo está formado por personas de diferentes perfiles, se obtienen mejores soluciones ya que cada problema es visto desde un punto de vista diferente, aportando una gran diversidad.

Los miembros del equipo además están en contínuo contacto, por lo que poseen todo el conocimiento de lo que está sucediendo y lo que va a haserse al contrario que en organizaciones donde todo esta compartimentado. Gracias ello conseguimos una gran colaboración desde el inicio del proyecto logrando una mayor eficiencia de equipo, y trabajadores mucho más implicados en el proyecto.

Equipos pequeños, dedicados y juntos

Lo ideal: no más de 10 personas, focalizadas en el mismo problema y a ser posible en la misma ubicación. ¿Por qué?

Los equipos muy grandes tienen problemas para organizarse y compartir la misma información.

Los equipos pequeños generan un mayor sentimiento de camadería lo que genera mayor implicación en el proyecto y en las personas que lo están creando juntas.

Building a team

Imagen obtenida de aquí

Trabajando además en el mismo y único proyecto se consigue que estén centrados al máximo en las mismas prioridades y elimina las odiosas dependencias sobre otros equipos.

Autosuficientes y con poder para decidir

Si queremos obtener de forma rápida algo con lo que poder testear una suposición necesitamos que el equipo tenga todas las capacidades necesarias para trabajar sin dependencias externas.

Seguir leyendo «Principios Lean UX para guíar la organización de equipos»

¿Optimización Client-side o Server-side?

La optimización de un sistema digital se encarga de estudiar el comportamiento de los usuarios para determinar en qué elementos se tiene que actuar para aumentar la eficiencia hacia el objetivo final.

Existe un montón de factores referentes a la optimización pero en este artículo quiero centrarme en aquellas herramientas que como nos permiten modificar una página web o app mostrando diversas versiones de la misma para posteriormente elegir la versión que mejor convierta.

Herramientas que nos permiten trabajar con el famoso CRO (Conversion Rate Optimization)

Para que en base a lo observado podamos aumentar las conversiones de nuestra página, es decir, cuando un usuario llega a un sitio y cumple el objetivo de negocio que hemos previamente establecido. 

Video explicativo de Optimizely X

Para ello es imprescindible conocer sus necesidades, e intentar resolverlas de la mejor forma posible analizando su comportamiento.

Existen 2 tipos de herramientas de optimización:

  1. Client-side (Del lado del cliente), actualmente las más usadas
  2. Server-side (Del lado del servidor)

En las primeras, las diferentes versiones se crean en la página del navegador (Chrome, Firefox…) El servidor envía la versión original al navegador, y mediante un código JavaScript introducido el propio navegador la modifica. De este tipo tenemos Optimizely X,  Visual Website Optimizer, Unbounce, Hubspot, A/B Tasty, Google Optimize, Adobe Target y Oracle Maxymiser.

Seguir leyendo «¿Optimización Client-side o Server-side?»

Recursos sobre Evaluación Heurística

Un análisis heurístico es una técnica para evaluar la usabilidad de un sistema de interfaces y procesos a cargo de un experto, a partir de los principios de la disciplina de Interacción Persona-Ordenador (IPO o HCI en inglés, Human Computer Interaction).

Esta técnica es perfecta para entender el estado actual del producto e identificar problemas básicos a evitar si es un rediseño o proponer soluciones para arreglarlos.

El análisis consiste en una serie de comprobaciones en base a criterios establecidos que velan por la usabilidad y la consecución de los objetivos de negocio de la aplicación.

Estos criterios se deben adecuar al contexto, por lo que hay que previamente hay que conocer las tareas que se han de realizar y el perfil de usuarios que van a utilizar el sistema o sitio web.

Principios de Jakob Nielsen

Los principios heurísticos de Jakob Nielsen son probablemente los más usados para verificar la usabilidad del diseño de interfaz de usuario.

Existen dos versiones, una primera publicada junto con Rolf Molich en 1990, donde se les denomino «heurísticas» y una segunda junto con Marie Tahir en 2002, donde se revisan los anteriores en base a un análisis de más de 200 sitios web (anglosajonas). A continuación, se enumeran los contenidos en la segunda publicación:

  1. Visibilidad de estado del sistema, informando a los usuarios de lo que ocurre proveyendo feedback adecuado.
  2. Correspondencia entre el sistema y el mundo real. El lenguaje empleado debe ser adecuado al usuario, siguiendo en todo momento las convenciones del mundo real.
  3. Control de uso y libertad. Dado que el usuario va a cometer errores, el sistema debe ayudar a evitar situaciones indeseadas.
  4. Consistencia y estándares para que el usuario no tenga que adivinar diferentes conceptos o palabras. Seguir las convenciones de la plataforma que se esté usando.
  5. Favorecer la prevención de errores antes de que estos ocurran mediante elementos que ayuden a evitarlos.
  6. Reconocimiento de los elementos antes que recuerdo, optando por la visibilida y repetición de elementos, así como de estándares de uso evitando la sobre carga cognitiva de la memoria a corto plazo.
  7. Flexibilidad y eficiencia de uso, estando adaptado tanto para usuarios novatos y expertos.
  8. Estética y diseño minimalista evitando usar elementos que no sean necesarios y sólo añadan ruido visual, restando importancia a los que si la tienen.
  9. Ayuda a los usuarios para reconocimiento, diagnóstico y recuperación de errores mediante indicaciones claras de cómo resolverlos.
  10. Aunque lo ideal es que no sea necesaria, en el caso de que se requiera debe existir una ayuda general y documentación de forma accesible y concisa.

Recursos:

Lista de comprobación de Deniese Pierotti

El conjunto de principios heurísticos de Nielsen ha servido como punto de partida para la creación de numerosas listas de subheurísticos. La de D. Pierotti fue usada por la empresa Xenox Corporation, famosa pionera en evaluar la usabilidad de sus interfaces.

Añade 3 principios a la lista de Nielsen, más una lista de sub-heurísticas de los 10 principios de Nielsen y de los 3 nuevos añadidos:

  • 11. Habilidades: el sistema debe tener en cuenta, extender, suplementar e incentivar las habilidades del usuario, sus conocimientos y su experiencia.
  • 12. Interacción placentera y respetuosa: Las interacciones de los usuario con el sistema deben favorecer su calidad de vida, presentando un diseño estético, en donde los valores artísticos se igualen a los funcionales.
  • 13. Privacidad: el sistema debe ayudar al usuario a proteger la información personal o privada, tanto la del propio usuario como la que pertenece a los clientes del usuario.

8 Principios de usabilidad de Ben Schneiderman

Pero estos no son los primeros. Existen otros, como las 8 reglas de oro para el diseño de interfaces de Ben Schneiderman, publicadas por primera vez en 1986 en su libro «Designing the User Interface: Strategies for Effective Human-Computer Interaction«. Seguir leyendo «Recursos sobre Evaluación Heurística»

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»

¿Qué busca el usuario en una web?

Las personas accedemos a internet buscando satisfacer una necesidad de información y/o realizar una transacción.

Este artículo vamos a hablar sobre el primer caso: la satisfacción de una necesidad de información, basándonos en el libro de Mario Pérez-Montoro Gutiérrez, «Arquitectura de la información en entornos web«. Te recomiendo su lectura si te gusta el tema.

Tipos de necesidad de información

Existen 4 tipos de necesidades informativas:

  1. Necesidad de información concreta (NIC) o búsqueda de un item conocido. Esta necesidad responde al momento en que el usuario busca cuánto vale un vuelo de Barcelona a Nueva York o quién ganó la copa de futbol en 1982. Es una necesidad que se puede formular de forma exacta y que se resuelve a partir de una única respuesta.
  2. Necesidad de información orientada a problemas (NIOP). En este caso, no acostumbra a presentar unos límites bien definidos o no se puede establecer si se necesita más información para resolverla. Para ello, el usuario navegará a través de diferentes items de información hasta que crea que ha resuelto su necesidad. El ejemplo que nos presenta Mario Pérez-Montoro en su libro sería conocer la relación entre la educación de un país y su economía.
  3. Necesidad de información exploratoria (NIE) o búsqueda exploratoria. En este caso se busca una respuesta útil dentro de un conjunto de respuestas localizadas previamente. Lo que ocurre es que no estamos seguros de que la respuesta elegida sea la más adecuada. Por ejemplo ocurre, cuando después de haber investigado varios hoteles para las vacaciones que se ajustan a nuestro presupuesto, buscamos opiniones de otros usuarios que nos ayuden a decidirnos sobre el tema.
  4. Necesidad de información sobre búsquedas previas (NIBP) o recuperación de una búsqueda. En este caso el problema de necesidad de información se resuelve volviendo a localizar una información que ya habíamos encontrado previamente, como cuando abrimos una página web que tenemos guardada en favoritos.

¿Cómo resuelvo mi necesidad de información?

Dependiendo del contexto, la forma de satisfacer esa necesidad cambia. Un niño pequeño, le pregunta a su madre, en el instituto le preguntamos al profesor, en un aeropuerto a la persona del mostrador de información, antiguamente si estábamos perdidos con el coche por una ciudad, al primer peatón que pase.

Seguir leyendo «¿Qué busca el usuario en una web?»

Jerarquía de necesidades

Adaptadas de la Jerarquía de necesidades de Maslow, un diseño debe servir primero a las necesidades primarias del usuario (por ejemplo, debe funcionar bien), antes que a las de más alto nivel (por ejemplo, ser bonito).

Jerarquia necesidades UX

Existen 5 niveles de necesidades que deben ser cumplidas en el orden mencionadas: Funcionalidad, Confianza, Usabilidad, Eficiencia y Creatividad.

Buenos diseños siguen el principio de la jerarquía de necesidades, mientras malos diseños intentan cumplir necesidades de diferentes niveles sin cumplir los primeros.

Necesidades de Funcionalidad

Consiste en satisfacer los requerimientos más básicos del producto. Por ejemplo, un teléfono debe tener al menos la mínima capacidad de llamar. Si un producto o aplicación no las cumple no tiene valor para el usuario.

Necesidades de Confianza

Un producto o aplicación debe cumplir siempre su función perfectamente. Si el producto falla continuamente o actúa cada vez de una manera, el usuario no confía y el producto tiene poco valor.

Si cada vez que encendiéramos las luces del coche estas se encendieran unas veces si y otras no, el coche cumpliría su función básica de transporte pero tendría muy poco valor al tener a veces que conducir de noche y no poder confiar en hacerlo.

Necesidades de usabilidad

Tienen que ver con como de fácil o de deshacer nuestra elección cuando nos equivocamos al usar un producto.

Si su uso es muy difícil para el usuario, o la consecuencia de un simple error es muy severa, no se cumplen las necesidades de usabilidad. Si borramos una foto por equivocación, sabemos que la podemos encontrar en la papelera y recuperarla. Eso hace que confíemos en el producto.

Necesidades de eficiencia

Consisten en ayudar a las personas para que hagan las cosas de una forma superior y mejor a como las hacía antes. Los diseños que cumplen esta necesidad tienen un gran valor para el usuario.

Que el móvil nos permita hacer fotos o servir como despertador ha conseguido que no tengamos que tener otros dispositivos para realizar esas funciones. Que la lavadora lave la ropa dejándonos a nosotros ese tiempo para hacer otras cosas, nos soluciona un gran problema.

Necesidades de creatividad

Cuando todos los niveles anteriores han sido satisfechos, la gente interactúa con el diseño de forma innovadora.

El diseño permite al usuario crear y explorar áreas que mejoran ambos, el diseño y la persona que lo usa. Diseños que cumplen este nivel son percibidos como de gran valor, y crear usuarios fieles a ellos.

Cumplir estas necesidades en orden a la hora de diseñar nuestros productos y aplicaciones, harán que nos centremos en lo que realmente necesita el usuario, determinando una vez cumplidas las más bajas, cómo seguir evolucionando el proyecto.

Investigación de usuarios en la BBC, un caso práctico con impacto

Júlia Ivorra da una de las charlas que más me ha gustado este año: Investigación de usuarios en la BBC, un caso práctico con impacto.

Nos cuenta como en la BBC Sport habían desarrollado un ecosistema de productos y servicios (online y offline) para su audiencia y querían, aprovechando un verano lleno de deporte, mejorar los servicios de la BBC online y preparar la cobertura de las Olimpiadas de Tokyo 2020.

El objetivo era averiguar cuáles eran las motivaciones de nuestros usuarios para conocer porque usaban unos productos u otros. Es decir, averiguar como estaba la BBC integrada en la vida de las personas.

Pero no querían hacer una investigación que sólo generase un informe tocho de entrega al final del verano que solo vieran (en el caso de que lo lean) los jefes, en vez de todo el equipo, por lo que definieron como querían que fuera su proyecto de investigación:

  • Tenía que ser agile
  • Tenía que ser reportada diariamente. Integrada con el trabajo. No sólo un informe al final del proceso
  • Involucrando a todo el mundo

Tenían unos 30 eventos para analizar en 3 meses y medio. Y pensarás, ¿por qué tantos?
Pues porque cada evento es único, y la gente que los sigue es diferente, no es la misma persona la que sigue el golf que la que ve el futbol.

Dividieron la investigación en 4 rondas con 4 participantes cada uno, realizando un análisis de resultados en cada ronda y difundiendo al equipo lo que estaban descubriendo.

Informaban al resto del equipo en vivo, mientras estaban pasando los eventos.

Iban publicando todo lo que iban averiguando en un canal de Slack consiguiendo que la gente les hiciera preguntas para que el equipo de investigación se las preguntase a los usuarios. O si veían algo raro en las analíticas, lo comentaban para que intentaran averiguar porque sucedía.

Como todo el mundo seguía el canal, muchos incluso se acercaban a las entrevistas que les interesaban.

Todo el equipo estaba hablando de usuarios, de cómo usaban sus productos.

Consiguieron erradicar, el típico “yo creo”, «a mi me gusta» o “he leído un post que dice esto”.

A nivel formal después de cada ronda iban difundiendo lo que aprendían colgando en una pared de la oficina las cosas para que todo el mundo las tuviera presente.

Caso de research en la BBC

También crearon artefactos UX: un journey map de toda la información que les estaba llegando. 
Y lo mejor, es que estos artefactos se siguen usando a día de hoy, no son algo puntual.

Están basados en algo real. En casos de usuarios reales.

Y a un nivel superior, pasó algo muy bonito. Los jefes ya no estaban encerrados en reuniones decidiendo que iban a hacer, sino que iban leyendo el mismo canal y haciendo preguntas cuando creían conveniente.

Y es que como comenta Julia, si sólo involucras a los jefes mandándole sólo a ellos el informe, en vez de a todo el equipo, acaba pasando que parece que están en una bola de cristal, aislados, con conocimientos únicos que solo poseen ellos.

Habían conseguido q los stakeholders hicieran User Centre Design.

Así cuando los jefes tuvieron que tomar decisiones estratégicas, las tomaban en base a casos reales.

Y cuando compartían los nuevos objetivos estratégicos a seguir todo el mundo los entendía y supo porque se habían tomado esas decisiones.

A mi modo de ver, una de las cosas que más fallan las empresas es en conseguir que todo el mundo comparta la misma visión del negocio. Qué los de arriba tengan información del día a día para tomar decisiones y encaminar el futuro de la empresa y qué las elegidas sean entendidas por toda la compañía.

Porque se puede IMPONER remar en una dirección, pero se avanza mucho más rápido cuando todo el equipo CREE que es la correcta.

En resumen, Ivorra finaliza compartiendo lo que ha aprendido en base a este proceso y que aplica en su día a día:

  • Ser agile: dividirlo todo y realizarlo a menudo
  • Ser transparente: todo el mundo tiene acceso a leer los proyectos e involucrarse en la investigación
  • La investigación tiene que tener un propósito, se hace para ayudar a otros a hacer mejor su trabajo.

Muchas gracias Julia por compartir un caso real de trabajo. Me ha encantado!

Diseñar servicios cara a cara

Una de las charlas que más me ha gustado ha sido la de Itziar Pobes de la empresa WeQuestionOurProject, un estudio de diseño de servicios en Barcelona.

Itziar nos comenta 3 ejemplos de proyectos que han realizado (me encanta cuando nos los ponentes nos cuentan ejemplos).

El primero trata sobre un pequeño ayuntamiento el cual, su población al estar cerca de la universidad tenia un elevado porcentaje de gente joven. Éstos les empezaron a hablar y a preguntar dudas usando las cuentas de Facebook y otras redes sociales que poseía la institución.

¿Y qué pasaba? Que sino respondan quedaban mal, por lo que aunque no era muy legal responder a algo oficial por ese medio, prefirieron dar el servicio.

Y los ciudadanos estaban encantados.

La alcaldesa se enteró y en vez de pararlo, decidió ver como podía mejorar el sistema. Incluso decidió tirar la oficina y construir una nueva generando un montón de inquietudes en el equipo de atención al ciudadano, al no tener ni un sitio donde trabajar. Y es en estos momentos, es cuando el equipo de Itziar entró a trabajar.

Empezaron a investigar las dinámicas de trabajo, cuales eran los diferentes servicios que los ciudadanos podían hacer… construyendo prototipos muy rápidos mediante cajas de cartón en la oficina en obras para ver como interactuaban en una situación real, probando la experiencia en la oficina.

El resultado final fue muy visual y tuvo mucho impacto, y el ayuntamiento, que siguió contando con WeQuestionOurProject durante los años siguientes, les ha gustado tanto la nueva forma de enfocar sus servicios, que ha llegado a montar incluso su propia oficina de innovación.

Rediseño de oficina aplicando service design

Rediseño de oficina aplicando service design

El siguiente proyecto consistía en una app para evitar la soledad a las personas mayores.

Cuando llegaron al proyecto ya estaban realizando un segundo proyecto piloto con desarrollo, equipo de UX y accesibilidad, de desarrollo, equipo de servicios sociales, personal de Evaluación de políticas públicas…

Service design

Seguir leyendo «Diseñar servicios cara a cara»

Scroll hacia arriba