El Dueño de la Experiencia de Usuario

Crear productos con buena experiencia de usuario requiere de un equipo con personas que tienen enfoques y habilidades muy diferentes. ¿Quién de ellos es el dueño de la UX?

El trabajo de desarrollo de tecnología dejó de ser desde hace mucho la tarea de una sola persona; los días del “webmaster” o del “hacker solitario” quedaron atrás como anécdotas de los tiempos en que la responsabilidad de programar, diseñar, crear contenido, asegurar la infraestructura, llevar a producción y dar a conocer un producto de tecnología era trabajo de una persona.

Los productos que sobresalen en el mercado casi siempre son creados por equipos de profesionales con habilidades y conocimientos diferentes, como en “The Avengers“, diría Adrián Solca:

El objetivo de tener un equipo es que el talento total compense las deficiencias individuales.

Un equipo multidisciplinario debe superar primero el impulso de sus miembros de trabajar únicamente orientados por requerimientos u objetivos personales. El primer reto es aceptar de que cada persona en el equipo, al tener diferente formación, tiene también formas diferentes de pensar, de comunicarse y de resolver problemas; usa herramientas diferentes que los demás y tiene objetivos personales diferentes también.

Trabajar enfocado en el beneficio del usuario sirve para centrar la atención de todos en el mismo tema y para unificar las visiones y objetivos de trabajo. Si el éxito del equipo depende del éxito del usuario final, entonces todos tiene un gran incentivo para crear la mejor experiencia de usuario posible.

La pregunta que surge en este punto es: ¿quién en el equipo es el responsable de la implementación correcta de UX?

La respuesta común es “todos son responsables“, pero esta respuesta tiene una trampa: cuando la responsabilidad es todos, en realidad nadie es 100% responsable. Los miembros de equipos con poca integración se pasan la responsabilidad entre ellos tratando de evitarla, lo que diluye el compromiso hacia el usuario y afecta el diseño final de la experiencia.

Es importante señalar en este punto que tampoco se trata de generar una “área de UX” que se responsabilice de la implementación de las buenas practicas del diseño centrado en el usuario. Una área que sólo tenga esa tarea como objetivo y trabaje de manera aislada de los equipos de producción solo volverá el proceso lento y burocrático, alienando a los demás.

En un buen equipo de UX no hay un “dueño”, pero si debe de haber un líder, un “campeón” que debe tomar dos roles adicionales a su contribución al equipo: primero, debe ser el representante del usuario, alguien que vele por los intereses de los usuarios finales y que le recuerde constantemente al equipo que el usuario es lo más importante; y segundo, debe de asumir el rol de facilitador para los otros miembros del equipo puedan conocer, entender los procesos, recomendaciones y mejores prácticas sobre UX.

Sobra decirlo, ser el “campeón” de UX en un equipo de trabajo no es sencillo. La persona que asuma ese rol deberá ser una persona que pueda trabajar con otros y comunicarse con ellos de manera puntual y eficiente, que pueda ganarse su confianza por medio mérito y no por un puesto o por pose.

En muchos sentidos, este “campeón” de UX refleja mucho el rol de un SCRUM Master en un proceso ágil pero con un giro: su principal preocupación no es el producto, sino el usuario final. Puede ser desarrollador, diseñador, project manager, el mismo CEO o alguien más. No necesita tampoco ser la misma persona todo el tiempo o en cada proyecto, o siquiera un “experto” en el tema. Es más: puede que sea una persona que trabaja fuera de la empresa, ¡o incluso un cliente!

Lo que es cierto es que cada equipo necesita a alguien que peleé por el usuario (¡como TRON!), pero no contra sus compañeros de trabajo. Si esta persona logra convencer a sus colegas que el usuario es lo más importante en el desarrollo de tecnología y los ayuda a trabajar en ese sentido, el resultado serán siempre productos increíbles y memorables.

Consultor en experiencia de usuario, developer, conferencista, escritor y emprendedor. Trabaja en Tesseract Space, es Google Expert en UX/UI, Microsoft Regional Director y co-fundador de UX Nights.

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.

Consultor en experiencia de usuario, developer, conferencista, escritor y emprendedor. Trabaja en Tesseract Space, es Google Expert en UX/UI, Microsoft Regional Director y co-fundador de UX Nights.