Carmel Hassan UX & Product Designer

Rediseños: mejorando la herencia recibida

Diseñar la solución a problema de cero nos presenta un terreno lleno de posibilidades. Podemos poner en práctica las técnicas que queramos, probar, errar, mejorar, etc. Sin embargo hay veces que llegamos a un proyecto que ya tiene un producto en funcionamiento y que requiere urgentemente de mejoras de usabilidad.

En diseño, también existe deuda técnica, bien sea porque se toman malas decisiones, se deciden cosas que ‘ya se harán mejor luego’ o se cometen errores de diseño que implican problemas para nuestros usuarios. Como deuda técnica que es el tiempo que pasamos sin solucionarla no hace más que empeorar la situación, agravada incluso por el hecho de que la deuda técnica en diseño sí se ve.

¿Cómo podemos gestionar la deuda técnica?

Si tienes la suerte de que el equipo de producto ha identificado y priorizado la resolución de la deuda técnica aquí van unas cuántas cosas que plantearse.

Conoce las debilidades de tu producto

No todos los problemas de usabilidad son igual de graves o tienen el mismo impacto para tus usuarios. En cualquier caso debes tenerlos identificados mediante cualquier técnica de testing.

Sé realista en cuanto a la dimensión y el impacto, asigna un grado de severidad al problema y decide junto a tu equipo qué pasos deben darse para solucionar cada problema de forma individual y conjunta.

Estrategia

¿Evolución o revolución?

Si empiezas el nuevo producto desde cero pensado para resolver todos esos problemas y que éste no sea visible hasta el final corres el riesgo de introducir nuevas funcionalidades y que nada de esto esté siendo probado por los usuarios que de verdad ‘sufrirán’ el cambio.

Por otra lado, el diseño evolutivo e incremental de pequeñas partes de tu aplicación puede comenzar a generar inconsistencias, y esto es un cáncer del usabilidad.

La consistencia es uno de los principios fundamentales del diseño, la consistencia ayuda a crear un lenguaje de interacción entre el usuario y el producto y facilita su aprendizaje. Introducir inconsistencias ya sean derivadas por rediseños parciales como por un fallo en la identificación de un patrón o un estándar, crea disonancias y dificulta el uso. Volver a ‘homogeneizar’ las soluciones puede llegar a ser bastante más costoso conforme se acumulan dichas inconsistencias.

Entonces ¿qué estrategia seguir? La estrategia depende del primer punto. Si tu producto sufre de inconsistencias o sufre de falta de personalidad, de que el lenguaje no es claro, de que hay ciertas funcionalidades que no se usan, las estrategias a seguir pueden ser muy diferentes.

Mi propuesta sería la siguiente (algo conservadora pero nada pasiva):

  • Una vez identificados y clasificados los problemas de usabilidad de tu aplicación según severidad e impacto, crea dos grupos en base al coste de la solución: baratos (bajo impacto pero fáciles de solucionar y de decidir sobre ellos) y caros (requieren tiempo, validación de conceptos y refactorizaciones de código)
  • Incluye soluciones baratas de forma constante en ciclo de desarrollo. Aunque luego un cambio futuro lo arregle todo o cambie de nuevo. No hagas sufrir más a tus usuarios más tiempo. La tipografía no funciona, cámbiala, no se muestran cosas alineadas, corrígelo. Demuestra a tus usuarios que el producto está vivo y con ganas de mejorar.
  • Lanza los cambios revolucionarios y costosos manteniendo lo que hay. Dirige a tus usuarios hacia tus nuevos diseños y mide el impacto que tienen ¿funcionan mejor? ¿tienen adopción? ¿dónde los abandonan? Esto te ayudará a decidir sobre el siguiente gran cambio y el éxito real de tu rediseño, aunque exista cierta disonancia los usuarios pueden entender mejor que existe una intención de cambio de su producto sin que le desarmes la casa de un día para otro.
  • No asocies el re-diseño sólo a nuevas funcionalidades. No hagas que tus usuarios de siempre piensen que no les importas. No crees dos identidades diferentes que puedan parecer productos diferentes.
  • Cambios de fuera hacia adentro. Esta discusión la he tenido muchas veces y aún no encuentro razones para hacerlo de otra manera. Si el layout o la navegación de tu aplicación es un problema, creo que es fundamental empezar por aquí e ir poco a poco entrando en el detalle del contenido de cada página o sección. Lo peor que puede pasar es que el rediseño de una sección no pueda ser accesible o encontrable, o que la sensación de pérdida sea igual que en el resto. Por otra parte los cambios estructurales pueden ayudar también a la resolución de deuda técnica en desarrollo.

Y recuerda, ignorar la deuda de UX afecta, entre otras cosas, a la confiabilidad del del producto. Da igual de quién recibiste la herencia, siempre que te incorpores a un equipo de diseño, la deuda hay que saber gestionarla.

I’m UX/Product Designer at Ebury. I have a chaotic side project called Cinefilica and founded the most interesting tech community in Málaga: Yes We Tech. I enjoy writing random thoughts on UX, Design, Technology and Society.

Add comment

Deja un comentario

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.

Carmel Hassan UX & Product Designer

Categorías

¡Suscríbete!

Introduce tu correo electrónico para suscribirte a este blog y recibir notificaciones de nuevas historias.

Entradas recientes

Comentarios recientes