La deuda de diseño de productos, servicios o experiencias
Definimos que es la deuda de diseño, como trabajarla y como no perecer bajo su tremendo influjo.
Hola! soy David Úbeda, Business manager en Interactius.
A lo largo de estos últimos 4 años me he dado cuenta de que siempre hay una constante que se repite y que nunca había sido capaz de identificar, una deuda que ha afectado a servicios y productos que he diseñado o proyectos en los que he participado.
Llamémosla ‘Deuda de diseño’. Y la odio.
Pero primero hemos de tener claras dos constantes de todos los proyectos.
- La gente; con diferentes skills y perfiles entran y salen en proyecto a lo largo de las etapas de desarrollo y ciclo de vida.
- El ciclo de vida; los productos digitales son seres vivo; nacen, crecen, se reproducen o evolucionan (a veces) y al final se mueren, y el 90% de las veces hacen esto fuera del control de los equipos de diseño.
¿Qué es?
Un factor que disminuye la calidad del proyecto, producto o servicio. ¡PAM!
La deuda de diseño es real y es difícil de gestionar, ser consciente de ella y activar mecanismos para mitigar su impacto nos va permitir no perder la pista de todas esas ideas maravillosas que por tiempo y limitaciones de desarrollo no pudimos entregar en producción. Además de dejar constancia de lo que se puso en producción y porque se hizo así.
Pasa en demasiadas ocasiones y en demasiados proyectos que no disponemos de un repositorio o herramienta y sobretodo tiempo para poder tener seguimiento de todo lo que diseñaremos; de la arquitectura de la información, de como trabajamos la accesibilidad y la usabilidad, del diseño de la interfaz o de la interacción y de todo lo que finalmente no será puesto en producción. Os adelanto llegados a este punto una recomendación; presupuestad horas de documentación y el coste de herramientas para gestionar la deuda. Vuestro cliente quiere calidad.
La deuda de diseño nos afecta a corto plazo, lo siento.
Los diseñadores no somos seres de luz, seamos ‘creativos’, seamos ‘artistas’, con un pensamiento divergente, claro que sí, pero no olvidemos aspectos de la gestión operativa de los proyectos en los que participamos.
La deuda de diseño va a aparecer más a menudo de lo que creemos, especialmente cuando researchers y diseñadores trabajamos con plazos ajustados o en entornos poco agilistas muy departamentados; funcional, diseño, desarrollo, QA… Impacta ya en los primeros entregables, se hace patente en las posteriores iteraciones y sobretodo en futuros evolutivos donde el desastre será épico.
El principal coste será todas esas ideas geniales, que incluso validadas por usuarios se quedan por el camino y nunca llegan a producción. Diles adiós, nunca volverás a saber de ellas.
¿Por qué quiero que la evites?
Lo primero, es mejor y mas económico hacerlo bien a la primera que hacer correctivos de diseño una vez estamos ‘on air’.
Además, las iteraciones de un producto digital van a llegar más pronto que tarde, igual que los correctivos y evolutivos sobre el mismo producto, es inevitable, por eso mismo necesitamos disponer de una base sólida y buena documentación, limpia y real para que cada nuevo evolutivo no se convierta en un nuevo diseño con poco y mala relación con versiones previas del producto.
El rediseño de aspecto y funcionalidades de un producto en producción consume gran cantidad de recursos: el equipo de diseño debe aprender el funcionamiento de las funcionalidades ya implementadas, dedicar tiempo al rediseño de las mismas para adaptarlas a la nuevas propuestas y adaptar otras áreas del producto para que tengan consistencias con las nuevas funcionalidades propuestas, y luego integrarlo…
“Antes de ponerme a definir las nuevas funcionalidades debo estudiar la arquitectura de la información, redibujar componentes para añadir un solo nivel de navegación y adecuar una interacción para resolver una acción que antes se hacia así y ahora se hará asá.” Sabes de lo que hablo verdad?
La experiencia del usuario es un coste añadido de la deuda:
- Poner en producción un diseño temporal, o un parche es una CAGADA. Muchos usuarios lo intentarán y se rendirán si el diseño es poco accesible o no satisface sus necesidades. Incluso si solucionamos las incidencias, los usuarios no lo sabrán, porque ya no volverán para comprobarlo una vez hayan tenido una mala experiencia. Lo que cuesta hacer un nuevo cliente y lo poco que cuesta perderlo.
- Los usuarios que no tengas más remedio a utilizar nuestro producto, a pesar de la mala experiencia, se acostumbrarán al mal diseño. Una cosa que no todos los usuarios tienen ganas de hacer o tiempo es esforzarse a entender un nuevo diseño, aunque sea objetivamente mejor que la versión anterior.
- La inconsistencia de usabilidad y aspecto gráfico del producto es la principal consecuencia de la acumulación de deuda de diseño.
- Malos scorings. Rating bajos y malos comentarios de los usuarios que harán que sea imposible captar nuevos usuarios. Además, aunque iteremos y mejores nuestra propuesta, las malas valoraciones quedan ahí.
Quá mala pinta! venga, ahora unas ventajas de porque es tan importante que trabajes en evitar la deuda de diseño, o que tengas un control positivo de esa deuda.
Para la área comercial (donde se generan los ingresos);
- Aumento de conversiones
- Incremento en las ventas
- Captación de nuevos clientes
- Mayor revenue
Ahora hablemos del ‘branding’
- Fidelización del cliente
- Satisfacción del usuario
- Beneficios en la imagen de marca
- Crecimiento del NPS
¿y el equipo de desarrollo? pues
- Mayor productividad
- Eficiencia del desarrollo
- Mejor calidad del producto
- Menor fricción entre diseño y desarrollo.
- Timings y presupuestos más reales.
¿Como trabajamos de manera positiva esta deuda?
No tengo una fórmula mágica para evitarla, hay muchos factores que dependen de características subjetivas. No hay que olvidar que estamos diseñando productos vivos, por lo que esta deuda crecerá y evolucionara de la misma manera que el producto, pero hay una seria de recomendaciones que podemos utilizar para minimizar el impacto en usuarios y negocio.
Clases de deuda de diseño.
Para trabajar un problema de manera positiva lo primero y más importante es identificarlo.
- Deuda intencional; la que sucede por propias limitaciones del proyecto; tiempo o dinero, falta de información para abordar la solución o por la naturaleza del método de ejecución del poyecto; agile, waterfall…
- Deuda no intencional; la que sucede debido a ****supuestos incorrectos o falta de información acerca de los usuarios, cambios en sus expectativas, cambio en el contexto de uso, necesidades o hábitos de consumo en el tiempo. Esta deuda crece exponencialmente con el tiempo debido a la propia evolución de nuestros usuarios.
¿Qué podemos hacer?
Hemos identificado 4 etapas de la vida de todo producto o servicio.
Nacen
Aunque teóricamente podamos lograr partir con 0 deuda de diseño en esta fase es cuando hay que establecer la reglas de juego para mitigar este impacto y la acumulación de la deuda.
- Estimar el esfuerzo de documentación, transferencia de conocimiento y demás tareas de mitigación como una tarea esencial más del proyecto.
- Construir la interfaz gráfica en base a un UI Kit o Design System.
- Definir una arquitectura de la información escalable desde el inicio.
- Diseña una buena estrategia de observabilidad al tiempo que diseñas el producto.
- Desarrollar el producto en **base a una estrategia clara de UX**. No evitará que aparezcan nuevas necesidades y oportunidades de mejora, pero tendrás una muy buena base.
Crecen
¿Cómo lo podemos hacer si el proyecto escapa de las manos de los diseñadores… o si evoluciona en funcionalidades o especificaciones que provienen de perfiles técnicos o de negocio? hay poco que hacer en este punto, sin embargo algo podemos hacer
- Documentar cambios no registrados cuando los detectemos en fases posteriores.
- Utilizar un potente gestor de versiones.
- Sé empático, nadie ha actuado con ánimo de cargarse tu trabajo.
- Revisa la documentación antes de hacer nada cuando trabajes en un evolutivo.
- Especial atención a las métricas; para tener datos objetivos de la evolución del uso del producto.
- Cuidar y mantener las incidencias de cada sprint, registrar y planear solucionar inmediatamente. No dejes acumular deuda al final de cada periodo de desarrollo.
Se reproducen.
O lanzamos una nueva versión al mercado.
- La documentación no empieza de 0. Traslada el conocimiento de la versión anterior a la nueva, e indicar la versión de la que hace referencia en la documentación.
- Anota ajustes o nuevos diseños y sobretodo el motivo.
Mueren
El producto termina su vida útil. Quizás esto es lo que tenga menos sentido, pero te lo explicaré con un ejemplo real.
“Tengo 3 cds con proyectos en freehand que ya nunca más voy a poder abrir 😪”
Asegúrate que siempre vas a poder recuperar ese diseño.
Unos Insights
¿Qué hará que aparezca o crezca esta deuda de diseño? ¿Qué hacemos?
Y finalmente muy importante, documentar, documentar lo implementado, y sobretodo esas ideas FLIPANTES que se nos han quedado en el backlog para más adelante.
