¿Qué primero, UX/UI o Scrum Backlog para crear un MVP?

Estoy realmente interesado en las opiniones de los expertos sobre mi enfoque en el diseño de UX/UI y el desarrollo de software Agile. Espero que alguien con experiencia en este campo pueda ayudarme con mis dudas.

Desde mi perspectiva, para crear un backlog (recopilación de historias de usuarios) para un MVP (desarrollo Lean), primero debe crear un proyecto básico de "Arquitectura de la información", donde puede diseñar un "Flujo de trabajo de tareas", "Flujo de trabajo del sitio". Map", "wireframes" y "Diseño de interacción", para que puedas estudiar y diseñar el comportamiento de un usuario, lo que tiene que hacer para lograr determinadas tareas, los flujos de la página web, cómo es el flujo real y esperado desde el principio. para finalizar, o cómo hacer que la "experiencia de usuario" sea mejor, como por ejemplo con menos clics, siendo más comprensible, etc.

Una vez que haya recopilado toda esta información necesaria para su MVP, puede comenzar a crear "épicas" y sus "historias de usuario" relacionadas, de modo que pueda realizar "tareas de usuario" (tareas de valor comercial). Obviamente, esta "especificación de UX/UI" cambiará entre los proyectos, pero la imagen básica permanecerá.

¿Qué opinas sobre este enfoque de desarrollo de software? Podríamos llamarlo "prediseño UX/UI MVP", para que después de eso, pueda comenzar su "desarrollo de software Lean Agile".

Con este enfoque, tiene el doble de vista de pájaro. Prediseño ligero de UI/UX (tareas de flujo, interacción de bocetos, etc.), sin "prototipos de alta fidelidad" y acumulación de historias de usuario, por lo que los desarrolladores tienen un mejor conocimiento y el diseño puede estar al frente.

Otra duda es dónde ubicar "Art Design" y "High Fidelity UI prototyping" :-)

Respuestas (2)

Esta es una buena pregunta, y hay un gran conjunto de respuestas y comentarios sobre UX SE: ¿En qué punto del proceso de desarrollo debería entrar en juego UX en un entorno de trabajo Agile? , y aquí en PM SE hay ¿Dónde se debe incorporar el diseño en un proceso ágil? que también tiene buena información.

En mi experiencia liderando equipos de desarrollo y administrando proyectos, es importante que si su equipo de desarrollo no incluye UX, el equipo de UX también ejecute Agile en paralelo y haya una buena conversación cruzada para garantizar que las historias se comuniquen según corresponda.

Sin embargo, lo que trato de hacer es asegurarme de que UX sea parte del equipo de desarrollo/equipo de proyecto general y que todos estemos operando en el mismo entorno Agile. En ese caso, su descripción de un proceso generalmente me parece bien, con algunas notas:

  • No permita que el grupo de UX caiga en cascada cuando se supone que deben estar haciendo Agile; no permita que produzcan enormes cantidades de wireframes y otra documentación por adelantado; en su lugar, encuentre el equilibrio que les permita producir algo significativo pero que mantenga el proceso en movimiento.
  • Recuerde que UX también será iterativo; este trabajo inicial no debería ser la última vez que estén involucrados.

Personalmente, no hago una distinción entre "trabajo de UX realizado antes de que ocurra el desarrollo técnico" y "desarrollo de software ágil".

