Vendiendo Experiencia de Usuario

Cuando se planea el diseño de un producto con “una buena UX” se habla mucho del usuario final, pero ¿quién representa a los que pagan por ese diseño? ¿Cuál es la mejor manera para alinear los objetivos de nuestros clientes con los de sus usuarios?

Se ha discutido mucho acerca de qué es y qué no es Diseño de Experiencia de Usuario. Todos los días personas de muy diferentes disciplinas, perfiles y niveles de experiencia se suman a sus filas interesadas en esta industria. Lo único que nos une a todos es que trabajamos es crear productos que brinden experiencias satisfactorias y funcionales a nuestros usuarios.

Me parece que el diseño de UX es un trabajo noble y desinteresado. En mi caso probablemente nunca voy a utilizar muchos de los productos que me han tocado estructurar, pero está bien porque esto no lo hacemos por beneficio propio, sino porque los usuarios merecen tener una mejor experiencia en cualquier aplicación, página, dispositivo o producto con el que tengan contacto.

En mis años de experiencia trabajando en publicidad me he encontrado, sin embargo, con una fila interminable de clientes que no comparten este gusto desinteresado por hacer de internet un mejor lugar. En algunos casos parecen más interesados en lo contrario. He conocido clientes que colocan tantos campos como les es posible en una página para que el usuario se harte y deje todos los valores del formulario por default para cobrarles de más a sus usuarios.

Son verdaderas historias de terror.

Cómo Diseñadores de Experiencia de Usuario tenemos la capacidad de conocer a fondo nuestros usuarios: los entrevistamos, encuestamos, analizamos y observamos para determinar cuáles son sus necesidades específicas. Nuestro súper poder mutante es ponernos en los zapatos de perfiles diferentes a los nuestros. El objetivo de este artículo, colegas, es el de hacerles ver que esto no solo debemos  hacerlo con nuestros usuarios, también tenemos que hacerlo con nuestros clientes.

Realidad vs Ficción

En todos los proyectos hay al menos tres roles: el que paga por el proyecto, el que hace el proyecto y el que usa el proyecto: stakeholders, product owners y los usuarios. Éstos pueden ser uno o varios, personas o empresas; en realidad eso no importa,  sino las tareas que realizan para que el proyecto tenga éxito. El flujo de la gestión del proyecto debería funcionar así:

  • El que paga el proyecto le pide al que desarrolla el proyecto que haga algo para que alguien lo use.
  • El que desarrolla el proyecto entrevista al que lo usa, arma una propuesta y se la enseña al que paga el proyecto
  • Al haber sido una propuesta desarrollada en conjunto con el que lo usará, será una propuesta exitosa.

Lo que sucede en realidad es esto:

  • El que paga por el proyecto le dice al que lo va a desarrollar (con diferentes niveles de detalle) lo que quiere ver
  • Éste a su vez lo verifica con el usuario, le hace modificaciones o mejoras, creando un mejor producto.
  • El que lo desarrolla se lo muestra al que lo paga
  • El que lo paga dice “eso no es lo que te pedí
  • El que desarrolla dice “sí, pero esto le gusta más al que lo usa
  • El que lo paga dice: “conozco a alguien sí puede hacer lo que le pedí

El resultado es que:

  • El que lo paga lanza un producto que no sirve para nada
  • El que lo desarrolla muere un poco por dentro ahogado en lágrimas
  • El que lo usa acaba frustrado por tener en sus manos un producto que en sus palabras “tiene una pésima usabilidad.

Es triste, lo sé. Vivimos en un mundo de supuestos y de “deberían ser”, muy diferentes de la realidad. Luego nos preguntamos por qué las cosas no cambian.

La solución

Aquí es donde viene lo que más disfruto de mi trabajo. *Redoble, por favor*:

Desarrollar un producto increíble para nuestros usuarios es solo la mitad del camino. la otra mitad es saber cómo venderlo a los stakeholders.

