Sin caer en la tentación de reinventar la rueda

Image for post
Image for post
Vista de la home de Universe después del rediseño. Imagen de Ideas4all Innovation

Como diseñadoras, sabemos que un proyecto de rediseño trae siempre consigo dos cosas muy opuestas: por un lado, la ilusión de darle un nuevo aspecto a algo ya existente y, por otro, la reticencia al cambio, ilustrada en esas expresiones demoledoras que le hundirían la moral al más pintado, del tipo “me gustaba más antes” o (peor todavía) “no noto la diferencia”.

Por eso, cuando me encargaron el rediseño del SaaS (Software as a Service) que ofrece Ideas4all Innovation, lo primero que pensé fue “Manolete, Manolete, si no sabes torear…”, pero después de un par de reuniones con el equipo técnico (y varios lorazepanes) me di cuenta de que era uno de los proyectos más retadores de mi vida y decidí coger el toro por los cuernos (sí, me ha dado por las expresiones taurinas).

“Manolete, Manolete, si no sabes torear…”

Para poneros un poco en contexto, este software de gestión de la innovación permite crear comunidades donde uno o varios de los colectivos de una empresa (como empleados, clientes o proveedores) pueden compartir sus ideas para cocrear nuevos productos, servicios o soluciones.

Cada vez que se crea una nueva cuenta se instala una instancia de dicho software, adaptando el branding al de la compañía y personalizando la configuración según el objetivo de uso.

Repensar el aspecto de un software en activo, con más de 7 años en el mercado, tiene una parte muy positiva y otra un poco menos. La buena noticia es que ya conoces a tus usuarias y puedes recoger datos de uso; la “menos buena”, es que suele tratarse de un producto un poco obsoleto, tanto a nivel tecnológico como de diseño.

Todo el equipo estaba de acuerdo con los objetivos principales: conseguir un código más limpio y refinar la interfaz para que resultara más moderna, limpia y amigable.

La gran decisión

Barajamos dos opciones: empezar de cero o ir realizando mejoras paulatinas. La primera propuesta daba un poco de vértigo pero traía consigo el atractivo de lo nuevo: ¿quién puede resistirse a crear un producto de la nada? La segunda nos ofrecía la posibilidad de ir progresando en cada subida a producción e ir sorprendiendo al público, pero planteaba el reto de cómo conseguirlo sin poner en riesgo la versión ya estable. Por otra parte, estaba el temido fantasma de la deuda técnica (léase con voz terrorífica) porque, siendo sincera, arremangarse y sacar la podadora de código no es un planazo para nadie.

¿Quién puede resistirse a crear un producto de la nada?

He de confesar que yo ya me estaba poniendo las gafas de buceo para tirarme a la piscina, seducida por el olor a juguete nuevo. Afortunadamente, la voz de la conciencia, esta vez en forma de CTO, supo esgrimir mejores argumentos y finalmente optamos por la segunda opción, dándole prioridad a la posibilidad de ofrecer una mejora lo antes posible (empezar de cero hubiera retrasado bastante la flamante salida a producción) y al hecho de poder reutilizar código que sí estaba funcionando correctamente.

Primeros pasos

Comenzamos dedicando varias horas a hacer responsive la aplicación (añadiendo Media Queries a las hojas de CSS ya existentes), a borrar código innecesario y a mejorar ciertos detalles de la interfaz que nos parecía urgente modificar. Esto nos daría unos meses de margen hasta la salida a producción de la primera versión de Universe, nombre con el que bautizamos a esta versión mejorada.

Image for post
Image for post
Imagen de Christopher Gower en Unsplash

A continuación, realizamos un exhaustivo estudio de las funcionalidades existentes y, posteriormente, un análisis de cuáles resultaban realmente útiles para el objetivo de la aplicación, que no era otro que la participación de las usuarias a través de la publicación de ideas. Para ello, consultamos los datos de uso cuantitativos de los que disponíamos (no muchos, a decir verdad; me temo que el Data Driven Design todavía no había llegado a nuestras vidas) y los cotejamos con los cualitativos, recogidos en entrevistas. También echamos un vistacillo a nuestro alrededor: ¿qué se cuece? ¿Qué lo está petando? Lo que comúnmente se suele llamar “estudio de la competencia”.

Una vez listadas las funcionalidades “ganadoras”, tocaba discutir el alcance del MVP (producto viable mínimo). Todas nos gustaban pero tuvimos que decidir cuáles eran realmente imprescindibles para el correcto funcionamiento del software y situarlas en la casilla de salida, por orden de prioridad. Esta parte del proceso suele costar mucho: hay que hacer un firme ejercicio de desapego y, sobre todo, recordar que, después de la salida a producción del MVP, vamos a seguir iterando sobre nuestro producto.

Os dejo el link a un interesante artículo sobre supuestos, hipótesis y MVP, por si os interesa seguir indagando en el tema.

Objetivo y decisiones de diseño

Era importante conseguir que la persona que visitara la home por primera vez pudiera saber, de un solo vistazo, de qué se trataba y qué acciones principales podía realizar.

Al tratarse de un software de innovación colectiva, nuestros esfuerzos se centraron en fomentar la participación: compartir ideas propias, leer propuestas ajenas, votarlas y/o comentarlas.

Queríamos una interfaz limpia y fácilmente escalable a futuro, por lo que nos planteamos un diseño basado en tarjetas o Card-Based Design que nos facilitara la labor de mantener la coherencia entre las diferentes páginas de la aplicación, ayudando a las usuarias a familiarizarse más rápidamente con los diferentes elementos.

El hecho de que este tipo de diseño funcione muy bien a la hora de moverse entre diferentes dispositivos móviles terminó de inclinar la balanza a su favor.

