Diseño por unanimidad

Internet es, de alguna manera, territorio inexplorado. Tenemos muy pocos años de experiencia si nos comparamos, por ejemplo, con otras disciplinas como la arquitectura, que lleva miles de años junto a nosotros.

Probablemente es eso lo que resulta tan atractivo de los proyectos en la red: tenemos espacio para la imaginación, para crear,  para desarrollar nuevos servicios y para buscar nuevas maneras de hacer las cosas.

Pero también es cierto que cuando te enfrentas a un desarrollo web, esa misma posibilidad de crear e innovar puede convertirse en uno de los mayores problemas del proyecto.

Generalmente empezamos cada nuevo proyecto muy ilusionados con todas las ideas que queremos añadir a nuestra web. Pero la experiencia nos ha enseñado algunas lecciones que no deberíamos pasar por alto:

• Muchas de las funcionalidades contempladas por un proyecto no siguen allí pasados pocos meses.
• Cuantas más funcionalidades tiene un proyecto, más tardamos en acabarlo y más tiempo en salir al mercado.
• El principio de Pareto está también presente en el uso de las aplicaciones, y más en el caso específico de la web: el 80% de los usuarios usa solo el 20% de las funcionalidades disponibles.

No fue hasta principios del siglo pasado cuando la arquitectura, de la mano de Mies van der Rohe, empezó a hablar de “menos es más“. Y nosotros estamos convencidos de que, efectivamente, es así.

Barry Schwartz lo explica maravillosamente en su libro La paradoja de la elección. El libro Getting Real es sin duda otra lectura recomendable para los que quieren entender por qué “menos es más”.

El problema se plantea cuando debemos elegir entre la enorme lista de cosas que queremos hacer.

De todas las cosas que hemos pensado añadir a la aplicación, ¿cuáles vamos a dejar fuera o para una segunda fase del proyecto?

Dicho en otras palabras:

¿Cómo elegir entre un montón de funcionalidad cuando estás diseñando una aplicación web?

Nosotros lo hemos resuelto acudiendo a la unanimidad.

Cuando estamos diseñando una aplicación proponemos que la decisión sobre la inclusión o no de una funcionalidad se tome por unanimidad. Es decir, basta con que  uno de los miembros del equipo no crea que una funcionalidad deba estar presente para que ésta quede fuera.

El resultado de este proceso es que el producto desarrollado contiene “sólo aquello que todos los miembros del equipo creen que debe estar”, en lugar de “todo lo que alguien del equipo piensa que debería estar presente”.

Necesariamente, las aplicaciones desarrolladas de esta manera:

• son más sencillas y, por tanto, más fáciles de usar, explicar, documentar, etc.
• son más baratas de desarrollar, puesto que hay menos funcionalidad
• son más fáciles de mantener cuando es necesario hacer cambios
• si surgen problemas, son más fáciles de resolver (hay menos líneas de código, por lo tanto, hay menos lugares en los que el error puede esconderse)

Pero lo más importante de todo es que, al ser las aplicaciones más sencillas, podemos ponerlas en el mercado mucho antes, y tenemos la oportunidad de probar con la realidad de nuestros usuarios. A partir de ese punto podemos empezar a desarrollar con datos y feedback reales, y no con previsiones o estimaciones. Podemos mejorar guiados por lo que los usuarios realmente nos piden o utilizan.

Prueba. Puede sonar un poco extraño, pero nuestra experiencia nos ha demostrado que el concepto “menos es más” es una práctica excelente para el desarrollo web.