En mi experiencia, los que pagan por el proyecto generalmente piden lo que ‘creen’ que quieren, pero detrás de sus peticiones siempre hay necesidades que es nuestra obligación entender. Un proyecto exitoso no radica solo en cumplir la expectativa de experiencia del usuario, sino también la expectativa de resultados para nuestros clientes.

Una frase que debería ya ser un mantra de la industria es que “la usabilidad no es el fin, es un medio para alcanzar los objetivos de un proyecto de una mejor manera”. Los clientes no vienen a nosotros para que les hagamos un “sitio más bonito”, vienen a nosotros porque saben que un sitio bien diseñado les ofrece mejor conversión (o lo que sea que hayan leído en Merca2.0 que ya los hace expertos en tecnología).

No tengo una guía predefinida para entender a mis clientes, pero con el fin de echarles la mano, mis queridos lectores, he armado una lista de preguntas básicas que todo UX debe preguntarle a su stakeholder para obtener información vital a la hora de armar una propuesta:

1. ¿En qué área trabaja la persona que te está solicitando el proyecto? 

Esto es importante porque determina las métricas por las que sus jefes la van a calificar. Si es de mercadotecnia seguramente será una métrica de Costo vs Indicadores (top of mind, impresiones, awareness o número de personas que verá el mensaje). Si es un área de CRM (el área que normalmente maneja programas de lealtad y retención de clientes, así como la minería de sus datos) lo medirán por cuánto ganan en promedio por cada usuario registrado.

Si es de sistemas tendrá otras métricas como Estadísticas de tráfico o de Optimización de recursos. Lo más probable es que sin importar el área, los clientes esperan mayor “bang for their buck” (valor por su dinero). Lo que cambia es lo que cada cliente considera cómo “valor”.

2. ¿Cuál es el modelo de negocio de la empresa? 

A lo mejor tienen un servicio gratis en el que venden espacios publicitarios. Si tu propuesta es “quitar los banners” en vez de ofrecer una manera de garantizar que más gente los vea, puedes decirle adiós al proyecto.

Con las aerolíneas, por ejemplo, no se trata de solo vender el boleto de avión sino de que la gente compre extras (mejor asiento, comida, etc.) ¿Cómo es que tu propuesta o solución ayuda a mejorar la conversión de tu cliente?

3. ¿Cuál es la realidad tecnológica de la empresa? 

Sí, tu propuesta revolucionaria de e-commerce es brillante, pero el cliente no tiene una bodega centralizada para la distribución de sus productos, o te enfrentas a mi peor pesadilla: las franquicias, las que el cliente no tiene control de la experiencia final del producto, sino que ésta la determinan otros personajes que pueden hacer lo que se les pegue la gana con el producto final.

O tal vez tu cliente no cuenta con la infraestructura para soportar una base de datos para que los usuarios que se registren para ofrecerles una experiencia personalizada. Posiblemente tu cliente no tiene idea de cuánto cuesta o cuánto tiempo toma desarrollar una app nativa. Una propuesta exitosa le ayuda al cliente a ahorrar dinero, no a gastar en soluciones costosas en las que encuentra valor.

Estas tres preguntas básicas deberían ayudarte a pintar un panorama general de qué  puedes hacer y qué definitivamente no deberías hacer. También es una guía sobre cómo venderle el proyecto a tus clientes: qué palabras utilices, el enfoque que le des a los resultados que entregará tu plataforma y cómo el proyecto hará de tu cliente una súper estrella dentro de su empresa o con sus colegas porque ofrecerá resultados increíbles.

Estrategias hay tantas como clientes, pero la moraleja de esta historia es que así como es cierto que no porque nos importe a nosotros le va a importar a nuestros usuarios, tampoco puede que le importe a los clientes; y que no porque nosotros queramos que una aplicación sea increíble, nuestros stakeholders compartirán la misma pasión.

Es nuestro deber cómo UXers entender las necesidades de los clientes y los usuarios para garantizar que un proyecto suceda como consideramos que es correcto. Somos nosotros, finalmente, los que tenemos todo para lograr que esto suceda.