Image for post
Image for post
Ideas de una de las comunidades, mostradas en forma de tarjetas

Obviamente, este tipo de estructura no es la panacea ni va a funcionar en el 100% de los casos. Ainsley Fagerström nos explica estupendamente los pros y los contras en este artículo de recomendada lectura.

Con las manos en la masa

Preparamos una librería de componentes reutilizables para ayudar a mantener la coherencia durante todo el proceso de implementación y aligerar el trabajo de los desarrolladores (tanto Front como Back) facilitando, además, la consecución de un código más limpio.

Al trabajar con plazos apurados, decidimos preparar wireframes y trabajar sobre ellos a la hora de preparar las plantillas HTML que, posteriormente, el equipo de desarrollo convertiría en vistas de Ruby on rails.

Este método nos funcionó a la perfección por tres razones: nos brindó la posibilidad de iterar sobre los propios wireframes de una manera muy ágil, facilitó la posterior validación de los mismos con el resto del equipo y nos permitió empezar la fase de desarrollo una vez conseguido este consenso.

Image for post
Image for post
Wireframe presentado para la home de Universe

A la hora de escoger una herramienta de prototipado, dentro de la inmensa variedad que existe ahora mismo en el mercado, barajamos varias posibilidades y nos decantamos por Balsamiq principalmente porque permite trabajar muy rápido, elimina las tentaciones de añadir elementos visuales innecesarios y la curva de aprendizaje es muy baja, por lo que cualquier persona del equipo podría utilizarla si quería proponer algún cambio.

Si estás dudando sobre que herramienta de diseño de prototipos utilizar, te recomiendo leer esto.

Los mayores retos

El mayor reto para mí fue diseñar una estructura que funcionase bien para todas las cuentas y todos los casos de uso. Era la primera vez que me enfrentaba a algo semejante y, como suele suceder las primeras veces, me ilusionaba y asustaba a partes iguales.

Partíamos de la premisa de que, para nuestra potencial clientela, el hecho de poder acercar el estilo de la comunidad a su imagen de marca era algo muy importante. Nuestra gran duda era: ¿dónde colocar los límites de esta mimetización? ¡Que levante la mano quien haya diseñado una web y no se le haya asomado una lagrimilla al ver cómo le solicitan una gama de colores digna del Holi festival de la India!

Image for post
Image for post
Holi festival, India. Imagen de Alex Braga en Unsplash

Para decidirlo, nos hicimos una pregunta, la gran pregunta: ya sabíamos lo que querían pero ¿qué necesitaban? Fundamentalmente, mantener la coherencia con su imagen visual, evitar la sensación de estar en lugares muy distintos al navegar entre los diferentes sitios de la compañía. Lo resolvimos utilizando los elementos básicos de la identidad corporativa de la compañía: logotipo, gama cromática y fuentes tipográficas. KISS (Keep It Simple, Stupid) al rescate una vez más.

La gran pregunta: ¿qué necesitaban?

A nivel técnico, preparamos una hoja de variables Sass a modo de plantilla. Así, cuando teníamos que preparar los estilos de una nueva cuenta, sólo teníamos que duplicar y modificar esa hoja y el resultado era muy limpio. Sí, amigas, erradicar el CSS Important! es cosa de todas (chiste friki, si me permitís la licencia).

Image for post
Image for post
Una de las comunidades, ya personalizada con los estilos de la compañía. Imagen de Ideas4all Innovation

Por otra parte, no todas las cuentas tenían el mismo objetivo, ya que no es lo mismo una comunidad recién lanzada que una que lleva 7 años funcionando. Decidimos ofrecer tres opciones para hacer la home más funcional, según el caso de uso y el objetivo deseado: comunidad recién lanzada, comunidad basada en la consecución de ideas o comunidad centrada en llegar a un mayor número de usuarios.

Sumando estas dos capas de personalización, imagen corporativa y caso de uso, conseguimos que un solo producto lograra adaptarse a los requisitos de clientes muy diferentes entre sí: grandes grupos bancarios, aseguradoras, grupos hoteleros, empresas retail, instituciones de carácter social, ayuntamientos y universidades.

Reflexiones finales

Después de todo el camino andado, tengo que decir que estoy contenta con el resultado del proyecto porque logramos alcanzar los dos objetivos principales: una interfaz más limpia y mayor velocidad de carga (gracias a la reducción de funcionalidades y limpieza del código en desuso).

Y, sobretodo, porque al presentar el nuevo aspecto del software a nuestra clientela las reacciones fueron muy positivas; poca reticencia al cambio y mucha ilusión por empezar a utilizar lo nuevo.

Siguientes pasos

Pero el trabajo no terminó con la salida a producción. Ya sabéis lo que toca: iterar, iterar y después, seguir iterando.

La gran ventaja de formar parte de un equipo de producto (equipazo en este caso) es que no entregas un diseño y “si te he visto no me acuerdo”; tienes la oportunidad de seguir trabajando tanto para mejorar la calidad de lo entregado (testando, revisando los datos de uso y tomando decisiones al respecto) como para diseñar y desarrollar nuevas funcionalidades que aporten valor.

Image for post
Image for post
Gráfico resumen del proceso.

Por lo tanto, el reto de los meses posteriores fue revisar las funcionalidades que se habían quedado en cola y repriorizarlas para empezar a planificar las siguientes iteraciones.

Pero eso ya es otro capítulo, que contaré más adelante :)

Si te ha gustado mi historia puedes 👏 o compartirla (¡no te cortes!) para que llegue a más gente. Y si tienes algún comentario o pregunta, escríbeme, estaré encantada de responder.

Written by

Compartiendo experiencias acerca del noble arte de diseñar e implementar productos digitales. Cualquier parecido con la realidad es pura “retranca”.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store