Diseñar es decir no

¿Por qué es tan difícil decir que no? Posiblemente sea porque decir que sí es demasiado fácil. Es rápido, cómodo y no te obliga a pensar ni a elegir. Evita enfrentamientos y es conveniente porque te hace quedar bien pero decir sí nos acaba saturando y condiciona nuestras prioridades y nuestras elecciones. Decir sí tiene un precio demasiado alto porque en la mayor parte de los casos te hace perder el control de tu vida.

Conseguiremos centrarnos en lo que realmente importa teniendo claras nuestras prioridades, tomando decisiones firmes y diciendo que no a muchísimas cosas.

Durante el proceso de diseño no saber decir que no puede tener consecuencias nefastas para lo que estás diseñando. Es necesario concentrarse y enfocar únicamente a lo importante. Qué es lo que vamos a diseñar y para qué sirve. Tenemos que apartar la maleza y encontrar la respuesta a esa pregunta porque muchas veces no será tan obvia como debería. Debemos concentrarnos en lo que realmente importa y lo importante suelen ser pocas cosas pero desde luego no lo lograremos si decimos que sí a absolutamente todo. Lo conseguiremos teniendo claras nuestras prioridades, tomando decisiones firmes y diciendo que no a muchísimas cosas.

A medida que el proyecto avanza y va teniendo más visibilidad entre stakeholders externos o internos es probable que vayan surgiendo ideas de funcionalidades para lo que estamos diseñando. Muchas veces van a ser buenas ideas, ideas que pueden llegar a ser muy útiles y con las que el usuario estaría encantado. Estas ideas pueden venir incluso de compañeros o personas que realmente consideres buenos diseñadores, pero da igual: vas a tener que decir que no. Pero no “en la siguiente fase” o “si se amplía el scope”. Responder con una negativa no tiene porque ser reflejo de una actitud negativa. Es importante decir no y es importante decir nunca.

Debemos tener claro qué es lo que no queremos conseguir con nuestro producto, qué no queremos que haga, para lo que no queremos que sirva.

Una de las cosas que va a definir el producto que estamos diseñando son aquellas cosas que rechazamos. Si sabemos cuál es el objetivo de lo que estamos construyendo es vital que nada nos haga perder el foco, por eso es importante asignar objetivos pero también es muy útil definir aquello que no es un objetivo. Es decir, debemos tener claro qué es lo que no queremos conseguir con nuestro producto, qué no queremos que haga, para lo que no queremos que sirva. Desde luego se nos ocurrirán miles de funcionalidades útiles pero párate a pensar si es necesario para lo que estás diseñando o simplemente es un adorno más.

Es demasiado fácil caer en el efecto árbol de Navidad añadiendo bolas simplemente porque son bonitas, porque nos conviene o porque nuestro cliente nos pide ponerlas. ¿Recordáis aquel reproductor de música que tantas alegrías nos dió llamado iTunes? Intentad definir qué es a día de hoy y veréis que es imposible. Un reproductor de música y una biblioteca donde puedes ver películas pero puedes comprar aplicaciones y también es una tienda donde a la vez puedes gestionar todos tus productos Apple. Es un reproductor que en su origen tuvo un objetivo claro pero que poco a poco fue parcheado con funcionalidades ajenas de tal manera que su crecimiento dejó de ser orgánico y se convirtió en una herramienta con sobrecarga de información y una inconsistencia fatal entre secciones y productos. Lo más curioso es que Steve Jobs dijo una vez que “People think focus means saying yes to the thing you’ve got to focus on. But that’s not what it means at all. It means saying no to the hundred other good ideas that there are. You have to pick carefully. I’m actually as proud of the things we haven’t done as the things I have done. Innovation is saying “no” to 1,000 things.

En la misma entrevista, Steve aboga por eliminar las partes innecesarias de una pieza de hardware, código innecesario, features de una aplicación, eliminar también productos superfluos de una oferta y palabras adicionales de una presentación. No es tarea fácil, se necesita coraje para excluir convenciones caducas profundamente ancladas en la mente del usuario pero los resultados pueden ser asombrosos.

iTunes es un claro ejemplo de exceso de propósitos en un producto pero no hace falta llegar a tal extremo, ya que diseñando a niveles mucho más bajos nos podemos encontrar con los mismos problemas. Nos tropezaremos con cientos de razones por las que decir que sí, estas son las que he encontrado más a menudo a lo largo de mi carrera:

. “En par de minutos lo tienes hecho”

Nunca hay cambios pequeños. Lo que parece un pequeño cambio sin importancia puede convertirse en un auténtico quebradero de cabeza sin que nos demos cuenta. Además, el scope de un proyecto o la sencillez de implementar no debería nunca ser una razón para incluir una funcionalidad en un diseño. Si decidimos añadir una funcionalidad al producto que estamos diseñando tiene que ser independiente de eso. Es cierto que en situaciones concretas hay que valorar si el esfuerzo vale la pena pero por norma general montones de malas ideas se pueden implementar rápidamente.

. “Démosle al usuario la libertad”

Es deber del diseñador comprender las necesidades del usuario y entender para qué sirve lo que está diseñando y cómo será usado. Crear funcionalidades opcionales significa trasladar al usuario decisiones que debería tomar el diseñador en su nombre y además genera serios problemas de confusión de interfaz y obliga a la configuración, aumentando la complejidad y la curva de aprendizaje. Otro factor relevante para desechar este argumento es que estas features van a ir diluyendo poco a poco el concepto de lo que estés diseñando.

. “Google lo tiene”

Si Google lo tiene, el usuario usará Google. Y quien dice Google dice Facebook, Whatsapp o Amazon. El usuario lo busca todo en Google y lo comparte todo en Facebook y es verdad que eso no es razón para dejar de diseñar cosas pero hay que tener mucho cuidado con qué queremos conseguir con ello. He visto demasiadas veces como un cliente pretendía competir con Google con proyectos de 16 semanas. Si la excusa del cliente para añadir una funcionalidad es querer competir con Google, cuanto antes rebajes las expectativas mejor será para todos

. “Ya que lo tenemos, aprovechémoslo”

Esto ocurre cuando un cliente o un departamento gasta muchos recursos en construir algo y nos vemos presionados a usarlo para justificar ese gasto. También es común pensar que cuántas más funcionalidades mejor, priorizando la cantidad a la necesidad, como si el diseño no fuese otra cosa que colmar al usuario de cosas qué poder hacer sin tener un objetivo claro. Si el usuario no lo necesita, descártalo, porque lo único que hará será generar ruido.

. “El usuario lo quiere”

No vamos a darle la razón a aquella afirmación tan añeja y caduca de que el usuario es tonto y no sabe lo que quiere ni pienso recordar la frase de los caballos de Ford pero es cierto que a veces el usuario, o incluso el mismo cliente, no tiene la capacidad de llegar a una conclusión válida sobre qué es lo que necesita. Una vez más, la pelota está en el tejado de los diseñadores. Debemos preguntar y escuchar y entender cuales son sus necesidades reales para poder encontrar soluciones a sus problemas. A veces será más sencillo y a veces más complicado pero aplicar soluciones a problemas sin indagar a fondo en ellos siempre será una mala idea. Hay que responder a lo que el usuario necesita, no a lo que dice que quiere.

Like what you read? Give Manel Abella a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.