El cavernícola que no podía tener un iPad

Imaginemos un mundo en el cual nunca hubiéramos tenido contacto con una iPad; de repente al caminar por la calle nos topamos con este “objeto mágico” y una nota que nos dice: “puedes leer libros en ella”.

Antes de prender la tableta lo más seguro es que podríamos imaginar cómo se verían las páginas del libro. También intuiríamos cómo pasar las hojas, cómo poner un marcador o hasta cómo subrayar texto.

Este resultado no sería por casualidad o gracias a un poder mágico, sino que sería la consecuencia de los modelos mentales que tenemos construidos bajo la experiencia de leer un libro impreso.

¿Pero qué diablos es un modelo mental y por qué debería de importarme?

El concepto no es nuevo: el primero de hablar de ello fue  K.J.W. Craik en 1943 en su libro The Nature of Explanation, pero con su muerte este concepto queda latente y no es hasta la década de 1980 cuando reaparece en escena.

En el libro Diseño Inteligente: 100 cosas sobre la gente que cada diseñador necesita saber, la psicóloga Susan Weinschenk define los modelos mentales como: “Las representaciones que construimos mentalmente de los objetos con los que interactuamos”, a diferencia de los modelos conceptuales, que son “los modelos reales que percibimos a través del diseño y la interfaz de los productos

Los modelos mentales que tienen las personas sobre una tarea en particular influyen en el uso que esos usuarios les vayan a dar a nuestras interfaces, y sobre todo a las experiencias que vayan a tener con ellas.

Imaginemos ahora la misma escena del iPad tirado con la nota y que quien lo encuentra es un cavernícola. A diferencia del caso anterior, lo más probable es que no sepa cómo usar el “objeto mágico” y acabe ignorándolo o destruyéndolo.

Esa reacción no sería culpa del cavernícola; para que pudiera usar la tableta necesitaría por lo menos dos modelos mentales previos: el del libro (objeto) y el de la lectura (acción); también, claro, el de la electricidad, pero dejemos esta de lado por un momento.

Con el fin de generar experiencias que no resulten frustrantes para los usuarios es necesario que el modelo conceptual de nuestros productos coincida con los modelos mentales de esos usuarios. No podemos mostrarles algo que huele a pollo, tiene cresta, alas y plumas y acabar diciéndoles que es un hipopótamo. ¿Será que estos modelos mentales limitan nuestra creatividad?

En realidad no: es posible desarrollar modelos conceptuales capaces de generar nuevos modelos mentales o modificar los ya existentes y para ello hay varios factores clave a considerar: la repetición, la formulación de mensajes claros y la formación del usuario, además del hecho de que los modelos mentales se interiorizan y acumulan. ¡No son mágicos!

Uno de mis recursos favoritos para la generación de nuevos modelos conceptuales es el uso de las figuras retóricas, en especial las metáforas

¿Cuáles otros recursos conocen?

Mapas Mentales

En muchos proyectos de tecnología no se genera una documentación inicial que englobe todos detalles que el producto debe de contener. Los mapas mentales son una herramienta útil para evitar huecos en el diseño de la experiencia del usuario.

El ámbito de la publicidad es muy común ignorar esos detalles, y se pasa directamente del brief del cliente al diseño y luego a desarrollo, sin ningún proceso de planeación.

Esta falta ocasiona que en la etapa de desarrollo aparezcan huecos que nunca fueron planeados: una sección adicional o procesos rutinarios como las pantallas de registro o recuperación de contraseña, pero que al no haber sido consideradas desde el inicio aumentan el tiempo del proyecto y con ello el stress y las pérdidas económicas de la agencia.

Una herramienta útil para evitar estos contratiempos son los mapas mentales. Con ellos podemos de forma creativa, lógica y organizada tener un vistazo completo a todas los elementos del proyecto.

