Experiencia del usuario: ¿Cuáles son algunos ejemplos de primera mano donde fallaron los trabajos de consultoría de UX / diseño en su organización empresarial? ¿Por qué fallaron?

Answer 1

Trabajamos en una gran aplicación para una organización de atención médica aún más grande que permanecerá sin nombre. Desarrollamos muchos proyectos para este cliente y entendimos que, en su cultura, la decisión de ciertas partes interesadas anula todas las demás preocupaciones, incluida la usabilidad.

Diseñamos una aplicación que aumentaría el tratamiento de ciertos pacientes psiquiátricos, proporcionando medios educativos y monitoreando el progreso a través de cuestionarios. Un equipo de proveedores de atención médica tenía un portal separado a través del cual manejarían sus casos compuestos por múltiples pacientes.

Al principio, comenzamos a identificar supuestos de diseño para comenzar a validarlos. ¿Quiénes son estos pacientes psiquiátricos? ¿Podemos hablar con algunos? ¿Estarían interesados ​​en consumir contenido en línea de este tipo? ¿Estarían dispuestos estos pacientes a responder cuestionarios sobre sus propios pensamientos y sentimientos personales y, de ser así, los responderían con precisión? ¿Y quiénes son los proveedores de atención médica? ¿Estarían interesados ​​en un sistema como este además de todos los otros sistemas en línea que usan en la organización?

Estas preguntas fueron formuladas desde la distancia por un propietario del producto / experto en la materia que era muy “mi camino o la autopista”. Debido a que valoramos la relación amistosa (y lucrativa) que tuvimos con esta organización, decidimos ir con ella y esperar lo mejor.

Después de unos 18 meses de diseño y desarrollo, se lanzó el proyecto. Fue en gran medida un proyecto divertido, desafiante y a veces estresante, y todos aprendimos mucho. La interfaz de usuario que diseñamos era hermosa y muy útil, si lo digo yo mismo.

Un año después, fue cerrado. Los usuarios se mantuvieron alejados de él como si fuera Google+. Los únicos pacientes psiquiátricos que respondieron fueron los maníacos, y sus respuestas tendieron a la mierda. Ninguno de los proveedores de atención médica quería trabajar de la forma en que el propietario del producto pensó que debería funcionar.

La compañía no nos culpó. Sabían quién había estado manejando esos requisitos. Pero mi propia conclusión personal fue esta: no te dejes intimidar por un dueño de producto dominante que piensa que él / ella es el usuario. (Es posible que le paguen bien, pero es casi seguro que el proyecto se encamina hacia el fracaso). Lo mejor es encontrar empleadores y clientes que entiendan el UCD y el pensamiento de diseño.

Answer 2

Hace años, estábamos trabajando en un producto. Estaba destinado a servir a las instituciones académicas al ayudar a sus oficinas de investigación a responder preguntas relevantes sobre qué tan bien le está yendo a su institución, cómo se compara con sus pares, etc. datos de investigación (realmente no puedo entrar en detalles, pero no está relacionado con ninguno de los productos en los que trabajamos actualmente).

En ese momento, contratamos a una agencia bastante famosa en el espacio para ayudarnos a idear un concepto para el producto (de nuevo, no puedo nombrar nombres). Lo que entregaron fue bastante bueno, ciertamente fue una solución interesante, pero no fue la solución adecuada para nosotros (al menos eso es lo que pensamos en ese momento, y nunca sabremos lo contrario, ya que nunca intentamos descubrirlo).

Entonces, este compromiso falló posiblemente por varias razones:

1. El compromiso (financiero) de nuestro lado no fue lo suficientemente grande como para que la parte consultada se involucrara con suficiente tenacidad para resolver realmente el problema correcto
2. El problema a resolver era demasiado complejo para ser subcontratado a una parte externa a través de un acuerdo de plazo fijo y presupuesto fijo
3. La parte consultada no estaba en casa en el espacio, por lo que luchó para dar sentido a las complejidades intrincadas relevantes que los equipos internos estarían más en casa con
4. Lo archivamos como fallido, ya que nunca buscamos su solución. Sin intentarlo, supongo que nunca podríamos saber si hubiera sido posible tener éxito

