Mapa de ecosistema: actores y relaciones de un servicio

Qué es un mapa de ecosistema de servicio, qué actores y relaciones muestra, en qué se diferencia del service blueprint y del journey map, y cuándo dibujarlo.

info Definición Rápida
Un mapa de ecosistema es una representación visual de todos los actores que influyen en un servicio y del tipo de valor que intercambian entre sí. Coloca al usuario en el centro y muestra quién le ayuda, quién le frena y quién está detrás del servicio.

¿Qué es y qué muestra?

Según servicedesigntools.org, el mapa de ecosistema es una representación sintética que captura todos los roles clave que tienen influencia sobre el usuario. Se construye en dos pasos: primero se dibujan todas las entidades, con quienes trabajan entre bastidores y quienes tienen un impacto indirecto; después se conectan según el tipo de valor que intercambian. La página señala que el valor está en los bucles, es decir, en que cada relación se piensa como dar y recibir, y que el mapa ayuda a encontrar huecos y posibles sinergias.

La idea central es que un servicio rara vez depende de una sola empresa. Hay proveedores, reguladores, plataformas, familiares, aseguradoras o instituciones que condicionan lo que el usuario puede hacer, aunque no aparezcan en la pantalla.

¿Por qué le importa a un diseñador junior?

Porque muchas decisiones de diseño dependen de actores que no están en la sala. Una pantalla de pago que no puede cambiar porque el banco fija el flujo, o una notificación que no llega porque la operadora la bloquea, son restricciones de ecosistema. Dibujarlas evita que el equipo prometa lo que no puede entregar.

Además, el mapa te obliga a preguntar por quién trabaja tras la escena. Un junior que solo ve al usuario y a la app pierde de vista a las personas que dan soporte, aprueban o financian el servicio.

¿En qué se diferencia del service blueprint y del journey map?

Esta es la diferencia más útil, con sus fuentes:

  • Journey map. IxDF lo describe como un mapa del recorrido del cliente por un servicio, con foco en sus motivaciones, experiencias y emociones. Es la vista del usuario.
  • Service blueprint. NN/g lo define como un diagrama que visualiza las relaciones entre los componentes del servicio. Cada blueprint corresponde a un recorrido concreto y a los objetivos del usuario en él, y añade la vista interna: acciones de backstage y procesos de soporte que el usuario no ve.
  • Mapa de ecosistema. Muestra a los actores y sus relaciones, sin centrarse en un recorrido. Responde a la pregunta de quién está en el servicio, no a cómo avanza una persona por él.

En resumen, el journey map y el blueprint son sobre un camino; el mapa de ecosistema es sobre el mundo alrededor del camino. Un servicio complejo suele necesitar los tres.

Ninguna de estas fuentes compara los tres artefactos de forma directa: la distinción se deduce de la definición de cada uno.

¿Qué elementos debe tener?

Service Design Tools menciona tres elementos:

  1. Actores y entidades. Incluye a quienes trabajan entre bastidores y a quienes tienen impacto indirecto.
  2. El usuario en el centro, con los demás actores ordenados según su importancia para él.
  3. Relaciones y flujos. Líneas con distinto trazo o color según el tipo de intercambio, como información o dinero.

Los canales por los que se comunican los actores, como correo, teléfono, app o presencial, no forman parte de esa descripción. Si tu equipo los añade como una capa más, indícalo como convención propia.

¿Cómo se construye, paso a paso?

  1. Define el servicio y el usuario central. Una frase que diga para quién es el servicio y qué resultado busca.
  2. Haz una lista de actores sin conectarlos. Pide al equipo que nombre a todos los que influyen, incluidos los internos, los externos y los de impacto indirecto.
  3. Ordénalos por importancia para el usuario. Coloca al usuario en el centro y acerca a los que más influyen.
  4. Conecta con relaciones. Para cada par, pregunta qué se intercambia: información, dinero, permisos, datos o decisiones. Usa trazos o colores distintos según el tipo de intercambio, y piensa cada relación como dar y recibir.
  5. Da un paso atrás y busca lo que falta. Discútelo en equipo, marca los dolores y los huecos que aparecen y compártelo con colegas y stakeholders para refinarlo.

