Cómo dejar de diseñar cosas que no se realizarán

todos nos ha pasado:
Después de estar planeando, haciendo skecthes, teniendo tormentas de ideas, con tu product manager y unos cuantos ingenieros, estás impaciente por empezar tu nuevo diseño.

Pasas horas y horas diseñando, haciendo ajustes y creyendo de corazón “los usuarios amarán esto”…y entonces, tus diseños no van a ninguna parte.

Ese sentimiento es horrible, pero es parte de la vida de un diseñador. Sin embargo, les puedo sugerir un sistema para evitar que esto no suceda…o si sucede, que sea lo más indoloro posible.

Es llamado el método 40/40/20, y es ideal para equipos que se mueven rápidamente. Permite enfocarse en el ahora, mientras se mantiene el roadmap general en perspectiva, lo que te evita perder tiempo enfocándote en cosas que no se construirán.

Donde empezó el método 40/40/20

Como diseñadores, exploramos a fondo el requerimiento para comprender cómo se construirán. Sin embargo, en la práctica es común que un mismo diseñador esté trabajando simultáneamente en 2 o más proyectos con diferentes equipos, cada uno con su propia agenda frenética, por lo que mantener el ritmo de desarrollo y hacer esa concienzuda exploración puede ser todo un reto.

Lo más natural es que los diseñadores trabajemos con un método que está optimizado para mantener a los ingenieros ocupados sacando releases en tiempo, que a nosotros enfocarnos en las cosas más importantes, un método que tal vez sea algo como:

• Se habla de una necesidad.
• Se idea una versión ideal de ella
• El resto del equipo empieza a quitar funcionalidades una por una, hasta que solo queda lo básico.
• Se hace otra versión, que requiere más cambios, y cuando se muestran al siguiente grupo de personas involucradas, hacen más cambios, que pudieron haberse previsto desde la primera ronda.

“lo que parece una modificación sencilla, puede representar un montón de trabajo para alguien más”.

Para prevenir esto, lo primero que hay que hacer es pasar más tiempo con el equipo de back-end, para entender qué es lo que ya está listo, que puede realizarse con poco esfuerzo, y algunas cosas que requieren mucho esfuerzo para implementarse. (más sobre esto en mi siguiente entrada)

Con esto podemos reconocer que lo que parece una adición sencilla, puede representar un montón de trabajo para alguien más.

Cuando tengamos esa información aún podemos hacer un diseño ideal….pero dividido en tres entregas completamente diferentes:

40% Must Have: Son aspectos indispensables que se han pensado a fondo, están totalmente documentados y que el equipo de Back End está al tanto. Listo para ser implementado por Front End.

40% Nice to have. Funcionalidades que serían buenas pero no indispensables. Pueden representar un poco de trabajo extra para backend, ya está listo para ser documentado tan pronto los ingenieros lo estén.

20% Innovación: Aún falta por pensar algunos detalles, y podrían estar listos para implementarse con otras 2 a 4 hrs de trabajo de diseño. Probablemente requiera trabajo por parte de back end.

Hay dos motivos principales por los que esta técnica es útil:

• Nos enfocamos en el ahora, pero no perdemos visibilidad del mapa general.

Lo bello de diseñar modularmente, y diseñar primero únicamente lo indispensable es que se pueden empezar a hacer pruebas sobre este núcleo para tener la confianza de que nada serio fallará cuando ya se le haya invertido demasiado tiempo.

Sin embargo, tenemos claro los elementos que se incluirán en siguientes fases, ahorrando tiempo para diseño y desarrolladores.

• No gastamos tiempo en cosas que no construiremos:

Este es el beneficio más obvio es que no perderemos tiempo en el 60% restante hasta que los desarrolladores nos digan que están listo para hacerlos.

En la mayoría de los casos avanzamos hasta el siguiente 40% pero no siempre. Algunas veces logramos llegar hasta el último 20% si no se atraviesa nada importante. Pero si eso sucede, es fácil regresar, arreglar cualquier posible problema y regresar a la siguiente “cosa importante” en la que se haya estado trabajando.

¿Alguna otra ventaja?

Podemos trabajar en varias “cosas importantes” a la vez.

Esto usualmente es una gran ventaja, ya que los equipos de diseño UX tienden a ser pequeños, por lo que la velocidad es una ventaja. Este proceso nos permite trabajar tanto a diseño como a desarrollo en grandes aspectos del proyecto simultáneos, pero enfocándonos en un objetivo a la vez:

Otra ventaja es que respetamos nuestros periodos de atención, dividiendo nuestro día en periodos de 4 horas, dedicando un segmento (antes o después de comer, depende de uds) a las “cosas grandes” y el resto del día para “todo lo demás”

“Todo lo demás” usualmente es regresar al 60% de un proyecto previo y documentar para los otros equipos. Algunas veces significa empezar a planificar las siguientes “grandes cosas” con el PM para que las pueda empezar a planear. Lo que quiera que sea, es algo que necesita hacerse, pero no es lo más importante.

Según aumenta el tamaño de un equipo, es más importante desarrollar un proceso  para mantener no solo la productividad, sino la sanidad mental de todos. Y parte de mantener la sanidad mental consiste en no invertir demasiado de nuestro tiempo en cosas que nunca se harán.

Por último. Recuerden que todo proceso, toda organización, todo proyecto son seres vivos. Evolucionan, cambian, día a día. Este procedimiento seguramente podrá mejorarse, adaptarse para su caso, su empresa en particular, pero es un inicio que espero les sea útil.