Archivo de la etiqueta: Diseño de servicios

Realización de una prueba de usabilidad con test de usuarios

Tiempo de lectura: 3 minutos

Esta semana he estado colaborando con una empesa realizando un análisis heurístico y varios test de usuarios para evaluar la usabilidad de 2 webs que querían analizar.

Test de usuarios Valencia

Momento del montaje de la sala para la realización del test

El propósito de las pruebas de usabilidad realizadas era recopilar información sobre cómo los usuarios usan el sitio, ver si existen problemas al navegar, al interactuar con los elementos y al leer la información, y comprobar si existen mejoras que permitan aumentar la conversión del objetivo principal de la web: la reserva una habitación.

Para ello se han definido varios elementos que eran necesarios:

  • La metodología de prueba
  • Los tipos de usuarios para la prueba
  • La declaración del problema y las tareas/escenarios propuestos
  • Entregables con las conclusiones obtenidas

Durante la prueba se han realizado 3 test:

  1. Test para recolectar los participantes: test de filtrado mandado a los partipantes interesados via formulario online para que lo rellenasen y detectar en base a sus respuestas cuales entraban dentro de la tipología definida.
  2. Test con las tareas a realizar en la prueba: Definición de las tareas a realizar en la prueba (4 en este caso)
  3. Test realizado después de cada prueba para su evaluación: Después de cada tarea y al finalizar la prueba mediante un ipad que disponíamos al lado del ordenador,  el usuario debía valorár del 1 al 10, 3 preguntas por tarea para analizar su satisfacción de lo realizado y el sentimiento generado.

Tipología de usuario para la prueba

Después de analizar el perfil del usuario en base a entrevistas con el cliente, al producto ofrecido, y la posible competencia, se definió un usuario tipo a buscar para la prueba con varias preguntas de control.

El participante debía cumplir los siguientes requisitos:

  • Que viajasen mínimo 1-3 veces al año a hoteles (se les preguntaba además número de noches dormidas en hotel el pasado año).
  • Que viajasen por placer y acompañados de la familia o pareja (se les preguntaba además año de nacimiento).
  • Que utilizasen internet más de 2 horas al día (se les preguntaba para que lo usaban).
  • Que fueran ellos los que realicen las reservas (se les preguntaba donde reservaban habitualmente).

Además, lógicamente se agradecía su tiempo con un cheque regalo de 30€.

Escenarios propuestos para el test de usabilidad

EL objetivo de la prueba es proporcionar datos cualitativos sobre la experiencia del usuario en la web.

Sigue leyendo Realización de una prueba de usabilidad con test de usuarios

Cómo diseñar un bot

Tiempo de lectura: 3 minutos

Una de las charlas que más me gusto de la Tarugoconf fue la de Cris Santamarina (@crissantamarina) de TheNeonProject.org una persona que ha vivido más vidas que mucha gente.

Después de dejar a toda la sala abierta con su experiencia por África, Europa, o Sudamérica, Cristina nos cuenta algunos consejos para diseñar un buen chatbot o BYOB (Bring Your Own Bot).

Tecnologia chatbot

Una de las principales ventajas es que el usuario no tiene que instalarse nada especial. Viven en apps o webs que la gente ya usa en su día a día como Facebook, Slack, Twitter, Echo, SMS, en la web…

Uso de los chatbots

Si nos centramos en los usos (buenos) de los bots encontramos 3:

  • Bots transaccionales:  que actúan como intermediarios en transacciones entre personas y medios externos.
  • Bots informativos o promocionales: ayudan a gestionar la información que se publica en los canales de información.
  • Chat Bot: simulando una conversación con humanos, dando información y tratando de resolver dudas.

Bot Patrontequila

Ejemplo de chatbot promocional: Patrón Tequila

Pero vamos a ver como diseñamos un chatbot. Y es que, como en cualquier otro proyecto, se deben tomar una serie de decisiones para que la experiencia de usuario sea la mejor.

1. Decidir como va a navegar

Lo primero es decidir como va a navegar el usuario por nuestra chatbot. Existen 2 tipos de navegación:

  1. Expresiones
  2. Botones

Expresiones y botones bot

En la imagen vemos ejemplos propuestos por Cristina de las dos opciones de nagevación en chatbots.

El mejor approach es hacer una navegación mixta

La conversación mediante expresiones “más humana” es decir, más cercana a la forma en que hablamos entre nosotros.