Para identificar a los actores, el artículo sobre entrevistas a stakeholders ofrece preguntas útiles.

¿Cuándo NO conviene dibujarlo?

  • Cuando el problema es un flujo concreto de un usuario. Ahí sirve mejor un journey map o un service blueprint.
  • Cuando todos los actores son internos. Si no hay ecosistema externo que mapear, el mapa añade poco.
  • Cuando el mapa se vuelve un inventario. Un mapa con sesenta actores y cien líneas no ayuda a decidir nada. Conviene agrupar y priorizar.
  • Para decidir prioridades sin objetivos. Si no sabes qué resultado buscas, el mapa es un dibujo. El artículo sobre impact mapping ayuda a conectar actores con objetivos.

Estos casos son criterios de práctica, no parte de la definición del método.

Ejemplo

Ejemplo ilustrativo: una app de telemedicina para pacientes con diabetes.

  • Usuario central: la paciente.
  • Actores cercanos: su médica de cabecera, la enfermera de seguimiento y un familiar que le ayuda con las medicinas.
  • Actores externos: la farmacia, la aseguradora que decide qué medicamentos se cubren y el laboratorio que envía los kits de medición.
  • Canales (capa opcional): la app, el mensaje de texto de recordatorio, la llamada telefónica de la enfermera y la farmacia física.
  • Relaciones: la aseguradora condiciona qué medicamento puede recetar la médica; la farmacia confirma la entrega por mensaje; el familiar recibe un aviso si la paciente no registra su medición.

El mapa muestra que buena parte del problema no está en la app, sino en la autorización de la aseguradora. Eso cambia qué se diseña y qué se negocia con terceros.

Si quieres relacionar el mapa con las decisiones de producto y de negocio, el artículo sobre estrategia y visión describe cómo conectar el servicio con un objetivo.

Errores comunes

  • Dibujar el mapa sin un usuario central claro.
  • Olvidar a los actores internos que trabajan entre bastidores.
  • Mezclar el mapa de ecosistema con un journey map y perder la noción de recorrido.
  • Crear un inventario de actores sin relaciones que expliquen algo.
  • Compartir el mapa solo con el equipo interno y no con quienes participan en el servicio.
  • Presentar los canales como un elemento obligatorio del método, cuando son una convención del equipo.

Fuentes

Preguntas frecuentes

¿Qué es un mapa de ecosistema?
Es una representación sintética de todos los roles clave que influyen en el usuario de un servicio. Según servicedesigntools.org, se construye mostrando primero todas las entidades y después conectándolas según el tipo de valor que intercambian.
¿En qué se diferencia de un service blueprint?
El blueprint sigue un solo recorrido y un objetivo de usuario, y añade la vista interna de procesos y acciones de soporte. El mapa de ecosistema muestra los actores y sus relaciones, sin centrarse en un recorrido. NN/g define el blueprint como un diagrama de las relaciones entre componentes del servicio.
¿Qué elementos debe tener un mapa de ecosistema?
Actores y entidades, incluidos los que trabajan entre bastidores; el usuario en el centro, con los actores más importantes para él más cerca; y relaciones con líneas que muestran el tipo de intercambio, como información o dinero. Los canales de comunicación son una capa opcional que añaden algunos equipos, no parte de la definición.
¿Cuándo no conviene dibujar un mapa de ecosistema?
Cuando el problema es un flujo concreto de un usuario, donde un journey map o un blueprint sirven mejor, o cuando todos los actores son internos y no hay ecosistema externo que mapear.
¿Cómo se valida el mapa?
No existe una cifra ni un método formal. Service Design Tools propone discutirlo en equipo, revisar qué falta y compartirlo con colegas y stakeholders para refinarlo.