En primer lugar, muchas gracias por su respuesta. Realmente entiendo el concepto de ser esbelto o construir un producto MVP a través de ciclos ágiles (historias de usuarios). Pero todavía no entiendo el punto de trabajar en UX/UI/Art-Design sin un avance (sin cascada). Desde mi punto de vista, si tienes que hacer Lean UX solo en cada ciclo, estás creando un "frankenstein". Una historia de usuario tal vez no incorpore un proceso de flujo de tareas completo, entonces, ¿cómo vas a diseñar arte con Photoshop o estudiar la arquitectura de interacción para un proceso de flujo de tareas completo entonces? En Lean..
.. giras cuando creas una versión MVP, no en el décimo ciclo, por ejemplo. Así que ese es el núcleo de lo que no entiendo en absoluto. Tiene sentido que después de su MVP, recopile comentarios de usuarios reales, por lo que tal vez necesite cambiar a algo diferente. En esta situación, creará cambios no solo en el código de back-end, sino también en el código de front-end y el diseño de UX/UI. En esta situación, entiendo que tendrá que volver a crear un diseño de UX/UI por adelantado para crear las modificaciones que necesita para pivotar. Porque cuando creamos un backlog, todos estamos de acuerdo en que estamos creando un up-front, ¿verdad?
@user1106811 Si va a usar Lean, háganlo juntos (UX y desarrollo tecnológico). Del mismo modo, si te vuelves ágil, ve junto. Será difícil tener un grupo Lean y otro Agile, y creo que es desesperante volverse Agile al principio y luego Lean (o viceversa). Puede hacer Lean UX (pensar-hacer-verificar) al igual que puede hacer Lean tech dev (construir-medir-aprender), y con las personas adecuadas y la atención al método, la combinación de los dos puede funcionar. También te puede interesar esta pregunta de UX SE
Creo que tengo algún tipo de malentendido conceptual con Agile, Lean y LeanUX :-). Lo que entiendo: infoq.com/news/2008/09/Not-Agile-Vs-Lean.Desde mi perspectiva, es casi lo mismo. Cree un MVP a través de Agile (es el objetivo Lean), así que después de eso, si necesita pivotar, hágalo. De lo contrario, continúa con la siguiente característica comercial principal. Mi duda era sobre la creación de prototipos UX (IA) y HiFi. Realmente veo LeanUX (o AgileUX) como algo desde donde no se puede planificar correctamente la experiencia del usuario en su conjunto, teniendo en cuenta todo el flujo de tareas del usuario.
@ user1106811 No estoy diciendo que planifique toda la experiencia del usuario por adelantado; de hecho, es lo contrario: que también es iterativo. Es "pensar en la experiencia en fragmentos priorizados", consulte "Lean UX: Salir del negocio de los entregables" y de manera progresiva. Puede iniciarlo, traer desarrollo tecnológico y luego continuar juntos utilizando el mismo marco metodológico.
Hace unas semanas leí este artículo. Define una nueva forma de desarrollo para UX/IA, donde se sale de los derivables y del diseño up-front (IA/UX y prototipos). Es el nuevo método llamado LeanUX. Pero desde mi punto de vista (solo una opinión muy personal y humilde), para lanzar un MVP a través de Agile (Lean), es mejor seguir la forma tradicional de cascada para el paso de Definir--> Diseño (ligero, no HiFi) , dejando la fase Desarrollar → Probar → Implementar para las iteraciones ágiles. De esta forma, los desarrolladores tienen una vista panorámica y los errores son más baratos de modificar en la fase de diseño. ¿Qué opinas?
@user1106811 Creo que debe hacer lo que funcione mejor para su equipo y su proyecto, pero si está implementando múltiples metodologías, también debe equilibrar las expectativas, los cronogramas y las personas de manera diferente que si estuviera trabajando constantemente con una.

¿Qué opinas sobre este enfoque de desarrollo de software? podríamos llamarlo "prediseño UX/UI MVP", para que después de eso, pueda comenzar su "desarrollo de software Lean Agile".

Normalmente no soy tan pesimista, pero no creo que funcione. El enfoque Lean Startup y los métodos ágiles de desarrollo de software pueden tener raíces comunes, pero sus formas son diferentes. Si publica un MVP, debe seguir el proceso del proceso Lean Startup , que depende de los comentarios que dé el cliente sobre el MVP y los datos medidos. ¿Cómo le gustaría manejar estos comentarios y datos? No puede simplemente crear un backlog, porque contendrá varios elementos; sin embargo, en Lean Startup solo hay dos opciones después de un MVP: Continuar con la siguiente característica o pivotar. Tener un backlog es una pérdida de tiempo y recursos en este caso.

Cuando un proyecto depende en gran medida de la interfaz de usuario, puede tener un prototipo, lo cual está bien. El cliente puede dar retroalimentación, pero cada retroalimentación será una nueva historia de usuario, y deben priorizarse, u olvidarse de Agile y hacer el desarrollo como se describe en Lean Startup .

,pero hasta donde entiendo el método Lean, se trata solo de crear un MVP con características comerciales mínimas, pero funcional. Para crear este MVP, la mejor manera es usar Agile (historias de usuarios). Si tiene que pivotar, simplemente modifique la aplicación eliminando y/o agregando nuevas historias de usuario, como al principio. No entiendo su comentario de que "tener un retraso es una pérdida de tiempo". ¿No es así? ¿Se supone que Lean y Agile están totalmente relacionados?
En realidad, Lean != Lean startup y Agile != Lean. Lean se trata de personas y mejora continua. Lean startup introdujo el MVP y sugiere que debe mejorar continuamente su producto. Existe la única conexión además del nombre. Lean y Agile no están relacionados. Puede encontrar algunos principios Lean en Agile, pero tienen un enfoque completamente diferente.
con "relacionado" quise decir que hay dos conceptos diferentes relacionados hoy en día para el desarrollo de inicio. Agile es el mecanismo recomendado utilizado por Lean Startup para crear MVP en un contexto de iteración continua (desarrollar-probar-mejorar). Para crear un MVP, necesita un mínimo de historias de usuario en su cartera de pedidos. De todos modos, si una persona no quiere seguir el método Lean Startup y simplemente se vuelve ágil, ¿le aconsejaría tener un prototipo completo de IA y HiFi antes de comenzar a crear el backlog?
¿Qué primero, UX/UI o Scrum Backlog para crear un MVP?
RespuestasAquíPolítica de privacidad1y, 0v