El incoveniente es cuando el usuario pide algo que no tiene o entiende el bot.

Cristina comenta además que lo primero que hace la gente al llegar a un bot es preguntar.

La conversación mediante botones es menos conversacional, ya que le estás dando al usuario 2 o x opciones, con lo cual debes conocer que necesita para saber que oferecer.

En este caso sobre todo debemos asegurarnos que el usuario entiende que eso es un botón que se puede y debe pulsar, ya que comenta que hay casos que por el diseño de interfaz que ofrece, el usuario no lo sabe utilizar y hay que enseñarselo al iniciar la conversación.

UI Chatbot

2. Decidir la personalidad del bot

El segundo punto es decidir si queremos que el bot tenga personalidad o no, y en el caso de que la tenga cual queremos que sea.

Y es que no todos los chatbots tienen que tener personalidad ya que por ejemplo, en uno cuya funcionalidad principal es ayudarte a buscar una plaza de parking vacía, el usuario no quiere perder tiempo hablando con él.

3. Hola soy un bot

Cristina comenta que la clave de la experiencia de usuario de un bot es la conversación. Por ello siempre debe presentarse como un bot para que la gente lo sepa.

Conversacion Chatbots

Por ello, sobre todo si es un bot para automatizar parte de la Atención al cliente o soporte, siempre debe haber soporte humano detrás en el caso de que el usuario necesite un mayor interacción que el bot no le pueda dar.

4. Sencillos

Igual que sucede en las páginas web los usuarios somos vagos y muchas veces evitamos leer. Por ello el bot debe adaptarse a ello, proveyendo botones que indiquen acciones en vez de textos largos.

UX bot

5. Mensajes de error

No hay nada más frustrante que preguntar por algo a un chatbot y que todo el rato te responda de la misma forma sin poder salir de ese bucle. Sigue leyendo Cómo diseñar un bot

Mejorando la experiencia de usuario gracias a Soporte (II)

Tiempo de lectura: 6 minutos

Seguimos con el resumen de la genial charla de Inés Luna (@cuquiesp) en la Tarugoconf 2016 sobre lo aprendido al montar un equipo de soporte desde cero en una startup. (Leer antes la primera parte)

2º Fase: Escala o muere

Vas creciendo y tienes un volumen de clientes más grandes, es un caos contestarles por email, has tenido problemas con los equipos porque no sabes que hacer cuando alguien reporta un bug, los bugs no se arreglan…

Luna comenta que cuando el equipo crece busca personas que no necesariamnete tengan experiencia en soporte, sino que sean grandes comunicadores y que tengan una gran capacidad empática con los clientes, pero que tengan “huevos grandes” para tomar decisiones porque muchas veces hay que decirles que no a los clientes, pelerse con ventas que han mentido a los clientes, con producto…

Inés nos cuenta que la clave es formar un equipo fuerte y solidario. No solamente personas alineadas con la cultura de la organización sino q esten alineadas con el resto del equipo para crear un equipo muy unido ya que atención al cliente puede ser muy ingrato. ¿Cómo?:

  • Hacerles participe en el proceso de nuevas incorporaciones
  • Que el equipo cree documentos de onboarding para ayudar a los nuevos miembros
  • Poner un mentor a la persona nueva para ayudarle y que aprendan entre ellos

Segmentar a los usuarios

Cuando creces y tienes muchos clientes, seguramente ya has cabredo a más de uno (y parece que se acabe el mundo! Pero no). Si, como en su caso, eres un producto freemium, tienes que empezar a tomar decisiones,y segmentar a tus usuarios, ya que no es el mismo soporte el que le das a una persona que no paga, a una que paga poquito o a una que paga mucho.

Tienes que empezar a segmentar a los usuarios y empezar a entender:

  • Cómo de rápido puedes contestar a la gente
  • Qué tipo de incidencias equieren atención urgente
  • Cual es el canal más adecuado para cada segmento, no es lo mismo una gran corporación que tiene el pooducto instalado a medida, que una persona que lo usa gratis una vez al mes…

Zendesk

Es el momento de empezar a pensar a usar una herramienta de Customer Service profesional como ZenDesk y empezar a trabajar en los procesos, como las automatizaciones, el workflow de los tickets… ya que vas a ser mucho más eficiente en lo que haces.

Gestión de indidencias

