¿Cómo debemos entregar y emitir boletos de los diseños de la interfaz de usuario a los desarrolladores para garantizar que el diseño desarrollado coincida con las maquetas de la interfaz de usuario proporcionadas, sin dejar de ser ágil?

¿Cómo debemos entregar y emitir boletos de los diseños de la interfaz de usuario a los desarrolladores para garantizar que el diseño desarrollado coincida con las maquetas de la interfaz de usuario proporcionadas, sin dejar de ser ágil?

Nota: definitivamente no somos completamente ágiles, pero estamos trabajando para lograrlo.

Nuestro primer enfoque dio como resultado diseños que se desviaban de las maquetas. Nuestro segundo enfoque no se siente ágil o correcto.

Primer enfoque

Originalmente proporcionaríamos enlaces abstractos y les diríamos a los desarrolladores que lo igualaran lo más cerca posible

Aquí hay un enlace de resumen de muestra: https://app.abstract.com/share/aaec8bba-f473-4f64-96e7-bff41c70ff8a?mode=design&selected=root-0D96514D-DEEB-4B05-A00B-4EEB38A353A3

Si hace clic en la pestaña de inspección, puede ver el espacio entre todos los elementos.

Problemas con el primer enfoque:

  1. Los desarrolladores no tenían una "lista de verificación de IU" a seguir. Terminarían ignorando el diseño abstracto a la mitad y simplemente improvisando. Esto condujo a diseños que no coincidían con los resúmenes proporcionados.
  2. El diseño abstracto no comunica la capacidad de respuesta, como qué elementos se fijan en el borde derecho de la página o qué elementos se extienden a medida que la ventana gráfica se hace más grande. estirar con el no pasaría por completo todos los requisitos de espacio.
  3. Es tedioso actualizar enlaces abstractos con cambios de diseño. Como resultado, en lugar de actualizar el enlace abstracto, simplemente pondríamos "notas de ajuste" en el ticket. Dado que los resúmenes a menudo estaban desactualizados, los desarrolladores no podían consultarlos con confianza para el espaciado y otros estilos.

Segundo enfoque

Para asegurarnos de que los desarrolladores coincidieran con los diseños, comenzamos a escribir cada uno de los requisitos de diseño como su propio ticket independiente.

Por ejemplo, aquí hay algunos boletos que hemos escrito con el nuevo sistema:

  1. "diseña el botón de la siguiente manera"
  2. "hacer el espacio entre botones de la siguiente manera"
  3. "anclar el botón al lado izquierdo de la ventana gráfica"

Esto resolvió completamente nuestros problemas con el diseño no

Problemas con el segundo enfoque:

  1. No encaja con el método de emisión de tickets de la historia de usuario (¿cómo podemos realizar un seguimiento de 30 tickets de diseño que están relacionados con una sola historia de usuario?)
  2. Tedioso escribir tantos billetes
  3. Desordena el tablero Kanban. El control de calidad tiene demasiados tickets para revisar (y es principalmente una pérdida de tiempo, porque creo que el control de calidad debería probar la funcionalidad, no el diseño)

__

Entonces, que sugieres?

Tener su proceso de UX separado del Equipo Scrum es un anti-patrón ágil. También lo son las "historias" como mover este widget 1 píxel a la izquierda . Es posible que desee reconsiderar su enfoque.
¿Intentó algo como el segundo enfoque, pero en lugar de recaudar una tonelada de boletos, usó viñetas en un solo boleto? Siempre que sea posible, los tickets deben representar tareas separadas. Si no tiene sentido con su flujo de trabajo agregar primero el botón y luego que otra persona lo ancle en el lado izquierdo de la ventana gráfica, entonces no tiene por qué generar dos tickets.
O para decirlo de otra manera: si necesita comunicar 10 piezas de información a un desarrollador para que haga bien el trabajo, hay muchas maneras de hacerlo además de generar 10 tickets :-)
Una cosa que he visto que no se menciona aquí: hay herramientas de maquetas de diseño que puede usar para hacer maquetas receptivas sin escribir código. Eso podría ser una mejora incremental sobre el uso de Photoshop. (No estoy muy familiarizado con tales herramientas, o daría una respuesta).
Estoy confundido por qué "They would end up disregarding the abstract design half way through and just wing it."sucedió. ¿Hubo una razón técnica por la que simplemente decidieron no hacer lo que se les pidió que hicieran? Mi empresa sigue exactamente su "primer enfoque" (aunque con una herramienta diferente) y no tenemos este problema.
Creo que el problema aquí es que el diseño y el sitio web pueden funcionar de manera muy diferente. He estado en la posición de que el desarrollador tiene que editar el trabajo del diseñador. A veces, es porque el diseño responde, a veces es porque x es realmente difícil de hacer sin errores. Particularmente cierto si alguien ha improvisado el diseño en Photoshop. Esto parece que necesita un diálogo con su equipo de desarrollo. Escuche lo que les resulta difícil, invítelos a reuniones para informar sobre el diseño desde el principio, ofrézcales ayuda cuando crean que es necesario hacer cambios. Esto también le permite impulsar las cosas importantes.