Los mapas mentales parten de una idea central, de la que se desprenden los elementos que la integran, los cuales pueden ser, por ejemplo, las secciones de una página o funciones específicas de un app.

Mapa Mental
Mapa Mental para pedir pozole.

En la imagen podemos ver un mapa mental para una aplicación móvil ficticia para pedir pozole. En el mapa lo que encontramos no son los flujos del app, ni las secciones en específico, pero si los elementos que debe de contener. De esta forma este documento servirá de referencia para los diseñadores, desarrolladores y project managers que tendrán de una forma más sencilla una visualización lo que debe de incluirse en el producto.

El lápiz y el papel pueden usarse siempre para crear mapas mentales, pero quisiera recomendar un par de programas:

MindNode

MindNodeSin duda la mejor aplicación de su género para Mac y iPad, con la que hice la imagen de ejemplo del app pozolera. Es limpio y muy sencillo de utilizar, y permite personalizar con facilidad el look & feel de nuestros mapas. Existe una versión libre para Mac, pero limitada. Los documentos creados en MindNode Pro, la versión pagada de la app, se pueden compartir entre la versión de escritorio y la de iPad mediante iCloud.  En cualquier versión se puede exportar a documentos en formatos PDF, PNG, JPG o FreeMind.

FreeMind

FreeMindComo el nombre lo dice, FreeMind es una herramienta de software libre; está escrita en Java, lo que permite que se pueda utilizar en Windows, Mac OS y Linux sin costo. La herramienta es bastante buena y eficiente, pero la interfaz no es del todo amigable. Es una muy buena opción para empezar a implementar mapas mentales en nuestros proyectos.

UX: una gran mancha de tinta

Hablar sobre User Experience (UX) puede ser como ver un test de manchas de tinta: aquello que te importe, es lo que terminas viendo en ella.

Leah Buley inicia con esta frase el libro The User Experience Team of One para intentar definir este controversial término, cada vez más común en la jerga cotidiana, pero tan ambiguo y abstracto en ocasiones que la analogía parece bastante acertiva.

Desde disciplina científica hasta término fancy empleado por millennials, el concepto User Experience ha transitado por una gran variedad de acepciones y matices en un periodo de vida relativamente corto. Te presento aquí una mirada, tan fugaz como profunda, sobre lo que es y no es User Experience.

Historia (mínima) sobre User Experience (y más allá)

Según cuenta la leyenda, en 1993 Don Norman llegó a Apple Computer para ser el líder del equipo que realizaría la investigación y diseño de la nueva línea de productos de la empresa de la manzana. Norman pidió que lo llamaran “Arquitecto de Experiencia de Usuario”, siendo el primero en la historia en desempeñar un puesto con ese título. Existe una frase célebre pronunciada por Norman sobre el porqué creó un nuevo término para describir su trabajo en Apple:

“Inventé el término porque pensé que interfaz y usabilidad eran demasiado limitados: quise cubrir todos los aspectos de la experiencia de una persona con un sistema, incluyendo el diseño industrial, gráficos, la interfaz, la interacción física y la manual”.

Para muchos, User Experience nació a partir de ese momento y evolucionó con el advenimiento del iPhone, las apps, redes sociales y demás vorágine propia de nuestros días. Nada más erroneo.

Aunque es un término relativamente reciente, User Experience se relaciona con un conjunto de disciplinas, tecnologías y acontecimientos importantes en la historia, por lo menos, desde el último siglo.

UX Timeline
Acontecimientos relevantes en la historia para User Experience

Los pioneros

Hagamos un efímero recuento cronológico: omitiendo al hombre de las cavernas y saltandonos a Leonardo Da Vinci, dentro de los precursores de lo que ahora conocemos como User Experience podemos mencionar a Frederick Taylor y a Henry Ford, quienes investigaron sobre la eficiencia de la interacción entre los trabajadores y sus herramientas, dando origen al Taylorismo. Después encontramos al Sistema de Producción de Toyota con la filosofía “respeto a la gente” que dio lugar a la participación de los trabajadores en la solución de problemas y la optimización de los procesos del que eran parte.

