Quién debe tomar las decisiones finales de diseño y UX en un equipo sin diseñador

Es deber de los propietarios de productos definir los criterios de aceptación. Esto puede incluir funciones de usabilidad.

Por ejemplo: Como usuario daltónico, quiero usar esta función sin ningún impedimento

Es deber de los ingenieros averiguar cómo hacerlo.

Por ejemplo: Subtarea: como usuario, quiero que mi configuración de daltonismo de la aplicación principal tenga efecto al usar esta función

O

Tal vez los ingenieros decidan usar un pulgar hacia arriba/pulgar hacia abajo en lugar de un semáforo rojo/verde aquí.

Lo que sea que elijas. el propietario del producto dice lo que quiere, los ingenieros deciden cómo se hace.

UX es cómo .

Mi consejo:

• Reserve tiempo para que su equipo aprenda algo básico de UX/usabilidad, ya sea mirando blogs o videos juntos o capacitación real. Incluso si obtiene una persona dedicada más tarde, ayudar a su equipo a tener más forma de T pagará dividendos.
• Trabajen juntos para crear un proxy para un diseñador de UX, es decir, una guía de estilo visual que pueda ser seguida por casi cualquier persona al implementar algo y referenciada en las discusiones.
• Si su producto va más allá de la simple funcionalidad, debe considerar incorporar pautas sobre cómo debe sentirse un usuario al usarlo. Esto impulsará debates importantes en torno a decisiones específicas.
• Haz lo que puedas para conseguir ese verdadero miembro de UX/usabilidad, incluso si es solo un contratista a tiempo parcial que pone sus ojos en las piezas más críticas como la guía de estilo, los grandes cambios, las nuevas características que marcan la prioridad, etc.

Editar: casi olvido el punto más importante: ¡validación! Realice pruebas de usabilidad, obtenga comentarios de los usuarios e involucre a la mayor parte del equipo posible: hay muchas más posibilidades de que sean dueños de la iteración y las soluciones necesarias cuando surjan problemas, y tienen la oportunidad de estar más cerca de la perspectiva del usuario. Incluso con un miembro de UX dedicado que da el primer paso en los diseños, la verdadera validación del usuario es invaluable.

Reformularía su pregunta de esta manera: "somos pocas personas en un barco y ninguno de nosotros está calificado para ser capitán. ¿Cómo debemos navegar el barco? ¿Dejar que lo haga el personal de cocina o que todos participemos por mayoría de votos?"

Por supuesto, la respuesta correcta se encuentra fuera de las dos opciones que sugiere. Debe contratar a un experto externo o capacitar a (uno de) ustedes mismos en ese trabajo.

"La última palabra" es una decisión empresarial; Consultar el Marco o Carta

¿Es mejor para el producto o para los ingenieros tener la última palabra en las decisiones de UX/diseño? ¿O debería ser una mayoría de votos?

La respuesta es: "Ninguno. Ambos. Depende".

Su suposición subyacente parece ser que la autoridad para tomar decisiones se basa en la experiencia en UX o diseño de productos, ¡pero no es así! La autoridad para la toma de decisiones es delegada por la empresa , y la forma en que se delega esta autoridad generalmente se detalla en el acta de constitución del proyecto, los documentos de gobierno corporativo o es inherente a la metodología del proyecto.

Por ejemplo, en un proyecto Scrum, el propietario del producto (PO) definiría un objetivo, como una pantalla de inicio de sesión, como un elemento de la cartera de productos (PBI), y el equipo Scrum decidiría en colaboración cómo implementarlo. En Scrum, esto sería cierto ya sea que haya o no un recurso de UX dedicado en el equipo. Otros marcos delegarán la responsabilidad de manera diferente.

Nuestro equipo no tiene un empleado de UX/diseño dedicado.

Puede o no necesitar uno. No tiene nada de malo tener equipos multifuncionales con responsabilidades compartidas, y es posible que la UX formal ni siquiera sea parte de la ruta crítica de su proyecto. Sin embargo, si falta la experiencia específica necesaria para entregar con éxito el proyecto, entonces este es un problema de proceso que debe hacerse visible a la alta dirección para que puedan abordarlo o aceptar el riesgo asociado del proyecto.

En ágil tratamos de lograr tanto como sea posible por consenso.

Intente construir una relación de trabajo entre la gente del producto y los ingenieros, de modo que se llegue a un consenso con frecuencia y no haya necesidad de votar o de que una de las partes tenga la autoridad final.

Como ejemplo, podría llegar a un acuerdo de que la gente del producto decida el diseño general, pero que los ingenieros puedan decidir sobre los detalles. O puede estar de acuerdo en que se sigue una guía de estilo, pero que la gente del producto puede tomar decisiones siempre que no entren en conflicto con la guía de estilo.

Lo importante es tener un enfoque que permita que todos se sientan cómodos con el diseño.

Aquí hay algunas variables abiertas:

• ¿Qué tan grande es el valor del producto basado en sus atribuciones de diseño/UX?
• ¿Qué tan "sexy" es el producto?

En general (especialmente si la respuesta es "baja" para las preguntas anteriores), diría que el OP/PM debe hacer estas definiciones. Algunas de estas definiciones incluso serán fáciles de hacer, ya que algunos requisitos comerciales se basan en definiciones de UX/Diseño.

Sin embargo, un PO inteligente pediría aportes a sus compañeros de equipo que tengan un conocimiento/experiencia más profundo (o incluso algo) con UX. Además, la empresa y/o el equipo definitivamente deberían encontrar alguna calificación en esa habilidad, ya que esta necesidad probablemente no desaparecerá :)