¿Es difícil o una pérdida de tiempo para los desarrolladores ajustar el diseño de la página en función de los cambios en el diseño de los componentes?

Condición

Este es un sitio para la gestión de proyectos, no para la ingeniería, por lo que le proporcionaré una respuesta de gestión de proyectos. Si desea una respuesta de ingeniería, es posible que deba buscar un sitio diferente para hacer la pregunta.

TL;DR

"Diseño" es a menudo un término que se aplica a alguna representación artística o estructura alámbrica durante el diseño del producto, por lo que es más una ayuda visual que un conjunto de especificaciones procesables. Hay excepciones (como siempre las hay), pero esto es cierto con tanta frecuencia que generalmente se puede suponer que el diseño de la interfaz de usuario (IU) (a diferencia de la implementación de la IU ) es más fácil de cambiar que parte de la implementación del producto en sí.

No hay una respuesta canónica aquí. Las únicas soluciones generalizables son una mejor comunicación y colaboración entre los roles de diseño e implementación.

Análisis y Recomendaciones

Dependiendo de su producto (supongamos que es un sitio web para simplificar el ejemplo), los cambios en la interfaz de usuario pueden ser tan simples como:

¿Puede mover esta casilla de verificación tres píxeles a la izquierda?

y tan duro como:

Queremos que este campo se complete con el conjunto conocido de usuarios que viven en Spokane con códigos postales impares cuyo apellido también termina en la letra A.

A primera vista, el primer cambio es mucho más fácil de lograr que realizar cambios importantes en la base de datos y la lógica de back-end para implementar la segunda solicitud de cambio. Sin embargo, las únicas personas que saben con seguridad lo difícil que es un cambio son las personas que necesitan realizarlo, por ejemplo, los diseñadores, los desarrolladores front-end y los desarrolladores back-end.

Si tiene suerte, las tres cosas las manejan las mismas personas completas, pero en el peor de los casos, debe tener los tres conjuntos de habilidades representados dentro de su equipo para que puedan colaborar en la mejor manera de implementar los cambios necesarios. Sin esa colaboración, y sin comunicación y estimaciones de las personas que realmente harán el trabajo, es imposible evaluar con precisión el nivel de complejidad de cualquier parte del trabajo propuesto.

La entrada del líder del proyecto debe ser un qué , por ejemplo, qué cambios se deben hacer para cumplir con algún objetivo comercial medible. La entrada del equipo debe ser un cómo , por ejemplo, cómo el equipo puede cumplir con mayor eficacia el objetivo del nuevo producto dado el estado actual del producto, las habilidades y herramientas disponibles para el equipo y el nivel de esfuerzo involucrado en la solicitud.

La única forma de obtener esa información con precisión es preguntar a las personas involucradas. Pregunta a los diseñadores por qué necesitan este cambio. Pregunte a los implementadores de cambios qué implica el cambio para ellos y si hay opciones o circunstancias que puedan afectar el nivel de esfuerzo necesario para implementar el cambio.

Si está buscando una respuesta universal y canónica: no hay ninguna. Sin embargo, como regla práctica puramente pragmática, el diseño es más fácil que la implementación, especialmente si la implementación se trata como una tarea posterior o "sobre la pared" que no tiene en cuenta la complejidad de la implementación. Las únicas soluciones generalizables son una mejor comunicación y colaboración entre los roles de diseño e implementación. Si no es su rol facilitar eso, entonces por favor escálelo al rol que posee la colaboración y la comunicación dentro de la organización de desarrollo de productos.

A veces pienso que un diseño de UX es bueno y no hay problema en desarrollar este diseño.

Entonces... dos personas sin habilidades de desarrollo piensan que algo debe ser fácil de desarrollar...

¿Por qué no cambian el componente según el diseño? ¿Es difícil para ellos?

... y los desarrolladores reales te dicen que no lo es.

