Diseñar para la transición
No es lo mismo crear algo desde cero que innovar cuando lo que tienes algo que ya está online. Cuando eres una start-up y creas algo nuevo, tu base de datos está limpia y la interfaz la puedes adaptar de una forma mucho más flexible y dinámica. Si ya tienes algo funcionando desde hace tiempo la cosa se complica; tu base de datos adquiere un conjunto de limitaciones y cada paso hay que pensarlo casi el doble. Crear nuevas funcionalidades exige un trabajo adicional por el que es necesario pasar.
¿Por qué pensar en la transición?
Porque ponerse en la piel de algo que sucederá a largo plazo y no considerar lo que sucederá a medio plazo deja un hueco importante en lo que defines. Si tienes alguna funcionalidad para enriquecer tu interfaz, es necesario pensar en lo que sucederá en el mismo momento que cambies cualquier detalle (medio plazo) y, por otro lado, visualizar qué sucederá cuando todo esté funcionando como realmente quieres que sea todo (largo plazo).
Doble trabajo/Mitad de preocupaciones.
No tener en cuenta el diseño de transición te obligará a tener que estar readaptando constantemente el prototipo que quieres implementar a largo plazo: “Esto será así más adelante, pero de momento no. Te pinto esta sección y te la paso, lo demás todo igual” – conversación muy típica en estas situaciones – . Aunque sea necesario ir un poco más allá en tus wireframes merece la pena el esfuerzo.
En idealista.com hemos aprendido mucho de este tipo de situaciones. La última nos ocurrió cuando introducimos el aumento de tamaño y aceptamos diferentes formatos (apaisado y a lo largo) en las fotos de los anuncios. Nos dimos cuenta de que las fotos que existían antes de implementar dicho cambio tenían un tamaño cuadrado fijo (300x300px) y que lo que queríamos implementar tendría que convivir con lo que ya existía durante un buen tiempo, hasta que el formato cuadrado caducase. El wireframe definido a largo plazo era genial, pero ¿cómo convivirían ambos formatos? El ejercicio de pensar en esa convivencia nos vino muy bien para desarrollos a posteriori.
Cualquier detalle mal implementado puede dar al traste con la fidelidad de muchos usuarios. Es necesario que definas bien la transición para evitar frustaciones o abandonos. También es importante no realizar cambios radicales que impliquen reaprender lo que ya aprendieron tus usuarios más fieles. Un cambio de transición hace que poco a poco los usuarios más avanzados se vayan acostumbrando, evitando menos frustraciones.