Respuestas (3)

He visto que esto sucede con el diseño tantas veces. Es un problema estructural con la forma en que se organizan las personas y los equipos. Ahora, siento que debería decir que los equipos multifuncionales no están obligados a ser ágiles. Scrum los requiere, pero no veo que estés usando específicamente Scrum. Dicho esto, la estructura de "El equipo de diseño crea un diseño y el equipo de desarrollo implementa" conduce directamente a lo que tienes aquí.

Cuando tienes un equipo de diseñadores que están creando un diseño, hay dos caminos por los que pueden ir. En primer lugar, pueden usar una herramienta como Photoshop que representa los gráficos de una manera tan diferente a la web que tratar de traducirse perfectamente entre ellos es una broma. En segundo lugar, puede usar una herramienta como esta en la que el diseñador está construyendo una página web HTML/CSS.

Luego, los desarrolladores intentan construirlo, pero la herramienta ha ofuscado muchos de los detalles de HTML/CSS en un extraño intento de proteger a los diseñadores del código aterrador.

La solución simple, los diseñadores deben construir la parte HTML/CSS de la aplicación y terminar con ella. Si pueden hacer lo que vinculaste, pueden crear la presentación HTML y CSS. Será aún más fácil si los diseñadores y desarrolladores trabajan mano a mano en el mismo equipo.

Algunas advertencias rápidas:

  1. una excusa común que he escuchado es que es demasiado técnico. Lo siento, pero tengo que llamar a BS. Un buen artista es un experto en las propiedades del grafito y la pintura. Un músico entiende cómo se construye su instrumento y cómo funciona. Es solo un medio y el diseñador gráfico necesita comprender el medio en el que está trabajando.

  2. dicho esto, puede haber un tiempo de aceleración. Sugiero encarecidamente alguna programación en pareja para desarrollar la habilidad (y el experto debe ser el observador/ayudante, no el hacedor)

  3. otra posibilidad que en realidad invalidaría toda mi respuesta es que la plataforma en la que está desarrollando crea una abstracción adicional completa sobre la capa HTML/CSS de modo que, aunque al final todo se convierte en eso, en realidad no puede ingresar al HTML/CSS. He visto esto muchas veces con los CMS. Estos pueden requerir algunas soluciones mucho más creativas que las que obtendrá en un foro de preguntas y respuestas y, francamente, probablemente merezcan una conversación seria sobre lo que ese marco está poniendo sobre la mesa para usted. Sin embargo, en general, elegir usar una abstracción como esa funciona mejor cuando está diseñando estrictamente dentro de los límites preestablecidos de ese marco.

"la plataforma en la que está desarrollando crea una abstracción adicional completa sobre la capa HTML/CSS" o incluso, la capa HTML/CSS crea una abstracción adicional completa más allá de lo que el diseñador ha tenido en cuenta. Por ejemplo, los desarrolladores son el tipo de personas pedantes que hacen preguntas que los diseñadores odian como: "Está bien, me dijiste todos los espacios en píxeles, ¿y qué pasa si la ventana gráfica no tiene el tamaño que crees que debería ser?" Esta es la razón por la que los píxeles CSS ya no son realmente píxeles: ¡los desarrolladores se dieron cuenta de que estaban siendo demasiado pedantes!
Y sí, para el tamaño de la ventana gráfica, puede decir que es algo que cualquier persona que diseñe para la web debe conocer y decidir por sí mismo como parte del diseño. Pero identificar casos extremos molestos es una parte fundamental del trabajo de un desarrollador: menos esencial para los diseñadores gráficos. Entonces, si no es el tamaño de la ventana gráfica, su desarrollador encontrará algo .
Creo que sus comentarios refuerzan el desafío de que el diseño y el desarrollo son dos esfuerzos separados. El desarrollador no debería intentar darle una llave al diseñador y los diseñadores no deberían tirar su arte por la borda para el desarrollo. Juntos, pueden usar sus conocimientos y habilidades para encontrar una gran solución.
De acuerdo: en lugar de tirar llaves, desea un proceso colaborativo en el que pueda hacer una pregunta lo antes posible, lo que evita que se pierda tiempo trabajando en suposiciones erróneas. Entonces, en el caso de la ventana gráfica y el espaciado, en el momento en que el diseñador dibuja un rectángulo grande y lo marca como "800x600 px", alguien puede decir "OK, sobre eso...", antes de que el diseñador pase una tarde averiguando cuántos píxeles para permitir cada componente.
Permítame contribuir con algunos materiales para ayudarlo a ampliar su tribuna.
lo siento chrylis, no entiendo el comentario

