0

Devs y el eterno problema de las “soluciones de informático”

En el mundo startup, no siempre, al menos en los inicios, puede que no tengas un equipo dedicado a la usabilidad de forma pro, pero eso no quiere decir que seas “feliz desplegando caca” pensando que todo el mundo va a entender lo que lanzas al mercado, es un enorme, repetitivo y craso error de muchísmos desarrolladores/programadores (el ego de muchos hace que se incomoden si se les llama lo segundo) que son partidarios del function over form a cualquier precio.

La mejor forma de crear un software es que tú mismo seas un usuario real
Alfonso Gutiérrez

Es cierto que hay que diseñar para la funcionalidad, no para el usuario necesariamente, pero por lo mismo es de vital interés que seas tú mismo quien pruebe lo que estás haciendo, te pongas desde el punto de vista de tu usuario y te des cuenta que no todo el mundo es capaz de cumplir con éxito las tareas que para tí son simples, o lo que yo llamo “solución de informático”, el post de Alfonsogu da una perfecta explicación a lo que en esta breve entrada comento. Cuando puedas permitirte un crack en UX, no dudes en integrarlo al equipo, pero de momento, sigue los consejos que en el post de referencia nos comentan.

En teoría, no hay diferencia entre teoría y práctica. Pero en la práctica si que la hay.
Alfonso Gutiérrez

Cito otro muy buen post del mismo autor que dice:
“Como programadores trabajamos en solucionar problemas complejos pero no estamos educados para pensar en los interfaces que los van a solucionar. El diseño de software no se valora, se piensa que un formulario vale lo mismo que otro, puedes pasar horas con un proceso, una función, un algoritmo pero tiramos los campos en un formulario sin pensar en el usuario que los va a realizar.”

En alguna startup donde trabajé, no se daba ni una situación ni la otra, en algún momento el CEO era el user tester, con lo que los resultados eran fails monumentales por la contaminación con la herramienta a la que estaba sujeto; me costó muchísimo cambiar la mentalidad desde dentro de la organización pasando por una primera etapa de darle poca importancia a la labor de la usabilidad y tests a un profundo respeto posterior. El entorno era básicamente de programadores que jamás habían escuchado nada que tenga que ver con usuarios, parecía la oficina en ese momento una copia de Dilbert!, pero bueno, hacer test con usuarios siempre es posible aunque seas un teki irredento, Alfonso también nos propone este post de Velneo V7 súper interesante que recomiendo revisar y le cito:
¿Cuando realizar un test?
Aquí la respuesta siempre es “cuanto antes mejor!!”, y esto es debido a que cuanto más avanzado esté el desarrollo más costosos se hace realizar cambios de diseño (y de todo tipo en general).
En el gráfico podéis ver cómo el coste de realizar cambios durante el periodo de desarrollo se multiplica x6 y si los cambios se realizan después del lanzamiento x100!!.
La clave aquí es testar prototipos, incluso de bocetos papel denominados sketching (se puede aunque parezca mentira) antes incluso de tocar una línea de código.

Fatal error: Uncaught Exception: 12: REST API is deprecated for versions v2.1 and higher (12) thrown in /web/htdocs/www.uxinperu.com/home/wp-content/plugins/seo-facebook-comments/facebook/base_facebook.php on line 1273