Probablemente haya algunas razones más por las que este proyecto fracasó al final, y en realidad es una mezcla de la mayoría de ellas en diversos grados.

Me interesaría mucho leer qué historias tienen que contar los demás.

Answer 3

La configuración de mi empresa es ligeramente diferente: trabajo para una agencia interna dentro de una empresa. Esencialmente, operamos como consultores en el sentido de que nos relacionamos con equipos de desarrollo que “poseen” los productos que vende la empresa; estos equipos simplemente no tienen recursos UX y, por el contrario, no tenemos recursos para el desarrollo.

Hay diversos grados de falla.

Una vez, un colega y yo tuvimos la tarea de “volver a imaginar el comercio electrónico”, y comenzamos una exploración de cielo azul en la que diseñamos un montón de pantallas para un producto imaginado. El diseño no estaba vinculado a ninguna tecnología existente, y era muy ideal (por decir lo menos), especialmente cuando se trata de software empresarial. Pensamos que solo estaba destinado a superar los límites y dar a los equipos de desarrollo una idea de hacia dónde se dirigía UX y cómo podían dar los primeros pasos para llegar allí.

Pero entonces los ejecutivos lo vieron y lo quisieron.

En realidad, se está construyendo ahora, por lo que se hará (aunque su misión y capacidades han cambiado significativamente desde nuestra primera visión de lentes color de rosa). Sin embargo, ha costado una tonelada de dinero, más de lo que debería, y resultó en una gran rotación y frustración interna. Hay muchas razones para esto:

1. El factor determinante fue el diseño, que no tuvo en cuenta cuáles serían los requisitos técnicos. Dev cometió el error de sentir como si tuvieran que diseccionar los diseños, derivar los requisitos de ellos y construir de nuevo para que coincida perfectamente. Decir que se omitieron algunos pasos es un eufemismo.
2. Relacionado con lo anterior, falta de propiedad. No había un gerente de producto real, nadie dispuesto a rendir cuentas por la visión y la misión de lo que este producto podía y debería haber sido, y de lo que implicaría el esfuerzo relacionado.
3. Sin recursos de desarrollo: debido a que mi departamento actúa como la función de diseño de los productos existentes, cualquier cosa nueva debe asignarse a un equipo existente, y estos equipos ya tienen su propio producto con hojas de ruta relacionadas de 12 a 18 meses. Como resultado, nuestro liderazgo en ese momento decidió contratar a su propio equipo de desarrollo que resultó en …
4. … dev no tiene una idea de los orígenes de este proyecto. Básicamente, se les entregó diseños anotados y se les dijo que lo construyeran. No tenían aportes por adelantado, y cuando se trataba de comprender la magnitud de la tarea técnica aquí, estaban en una grave desventaja porque no entendían la magnitud del esfuerzo involucrado en la integración con la tecnología de fondo existente.

Podría seguir, pero no lo haré.

Hubo una falta de estrategia comercial en lo que respecta al origen y la ejecución de este producto. Creo que los proyectos más exitosos de mi departamento son cuando nos relacionamos con un equipo de desarrollo que conoce muy bien su producto y mercado, y tiene una idea de dónde está el potencial. Luego ingresamos y llevamos a cabo investigaciones de usuarios para determinar las necesidades de los usuarios finales y ayudar a estos equipos de desarrollo a priorizar las mejoras basadas en lo que es factible tanto desde el punto de vista técnico como de tiempo. Y luego comience a enmarcar con un examen técnico constante, constante y técnico del equipo de desarrollo.

Ya sea netamente nuevo o un rediseño, los compromisos de UX requieren responsabilidad, colaboración y visión.