Mención especial merece el trabajo del diseñador industrial Henry Dreyfuss y su aportación a los campos de la ergonomía, la antropometría y los factores humanos; los métodos que describió en su libro Designing for People son todavía utilizados hoy día por los diseñadores de experiencia de usuario.

El psicólogo experimental Paul Morris Fitts también contribuyó enormemente en la misma área, fundó uno de los primeros laboratorios de investigación sobre el rendimiento humano y el procesamiento de información; creó además un modelo predictivo de la conducta psicomotora humana basado en el tiempo y la distancia conocido como la Ley de Fitts, clave en el diseño de interacción y diseño web.

A la par de la ergonomía, otra disciplina fue tomando forma en aquellos años: la ciencia cognitiva, que combina el interés en los fenómenos de la cognición humana (principalmente de la memoria a corto plazo) con conceptos como la inteligencia artificial, la lingüística o la antropología, por mencionar algunos. Estos fueron los albores del interés por estudiar la interacción entre el hombre y los objetos.

¿Y el iPhone ‘apá?

Vamos para allá: una serie de impresionantes avances tecnológicos sucedieron de manera vertiginosa a partir de la década de los 50, la invención del transistor (1947), del circuito integrado (1957) y del microprocesador (1971) fueron el preludio al advenimiento de la microelectrónica y la evolución de los sistemas de cómputo.

La historia registra como primera computadora electrónica a la ENIAC en 1946, posteriormente aparecieron la UNIVAC 1 (1951), Altair 8800 (1974), Apple I (1976) y la IBM PC (1981), definitivamente, la llegada del Macintosh Apple en 1984 marcó el primer paso hacia una informática orientada al usuario.

Así es, existió un universo antes del iPhone y de la MacBook Pro, pregúntenle a sus padres. Lo importante de todo esto es entender que la rápida evolución de los dispositivos microelectrónicos y la intensificación, tanto en hardware como en software, de los equipos informáticos permitió su abaratamiento y, en consecuencia, la masificación de su uso.

¿Qué no todo empezó con las redes sociales?

Pues no: a partir de la década de los 60, los continuos avances y la rápida difusión de las Tecnologías de la Información y las Comunicaciones (TIC) empezó a caracterizar a la sociedad, creando un nuevo paradigma para interpretar el accionar social, económico, político y cultural, soportados ahora en el acceso y uso de las TIC. Un considerable número de autores, principalmente de las ciencias sociales, vaticinó que el nuevo paradigma implicaría la desaparición de la sociedad industrial, característica del siglo XX, para dar surgimiento a un nuevo tipo de sociedad: la Sociedad de la Información. No se equivocaron. Observen a su alrededor en este momento.

Nicholas Negroponte lo expresó de forma magistral en su libro Being Digital: “la transformación de átomos a bits es irrevocable e imparable”, la informática “ya no se ocupará sólo de las computadoras, sino de la vida misma” porque “nos relacionaremos en comunidades digitales en las que el espacio físico será irrelevante y el tiempo jugará un papel diferente”. Being Digital fue escrito en 1995. Mark Zuckerberg tenía 11 años entonces.

Interacción Humano-Computadora, Usabilidad y UX: el Padre, el Hijo y el Espíritu Santo

La revolución de las tecnologías de información (TICs) y toda su parafernalia, despertó el interés de la comunidad científica y académica en estudiar de manera formal y sistemática las relaciones entre humanos y computadoras.

Abordada de manera inicial sólo por las ciencias computacionales, muy pronto se hizo evidente que se requería de la perspectiva de otras disciplinas que incorporaran aspectos humanos al diseño de dispositivos y sistemas interactivos, como la ergonomía, las ciencias cognitivas, entre otras. Así surgió la Interacción Humano-Computadora (HCI, por sus siglas en inglés) definida como la disciplina dedicada al diseño, evaluación e implementación de sistemas de cómputo interactivos para uso humano y al estudio de los fenómenos que rodean a la interacción.

