ux: reflexionando más allá de la interfaz

En los últimos años el diseño de las interfaces de usuario han evolucionado mucho. Se ha pasado de desarrollar aplicaciones para las cuales hacía falta un master para aprender su uso, sin lógica (visual) ninguna, etc. Esto tiene lógica, el programador no tiene porqué saber de diseño, no es un diseñador. Por lo tanto lo que pueda salir de las manos de éste no será nunca algo ergonómico, ni visualmente atractivo.


Antes de que nadie se ofenda, quiero decir que siempre hay excepciones y todo dependé de qué aplicaciones estemos hablando, porque para una aplicación de consola no necesitaremos ningún diseño..


En las antguas aplicaciones se incluía todo en la ventana principal, reservando cada región de la pantalla para una funcionalidad especifica de la aplicación. ¿Esto era óptimo? Yo creo que no, y la historia lo confirma. La tendencia entonces fue a separar todas esas funcionalidades, teniendo la funcionalidad principal en la ventana principal y en unas “ventanas-popup” características extra. Pero éste modelo también tiene sus inconvenientes y es la pérdida del contexto. Cuando tu pides una funcionalidad extra y te sale una de estas “ventanas-popup” tu no sabes a que parte de la aplicación está afectando esto, de tal forma que sufrimos una perdida de contexto que genera frustración en el usuario.


Como podéis observar el encargado del diseño de una aplicación no solo debe saber de diseño gráfico, sino también de psicología. Ahora bien, la pregunta es, ¿debe de haber un rol específico de diseñador de interfaces de usuario? Yo creo que no, y bien, el motivo es que considero la programación como un proceso creativo en el que tu mente no solo debe conseguir abstrarse lógicamente sino saber llevarlo al campo visual.


El usuario no va a interactuar con el acceso a datos, ni la lógica de negocio, va a interactua con la interfaz de usuario, por ello el programador debe de tener los conocimientos necesarios para poder construír una interfaz rica visualmente, ergnonómica y con un flujo de ejecución lógico para evitar la frustración y el agotamiento.


Si nosotros desarrollamos una aplicación con una ergonomía pobre y con unas carencias en cuanto a diseño y lógica en su flujo, el usuario no sabrá que hacer, se pondrá nervioso, buscará la forma de hacer las cosas, se equivocará, se frustrará, continuará buscando y terminará estresado tras haberse peleado con la aplicación para aprender a usar la aplicación. Poniendo en juego no solo la salud psicológica del usuario sino también su tiempo, uno de los bienes más escasos y que más necesitamos.


Un ejemplo de buen diseño son los asistentes tipo “siguiente, siguiente, finalizar”. Mucho han sido criticados, pero realmente es un ejemplo que cabe destacar. La mayor parte de los usuarios están familiarizados con ellos, saben que el siguiente paso se llega al pulsar el botón siguiente, hasta que se encuentre con el de Finalizar o Cerrar. No digo, para nada, que sean la panacea, de hecho considero que su diseño se encuentra incluso antiguado para los medios actuales. Ahora bien, los diseñadores deben ponerse las pilas para crear algunas buenas prácticas a la hora de diseñar aplicaciones ágiles y ergonómicas.


Para ello algunas cosas a pensar en un nuevo diseño son:




  • Simplicidad de la aplicación


  • Destacar cual es el siguiente paso, o destacar el área de trabajo principal llamando la atención del usuario


  • La aplicación debe inspirar familiaridad o cercanía con el usuario para mejorar la autoestíma del usuario


  • Trucos, o ayudas integradas en la aplicación, métodos de busqueda en la ayuda con lenguaje natural (humano) en el contexto de la aplicación


  • Los extras en su contexto


  • Personalización de la aplicación al gusto del usuario: colores, temas, etc.

Un ejemplo de buena parte de estos puntos es Office (y más con su versión 2007, que cuenta con una excelente interfaz): simplicidad, contexto, familiaridad, personalización, ayuda, etc.


Solo con estos pasos podremos realiazar unas mejores interfaces. Por otra parte, si cuidamos los colores a usar y los iconos. Que por cierto los iconos deben incluír siempre una descripción, ya que para lo que para ti es guardar o proteger para otra persona bien puede ser cualquier otra cosa inesperada. Hay que intentar mejorar la fluidez de la aplicación, evitar malos refrescos, las interfaces colgadas a base de cargar datos, etc. Si se necesitan cargar datos se cargan en el splash de la aplicación, si es necesario crear unos controles o llenarles los datos obtenidos lo mismo, en el splash, para eso se ha creado.


Siguiendo esta línea, intentaré hacer una serie de post tratando el tema del diseño de interfaces. Buscando algunos consejos con los que nuestras aplicaciones mantengan un estilo y un diseño ergonómico y usable. En otros post también intentaré tratar el tema del desarrrollo Web empresarial.


http://eugenioestrada.es

2 comentarios en “ux: reflexionando más allá de la interfaz”

  1. Creo que es muy erróneo el descartar la necesidad del perfil de un diseñador de interfaces.

    Llevo una jartá de años realizando aplicaciones Web, y la calidad de los interfaces se multiplica por mil cuando los conocimientos de lenguaje visual y psicología de la navegación se unen con un buen programador en script de cliente web y llegan a los más altos valores cuando un diseñador gráfico puro entra en juego.

    Nunca el programador de la aplicación debería ser quien diseñara el interface gráfico. Ni en lo visual, ni en su interacción ni en su ergonomía o flujo de uso.

    O es el mismisimo Leonardo D’ Vinci o no va a conseguir más que un mediocre interface, posiblemente copia de otro.

    Pero, esto solo es una opinión y me quedo a la espera de la continuación de este post del que, seguro, aprenderé bastante.

  2. MMmm…. en mi opinión para desarrollar una aplicación amigable hoy día es imprescindible que participe en el desarrollo (o al menos en el diseño) alguien especialista en UX.
    Para mí el perfil ideal de UX es alguien que conoce el desarrollo de IUs desde su doble vertiente: la psicológica de como diseñar estas UIs (a nivel funcional, colores, disposición, …) y de desarrollo (a nivel de lenguajes de script: html, xaml, …).

    El diseño de una UI puede afectar y mucho, al diseño posterior de una aplicación, y dejar esta decisión en manos de un desarrollador es cuanto menos arriesgado.

    Que el desarrollo de aplicaciones se considere un proceso “creativo” no impide para nada la participación de un diseñador en el proceso. No se puede saber de todo, y si alguien dedica mucho tiempo a aprender todo sobre UIs, pues no podrá ser tan bueno desarrollando componentes de accesos a datos o infraestructuras distribuídas.

    Eso sí, creo que los diseñadores deben dar un paso adelante: los que entregan las maquetas finales en ppt o png y luego el “pobre desarrollador” hace lo que puede, deben ir siendo sustituídos por aquellos que pueden preparar el esqueleto en (x)html o xaml. Aunque usando esos lenguajes de marca sigue siendo una utopía separar el 100% el diseñador del desarrollador si se que consigue un cierto grado de desacoplamiento realmente interesante.

    Saludos! 😉

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *