UXuarios

Publicación de artículos de diseño en español

Follow publication

¿Por qué seguimos hablando de productos en una economía de servicio?

--

Abby Covert en su ponencia del IAC20 habla sobre la perseverancia y los problemas persistentes. Los problemas persistentes son aquellos que todos ven y nadie arregla; es complicado pensar en ellos y hablar de ellos; y les falta un dueño. He presenciado muchos de ellos a lo largo de mi carrera, pero no los reconocí por lo que eran. Seguí sintiéndome frustrada por la situación y pensando: ¿por qué nadie ha abordado esto si esto está creando una carga para todos?. Vale la pena el trabajo de introspección para preguntarme ¿Por qué no los tomé yo? Muchas veces la respuesta era porque no era mi responsabilidad o no tenía las habilidades para resolverlos. Pero si no era yo, ¿Quién? Por lo general, me encontraba con el “porque siempre lo hemos hecho de esta manera”.

¿Qué es un problema persistente? Territorio recorrido muchas veces por muchas personas, caótico al pensarlo y hablarlo, carece de un dueño
¿Qué es un problema persistente? Territorio recorrido muchas veces por muchas personas, caótico al pensarlo y hablarlo, carece de un dueño — Abby Covert, IAC20

Abby también habla sobre la cultura de “romper las cosas rápido” y cómo debemos asumir un enfoque de “arreglar las cosas lentamente”. Y estoy de acuerdo a medias. No estoy segura sobre la parte lenta, pero diría “arregla las cosas con la cantidad de tiempo que tardan en arreglarlas”. Estos problemas persistentes o arreglos temporales que se vuelven permanentes, y en muchas organizaciones resultan ignorados hasta que eventualmente se vuelven urgentes de solucionar o se convierten en la principal razón del fracaso de los proyectos.

Caso en cuestión: durante el inicio de la pandemia en el 2020, los bancos que no pudieron hacer frente a las solicitudes de atención al cliente porque su capacidad para atender llamadas se redujo a la mitad por la falta de agentes, y tuvieron la necesidad de mantener actualizada su información en línea como pudieron y al último minuto, para que las personas no llamaran tanto. ¿Por qué no han tenido la documentación adecuada, una comunicación clara en todos sus puntos de contacto desde el principio? Lo más probable es que, y según mi propia experiencia, este sea un problema persistente. Nadie es propietario del contenido, nadie ha diseñado el servicio, siempre lo han hecho de esta manera, así que está bien. Hasta que no lo es.

La arquitectura de la información y el diseño de servicios implican solucionar problemas persistentes

Mientras pensaba todo esto, tropecé con un interesante hilo de Twitter que me permitió darle sentido a mis ideas sobre un tema que he considerado durante un tiempo.

Vivimos en una economía de servicios, pero todavía hablamos de equipos de productos y dueños de productos. ¿Por qué es eso? Jeff Sussna

A lo que Andy Budd argumentó que el diseño generalmente está ligado al producto en la jerarquía organizacional. ¿Y por qué es eso? Bien, el diseño de productos ha existido durante más tiempo que el servicio. El concepto de diseño de producto proviene del comercio industrial, como Matt Ventre agregó a la conversación.

Mi opinión es que los productos son tangibles, los servicios no. A la dirección de las organizaciones les encanta ver pantallas. “Entrega” el producto. “Escala la cosa”. Pero, ¿qué pasa cuando lo que vendes es accesos? Al transporte, a la comida, a la comunicación. Entonces, el “producto” es el medio, no lo que le estás vendiendo a las personas. Cuando usas Zoom, por ejemplo, no te venden el código para que lo instales en su propio servidor e implementes una aplicación de videoconferencia. Venden el acceso a la comunicación a través de la tecnología. No puedes verlo. No puedes tocarlo. No lo tienes en tu posesión.

Además, ese “producto” -en este caso la aplicación- forma parte de un ecosistema mayor. La aplicación no es el único componente del servicio de la comunicación, es fundamental, pero no el único. ¿Cómo se entera la gente? ¿Qué sucede cuando alguien ha tenido un problema con el pago? ¿Cómo aprendo a usarlo? Todo eso es parte del servicio que no es tangible. No es sexy de diseñar. No es realmente “entregable”. Y si lo que estás vendiendo es un servicio, si no tiene una estrategia, diseño e investigación adecuados, no importa lo que hagas con el producto. No funciona bien como servicio.

