Durante los últimos años, aquellas personas que de una u otra manera interactuamos con tecnología, hemos visto el crecimiento y desarrollo casi imparable de la Industria del Software. Casi diariamente vemos el nacimiento de un nuevo framework de desarrollo, de un nuevo lenguaje, de una nueva técnica que promete invalidar todo lo anterior.
Las cosas han cambiado. Cada creación nueva nos da mayor facilidad para crear a su vez nuevas aplicaciones, nos quita las restricciones del pasado, nos brinda mayor libertad de disponer. Y aún así, cada día seguimos viendo como aplicaciones como ésta se siguen creando:
Las cosas han cambiado ciertamente, pero muchos siguen pensando aún que diseñar una interfaz se reduce a instalar una nueva caja de controles y lanzarlos a diestra y siniestra en los formularios; que los usuarios disfrutan pasar varias horas de su día haciendo click en varios botones, listas de selección y tabs, y que si la interfaz es gris (muy, muy gris) están aplicando buenas prácticas de software y éste será visto con beneplácito por los inversionistas o la alta gerencia.
“Pero yo no soy diseñador”
Una de las respuestas más comunes que recibo cuando converso de éste tema con conocidos es casi siempre “Pero.. ¡yo no soy diseñador!”. Craso error. Se ha extendido la errónea idea que diseñar es embellecer algo. Un tema que debe ser aplicado “si sobra tiempo y presupuesto” y que su ignorancia es el argumento al que nos escudamos siempre. Pero la sencilla verdad es que no lo es.
Una leída rápida a Wikipedia nos otorga la siguiente definición:
“[...] ‘diseñar’ se refiere al proceso de creación y desarrollo para producir un nuevo objeto o medio de comunicación (objeto, proceso, servicio, conocimiento o entorno) para uso humano.”
Notablemente, podemos leer que en ninguna parte obtenemos una orientación hacia la parte estética [1]. Estamos hablando de una disciplina que se aplica desde la creación y planeamiento y durante todo su desarrollo, orientada a un fin único: dotarle de características para el uso humano. No buscamos que se vea mejor (lo cual no está mal, ciertamente), o que tenga música detrás o que los controles brillen mientras los enfocamos con el cursor. Se busca que lo que hemos creado sea utilizado por humanos (al menos hasta que encontremos otras razas en el universo).
“The applications that are easy to use are designed to be familiar”
¿Cómo entonces puedo llegar a diseñar mejores interfaces?
El primer paso que debemos tener en cuenta es que No necesitamos tener una educación formal en Diseño Gráfico para poder diseñar. Lo hacemos diariamente. Lo hacemos cuando ordenamos nuestras cosas en nuestra maleta, cuando ordenamos las carpetas que utilizamos en el trabajo, cuando componemos un Currículum Vitae o simplemente cuando posicionamos el pan al lado de nuestra taza al desayunar.
Lo necesario es entender dónde fallamos y dónde podemos mejorar y utilizar esa información, más algo de sentido común, como nuevas armas a tener en cuenta.
Existen tres puntos principales, en mi opinión, donde podemos encontrar los errores más comunes:
No orientarse al dominio del problema
Es probablemente uno de los dolores de cabeza más comunes para los usuarios. Poseen un término específico en su negocio que utilizan diariamente. Lo conocen sus proveedores, lo conocen sus clientes. Pero cada vez que tienen que realizar una registro o utilizar el sistema que alguien les desarrolló, se ven obligados a utilizar terminologías externas a su día a día.
Una de las principales labores que tenemos que tener en cuenta es definir con los usuarios qué terminos utilizan, que simbología es apropiada, qué colores y formas aplican. Debemos recordar que es finalmente el cliente el que utilizará nuestra aplicación y que debe estar definida en sus términos y de su flujo de trabajo.
Olvidar el público objetivo
Olvidarnos de quien es el finalmente usará nuestra interfaz puede ser un tema peligroso. He visto muchas aplicaciones que funcionaban correctamente pero que nadie nunca usaba.
Definir qué tener en cuenta y cómo sobre cada tipo de usuarios requería muchas líneas y saldría un poco del tema original de este artículo, pero creo que es importante mencionar al menos qué características tener en cuenta:
- Edad. Es distinto diseñar una interfaz a ser utilizada por un niño de 12 años (aquellos que te recompilan un Kernel de Linux y exponen en Google antes del desayuno) que de un trabajador de 40 y una a ser utilizada por un adulto mayor. Lo más sencillo en este caso es realizar pruebas de usuario con aquellos que compartan esas características, revisar aplicaciones similares y conversar con los usuarios.
- Profesión/Educación. Cada profesión tiene palabras propias, simbologías, formas de aprender y trabajar, y una buena interfaz debe reflejar aquello. Será distinta la interfaz de un programa de recetas de cocina que la de un aplicativo para programar en LISP y debemos diferenciar el flujo de trabajo distinto y adaptarnos a éste.
- Grado de Familiaridad con Tecnología. Algunos de mis clientes no habían utilizado mucho las computadoras, pero la gerencia les imponía utilizar el sistema que estábamos desarrollando. Adaptarnos a sus necesidades, realizando interfaces usables y sencillas, sin muchos “sofisticaciones” modernas, permitió que la barrera de entrada disminuyera y la curva de aprendizaje fuera menor también.
Tal como mencioné anteriormente, reunirse con el público objetivo es importante para entender su nivel de envolvimiento y experiencia, así como entender como poder adaptarnos y construir la interfaz a su alrededor.
- Discapacidades. En la medida de lo posible, debemos tratar de incorporar medidas que aseguren la accesibilidad de las interfaces. No debemos discriminar y dificultar el uso de éstas.
Orientarse a las características
Tal vez uno de los principales problemas en los aplicaciones modernas sea una enfermedad conocida como Featuritis o Feature Creep (del término Feature, Característica, en inglés).
La Featuritis se puede definir como la presencia de características inútiles para la funcionalidad principal del aplicativo. Normalmente podemos ver como aparece cuando nuestra aplicación es Diseñada por Comité y no bajo una dirección única.
Se puede observar también que suele aparecer cuando la decisión de qué característica y cualidades implementar no se basa en el problema que tratamos de solucionar, si no en aquello que ha implementado la competencia, copiando función tras función y agregando a esa lista más, con el erróneo pensamiento que Más es mejor y que mientras más brindemos, mejor seremos percibidos por nuestros usuarios.
En Marketing Myths Exploded: What Your Customers Don’t Want encontramos el siguiente pensamiento:
Customers want more technology. This is coming after the demise of several dotcom companies and the plunging stock market in high tech in 2000. 1999 was a great year to invest in technology. 2000 brought about an interesting concept called reality! Customers don’t care about the gizmos and gadgets as much as they do about finding a solution to real problems. Be aware of these high-tech companies and market accordingly.(énfasis agregado por mí)
Orientarnos a la solución y a las características nos hace perder perspectiva de lo que queremos lograr y nos puede llevar a una situación donde cada nueva aplicación trate de imitar lo que hace el resto sin deternos a pensar si esa acaso aquella la mejor solución.
Orientarnos a los usuarios nos permite pensar realmente qué es lo que quiere hacer éste, pensar no en mejorar el diseño de los formularios de la aplicación, si no en cuestionar si usar formularios es la mejor opción.
Entendiendo al usuario
- encontrar un dato hecho o información
- aprender sobre algo
- realizar una transacción
- controlar o monitorear un proceso
- crear o modificar algo
- conversar con otras personas
- ser entretenido
Y eso es, finalmente, lo que la interfaz debería apoyar. No hablar de si usar AJAX o Flash. No pensar en si usar tabs o mejor ese plugin de jQuery que hemos encontrado. No pensar en qué controles utilizar para que el usuario se registre o realice una tarea, si no, ¿estamos ayudando a que haga lo que originalmente quiere hacer?
Algunos consejos finales
Entendiendo mejor ahora cuál debe ser nuestra preocupación, podemos plantearnos algunas soluciones prácticas para mejorar nuestras interfaces:
- Leer, revisar y utilizar las recomendaciones de interfaces existentes como las Macintosh Human Interface Guidelines o el Windows Style Guide). Han sido redactados por los equipos internos de cada una de esas empresas y normalmente son buenos textos a seguir en cuenta.
- Así como existen patrones de diseño de software, también podemos revisar aquellos que existen para el manejo de interfaces. En Designing Interfaces podemos encontrar patrones para organización de contenido, navegación, acciones y comandos, formularios y más.
- Una de las prácticas más importantes para probar una interfaz que suelo encontrar es revisar detenidamente lo que estamos haciendo y preguntarnos, ¿es absolutamente (100%) necesaria éste control o funcionalidad? Si la respuesta es negativa, suelo eliminarla. He encontrado que en la mayoría de los casos, la interfaz se volvió mucho más limpia e intuitiva. Y en caso contrario, al menos nos permitirá repensar los elementos y diseño que estamos utilizando.
- Probar si nuestra interfaz funciona bien si desactivamos elementos adicionales como Javascript, Hojas de Estilo y Flash. No tiene que verse igual (no tiene que verse bien, realmente) pero si mantiene su funcionalidad y usabilidad, y se pueden realizar las tareas correctamente, es prueba que vamos por buen camino.
- Orientarnos al mínimo común denominador de los usuarios permitirá que podamos tener interfaces sencillas y sin complejidad innecesaria. Nos permitirá evaluar también qué tipo de funcionalidad y controles ocultar en paneles de “Opciones Avanzadas” o similares.
- No compliquemos el lenguaje con opciones arcanas y difíciles de entender. Debemos mantener una lista de vocabulario a utilizar relacionado con el tipo de usuario que tendremos y su entorno.
- Realizar prototipos, probarlos, corregir y repetir. Las pruebas de usuario deben hacerse a lo largo del periodo de desarrollo y no al final, cuando el costo de mejorar o corregir las interfaces es mucho más alto y a veces, prohibitivo.
Y la regla de oro a tener en cuenta:
Disponer menos tiempo pensando cómo usar la interfaz y más usándola. Los mejores proyectos y las mejores interfaces nacen de quienes son los principales usuarios. Puede ser complicado dependiendo del tema, pero es una responsabilidad que debemos tener.