El carácter multidisciplinario de HCI se ve reflejado en la currícula de ACM SIGHCI. Un profesor y gran amigo (@sirpeto) siempre nos decía: “en HCI cabemos todos”.

Currícula de la ACM SIGCHI para Interacción Humano-Computadora
Currícula de la ACM SIGCHI para Interacción Humano-Computadora

Gracias a la disciplina de Interacción Humano-Computadora, a partir de la década de los 90 empezaron a popularizarse conceptos como el de usabilidad, diseño de interacción, arquitectura de información, entre otros. Surgieron personajes influyentes en la naciente industria web como Jakob Nielsen, Steve Krug o Alan Cooper, algo así como los tweetstar de HCI, sólo que Twitter aún no existía.

Sin lugar a duda, la usabilidad es uno de los componentes intrínsecos de HCI y el que le permitió traspasar la barrera de la investigación académica y llegar a la industria. La usabilidad se define actualmente como la efectividad, eficiencia y satisfacción con la que un producto permite alcanzar objetivos específicos a usuarios específicos en un contexto de uso específico (norma ISO 9241). No siempre fue definida de esa forma tan cool y rimbombante.

La palabra producto sustituyó al término software, empleado en una primera definición de usabilidad (norma ISO 9126), es decir, antes se concebía a la usabilidad como un grado o medida de evaluación únicamente de productos de software; actualmente, cualquier producto, incluso de la vida cotidiana, es susceptible de ser evaluado en términos de usabilidad.

El término “contexto de uso” no figuraba en la definición ISO 9126. Al considerar o reconocer la importancia de la experiencia total con la que un usuario está involucrado durante la interacción con un producto, incluso antes y después de la interacción misma, la usabilidad dio origen a User Experience.

Y como dicen en las películas, aquí termina la historia y comienza la leyenda.

Definición (mínima) de User Experience

Existen tantas definiciones de User Experience como interpretaciones a la mancha de tinta. Sin entrar en controversia, considero que la definición mínima y más aproximada de UX es la generada por la norma ISO 9241-210: Ergonomics of human–system interaction — Part 210: Human-centred design for interactive systems, que dice más o menos así:

Experiencia de Usuario:
Percepciones de una persona y las respuestas resultantes del uso y/o el uso previsto de un producto, sistema o servicio.

NOTA 1. La experiencia del usuario incluye todas las emociones de los usuarios, creencias, preferencias, percepciones, las respuestas físicas y psicológicas, comportamientos y logros que ocurren antes, durante y después de su uso.

NOTA 2. La experiencia del usuario es una consecuencia de la imagen de marca, la presentación, la funcionalidad, el rendimiento del sistema, el comportamiento interactivo y capacidades de asistencia del sistema, el estado físico e interno del usuario como resultado de experiencias previas, actitudes, habilidades y personalidad, y el contexto de uso.

NOTA 3. Usabilidad, si se interpreta desde la perspectiva de las metas personales de los usuarios, puede incluir el tipo de aspectos perceptivos y emocionales típicamente asociados con la experiencia del usuario. Los criterios de usabilidad pueden ser usados para evaluar los aspectos de la experiencia del usuario.

Mi definición de UX es esta:

La experiencia de usuario es todo el conjunto de fenómenos que rodean la interacción de un usuario específico con un producto específico en un contexto específico, antes, durante y después de la interacción misma.

Si tú ves dos elefantes bebés trepando un árbol en esa gran mancha de tinta, quizá compartimos una visión común sobre UX, es lo que yo veo. O Puede ser que no, siendo esto lo deseable, porque en UX también cabemos todos.

