Gestión de stakeholders para diseñadores: poder, interés y actitud
Gestionar stakeholders es decidir cuánto y cómo involucrar a quien influye en el proyecto. Cómo mapear poder, interés y actitud y qué estrategia usar.
¿Qué significa gestionar stakeholders?
Un stakeholder es cualquier persona que afecta o se ve afectada por el proyecto. En un rediseño puede ser la dirección comercial, el equipo legal, el responsable de soporte o un desarrollador que mantiene la base de código. Ignorar a uno de ellos suele salir caro en la última semana.
Gestionar no significa tratar a todos igual. Significa dedicar más tiempo a quien puede frenar o impulsar el proyecto, y menos a quien solo necesita saber lo que pasa.
¿Cómo se mapean?
La herramienta clásica es la matriz de poder e interés, conocida como matriz de Mendelow por Aubrey Mendelow. Ubica a cada stakeholder en dos ejes: cuánto poder tiene para influir o bloquear el proyecto y cuánto interés tiene en el resultado. NN/g añade un tercer eje, la actitud: si la persona es favorable, neutral o contraria al trabajo de diseño (NN/g, “Stakeholder analysis for UX projects”).
Ese tercer eje importa porque dos personas con el mismo poder pueden actuar de forma opuesta. Una te apoya y otra te bloquea. El mapa tiene que recoger ambas cosas.
¿Qué estrategia usar en cada cuadrante?
NN/g propone cuatro estrategias, una por cuadrante:
- Alto poder, alto interés: gestionar de cerca. Pueden bloquear el proyecto o convertirse en promotores. Involúcralos en decisiones, pide su criterio y revisa con ellos cada entrega importante.
- Alto poder, bajo interés: mantener satisfechos. Son los latentes. Asegúrate de que sus intereses estén cubiertos y consúltalos cuando tu trabajo afecte al suyo, para que no aparezcan al final con una objeción.
- Bajo poder, alto interés: mantener informados. Invítalos a las sesiones de investigación, ponlos en copia de los resúmenes posteriores e invítalos a las críticas de diseño. Suelen ser aliados útiles.
- Bajo poder, bajo interés: vigilar. No gastes mucho esfuerzo, pero revísalos con regularidad por si su poder o su interés cambian.
NN/g advierte que estas estrategias no son específicas: la mejor depende de cada persona y de la cultura de la organización.
¿Cómo se conoce a un stakeholder?
Las entrevistas son la herramienta más útil. UserTesting reúne consejos de varios profesionales: preguntar por los resultados ideales de la investigación, qué pasó la última vez que se hizo, qué saben de sus usuarios y cuál sería su calendario y enfoque ideal (UserTesting, “How to get stakeholder buy-in for user research”).
NN/g añade que las entrevistas pueden revelar cuánto conoce la persona sobre UX. Si alguien con mucho poder sabe poco, conviene dedicar un tiempo a explicar conceptos básicos y el retorno del trabajo de diseño antes de pedir una decisión.
¿Cómo se gana apoyo?
Baymard, en una guía sobre presentar hallazgos, propone varias prácticas: explicar la metodología al inicio, usar evidencia externa para no depender de opiniones internas, traducir el hallazgo a métricas de negocio como conversión, valor de vida del cliente o volumen de llamadas al centro de contacto, y cerrar con próximos pasos claros: prioridad, consecuencia para el negocio, esfuerzo, plazo y los permisos que necesitas antes de dar el trabajo por terminado (Baymard, “How to present UX research findings to get buy-in”). Esa guía es de una empresa que vende investigación UX, así que léela como práctica, no como evidencia.
La regla de fondo es la confianza. Una de las profesionales citadas por UserTesting recomienda resolver primero las dudas urgentes del stakeholder y dejar los temas amplios para cuando haya credibilidad. Involucrarlo en talleres y en sesiones de investigación también ayuda: quien participa siente el proyecto como suyo.
Ejemplo
Ejemplo ilustrativo: un diseñador va a rediseñar el proceso de devoluciones de una tienda en línea. Su mapa tiene cinco personas. La directora de operaciones tiene mucho poder y mucho interés, pero es escéptica: piensa que el problema son los transportistas. Se gestiona de cerca con una entrevista en la que el diseñador le pregunta qué métricas usa para decidir, y después le muestra dos devoluciones grabadas con su equipo. El responsable de legal tiene mucho poder y poco interés: se le consulta solo sobre el texto de la política de devolución. El equipo de soporte, con poco poder y mucho interés, se invita a las sesiones y a revisar el prototipo. Al cabo de tres semanas, el mapa cambia: la directora pasa de escéptica a aliada.
¿Cuándo NO conviene involucrar a todos?
- Cuando la decisión es pequeña. Un cambio de color no necesita que la dirección participe.
- Cuando la participación se vuelve un comité. Demasiados aprobadores frenan el trabajo. Define quién decide.
- Cuando la persona no tiene nada que aportar. Involucrar por cumplir genera ruido y resentimiento.
- Cuando el conflicto es de poder y no de información. Ahí conviene escalar a quien tiene la autoridad, no seguir explicando.
Errores comunes
- Mapear una vez y no volver a revisar el mapa.
- Tratar la actitud como algo fijo.
- Hablar solo con la persona con más poder y olvidar a quien usa el producto.
- Presentar hallazgos críticos sin contexto, lo que puede generar rechazo.
- Confundir la gestión de stakeholders con dar gusto a todos.
Cómo empezar mañana
Antes de tu próxima reunión de proyecto, haz una lista de las personas que afectan el resultado. Para cada una, escribe su poder, su interés y su actitud en una frase. Asigna un cuadrante y una estrategia. Elige una persona de alto poder y bajo interés y pídele una entrevista de veinte minutos sobre sus metas. Después, actualiza el mapa. Si el proyecto necesita justificar su retorno, la conversación con esa persona es buen momento para acordar cómo se medirá. Para eso, consulta ROI del UX. Y para cerrar el proceso, un kickoff de proyecto es el lugar para asignar responsables.