Tambien en esta etapa debes empezar a coordinarte mucho más con el resto de los equipos, como en el caso de las incidencias técnicas o bugs, trabajando con QA, desarrollo, producto… para definir que algo es una incidencia versus que el cliente no entiende cómo usar el producto, como reproducir esa incidencia, acordar entre todos cual es el criterio para poner una prioridad, quien es el responsable de asignar esa prioridad, si esa prioridad puede variar en función del número de tickets que dispongas…

Sino hay un acuerdo entre todos, el proceso puede ser muy doloroso.

Medición y analítica

Implementas procesos con ventas, con facturción…. y ya usas una herramienta específica para atención al cliente y tienes q empezar a medir lo que estás haciendo. Y con herramientas como Zendesk puedes hacer reporting de cualquier cosa. Inés nos recomienda que nos centremos en cosas básicas en su caso por ejemplo, en el tiempo que tardaban en atender a un cliente.

Se dieron cuenta de que atendían antes a los usuarios que no pagaban, ya que preguntaban cosas más sencillas, haciendo esperar más tiempo a los que pagaban por la herramienta.

Darse cuenta de eso hizo que tuvieran que reorganizar el workflow para poner la prioridad en los clientes que más aportan.

El tiempo de resolución de un ticket es otra historia, porque si tienes incidencias que tienes que escalar a otro equipo ya no depende de tu trabajo, y ver cual es el proceso para escalar, cuanto tardan en resolverlas, cada cuanto haces una release, cada cuanto se arreglan los bugs, la proporción de tiempo entre trabajar en roadmap y hacer la plataforma más estable y arreglar bugs… Esas métricas ya no depende sólo de ti.

Satisfacción de tus usuarios

Para conocer si los usuarios estaban contentos, Inés comenta que ella implementó 2 tipos de métricas, una más transaccional que es en base a las interacciones con el equipo de soporte y la otra para conocer la satisfacción general, el NPS.

En la primera mandaba un email después de resolverles la incidencia con una encuesta, donde les preguntaba si están satisfechos o no. Descubrieron que vivían estresados con los tickets pero los usuarios estaban en un 95% sastisfechos con el servicio que tenían en soporte.

Lo segundo que implementaron fue el NPS (Net Promote Score) que no es una métrica de soporte sino que es mucha más amplia, usada en marketing, producto… que consiste en hacerles la pregunta de ¿Cómo de problable es que recomiendes este producto a un compañero de trabajo o un amigo?

Descubrieron que si bien en soporte estaban contentos, había un descontento generalizado de los clientes que no tenía que ver con soporte sino que tenía que ver con funcionalidades que habían quitado en el producto, sobre el proceso de ventas y facturación que era muy engorroso y muy lento para muchos clientes pagar, con el reposicionamiento del producto, de gestiñon de proyectos en comunicación en tiempo real que la gente no entendía porque habíaan hecho ese cambio.

Son métricas muy diferentes que te dan 2 visiones para ver como de contentos están tus usuarios.

Etapa: Todo explota

En 2014 hacen un rebranding y lanzan una visión nueva del producto. Era simplemente un lavado de cara visual, pero a los usuarios no les gustan los cambios. Y eso hace que el equipo de soporte reciba miles de llamadas contestando siempre lo mismo.

¿Qué haces cuando tus clientes no están contentos de ese cambio?

Sigue leyendo Mejorando la experiencia de usuario gracias a Soporte (II)

Consultoría UX para empresas

Tiempo de lectura: 1 minuto

Hoy os quiero contar la sesión de consultoría de Experiencia de Usuario que estuve realizando con el equipo de Waidis, una startup de Demium, cuyo modelo de negocio se basa en proporcionar ayuda a grandes empresas que requieren un volumen extra de trabajadores en determinados momentos puntuales agilizando el proceso y mejorando la calidad de sus contrataciones.

Waidis

Fue una reunión de 2 horas muy productiva donde trabajamos en varias líneas.

Por un lado yo había previamente realizado un análisis heurístico de la web y les pase ciertas cosas mejoras e ideas que había visto (hay que decir que la web la crearon hace meses y ellos mismo la tenían pendiente de cambio).

Por otro lado, realizamos varios story mapping desde el punto de vista de los 2 principales grupos de usuarios para identificar posibles problemas, y contemplando de forma rápida mediante bocetos cuales podrían ser las mejores soluciones.

Sigue leyendo Consultoría UX para empresas

Charla UX en Demium

Tiempo de lectura: 2 minutos

