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

Escrito por Elyse Bogacz de Drift y publicado originalmente como un artículo invitado en el blog de InVision

Después de sentarse y poner las cosas en la pizarra con su gerente de producto y algunos ingenieros, no puede esperar para comenzar a trabajar en un nuevo diseño.

Pasas horas diseñando y ajustando y creyendo de todo corazón "¡A los usuarios les encantará esto!"

Y luego tus diseños nunca llegan a ningún lado.

Esa sensación apesta, pero también es parte del juego. Es la vida de un diseñador. Pero a lo largo de mi tiempo en RunKeeper y ahora en Drift, he desarrollado un sistema para ayudar a asegurar que esto no suceda, y para suavizar el golpe cuando lo haga.

Lo llamo el método 40/40/20, y es ideal para equipos de rápido movimiento. Te permite concentrarte en el ahora sin dejar de mirar el camino por delante, lo que evita que pierdas el tiempo en cosas que nunca se construirán.

Comencé a hacer las cosas de esta manera porque he experimentado el escenario descrito anteriormente muchas veces: es difícil dejar todo su arduo trabajo en el piso de la sala de ingeniería.

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

Como diseñador, quiero explorar las cosas completamente y comprender cómo las cosas se construirán unas sobre otras con el tiempo. Agregue algunos momentos “encantadores” para que los usuarios se encuentren.

Pero como diseñador solitario que atiende a 2 equipos de productos, eso no siempre es factible. Sí, mis diseños deben ser considerados, pero también necesito trabajar a un ritmo que mantenga en movimiento a 6 ingenieros de alto rendimiento.

Antes de comenzar a usar el método 40/40/20, tenía un proceso que estaba (sin saberlo) más optimizado para mantener ocupados a nuestros ingenieros en lugar de permitirnos abordar rápidamente lo más importante.

Nuestro equipo hablaría sobre una idea, y yo me iría a diseñar la versión ideal de la misma. Luego, cuando se lo mostré a mi equipo, quitábamos las cosas una por una hasta que lo único que quedaba era un diseño que pudiera armar en una hora.

Gorrón.

Esto me dejó luchando constantemente: saltando de un lado a otro entre los equipos, tratando de no bloquear a nadie y nunca realmente avanzando. Necesitaba cambiar mi proceso.

"Lo que se siente como una adición trivial para ti podría ser un montón de trabajo para otra persona".

Lo primero que comencé a hacer fue pasar más tiempo con nuestro equipo de back-end para poder entender qué puntos finales teníamos a nuestra disposición, qué cosas podríamos hacer con un poco de trabajo y qué cosas requerirían mucho trabajo para implementar .

Necesitaba reconocer que lo que se siente como una adición trivial para mí, es probablemente una pila de trabajo para otra persona.

Después de tener toda esa información, todavía diseñaría el ideal ... pero desglosé el archivo de manera completamente diferente en 3 partes que se pueden enviar:

  • 40% - MVP. El mayor impacto imprescindible. Pensado completamente, documentado completamente, back-end en su lugar, listo para ser pasado al front-end para su implementación.
  • 40% - V2. Los buenos para tener. Sobre todo pensado. Podría necesitar un poco de trabajo de fondo. Listo para ser documentado cuando la ingeniería esté lista para ello.
  • 20% - Innovación. Una especie de pensamiento a través. Podría estar listo para la implementación con otras 2 a 4 horas de trabajo de diseño. Probablemente requiere algo de tiempo de back-end.

Aquí hay un ejemplo real con un reciente rediseño de conversación que implementamos y cómo lo separamos:

Combinar y diseñar cosas de esta manera ha funcionado de maravilla por un par de razones:

Solo me estoy centrando en el "ahora", pero puedo ver el camino por delante.
 Lo bueno de diseñar parcialmente esos dos últimos cubos es que puedo hacer una prueba de esfuerzo de un diseño y tener la confianza de que no se romperá sin pasar demasiado tiempo. Considerar cómo se escalarán las cosas me ayuda a evitar diseñarnos en una esquina, y nos ahorra mucho tiempo de ingeniería a largo plazo.

"Considere cómo se escalarán las cosas y evite diseñar a su equipo en una esquina".

No estoy perdiendo el tiempo en cosas que no vamos a construir.
 El beneficio más obvio es que no pasaré ningún tiempo extra en ese último 60% a menos que la ingeniería me diga que vamos a estar listos para ello. Por lo general, superamos el segundo 40%, pero no siempre. A veces llegamos a ese último 20%, si no tenemos nada más importante. En esos momentos, es fácil para mí saltar hacia atrás, atar los cabos sueltos y volver a la siguiente "gran cosa" en la que estaba trabajando.

La otra gran ventaja de esto?

Puedo trabajar en múltiples "grandes cosas" a la vez.
 Este último es enorme porque, como equipo pequeño, la velocidad es nuestra ventaja. Este proceso me permite trabajar en cosas importantes para ambos equipos entrelazados entre sí, pero la naturaleza de la inversión me ayuda a mantener la concentración en un hito a la vez. Y eso me permite entregar un trabajo más reflexivo a mis dos equipos.

Aquí hay un ejemplo reciente de este proceso en Drift:

La otra cosa que me gusta de este proceso es que respeta los límites de mi capacidad de atención. Soy más productivo antes del almuerzo, así que trato de dividir mi día en bloques de 4 horas. Por la mañana trabajo en mi "gran cosa" y por la tarde presto atención a "todo lo demás".

"Todo lo demás" generalmente significa volver al último 60% en un proyecto anterior y documentar unos días más de trabajo para ese otro equipo. A veces, significa "hacer algo importante" en la pizarra blanca con mi primer ministro para que pueda comenzar a planificar. Sea lo que sea, es algo que debe hacerse, pero no es lo más importante.

A medida que nuestro equipo crece, desarrollar un proceso ha sido cada vez más importante no solo para mi productividad, sino también para mi cordura. Y mantenerse cuerdo significa saber que no estoy desperdiciando gran parte de mi tiempo en exploraciones infructuosas.

Sé que este proceso tendrá que adaptarse continuamente y satisfacer las necesidades siempre cambiantes del equipo. Pero en este momento, está funcionando.

Autor: Elyse Bogacz
Nerdy para startups, diseño y todo lo creativo. Diseño Senior @Drift. Anteriormente @RunKeeper.
Sigueme en Twitter

Publicado originalmente en blog.invisionapp.com el 27 de septiembre de 2016.