Creo que los entregables de los servicios no son atractivos. Hacer sesiones de colaboración, mapas mentales, service blueprints “parece” no ofrecer ningún valor. Porque tienen que implementarse. El trabajo de diseño de servicios y arquitectura de la información a veces ni siquiera llega a implementarse porque requiere que las personas y las organizaciones cambien. Cambio de procesos, cultura, mentalidad e incluso estructura.

Para que las organizaciones cambien, la alta dirección es quien debe hacer que eso suceda. No las personas que tienen el título de “diseñador de servicios” porque normalmente no tienen el poder para hacerlo. Sin embargo, creo que las expectativas de la alta dirección cuando contratan a un diseñador de servicios o un arquitecto de información son… En realidad, no tengo idea de lo que esperan. Creo que alguien del equipo de diseño los ha convencido, pero no saben realmente para qué sirven. Y cuando no entregan algo o no tienen buenos resultados, sino que comienzan a tener conversaciones que nadie quiere tener sobre problemas persistentes, se considera engorroso, incómodo, costoso y lo más importante: lleva demasiado tiempo.

Diseñar un producto no requiere la comprensión compartida de otros equipos y de toda la organización. Solo una pequeña parte, si la hay. Pero diseñar un buen servicio requiere que todos los engranajes de la maquinaria estén coordinados, sean consistentes y estén de acuerdo (en su mayoría).

Por lo tanto, el trabajo de diseño de servicios y de investigación no es valioso a corto plazo. Requiere mucho tiempo para implementar y un pensamiento a largo plazo, en mi opinión. Considerando que, el trabajo de diseño de productos se puede enviar en meses, incluso semanas, lo que es visto como más valioso para las empresas. Creo que es solo un reflejo de cómo actuamos en el mundo como un todo. Valorar las ganancias a corto plazo frente a la estrategia a largo plazo. Dejar la organización con problemas que no desaparecen y simplemente crecen con el tiempo.

Una oportunidad de cambio

Vivimos en un momento histórico -año 3 de la pandemia al momento de escribir este artículo- en el que tenemos los argumentos para abordar estos problemas persistentes. La razón para abordarlos no es solo porque podemos evitar problemas más importantes en el futuro (lo cual podemos), sino también porque crea servicios que la gente valora más, reduce los costos y hace que el tiempo de todos sea más eficiente.

La resolución de problemas persistentes requiere un ritmo diferente. No se pueden arreglar rompiendo las cosas rápidamente e incluso, no se pueden arreglar rápido, por eso no deben sujetarse al mismo entorno “ágil”. No se puede entregar en unas semanas porque requieren la colaboración de personas. Las personas son complejas y, por lo tanto, también lo son los problemas persistentes que las rodean.

Abordar esos problemas persistentes debe tener su propia línea de tiempo, milestones, resultados esperados y, sobre todo, la verdadera creencia de las personas que los quieren solucionar, de que se pueden resolver y que resolverlos contribuirá más que nada.

Reflexiona

  • ¿Qué problema persistente merodea en tu organización?
  • ¿Qué recursos se requieren para su resolución?
  • ¿Qué podría obtener la organización al solucionarlo?
  • ¿Qué cosas se estarían dejando de hacer para dedicarle esos recursos?
  • ¿Quién en la dirección de la organización se puede beneficiar más de solucionarlo?
  • ¿Está lista la organización para solucionarlo?
  • Y finalmente, ¿Puedes hacerte cargo del problema persistente?

Pongamos nuestro grano de arena para solucionar más problemas persistentes en nuestras organizaciones, uno a la vez y antes de que se vuelvan urgentes.

--

--

UXuarios
UXuarios

Published in UXuarios

Publicación de artículos de diseño en español

Bibiana Nunes

Written by Bibiana Nunes

Information architect and service designer living in Mexico City.

No responses yet