¿Por qué un libro sobre service design puede dejar cierta insatisfacción?
Una persona que empieza a explorar el diseño de servicios puede esperar un conjunto completo de recetas: cómo investigar, cómo construir el prototipo, cuántos participantes invitar, qué observar y cuándo considerar terminada la prueba.
“This is Service Design Thinking”, sin embargo, ofrece sobre todo una perspectiva amplia y una colección de herramientas. Muestra cómo mapear experiencias, implicar a stakeholders, visualizar procesos y apoyar la cocreación. No siempre guía al lector paso a paso por la construcción de un prototipo para un servicio concreto.
Esto puede resultar decepcionante, especialmente para quienes ya han utilizado toolboxes de design thinking muy detallados. Los buenos materiales de taller suelen describir:
- el objetivo de la técnica,
- los materiales necesarios,
- el tiempo estimado,
- las acciones siguientes del facilitador,
- las preguntas para los participantes,
- los errores habituales,
- la forma de analizar los resultados.
Un libro sobre service design puede ser menos prescriptivo porque la disciplina depende mucho del contexto. La atención a pacientes, un servicio de telecomunicaciones y un proceso de devolución en comercio requieren prototipos muy diferentes.
La falta de una receta universal no significa que el prototipado de servicios sea impreciso. Significa que el prototipo debe construirse alrededor de un riesgo, un proceso y un grupo de personas concretos.
Un prototipo de servicio no es un wireframe de un sitio web
En proyectos digitales, la palabra «prototipo» suele significar una maqueta interactiva. El usuario ve varias pantallas, realiza una tarea y el diseñador observa si la navegación y los mensajes son comprensibles.
En un servicio, la interfaz puede ser solo uno de muchos puntos de contacto. El cliente puede:
- ver un anuncio,
- llamar a una línea de atención,
- visitar un punto de servicio,
- firmar un documento,
- recibir un SMS,
- esperar a un instalador,
- hablar con un técnico,
- presentar una reclamación,
- utilizar una cuenta online.
Cada uno de estos elementos puede estar bien o mal diseñado. Incluso si cada punto de contacto funciona correctamente, la experiencia general puede fallar cuando no existe coherencia entre ellos.
Por ejemplo, el cliente puede contratar fácilmente el servicio por internet, mientras que el instalador recibe datos incompletos. El portal del cliente puede mostrar una fecha y el centro telefónico otra. Las condiciones pueden prometer una devolución sencilla, mientras que el procedimiento interno exige varias autorizaciones.
El prototipo de servicio debe probar no solo una pantalla, sino también la transferencia de información, la responsabilidad, los tiempos, el comportamiento de los empleados y las reacciones del cliente.
¿Qué se puede prototipar realmente dentro de un servicio?
El alcance es mucho más amplio de lo que parece al principio. Se puede prototipar:
- el primer contacto con la oferta,
- una conversación de ventas,
- la forma de explicar un precio,
- un proceso de registro,
- la reserva de una cita,
- el traspaso entre departamentos,
- la gestión de reclamaciones,
- notificaciones y mensajes,
- el comportamiento de un empleado en una situación difícil,
- la distribución de un punto físico de atención,
- la experiencia de espera en una cola,
- un procedimiento de toma de decisiones,
- un sistema que apoya al empleado,
- todo el recorrido del cliente de principio a fin.
No es necesario construirlo todo de inmediato. El prototipo puede cubrir solo una parte del servicio si precisamente allí se encuentra la mayor incertidumbre.
Si el problema consiste en comprender la oferta, se pueden prototipar la conversación del consultor y los materiales informativos. Si el riesgo está relacionado con el tiempo de atención, conviene simular el flujo de información entre empleados. Si no se sabe si los clientes aceptarán un nuevo modelo de pago, se pueden realizar varias transacciones de prueba manualmente.
Primero la pregunta, después la forma del prototipo
Un error frecuente consiste en elegir una técnica atractiva antes de determinar qué quiere aprender el equipo. Un taller puede parecer espectacular y no producir información útil si la pregunta de investigación no está clara.
Antes de empezar conviene responder:
- ¿Qué suposición es la más arriesgada?
- ¿Qué debe ser cierto para que el servicio tenga sentido?
- ¿En qué momento puede abandonar el cliente?
- ¿Dónde pueden cometer errores los empleados?
- ¿Qué elemento será más caro de implantar?
- ¿Qué puede probarse sin construir toda la solución?
- ¿Qué comportamiento del usuario demostrará que la idea funciona?
La forma del prototipo debe derivarse de la pregunta. Si la cuestión se refiere a una conversación, el prototipo puede ser esa conversación representada. Si se refiere al flujo de información, quizá sea necesario un mapa de procesos o una simulación con varias personas.
El mapa de stakeholders como punto de partida
El stakeholder map permite mostrar todas las personas y organizaciones que influyen en el servicio o se ven afectadas por él.
En un proyecto pueden participar muchas más partes que el cliente y la empresa. También pueden ser relevantes:
- empleados de primera línea,
- equipos comerciales,
- técnicos,
- socios externos,
- proveedores tecnológicos,
- operadores de pago,
- instituciones reguladoras,
- la familia del usuario,
- la persona que toma la decisión de compra,
- la persona que utiliza realmente el servicio.
El mapa ayuda a responder preguntas importantes:
- ¿Quién influye en el éxito del servicio?
- ¿Quién asume trabajo adicional?
- ¿Quién puede bloquear el cambio?
- ¿Quién posee conocimientos que el equipo no tiene?
- ¿A quién debemos invitar a la prueba?
Esta herramienta es especialmente útil antes de prototipar porque revela qué comportamientos deben aparecer en la simulación.
Desktop walkthrough: el servicio colocado sobre una mesa
El desktop walkthrough reproduce el servicio mediante objetos sencillos colocados sobre una mesa. Se pueden utilizar figuras, tarjetas, bloques, maquetas de espacios, símbolos de dispositivos y flechas que representan el flujo de información.
La técnica permite recorrer físicamente las etapas del servicio:
- el cliente observa la oferta,
- contacta con la empresa,
- un empleado verifica los datos,
- el sistema transmite la información,
- otra persona realiza una acción,
- el cliente recibe el resultado.
Mover los elementos sobre la mesa puede revelar problemas difíciles de ver en una descripción escrita:
- traspasos poco claros,
- falta de información,
- demasiados pasos,
- actividades repetidas,
- espera sin información,
- dependencia de una sola persona,
- acciones contradictorias de dos departamentos.
El desktop walkthrough no necesita representar el servicio de forma realista. Su objetivo es hacer visible el proceso y permitir que se analice conjuntamente.
Customer journey map y service blueprint
El customer journey map muestra la experiencia desde la perspectiva del usuario. Ayuda a ordenar:
- las acciones del cliente,
- los puntos de contacto,
- las preguntas y necesidades,
- las emociones,
- los problemas,
- los momentos de decisión.
El service blueprint amplía el mapa con elementos de la organización que el cliente no ve:
- acciones de los empleados,
- procesos de backstage,
- sistemas informáticos,
- documentos,
- flujo de datos,
- responsabilidades,
- dependencias de socios.
Estas herramientas no son prototipos completos por sí mismas, pero muestran qué conviene prototipar y dónde se encuentran las mayores tensiones e incertidumbres.
Si el recorrido revela frustración durante una espera, el prototipo puede centrarse en la comunicación del estado. Si el blueprint muestra introducción manual de datos, se puede probar una nueva forma de transferir información entre sistemas y empleados.
Role-playing y simulación del servicio
El role-playing permite que los participantes representen los papeles de cliente, consultor, técnico, socio u otro empleado. El escenario puede ser sencillo y realizarse en un espacio provisional.
La representación ayuda a comprobar:
- si el empleado sabe qué decir,
- si el cliente comprende los siguientes pasos,
- si el procedimiento puede ejecutarse realmente,
- si aparecen momentos incómodos,
- si el empleado dispone de la información necesaria,
- si el tiempo de atención es realista,
- cómo funciona el servicio en situaciones poco habituales.
Es importante probar algo más que el escenario ideal. También conviene representar casos como:
- falta de un documento,
- fallo del sistema,
- retraso de un empleado,
- cliente enfadado,
- cambio de decisión,
- problema de pago,
- traspaso del caso a otra persona.
Un servicio que solo funciona en condiciones ideales todavía no está bien diseñado.
Bodystorming: pensar mediante la acción
El bodystorming consiste en entrar físicamente en la situación del usuario y representar el proceso en un entorno parecido al real.
La técnica resulta útil cuando importan:
- la distribución del espacio,
- las distancias,
- la visibilidad de la información,
- el orden del desplazamiento,
- la interacción con dispositivos,
- la presencia de otras personas,
- el ruido,
- el tiempo de espera.
Se puede construir un punto de atención provisional con mesas, sillas y cajas. Después, los participantes recorren el proceso como clientes y empleados.
Esto puede mostrar que el cliente no sabe dónde colocarse, que el empleado debe abandonar repetidamente su puesto o que una conversación con datos confidenciales puede ser escuchada por otras personas.
Wizard of Oz: prestar manualmente un servicio aparentemente automatizado
En la técnica Wizard of Oz, el usuario cree que interactúa con un sistema funcional, aunque una parte del proceso la realiza manualmente una persona.
Así se puede probar el servicio antes de construir una tecnología cara. Por ejemplo:
- un empleado selecciona manualmente una recomendación en lugar de un algoritmo,
- un operador prepara los mensajes en lugar de un sistema automático,
- el cliente envía una solicitud sencilla y un empleado realiza manualmente el proceso de backstage,
- un consultor calcula el precio según reglas temporales en lugar de utilizar una herramienta automática.
Esta técnica permite comprobar si el propio servicio aporta valor antes de invertir en automatización.
Hay que cuidar especialmente la ética. No debe engañarse al usuario de una forma que pueda causarle daño, vulnerar su privacidad o generar obligaciones financieras reales.
Concierge prototype: prestar el servicio personalmente
En un prototipo concierge, el servicio se presta de forma manual y muy individual. El equipo observa al cliente, conversa con él y adapta el proceso en tiempo real.
Esta forma resulta útil cuando todavía no se sabe:
- qué pasos son realmente necesarios,
- qué información espera el cliente,
- qué elementos crean más valor,
- qué se podrá automatizar después,
- cómo debería ser el estándar de atención.
El prototipo concierge no es escalable y no necesita serlo. Su objetivo es aprender cómo debería funcionar el servicio antes de estandarizarlo.
Prototipar la comunicación
Una parte importante de la experiencia del servicio se crea mediante mensajes. Se pueden prototipar:
- correos electrónicos,
- SMS,
- notificaciones,
- guiones de conversación,
- instrucciones,
- condiciones,
- confirmaciones,
- mensajes de error,
- información sobre retrasos,
- la forma de pedir disculpas.
Una prueba sencilla puede mostrar varias versiones de un mensaje y comprobar qué entiende el cliente. Una prueba más completa representa toda la situación: el cliente realiza una acción, recibe el mensaje y decide qué hacer después.
Así se comprueba no solo si el texto es claro, sino también si aparece en el momento adecuado y conduce a la acción deseada.
Prototipar el espacio y los elementos materiales
Los servicios suelen utilizar lugares y objetos físicos. Pueden ser mostradores, señales, dispositivos, formularios, tarjetas, embalajes o equipamiento.
No es necesario construir el interior definitivo. Se pueden utilizar:
- cajas de cartón,
- cinta adhesiva en el suelo,
- señales impresas,
- formularios temporales,
- modelos sencillos de dispositivos,
- muebles móviles.
Estos prototipos ayudan a probar la visibilidad, la secuencia, la privacidad, la accesibilidad y el comportamiento de las personas en el espacio.
¿Cómo construir el primer prototipo de un servicio real?
El primer prototipo no debería cubrir toda la organización. Es mejor elegir un momento importante de la experiencia.
Paso 1. Elegir un escenario concreto
Ejemplo: un nuevo cliente quiere activar un servicio de telecomunicaciones y reservar una instalación.
Paso 2. Escribir la hipótesis principal
Ejemplo: el cliente comprenderá la diferencia entre los paquetes y elegirá la opción correcta sin ayuda.
Paso 3. Identificar a los participantes
La prueba puede necesitar un cliente, un vendedor, un empleado que verifique los datos y una persona que represente al sistema.
Paso 4. Preparar los elementos mínimos
Pueden ser ofertas impresas, un formulario provisional, un guion de conversación, un SMS de confirmación y un calendario de citas.
Paso 5. Representar el proceso
Los participantes recorren el escenario sin explicaciones adicionales. El diseñador observa dónde aparecen preguntas, errores, esperas y necesidad de ayuda.
Paso 6. Recoger información
Conviene preguntar:
- ¿Qué resultó confuso?
- ¿En qué momento perdió seguridad el cliente?
- ¿Qué información le faltaba al empleado?
- ¿Qué actividad duró más?
- ¿Dónde fue necesario evitar manualmente el procedimiento?
Paso 7. Cambiar y repetir
El prototipado adquiere valor cuando los resultados conducen a otra versión. El objetivo no es una presentación única, sino el aprendizaje iterativo.
Ejemplo de prototipo de un servicio de telecomunicaciones
Un servicio de telecomunicaciones es un buen ejemplo porque combina oferta, contrato, sistema, instalación, dispositivo, soporte y pago.
Supongamos que una empresa quiere introducir un nuevo servicio de internet doméstico. El equipo puede prototipar:
- la forma de presentar los paquetes,
- la comprobación de disponibilidad en una dirección,
- la selección de la fecha de instalación,
- la confirmación de la visita,
- la preparación del cliente antes de que llegue el técnico,
- el proceso de instalación,
- la activación del servicio,
- el primer acceso al portal,
- la comunicación de un problema después de la instalación.
No se necesita un sistema funcional. Un empleado puede seleccionar las fechas en un calendario de papel, enviar manualmente el SMS y utilizar pantallas impresas en lugar de un portal real.
La prueba mostrará si el cliente comprende la oferta, si el empleado tiene todos los datos, si la fecha es realista y si los pasos posteriores están claros.
El nivel de fidelidad del prototipo
Un prototipo puede tener fidelidad baja, media o alta. No siempre merece la pena empezar con una versión realista.
Baja fidelidad
Tarjetas, escenarios sencillos, role-playing, mensajes en papel y espacios esquemáticos. Es barato y fácil de cambiar.
Fidelidad media
Materiales más realistas, formularios preparados, partes funcionales del proceso y una reproducción parcial del espacio.
Alta fidelidad
Un prototipo cercano al servicio real que utiliza canales, empleados y tecnología de destino.
La fidelidad debería ser tan baja como sea posible y lo bastante alta para responder a la pregunta de investigación.
¿Cómo probar la parte invisible del servicio?
El backstage suele ser la parte más difícil de prototipar porque el cliente no la ve.
Puede probarse mediante:
- simulación del trabajo de los empleados,
- transferencia manual de datos,
- fallos de sistema simulados,
- distintos modelos de permisos,
- medición de tiempos,
- conteo de traspasos,
- observación de los puntos en los que se necesita una decisión del responsable.
El equipo debe analizar no solo si el cliente recibe el resultado, sino también qué esfuerzo organizativo es necesario para proporcionarlo.
Un servicio puede parecer excelente desde fuera y exigir muchas actividades manuales. Un buen prototipo también debería revelar este problema.
¿Qué medir durante la prueba?
Dependiendo del objetivo, se puede observar:
- si el cliente comprende los siguientes pasos,
- el tiempo de realización,
- el número de preguntas y errores,
- el momento en el que se pierde la confianza,
- el número de traspasos,
- el tiempo de espera,
- el número de actividades manuales,
- la carga del empleado,
- la disposición del cliente a utilizar el servicio,
- el coste de una prestación.
No todas las pruebas deben generar datos estadísticos precisos. Los primeros prototipos suelen servir para descubrir problemas y comprender el mecanismo que los produce.
¿A quién invitar a la prueba?
Dependiendo del prototipo, pueden participar:
- representantes de los clientes objetivo,
- empleados de primera línea,
- personas responsables del sistema,
- gestores del proceso,
- socios externos,
- empleados que gestionan reclamaciones,
- personas que toman decisiones financieras.
Una prueba realizada únicamente por diseñadores puede no mostrar las limitaciones reales. Un empleado operativo detectará problemas de procedimiento y un usuario mostrará que el mensaje no se entiende.
El papel del diseñador durante el prototipado
El diseñador no tiene que crear personalmente todos los elementos del servicio. Sus principales tareas son:
- definir la pregunta,
- seleccionar la forma adecuada del prototipo,
- invitar a las personas correctas,
- facilitar el escenario,
- observar el comportamiento,
- separar hechos de opiniones,
- organizar los resultados,
- ayudar a preparar la siguiente versión.
El diseñador actúa como investigador, facilitador, director de la simulación y vínculo entre la perspectiva del cliente y las posibilidades de la organización.
Service design, UX, product design y marca
Las fronteras entre estos conceptos no son totalmente fijas.
User experience
Se concentra en la experiencia de utilizar un producto o una solución concreta.
Product design
Se ocupa de crear y desarrollar un producto, sus funciones, su funcionamiento y su valor para el usuario y para el negocio.
Service design
Incluye toda la experiencia y el sistema organizativo necesario para prestarla.
Brand experience
Influye en las expectativas, emociones e interpretación de todos los contactos con la empresa.
Los clientes no separan estas áreas. Pueden valorar el producto por una conversación con soporte, la marca por la gestión de una reclamación y la aplicación por si se cumplió la promesa del anuncio.
El diseño de servicios ayuda a conectar estos elementos en una experiencia coherente, aunque las fronteras exactas dependen del proyecto y de la organización.
¿Dónde termina el producto y empieza el servicio?
En muchos sectores, separar producto y servicio es artificial. Un teléfono sin activación, actualizaciones, garantía y soporte es solo un objeto. Un servicio de internet sin router, instalación y ayuda técnica tampoco está completo.
Una posible distinción consiste en considerar el producto como un elemento que aporta valor y el servicio como todo el sistema que permite al cliente obtener ese valor.
La frontera depende de la perspectiva. Para el fabricante, el dispositivo puede ser el producto. Para el cliente, forma parte de una experiencia más amplia que incluye compra, configuración, uso, soporte y sustitución.
La importancia de la marca en el prototipado de servicios
La marca crea expectativas antes del primer contacto con el servicio. El cliente puede esperar rapidez, sencillez, lujo, seguridad o precio bajo.
El prototipo debería comprobar si la experiencia real coincide con la promesa de la marca.
Si la marca promete sencillez y la activación exige cinco documentos y tres conversaciones, existe una contradicción. Si la empresa comunica cuidado, pero gestiona las reclamaciones mediante respuestas automáticas, el servicio debilita la marca.
Conviene probar no solo la funcionalidad, sino también las emociones:
- ¿El cliente se siente seguro?
- ¿Comprende lo que ocurrirá?
- ¿La empresa parece fiable?
- ¿El estilo de atención coincide con la promesa de la marca?
Un libro para diseñadores y un libro para el negocio
La recepción de una publicación depende también de la perspectiva profesional del lector. Un diseñador puede buscar el lenguaje de los métodos, ejemplos de visualización y formas de facilitar el proceso. Un directivo preguntará más por costes, decisiones, riesgo, implantación y resultados.
Por eso, un libro puede parecer muy concreto a un diseñador y demasiado general a un lector empresarial. Otra publicación escrita para managers puede explicar mejor cómo conectar el design thinking con la toma de decisiones y el crecimiento.
Ninguna de las dos perspectivas es superior. El diseño de servicios necesita ambas:
- sensibilidad hacia la experiencia humana,
- comprensión de procesos,
- capacidad de visualización,
- evaluación de la viabilidad,
- pensamiento económico,
- capacidad para implantar cambios.
La estética del libro como parte de la experiencia
En una publicación sobre diseño de servicios, la forma del propio libro adquiere un significado adicional. La composición, la tipografía, las ilustraciones, el ritmo de las páginas y la navegación crean la experiencia de uso del contenido.
Una buena forma no sustituye al contenido, pero puede:
- facilitar la comprensión,
- mostrar relaciones,
- animar a explorar,
- hacer más fácil volver a una herramienta,
- crear coherencia con la idea de diseñar experiencias.
En este sentido, el libro puede convertirse en un ejemplo de punto de contacto con el conocimiento diseñado conscientemente.
Errores frecuentes en el prototipado de servicios
Intentar prototiparlo todo a la vez
Un alcance demasiado amplio dificulta la observación y crea una simulación cara. Es mejor empezar por la incertidumbre más importante.
Hacer la primera versión demasiado perfecta
Un prototipo muy elaborado aumenta el apego del equipo a la idea y dificulta los cambios radicales.
Probar únicamente el escenario ideal
Un servicio real debe funcionar con errores, retrasos y clientes poco habituales.
Excluir a los empleados operativos
El concepto puede parecer bueno y ser imposible de ejecutar en el trabajo diario.
Concentrarse solo en las opiniones
El comportamiento, el tiempo, los errores y las dudas son tan importantes como preguntar si la idea gusta.
No realizar otra iteración
Una única representación no constituye un proceso de prototipado si los resultados no producen cambios.
¿Cuándo es suficientemente bueno un prototipo?
El prototipo no tiene que estar completo. Es suficiente cuando responde a una pregunta importante y permite tomar la siguiente decisión.
El resultado puede llevar a decidir:
- seguir desarrollando la idea,
- cambiar el proceso,
- realizar más investigación,
- simplificar el servicio,
- cambiar el público objetivo,
- descartar la solución,
- construir una versión más realista.
El objetivo del prototipo no es demostrar que el equipo tenía razón. Es obtener suficiente conocimiento para tomar una decisión mejor.
¿Cómo empezar sin experiencia?
La mejor forma de comprender el prototipado de servicios consiste en construir un prototipo sencillo. No hace falta esperar al proyecto ideal.
Se puede elegir un servicio existente y un problema, por ejemplo:
- los clientes no saben qué ocurre después de enviar una solicitud,
- un empleado tarda demasiado en encontrar información,
- una reserva requiere varias llamadas,
- el cliente no comprende la primera factura,
- una reclamación pasa de un departamento a otro.
Después basta con preparar un escenario simplificado, invitar a varias personas y representar la nueva versión del proceso.
El primer prototipo probablemente será imperfecto. No es un problema. Su función principal consiste en convertir una discusión abstracta en una experiencia que puede verse, vivirse y mejorarse.
Resumen
El prototipado de servicios es más difícil de captar que el prototipado de interfaces porque un servicio no es un solo objeto. Es una secuencia de acciones, relaciones, mensajes, sistemas y decisiones distribuidas en el tiempo.
No existe un único prototipo universal. Dependiendo de la pregunta, se puede utilizar un stakeholder map, desktop walkthrough, service blueprint, role-playing, bodystorming, la técnica Wizard of Oz, un prototipo concierge o una simulación sencilla de comunicación.
Lo más importante es comenzar por una suposición arriesgada y no por una herramienta favorita. El prototipo debe ser lo más sencillo posible, implicar a las personas adecuadas y revelar tanto la experiencia del cliente como el esfuerzo organizativo necesario para prestarla.
“This is Service Design Thinking” quizá no proporcione una receta completa para cada prueba, pero ayuda a comprender la amplitud de la disciplina y ofrece el lenguaje necesario para trabajar con servicios. El resto exige práctica, iteración y disposición para crear primeras versiones imperfectas.
El prototipado de servicios deja de ser un concepto abstracto cuando el equipo se atreve a representar el primer proceso real, detectar sus puntos débiles y construir una versión mejor.
Cuestiones: → service design thinking, prototipado de servicios, prototipo de servicio, diseño de servicios, This is Service Design Thinking, stakeholder map, desktop walkthrough, service blueprint, customer journey map, role playing service design, bodystorming, prototipo Wizard of Oz, prototipo concierge, pruebas de servicios, design thinking para servicios, prototipado de procesos, UX y service design.