El pasado martes di una formación en Demium sobre Experiencia de usuario a los integrantes del último AllStartup.

Formacion UX

180 diapositivas y dos horas de duración para explicar por qué es importante trabajar con metodologías centradas en el usuario, como nació la Experiencia de usuario, ejemplos divertidos de qué es y qué no es UX, técnicas para encuentrar el problema y conocer a los usuarios y sus necesidades, consejos sobre hasta qué nivel de detalle necesitas llegar al realizar un diseño, ejemplos de diferentes tipos de test con usuarios, y como medir  en base a lo que queremos analizar.

Además remarqué especial importancia sobre como trabajar el proceso de discovery de producto y la experiencia de usuario en un equipo, siguiendo la técnica Lean UX, que muestra como colaborar con otros miembros del equipo obteniendo feedback cuanto antes y de forma continuada.

Y es que ya que la charla iba dirigida a empresas que están comenzando nada mejor que remarcar la importancia que tiene la cultura de empresa y la forma de desarrollar un producto y trabajar en equipo.

Y es que la suma de las partes supera al todo.

Lean UX es un conjunto de principios que adaptados a cada empresa y equipo, sirven de guía para encontrar mejores y más deseables soluciones para los usuarios. Explica una serie de técnicas y una forma de aplicarlas haciendo diseño y descubrimiento participativo entre los diferentes pefiles implicados en el proyecto en un entorno siempre cambiante e impredecible.

Y es que para diseñar un gran producto o servicio no se debe confiar en la figura de una única persona, ya que no exiten los Gurús o Ninjas que lo sepan todo. Es sumando el conocimiento de los diferentes perfiles del equipo, lo que permite obtener un MVP (Minimum Viable Product) con el menor coste de recursos posibles que permita probar cuanto antes las suposiciones ideadas entre todos.

Y es que todo son suposiciones hasta que no se testea.

 

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

Tiempo de lectura: 4 minutos

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.

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

Ventajas de los workshops

Tiempo de lectura: 3 minutos

Ir a un sitio nuevo, juntar varias personas de diferentes ámbitos para que trabajen juntas, darles rotuladores y post-its, y pedirles que no hablen sino que escriban o dibujen sus ideas, predispone al cerebro a trabajar de forma diferente.

Un workshop rompe la rutina y crea nuevas situaciones y sensaciones desde el inicio.

Te levantas a una hora diferente, te vistes de otra forma, coges un camino alternativo ya que no vas a la oficina… Con la idea de trabajar en grupo podemos incluso estar un poco nerviosos… nuestro corazón se acelera.

La rutina es buena para alcanzar orden y eficiencia en una profesión, pero si buscamos creatividad, necesitamos inspiración.

Un workshop consigue inspiración e innovación al juntar miembros con diferentes conocimientos, al cambiar los roles de cada día… pero lo más importante es que los equipos consiguen nuevas ideas JUNTOS.

Pensar y construir juntos

Tanto en la vida personal como en la profesional, trabajamos en varios proyectos con mucha gente en los que asumimos diferente roles. En algunos, lideramos, en otros delegamos, en otros colaboramos… pero ¿cuántas veces trabajos activamente juntos?

Muchas veces gastamos más energía defendiendo una primera opinión que explorando más opciones cuando a lo mejor no es la opción más adecuada para el grupo.

Además en una reunión hablada siempre hay gente que habla más o gente más tímida que no participa. Si todo el mundo está obligado a escribir o dibujar sus ideas, todo el mundo tiene voz. No existen problemas de ego, ni de que “siempre decida el jefe”.

Las ideas no son de nadie, pertenecen al grupo.

Es el grupo quien las valora en conjunto. Nadie discute nada, sino que todo se visualiza. El resultado son un montón de opciones que facilitan la extracción de conclusiones.

Evitar la figura del experto

En un workshop no hay nadie delante de todo el grupo hablando. En vez de hacer un trabajo individual sobre lo que somos expertos que nadie lee, es mejor visualizar un proyecto común a través del dibujo o la escritura, construyendo un proyecto mediante la contribución de cada uno en vez de crearlo separadamente.

Sigue leyendo Ventajas de los workshops

Requerimientos de un proyecto

Tiempo de lectura: 3 minutos

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 que 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.

Sigue leyendo Requerimientos de un proyecto

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

Tiempo de lectura: 4 minutos

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

Tiempo de lectura: 3 minutos

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

Sigue leyendo Diseñar servicios cara a cara