Déjame desafiar un poco el marco de tu pregunta:

¿ Por qué tienen requisitos tan específicos que cambian para cada boleto ?

¿Es realmente necesario tener diferentes márgenes entre botones en diferentes páginas? ¿Es necesario tener diferentes estilos para cosas en diferentes páginas? ¿No es el trabajo de un diseñador crear un estilo reconocible para toda la aplicación?

Su diseñador debe tener una guía de estilo para toda la aplicación. Allí pueden definir cosas como márgenes predeterminados, tamaños de relleno comunes, tamaños de imagen, cómo se ven los botones en general en su aplicación. Qué colores usar cuándo.

Su propio trabajo no debería consistir en sentir que hoy debería ser 7px, porque es lunes y se ve bien. Debería ser 7px porque la guía de estilo dice que 7px es como lo hace esta aplicación.

Entonces, todo lo que tiene que hacer es usar los resúmenes y la guía de diseño en los boletos. Si tiene una "Definición de Listo", incluso podría ponerla allí, por lo que no necesita deletrearlo en cada ticket.

El punto es: si tiene requisitos cambiantes en cada boleto, lo siento, sí, tiene que deletrearlos. Pero no debería tener requisitos cambiantes, a menos que desee que su aplicación se vea como un niño loco de 13 años en su primer espresso. El buen diseño tiene reglas. Anótelos y páselos a sus implementadores de diseño, para que puedan seguir las reglas.

Agile se nutre de la colaboración entre personas, en lugar de construir muros alrededor de cada equipo y arrojar cosas sobre ellos.

La situación ideal sería que los diseñadores trabajen en el mismo equipo que los desarrolladores y creen sus diseños a medida que se desarrolla el software, con la tecnología utilizada para implementar los diseños. De esta manera, el diseñador es quien realmente implementa el diseño.

Si eso no se puede lograr y los diseñadores deben permanecer en un equipo distinto de los desarrolladores, entonces elegiría una variante de su primer enfoque:

  1. Los diseñadores proporcionan un enlace abstracto que muestra el diseño de una historia/característica. Esto se entrega tan tarde como sea posible, preferiblemente justo antes de que el desarrollador necesite el diseño para completar la implementación.
  2. Antes de comenzar a implementar el diseño, el desarrollador se sienta junto con el diseñador para discutir el diseño (qué aspectos no se pudieron capturar en el enlace abstracto, qué partes deben tener píxeles perfectos y dónde tiene el desarrollador algo de holgura para desviarse, etc.)
  3. El trabajo no se completa hasta que el diseñador confirma que el diseño se ha implementado según lo previsto. (a medida que crece la confianza, esto podría omitirse)

Esto aborda los problemas de cómo hizo el enfoque de la siguiente manera:

  • Al hacer el diseño lo más tarde posible, se debe limitar la cantidad de cambios entre el momento en que se hace el diseño y el momento en que se implementa. Eso hace que sea menos frecuente la necesidad de actualizar un diseño abstracto.
  • El paso de revisión debe captar los puntos en los que el desarrollador se desvía del diseño sin involucrar al diseñador.
De hecho, creo que la gente está demasiado ansiosa por saltarse (3) debido a la confianza. Como desarrollador en el ticket, quiero que las personas establezcan requisitos para "confiar, pero verificar", y un diseño que provenga de fuera del equipo de desarrollo es un requisito. El diseñador sabe lo que querían decir, así como lo que se incluyó en la especificación de diseño, por lo que siempre quiero que la persona que escribió la especificación revise el resultado si es posible. Del mismo modo, si es posible, consultaré a la persona que informa un error para confirmar que la solución soluciona su problema, no solo lo que escribieron, o lo que pensé que querían decir con lo que escribieron.
@SteveJessop, agregué ese comentario entre paréntesis porque esas revisiones podrían verse como algo que causa retrasos. Pero estoy de acuerdo con tu comentario de que deberías querer tener esas reseñas.
¿Cómo debemos entregar y emitir boletos de los diseños de la interfaz de usuario a los desarrolladores para garantizar que el diseño desarrollado coincida con las maquetas de la interfaz de usuario proporcionadas, sin dejar de ser ágil?
RespuestasAquíPolítica de privacidad1y, 0v