Conclusiones

  • UX es un término que ha transitado por una gran variedad de acepciones y matices en un periodo de vida relativamente corto.
  • UX se relaciona y tiene su origen en un conjunto de disciplinas, tecnologías y acontecimientos importantes en la historia que datan desde el último siglo.
  • Es imposible comprender la naturaleza y el sentido de UX sin la existencia previa de una disciplina como Interacción Humano-Computadora y de todas las ciencias que le dan soporte.
  • La usabilidad es la efectividad, eficiencia y satisfacción con la que un producto permite alcanzar objetivos específicos a usuarios específicos en un contexto de uso específico. UX es la nueva usabilidad.

Conociendo el contexto que le dio origen, concibe tu propia definición de UX: interpreta la mancha.

Sobre la experiencia de usuario

Se habla mucho sobre “Experiencia de Usuario”, pero ésta es una disciplina amplia que cambia mucho y constantemente. ¿De qué hablamos cuando hablamos de UX?

Ante la cambiante forma de interactuar que el usuario tiene debido a los avances de la tecnología, la ciencia y otras cosas, esta experiencia ha experimentado cambios radicales en su operación, en su orientación teórica y práctica en las últimas décadas. Surgen así varios paradigmas, como el contexto de la temporalidad de cada década y los artefactos que salen al mercado para consumo masivo.

El usuario siempre se encontrará con ciertas limitaciones en la interacción con la tecnología y se ha dedicado más tiempo en la promoción en la inmediatez de resolver las necesidades. Por ejemplo: con la implementación de propuestas de diseño de una interfaz gráfica y/o física vemos que los elementos básicos en el diseño como la iconografía, las imágenes, la navegación, la productividad o el diseño de contenidos son apenas uno de los muchos elementos que permiten una experiencia de usuario enriquecida. Es importante recordar que existen elementos con aspectos cualitativos o cuantitativos que dan valor agregado a la experiencia de un usuario.

He visto que en las distintas emisiones de UX Nights, los asistentes plantean interrogantes a los ponentes sobre quiénes deberían integrar un equipo de UX, cuál es el perfil idóneo que debe tener un a persona que se dedique sólo a hacer análisis o cuáles son las mejores prácticas para hacer análisis de UX, entre muchas otras preguntas.

Las interacciones en la experiencia que tiene un usuario se vuelven posibilidades, dejando ideas sobre cómo una buena experiencia de usuario es aquella donde el enfoque es siempre la interfaz que debe ser siempre accesible, cuál es el equipo idóneo que debe estar involucrado y quién puede hacer un uso más efectivo de la UX.

Las interfaces, sistemas o artefactos siempre presentarán “limitaciones”, y me refiero a las limitaciones que en la experiencia de usuario van cambiando en el momento en el que se incorporan más o menos elementos.

Aquí surgen preguntas importantes: ¿qué va a suceder con la experiencia de usuario como área de análisis e investigación, procesos o incluso como disciplina? ¿Cómo será vista en el futuro cercano? ¿Seguirá llamándose “Experiencia de Usuario”? Así concluyo, dejando más preguntas que respuestas.

Accesibilidad para sitios web

La accesibilidad en aplicaciones web para usuarios invidentes no es difícil de implementar, si se conocen las especificaciones que le dan soporte, como WAI ARIA.

De acuerdo con el último censo de INEGI en el año 2010, en México había entonces cerca de 1,292,201 personas con discapacidad visual, esto es poco más del 1% de la población del país. Si sumamos a las personas que no son completamente invidentes pero tienen algún problema visual el número sube a 48,575,560 personas, o al 43.24% de la población, de los que la tercera parte son niños en edad escolar.

En México la segunda discapacidad más común es la visual, y es la más temida por la población en general. No es sorpresa si consideramos que de toda la información que una persona recibe en su vida, el 80% de ella ingresa por los ojos. Esto es particularmente cierto cuando hablamos de la web y de los medios digitales.

Muchas personas que trabajan diseñando o desarrollando sitios web creen que para hacer sus sitios accesibles es necesario una tecnología adicional a lo que ya utilizan. En realidad no se necesita nada adicional, sino tener en consideración algunas guías para que su trabajo sea accesible a todas las personas, incluyendo a las que tienen problemas visuales.