Sí, desarrollar componentes basados ​​en requisitos es su trabajo. Y asumo que pueden hacerlo. No es difícil per se. Sin embargo, dado que es muy común que ni el tipo de UX ni el gerente de proyecto sepan nada sobre desarrollo, principalmente es así:

Hola, Sr. mecánico de automóviles, señor, estuve en el lago ayer y se veía increíble . Todos esos hermosos vehículos con todas las banderitas que tenían ondeando. Los quiero para nuestros vehículos también. Nuestro departamento de marketing está entusiasmado . Esta es la mejor idea nunca. Venderemos millones. Entonces, ¿cuándo podremos tener un mástil principal en el techo de nuestro automóvil para enarbolar nuestras banderas? ... ¿Qué quieres decir con "es difícil"? ... ¿No sabes cómo trabajar en los coches?

Hay cosas que son "estándar". Cambio de neumáticos. Cambio de cajas de cambios. Rehacer el trabajo de pintura. Esos son normales. Toman un poco de tiempo, pero no es nada fuera de lo común.

En programación, eso sería "elegir una fecha del control de calendario del sistema operativo" o "enumerar todas las imágenes y hacer que aparezcan en pantallas pequeñas mediante el algoritmo predefinido de la plataforma".

Ahora, lo que sí veo en la práctica es que, por ejemplo, la persona de UX no está contenta con el control de calendario que existe y quiere cambios. Pero no puedes simplemente "cambiarlo", solo puedes rehacerlo desde cero. Básicamente escribiendo uno nuevo. De la misma manera que tener un mástil principal saliendo del techo del automóvil probablemente requerirá una remodelación/reconstrucción completa.

¿Es difícil? No. Alguien escribió el original, tampoco era un superhéroe genio. Es solo trabajo. Pero es mucho trabajo por hacer. Tenemos una aplicación en la que construimos un control de calendario desde cero porque al propietario del producto no le gustó la apariencia del control nativo. Creo que gastamos fácilmente una suma de seis cifras en esto hasta que estuvo listo (planificación, desarrollo, rediseño, planificación, desarrollo, corrección de errores de las miríadas de casos extremos que tienen las fechas y las zonas horarias, pensar en todos los gestos y escribir que podría hacer para ingresar fechas en diferentes formatos, testing, QA...). Este dinero podría haberse utilizado fácilmente para desarrollar una función productiva, en lugar de "otro diseño" para una función existente.

Así que aplaudo a todos los diseñadores de UX que presentan formas nuevas e innovadoras de hacer las cosas. Pero el director del proyecto tiene que controlar el precio de este diseño. Al igual que en la fabricación, hacer más de "lo mismo viejo" es barato, hacer algo nuevo es extremadamente costoso en comparación.

Entonces, por ejemplo, si crea una pequeña aplicación (digamos algunos meses con algunas personas, se usaron componentes estándar, ~100 000 $), debe decidir si vale la pena agregar otra etiqueta de precio y duplicar, triplicar o cuadriplicar el precio solo porque sí. no te "gusta", por ejemplo, Material Design. O la apariencia de Apple. O cualquier dispositivo en el que estés. Si tiene esa cantidad de efectivo para gastar en apariencia, por supuesto, hágalo. Pero los desarrolladores probablemente se sentirían un poco insultados si le dijeras al mundo que necesitaron un año y medio para esa aplicación. Porque la aplicación se completó funcionalmente después de unos meses.

Así que solo obtenga dos etiquetas de precio... deje que sus desarrolladores le digan lo que necesitan para hacer su producto. Y luego deja que te digan lo que necesitan para cumplir con las especificaciones de UX. La diferencia se debe a que el diseñador de UX se desvía de lo que es normal para esa plataforma. Te puede gustar y pagar por ello. Pero debe tener claro el hecho de que pagó este precio adicional por el diseño, no por el desarrollo.

Todos tienen derecho a tener un mástil principal en el techo de sus autos si pueden pagarlo, pero no culpen al mecánico por el precio que cuesta o las horas-hombre que gastaron.