La W3C ha creado una especificación técnica para la implementación de accesibilidad para sitios web llamada WAI ARIA (Web Accessibility Initiative – Accessible Rich Internet Applications), enfocada especialmente a aplicaciones web que utilizan Javascript y AJAX, ya que estos patrones de desarrollo cambian dinámicamente el contenido de una página web, haciéndola poco accesible para personas que utilizan lectores digitales u otras tecnologías para usuarios con discapacidades.

WAI-ARIA describe cómo añadir contenido semántico y metadatos al contenido HTML para hacer los controles de la UI y el contenido dinámico más accesible. Por ejemplo, con WAI-ARIA es posible identificar enlaces en el menú de navegación incluso si éste se encuentra colapsado.

La especificación WAI-ARIA está basada en tres diferentes atributos: roles, estados y propiedades. Estos atributos tienen las siguientes funciones:

  • Roles (roles): describen algunos de los elementos y widgets comunes en la UI web pero que no están disponibles en HTML, como sliders, pestañas, etc., contruidos con HTML, CSS y JavaScript. También se utilizan para describir la estructura de la página incluyendo encabezados, tablas y otros elementos.
  • Propiedades (properties): describen los estados de los widgets. Por ejemplo, cuando un elemento en la página es “arrastrable”, tiene un elemento popup asociado con él.
  • Estados (states): describen si un elemento es interactivo o no, es decir, los ‘estados’ informan a los lectores digitales si el estado de un elemento en la página es ‘ocupado’, ‘deshabilitado’, ‘seleccionado’ u ‘oculto’.

Revisemos este código web sencillo para una navegación de pestañas:

<!-- ¿Cómo sabrías que este es un widget de pestañas solo viendo el código? -->

<ol>
    <li id="chapter1Tab">
        <a href="#chapter1Panel">Capítulo 1</a> 
    </li>
    <li id="chapter2Tab">
        <a href="#chapter2Panel">Capítulo 2</a>
    </li>
    <li id="quizTab">
        <a href="#quizPanel">Examen</a>
    </li>
</ol>

<div>
    <div id="chapter1Panel">Contenido del capítulo 1</div>
    <div id="chapter2Panel">Contenido del capítulo 2</div>
    <div id="quizPanel">Contenido del examen</div>
</div>

Ahora el mismo código, pero con WAI ARIA:

<!-- He añadido atributos de roles para describir cada pestaña y su contenido asociado -->

<ol role="tablist">
    <li id="chapter1Tab" role="tab">
        <a href="#chapter1Panel">Capítulo 1</a> 
    </li>
    <li id="chapter2Tab" role="tab">
        <a href="#chapter2Panel">Capítulo 2</a>
    </li>
    <li id="quizTab" role="tab">
        <a href="#quizPanel">Examen</a>
    </li>
</ol>

<div>
    <div id="chapter1Panel" role="tabpanel" aria-labelledby="chapter1Tab">
        Contenido del capítulo 1
</div>
    <div id="chapter2Panel" role="tabpanel" aria-labelledby="chapter2Tab">
        Contenido del capítulo 2
</div>
    <div id="quizPanel" role="tabpanel" aria-labelledby="quizTab">
        Contenido del examen
    </div>
</div>

Al añadir los atributos de WAI-ARIA al etiquetado HTML, las tecnologías de apoyo a personas discapacitadas pueden interactuar también con controles creados con JavaScript. De hecho, la implementación de WAI-ARIA está pensada para hacer accesibles sitios en navegadores viejos sin soporte a las etiquetas semánticas de HTML5.

El grupo de trabajo de WAI ARIA en el W3C ya está trabajando en una nueva versión de la especificación para integrarla con HTML5 y otros lenguajes como SVG. También han creado una herramienta llamada “Generador de reportes de evaluación de accesibilidad de sitios web” para revisar la integración de WAI ARIA y otras especificaciones de accesibilidad en sitios web existentes.