Diseño de interfaces, 3ª edición

Capítulo 1. Diseñar para las personas

Este trabajo se ha traducido utilizando IA. Agradecemos tus opiniones y comentarios: [e-mail]

Este libro trata casi por completo sobre el aspecto y el comportamiento de las aplicaciones, las aplicaciones web y los dispositivos interactivos. Pero este primer capítulo es la excepción a la regla. Aquí no hay capturas de pantalla, ni diseños, ni navegación, ni diagramas, ni nada visual.

¿Por qué no? Al fin y al cabo, probablemente por eso cogiste el libro en primer lugar.

En este primer capítulo, esbozamos el propósito y los resultados de comprender cómo utilizan las personas el software. Concretamente, te harás una idea de lo que es fundamental para las personas a la hora de diseñar sitios web, aplicaciones e interfaces:

• Objetivos generales al utilizar tu sitio o aplicación

• El desglose de tareas para llevar a cabo esos objetivos

• Cómo piensan sobre el tema o ámbito concreto

• El lenguaje que utilizan para pensar y hablar sobre este tema

• Lo cualificados o no que son para hacer el trabajo

• Sus actitudes hacia el tema

Un buen diseño de interfaz no empieza con imágenes. Empieza por comprender a las personas: cómo son, por qué utilizan un determinado software y cómo podrían interactuar con él. Cuanto más sepas sobre ellas y más empatices con ellas, más eficazmente podrás diseñar para ellas. Al fin y al cabo, el software no es más que un medio para alcanzar un fin para las personas que lo utilizan. Cuanto mejor satisfaga esos fines, más felices serán esos usuarios.

Aquí se describe un marco para conseguirlo. Abarca cuatro áreas. No se trata de normas o requisitos estrictos para crear grandes diseños. Pero tener un plan sobre cómo te informarás a ti mismo y a tu equipo en cada área te dará la seguridad de que tu trabajo se basa en verdaderos conocimientos sobre problemas valiosos que resolver para tus clientes objetivo. Decide por ti mismo qué nivel de tiempo y esfuerzo es adecuado para tu proyecto o empresa. Revisar estas áreas con regularidad mantendrá las ideas clave en lo más alto de tu mente y ayudará a centrar el esfuerzo de todos, especialmente el diseño de la interfaz de usuario (IU), en crear grandes resultados para las personas.

La estructura en cuatro partes para entender el diseño para las personas es ésta:

Contexto

¿Quién es tu público?

Objetivos

¿Qué intentan hacer?

Investiga

Formas de entender el contexto y los objetivos

Los patrones

Cognición y comportamiento relacionados con el diseño de interfaces

Contexto

El primer elemento importante de y el primer paso para diseñar para las personas es comprender el contexto humano de tu intención de diseño. El diseño de interacción empieza por definir y comprender a las personas que utilizarán tu diseño. Concretamente, fundamenta tus decisiones de diseño en la comprensión de lo que pueden querer hacer y lo que aportan a la interacción en términos de expectativas, conocimiento de temas relevantes o dominios de información, y su nivel de destreza con el software.

Conoce a tu público

Hay una máxima en el campo del diseño de interfaces: "Tú no eres el usuario".

Así pues, este capítulo habla de las personas. Cubre brevemente algunas ideas fundamentales en esta introducción, y luego discute algunos patrones que difieren de los del resto del libro. Describen comportamientos humanos -en contraposición a comportamientos del sistema- que el software que diseñes podría tener que soportar. El software que apoya estos comportamientos humanos ayuda mejor a los usuarios a alcanzar sus objetivos.

Las interacciones son conversaciones

Cada vez que alguien utiliza una aplicación, o cualquier producto digital, mantiene una conversación con la máquina. Puede ser literal, como con una línea de comandos o un menú telefónico, o tácita, como la "conversación" que mantiene un artista con sus pinturas y su lienzo: el toma y daca entre el artesano y lo que está construyendo. Con el software social, puede ser incluso una conversación por poder. En cualquier caso, la interfaz de usuario media en esa conversación, ayudando a los usuarios a alcanzar los fines que tengan en mente.

He aquí los puntos clave:

• Hay dos participantes en la conversación: la persona y el programa informático.

• Hay un constante intercambio de información de ida y vuelta.

• El intercambio es una serie de peticiones, órdenes, recepción, procesamiento y respuesta.

• El humano de la conversación necesita una respuesta continua de la interfaz que confirme que las cosas funcionan con normalidad, que las entradas se procesan y que avanzan satisfactoriamente hacia el objetivo del momento.

• Para que este bucle de retroalimentación funcione, el software -que no puede ser tan espontáneo y receptivo como un ser humano real (al menos no todavía)- debe estar diseñado para imitar a un interlocutor. Debe ser comprensible para su interlocutor, debe indicar que está activo (cuando está "escuchando") y debe ser obvio cuando está respondiendo. Otra forma de hacerlo es anticipar los siguientes pasos o recomendaciones, del mismo modo que una persona considerada puede ayudar a otra.

Como diseñador de interfaz de usuario, entonces, te toca guionizar esa conversación, o al menos definir sus términos. Y si vas a guionizar una conversación, debes comprender el lado humano lo mejor posible. ¿Cuáles son los motivos y las intenciones del usuario? ¿Qué "vocabulario" de palabras, iconos y gestos espera emplear el usuario? ¿Cómo puede la aplicación establecer expectativas adecuadas para el usuario? ¿Cómo acaban comunicándose entre sí de forma significativa el usuario y la máquina?

Adapta tu contenido y funcionalidad a tu público

Antes de empezar el proceso de diseño, considera tu enfoque general. Piensa en cómo podrías diseñar el estilo de interacción general de la interfaz, su personalidad, por así decirlo.

Cuando mantienes una conversación con alguien sobre un tema determinado, adaptas lo que dices en función de lo que entiendes de la otra persona. Puedes tener en cuenta cuánto le interesa el tema, cuánto sabe ya sobre él, hasta qué punto está dispuesta a aprender de ti y si le interesa la conversación en primer lugar. Si te equivocas en algo de esto, pasarán cosas malas: la persona puede sentirse tratada con condescendencia, desinteresada, impaciente o totalmente desconcertada.

Esta analogía lleva a algunos consejos de diseño obvios. El vocabulario específico del tema que utilices en tu interfaz, por ejemplo, debe coincidir con el nivel de conocimientos de tus usuarios; si algunos usuarios no conocen ese vocabulario, dales una forma de aprender los términos desconocidos. Si no conocen bien la informática, no les obligues a utilizar widgets sofisticados o convenciones de diseño de interfaz poco comunes. Si su nivel de interés puede ser bajo, respétalo, y no les pidas demasiado esfuerzo a cambio de muy poca recompensa.

Algunas de estas preocupaciones impregnan todo el diseño de la interfaz de forma sutil. Por ejemplo, ¿esperan tus usuarios un intercambio breve y muy centrado sobre algo muy específico, o prefieren una conversación que sea más bien una exploración libre? En otras palabras, ¿cuánta apertura hay en la interfaz? Demasiado poca, y tus usuarios se sentirán atrapados e insatisfechos; demasiada, y se quedarán paralizados, sin saber qué hacer a continuación, sin estar preparados para ese nivel de interacción.

Por tanto, tienes que elegir cuánta libertad tienen tus usuarios para actuar arbitrariamente. En un extremo de la escala podría estar un asistente de instalación de software: el usuario es llevado a través de él sin oportunidad de utilizar nada más que Siguiente, Anterior o Cancelar. Está muy centrado y es específico, pero bastante eficaz y satisfactorio, en la medida en que funciona y es rápido. En el otro extremo podría estar una aplicación como Excel, una interfaz de "planta abierta" que expone un gran número de funciones en un solo lugar. En un momento dado, el usuario tiene cientos de cosas que podría hacer a continuación, pero eso se considera bueno, porque los usuarios autodirigidos y hábiles pueden hacer mucho con esa interfaz. De nuevo, es satisfactorio, pero por razones totalmente distintas.

Nivel de destreza

¿Hasta qué punto tu público puede utilizar tu interfaz ahora y cuánto esfuerzo están dispuestos a dedicar tus usuarios para aprenderla?

Es posible que algunos de tus clientes lo utilicen a diario en el trabajo; evidentemente, con el tiempo se convertirán en usuarios expertos. Pero se sentirán cada vez más insatisfechos incluso con pequeñas insatisfacciones. Quizá lo utilicen a veces y lo aprendan sólo lo suficiente para arreglárselas (Satisficing). Pueden tolerar más las dificultades de uso. Quizá lo utilicen sólo una vez. Sé sincero: ¿puedes esperar que la mayoría de los usuarios se conviertan en intermedios o expertos, o la mayoría de los usuarios seguirán siendo principiantes perpetuos?

Entre los programas diseñados para usuarios de nivel intermedio a experto se incluyen los siguientes:

• Photoshop

• Excel

• Entornos de desarrollo de código

• Herramientas de administración del sistema para servidores web

Por el contrario, aquí tienes algunas cosas pensadas para usuarios ocasionales:

• Quioscos en centros turísticos o museos

• Controles de Windows o macOS para establecer fondos de escritorio

• Páginas de compra para tiendas online

• Asistentes de instalación

• Cajeros automáticos

Las diferencias entre ambos grupos son dramáticas. Las suposiciones sobre el conocimiento de las herramientas de los usuarios impregnan estas interfaces, mostrándose en el uso del espacio de pantalla, el etiquetado y la sofisticación de los widgets, y en los lugares donde se ofrece (o no) ayuda.

Las aplicaciones del primer grupo tienen muchas funciones complejas, pero no suelen guiar al usuario paso a paso por las tareas. Dan por sentado que los usuarios ya saben lo que tienen que hacer, y están optimizadas para un funcionamiento eficaz, no para facilitar el aprendizaje; suelen estar centradas en documentos o en listas (algunas son aplicaciones de línea de comandos). A menudo se escriben libros y cursos enteros sobre ellas. Sus curvas de aprendizaje son pronunciadas.

Las aplicaciones del segundo grupo son lo contrario: limitadas en funcionalidad pero útiles a la hora de explicarla por el camino. Presentan interfaces simplificadas, que no suponen ningún conocimiento previo de los estilos de aplicación centrados en documentos o listas (por ejemplo, barras de menú, selección múltiple, etc.). Los "asistentes" aparecen con frecuencia, quitando al usuario la responsabilidad de centrar la atención. La clave es que los usuarios no están motivados para esforzarse en aprender estas aplicaciones: ¡normalmente no merece la pena!

Ahora que has visto los extremos, mira las aplicaciones en el medio del continuo:

• Microsoft PowerPoint

• Clientes de correo electrónico

• Facebook

• Herramientas para escribir un blog

La verdad es que la mayoría de las aplicaciones se encuentran en este punto intermedio. Tienen que servir adecuadamente a la gente en ambos extremos: ayudar a los nuevos usuarios a aprender la herramienta (y satisfacer su necesidad de gratificación instantánea) y permitir a los usuarios intermedios frecuentes hacer las cosas sin problemas. Sus diseñadores probablemente sabían que la gente no haría un curso de tres días para aprender a usar un cliente de correo electrónico. Sin embargo, las interfaces resisten el uso repetido. La gente aprende rápidamente lo básico, alcanza un nivel de competencia que le satisface y no se molesta en aprender más hasta que se ve motivada a hacerlo con fines específicos.

Puede que algún día te encuentres en tensión entre los dos extremos de este espectro. Naturalmente, quieres que la gente pueda utilizar tu diseño "nada más sacarlo de la caja", pero también es posible que desees apoyar a los usuarios frecuentes o expertos en la medida de lo posible. Encuentra un equilibrio que se adapte a tu situación. Los patrones organizativos del Capítulo 2, como los Sistemas de Ayuda, pueden ayudarte a servir a ambos grupos.

Objetivos: Tu interfaz es sólo un medio para sus fines

Todo el mundo que utiliza una herramienta -software o de otro tipo- tiene una razón para utilizarla. Éstos son sus objetivos. Los objetivos pueden ser resultados como éstos

• Encontrar algún hecho u objeto

• Aprender algo

• Realizar una transacción

• Controlar o monitorear algo

• Crear algo

• Conversar con otras personas

• Entretenerse

Modismos, comportamientos de usuario y patrones de diseño bien conocidos pueden apoyar cada uno de estos objetivos abstractos. Los diseñadores de experiencia de usuario (UX) han aprendido, por ejemplo, cómo ayudar a las personas a buscar hechos concretos en grandes cantidades de información en línea. Han aprendido a presentar las tareas de modo que sea fácil recorrerlas. Están aprendiendo formas de apoyar la construcción de documentos, ilustraciones y código.

Pregunta por qué

El primer paso para diseñar una interfaz es saber qué intentan conseguir realmente sus usuarios. Rellenar un formulario, por ejemplo, casi nunca es un objetivo en sí mismo: la gente sólo lo hace porque está intentando comprar algo por Internet, renovar el carné de conducir o instalar un software. Están realizando algún tipo de transacción.

Hacer las preguntas adecuadas puede ayudarte a conectar los objetivos del usuario con el proceso de diseño. Los usuarios y clientes suelen hablarte en términos de características y soluciones deseadas, no de necesidades y problemas. Cuando un usuario o cliente te diga que quiere una determinada función, pregúntale por qué la quiere: determina su objetivo inmediato. Luego, a la respuesta de esta pregunta, vuelve a preguntar "por qué". Y otra vez más. Sigue preguntando hasta que superes con creces los límites del problema de diseño inmediato.¹

El valor del diseño: Resuelve el problema correcto, y luego resuélvelo bien

¿Por qué deberías plantearte estas preguntas si tienes unos requisitos claros? Porque si te gusta diseñar cosas, es fácil que te atrape un problema interesante de diseño de interfaz. Tal vez se te dé bien crear formularios que pidan la información justa, con los controles adecuados, todo muy bien dispuesto. Pero el verdadero arte del diseño de interfaces reside en resolver el problema adecuado, definido como ayudar al usuario a alcanzar su objetivo.

Así que no te encariñes demasiado con el diseño de ese formulario. Si hay alguna forma de terminar la transacción sin hacer que el usuario pase por ese formulario en absoluto, deshazte de él por completo. Eso acerca al usuario a su objetivo, con menos tiempo y esfuerzo por su parte (y quizá también por la tuya).

Utilicemos el enfoque del "por qué" para profundizar un poco más en algunos escenarios de diseño típicos:

• ¿Por qué un directivo de nivel medio utiliza un cliente de correo electrónico? Sí, claro: "para leer el correo electrónico". Pero, ¿para qué leen y envían correos electrónicos? Para conversar con otras personas. Por supuesto, otros medios pueden conseguir los mismos fines: el teléfono, una conversación de pasillo, un documento formal. Pero aparentemente, el correo electrónico satisface algunas necesidades que los otros métodos no satisfacen. ¿Cuáles son, y por qué son importantes para este directivo? ¿La comodidad de elegir cuándo enviar o responder? ¿La privacidad? ¿La posibilidad de archivar una conversación? ¿La convención social? ¿Qué más?

• Un padre va a una agencia de viajes online, teclea la ciudad en la que su familia pasará las vacaciones de verano, e intenta encontrar precios de billetes de avión en varias fechas. Aprende de lo que encuentra, pero su objetivo no es sólo navegar y explorar distintas opciones. Pregunta por qué. Su objetivo es en realidad una transacción: comprar billetes de avión. De nuevo, podría haberlo hecho en muchos sitios web diferentes, o por teléfono con un agente de viajes. ¿En qué es mejor este sitio web que esas otras opciones? ¿Es más rápido? ¿Es más amigable? ¿Tiene más probabilidades de encontrar una oferta mejor?

• A veces, el análisis de objetivos no es suficiente. Un sitio de snowboard puede ofrecer información (para aprender), una tienda online (para realizar transacciones) y una serie de videoclips (para entretenerse). Supongamos que alguien visita el sitio para realizar una compra, pero se desvía hacia la información sobre trucos de snowboard: ha cambiado sus objetivos de realizar una transacción a navegar y aprender. Quizá vuelvan a comprar algo, quizá no. Y la parte de estilo de vida y entretenimiento del sitio, ¿entretiene con éxito tanto al niño de 12 años como al de 35? ¿El de 35 años irá a otro sitio a comprar su nueva tabla si no se siente a gusto allí, o no le importa? Resulta útil ampliar tu marco de objetivos para incluir la comprensión del ciclo de compra específico del negocio. Tu cliente de snowboard tendrá objetivos diferentes en las distintas fases de este ciclo. Alternativamente, quizá quieras diseñar cómo podrías fomentar una lealtad a largo plazo entre la marca y el cliente. Esto podría hacerse mediante contenidos y funcionalidades que fomenten una identidad, construyan una comunidad y celebren un estilo de vida.

Es engañosamente fácil modelar a los usuarios como una única entidad sin rostro - "el usuario"- que recorre un conjunto de casos de uso sencillos, con un objetivo orientado a una tarea. Pero eso no refleja necesariamente la realidad de tus usuarios.

Para hacer bien el diseño, tienes que tener en cuenta muchos factores "más blandos": expectativas, reacciones viscerales, preferencias, contexto social, creencias y valores. Todos estos factores pueden afectar al diseño de una aplicación o sitio web. Entre estos factores más suaves, podrías encontrar la característica crítica o el factor de diseño que haga que tu aplicación sea más atractiva y tenga más éxito.

Por tanto, sé curioso. Especialízate en averiguar cómo son realmente tus usuarios, y qué piensan y sienten realmente.

Investiga: Formas de entender el contexto y los objetivos

La investigación es el punto de partida en el diseño para comprender a las personas. El descubrimiento empírico es la única forma realmente buena de obtener esta información. La investigación cualitativa, como las entrevistas individuales, te proporciona la base para comprender las expectativas de tu público, su vocabulario y la forma en que piensan sobre sus objetivos o estructuran su trabajo. A menudo puedes detectar patrones en lo que oyes. Éstas son tus señales para orientar el diseño. La investigación cuantitativa, como una encuesta, puede dar validación o descalificación numérica a tus hallazgos cuánticos.

Para iniciar un diseño, tendrás que caracterizar a los tipos de personas que utilizarán tu diseño (incluidos los factores más blandos que acabamos de mencionar), y la mejor forma de hacerlo es salir a su encuentro.

Cada grupo de usuarios es único, por supuesto. El público al que se dirige, por ejemplo, una nueva aplicación de teléfono móvil, diferirá radicalmente del público al que se dirige un software científico. Incluso si la misma persona utiliza ambos, sus expectativas para cada uno son diferentes: un investigador que utilice un software científico puede tolerar una interfaz menos pulida a cambio de una gran funcionalidad, mientras que esa misma persona puede dejar de utilizar la aplicación móvil si encuentra que su interfaz de usuario es demasiado difícil de usar al cabo de unos días.

Además, cada usuario es único. Lo que a una persona le resulta difícil, a la siguiente no. El truco consiste en averiguar qué es lo que ocurre en general con tus usuarios, lo que significa aprender sobre suficientes usuarios individuales para separar las peculiaridades de los patrones de comportamiento comunes .

Concretamente, querrás aprender lo siguiente:

• Sus objetivos al utilizar el software o el sitio

• Las tareas específicas que realizan para alcanzar esos objetivos

• El lenguaje y las palabras que utilizan para describir lo que hacen

• Su destreza en el uso de software similar al que estás diseñando

• Sus actitudes hacia el tipo de cosa que estás diseñando, y cómo diferentes diseños podrían afectar a esas actitudes

No puedo decirte cómo es tu público objetivo concreto. Tienes que averiguar qué podrían hacer con el software o el sitio web, y cómo encaja en el contexto más amplio de sus vidas. Por difícil que sea, intenta describir a tu público potencial en términos de cómo y por qué podrían utilizar tu software. Puede que obtengas varias respuestas distintas, que representen a grupos de usuarios distintos; no pasa nada. Podrías sentir la tentación de levantar las manos y decir: "No sé quiénes son los usuarios", o "Todo el mundo es un usuario potencial". Pero eso no te ayuda en absoluto a enfocar tu diseño: sin una descripción concreta y honesta de esas personas, tu diseño avanzará sin ningún fundamento en la realidad.

Esta fase de descubrimiento del usuario consumirá tiempo y recursos al principio del ciclo de diseño, sobre todo si no sabes realmente quién es tu público y por qué podría utilizar tus diseños. Es una inversión. Merece la pena porque la comprensión que tú y el equipo obtenéis se traduce a largo plazo en mejores diseños: que resuelven los problemas correctos y se ajustan a su finalidad.

Afortunadamente, ahora existen muchos libros, cursos y metodologías para ayudarte. Aunque este libro no aborda la investigación de usuarios, a continuación se exponen algunos métodos y temas a tener en cuenta.

Observación directa

Las entrevistas y las visitas a los usuarios in situ te sitúan directamente en su mundo. Puedes preguntar a los usuarios cuáles son sus objetivos y qué tareas suelen hacer. Las entrevistas, que suelen hacerse "in situ", donde los usuarios utilizarían realmente el programa (por ejemplo, en un lugar de trabajo o en casa), pueden ser estructuradas -con un conjunto predefinido de preguntas- o no estructuradas, en las que sondeas cualquier tema que surja. Las entrevistas te dan mucha flexibilidad; puedes hacer muchas o pocas, largas o cortas, formales o informales, por teléfono o en persona. Son grandes oportunidades para aprender lo que no sabes. Pregunta por qué. Vuelve a preguntarlo.

Casos prácticos

Los estudios de casos te ofrecen una visión profunda y detallada de unos pocos usuarios o grupos de usuarios representativos. A veces puedes utilizarlos para explorar usuarios "extremos" que amplían los límites de lo que el software puede hacer, especialmente cuando el objetivo es un rediseño del software existente. También puedes utilizarlos como estudios longitudinales, para explorar el contexto de uso a lo largo de meses o incluso años. Por último, si estás diseñando un software a medida para un único usuario o sitio, querrás aprender todo lo posible sobre el contexto real de uso.

Encuestas

Las encuestas escritas pueden recoger información de muchos usuarios. Con ellas puedes conseguir un número estadísticamente significativo de encuestados. Como no hay contacto humano directo, perderás mucha información adicional -lo que no preguntes, no lo sabrás-, pero puedes obtener una imagen muy clara de ciertos aspectos de tu público objetivo. El diseño cuidadoso de la encuesta es esencial. Si quieres cifras fiables en lugar de una "sensación" cualitativa del público objetivo, es absolutamente necesario que redactes las preguntas correctamente, elijas a los destinatarios de la encuesta correctamente y analices las respuestas correctamente, y eso es una ciencia.

Puedes encontrar más directrices para redactar preguntas de encuesta eficaces aquí:

• Redactar buenas preguntas de encuesta

• Hoja de consejos para el diseño de cuestionarios

Personas

Los personajes no son un método de recopilación de datos, pero te ayudan a saber qué hacer con ellos una vez que los tienes. Se trata de una técnica de diseño que modela las audiencias objetivo. Para cada grupo de usuarios importante, creas una persona ficticia, o "proto-persona", que capta los aspectos más importantes de los usuarios de ese grupo: qué tareas intentan realizar, sus objetivos finales y sus niveles de experiencia en el dominio del tema y con los ordenadores en general. Los personajes pueden ayudarte a mantenerte centrado. A medida que avanza tu diseño, puedes hacerte preguntas como: "¿Haría realmente X esta persona ficticia? ¿Qué haría en su lugar?".

La investigación de diseño no es investigación de marketing

Puede que notes que algunos de estos métodos y temas, como las entrevistas y las encuestas, suenan sospechosamente a actividades de marketing. Están estrechamente relacionadas. Los grupos de discusión, por ejemplo, pueden ser útiles, pero ten cuidado. En los grupos, no todo el mundo habla, y una o dos personas pueden dominar la discusión y sesgar tu comprensión. También existe la sólida práctica de marketing de la segmentación del mercado. Se parece a la definición de público objetivo utilizada aquí, pero los segmentos de mercado se definen por características demográficas, psicográficas y de otro tipo. Desde el punto de vista del diseño de la interfaz de usuario, el público objetivo se define por sus objetivos y comportamientos.

En ambos casos, de lo que se trata es de entender al público lo mejor que puedas. La diferencia es que, como diseñador, intentas comprender a las personas que utilizan el software. Un profesional del marketing intenta comprender a quienes lo compran.

No es fácil comprender los verdaderos problemas que subyacen a las interacciones de los usuarios con un sistema. Los usuarios no siempre tienen el lenguaje o la capacidad de introspección necesarios para explicar lo que realmente necesitan para lograr sus objetivos, y requiere mucho trabajo por tu parte desentrañar conceptos de diseño útiles a partir de lo que pueden contarte: las observaciones autodeclaradas suelen estar sesgadas de forma sutil.

Algunas de estas técnicas son muy formales, y otras no. Los métodos formales y cuantitativos son valiosos porque son buena ciencia. Cuando se aplican correctamente, te ayudan a ver el mundo como es en realidad, no como crees que es. Si haces la investigación de usuarios al azar, sin tener en cuenta sesgos como la autoselección de los usuarios, puedes acabar con datos que no reflejen a tu público objetivo real, y eso sólo puede perjudicar a tu diseño a largo plazo.

Pero incluso si no tienes tiempo para métodos formales, es mejor reunirte informalmente con algunos usuarios que no hacer ningún descubrimiento. Hablar con los usuarios es bueno para el alma. Si eres capaz de empatizar con los usuarios e imaginar a esas personas utilizando realmente tu diseño, producirás algo mucho mejor.

Los Patrones: Cognición y comportamiento relacionados con el diseño de interfaces

Los patrones que siguen son algunas de las formas más comunes de pensar y comportarse de las personas en relación con las interfaces de software. Aunque los individuos son únicos, la gente en general se comporta de forma predecible. Los diseñadores llevan años haciendo visitas y observando a los usuarios; los científicos cognitivos y otros investigadores han pasado incontables horas observando cómo hacen las cosas las personas y cómo piensan sobre lo que hacen.

Por tanto, cuando observas a personas que utilizan tu software, o que realizan cualquier actividad que quieras apoyar con un nuevo software, puedes esperar que hagan determinadas cosas. Los patrones de comportamiento que siguen suelen verse en las observaciones de usuarios. Lo más probable es que tú también los veas, sobre todo si los buscas.

Nota

Para todos los entusiastas de los patrones: estos patrones no son como los demás de este libro. Describen comportamientos humanos -no elementos de diseño de la interfaz- y no son prescriptivos, como los patrones de otros capítulos. En lugar de estar estructurados como los demás patrones, se presentan como pequeños ensayos.

De nuevo, una interfaz que soporte bien estos patrones ayudará a los usuarios a alcanzar sus objetivos de forma mucho más eficaz que las interfaces que no los soportan. Y los patrones tampoco tienen que ver sólo con la interfaz. A veces, todo el paquete -interfaz, arquitectura subyacente, elección de características, documentación, todo- debe considerarse a la luz de estos comportamientos. Pero como diseñador de la interfaz o de la interacción, debes pensar en ellos tanto como cualquier otro miembro de tu equipo. Puede que estés en mejor posición que nadie para defender a los usuarios.

• Exploración segura

• Gratificación instantánea

• Satisfaciendo

• Cambios en Midstream

• Opciones aplazadas

• Construcción incremental

• Habituación

• Microbreaks

• Memoria espacial

• Memoria prospectiva

• Repetición racionalizada

• Sólo teclado

• Medios sociales, prueba social y colaboración

Exploración segura

"Déjame explorar sin perderme ni meterme en líos".

Cuando alguien siente que puede explorar una interfaz y no sufrir consecuencias nefastas, es probable que aprenda más -y se sienta más positivo al respecto- que alguien que no explora. Un buen software permite a la gente probar algo desconocido, echarse atrás y probar otra cosa, todo ello sin estrés.

Esas "consecuencias nefastas" ni siquiera tienen por qué ser muy malas. La mera molestia puede bastar para disuadir a alguien de probar cosas voluntariamente. Alejar las ventanas emergentes, volver a introducir datos que se borraron por error, silenciar de repente el volumen del portátil cuando un sitio web pone inesperadamente música a todo volumen... todo puede ser desalentador. Cuando diseñes casi cualquier tipo de interfaz de software, pon a disposición de los usuarios muchas vías de exploración para que experimenten, sin que al usuario le cueste nada.

Este patrón engloba varias de las pautas de usabilidad más eficaces, basadas en la investigación, identificadas por el experto en usabilidad Jakob Nielsen:²

• Visibilidad del estado del sistema

• Correspondencia entre el sistema y el mundo real

• Control y libertad del usuario

He aquí algunos ejemplos de lo que es la "Exploración Segura":

• Un fotógrafo prueba unos cuantos filtros de imagen en una aplicación de procesamiento de imágenes. Luego decide que no le gustan los resultados, y pulsa Deshacer varias veces para volver a donde estaba. Luego prueban otro filtro, y otro, pudiendo cada vez dar marcha atrás sobre lo que hicieron. (El patrón llamado Deshacer multinivel, en el Capítulo 8, describe cómo funciona esto).

• Un nuevo visitante de la página principal de una empresa hace clic en varios enlaces sólo para ver lo que hay, confiando en que el botón Atrás siempre le devolverá a la página principal. No se abren ventanas adicionales ni pop ups, y el botón Atrás sigue funcionando de forma predecible. Puedes imaginar que si una aplicación web hace algo diferente en respuesta al botón Atrás -o si una aplicación ofrece un botón que parece un botón Atrás, pero no se comporta exactamente como tal-, puede producirse confusión. El usuario puede desorientarse mientras navega y abandonar la aplicación.

Gratificación instantánea

"Quiero conseguir algo ahora, no más tarde".

A la gente le gusta ver resultados inmediatos de las acciones que realiza: es la naturaleza humana. Si alguien empieza a utilizar una aplicación y obtiene una "experiencia de éxito" en los primeros segundos, ¡eso es gratificante! Será más probable que sigan utilizándola, aunque luego les resulte más difícil. Sentirán más confianza en la aplicación, y más confianza en sí mismos, que si hubieran tardado un rato en entender las cosas.

La necesidad de apoyar la gratificación instantánea tiene muchas ramificaciones en el diseño. Por ejemplo, si puedes predecir lo primero que probablemente hará un nuevo usuario, debes diseñar la UI para que esa primera cosa sea asombrosamente fácil. Si el objetivo del usuario es crear algo, por ejemplo, crea un nuevo lienzo, pon una llamada a la acción en él y coloca una paleta junto a él. Si el objetivo del usuario es realizar alguna tarea, señala el camino hacia un punto de partida típico.

Esto también significa que no debes ocultar la funcionalidad introductoria detrás de nada que haya que leer o esperar, como registros, largos conjuntos de instrucciones, pantallas lentas de cargar, anuncios, etcétera. Estos elementos son desalentadores porque impiden que los usuarios terminen rápidamente esa primera tarea.

En resumen, anticipa su necesidad, proporciona un punto de entrada obvio, aporta valor al cliente primero antes de pedir algo valioso (dirección de correo electrónico, una venta) a cambio.

Satisfaciendo

"Con esto me basta. No quiero dedicar más tiempo a aprender a hacerlo mejor".

Cuando la gente mira una nueva interfaz, no lee metódicamente cada una de sus partes y luego decide: "Hmmm, yo creo que este botón tiene más posibilidades de conseguirme lo que quiero". En lugar de eso, un usuario escanea rápidamente la interfaz, elige lo primero que ve que puede darle lo que quiere y lo prueba, aunque pueda estar equivocado.

El término satisficing es una combinación de satisfying y sufficing. Fue acuñado en 1957 por el científico social Herbert Simon, que lo utilizó para describir el comportamiento de las personas en todo tipo de situaciones económicas y sociales. La gente está dispuesta a aceptar "lo suficientemente bueno" en lugar de "lo mejor" si conocer todas las alternativas puede costar tiempo o esfuerzo.

La satisfacción es, en realidad, un comportamiento muy racional después de apreciar el trabajo mental necesario para "analizar" una interfaz complicada. Como señala Steve Krug en su libro Don't Make Me Think, Revisited: A Common Sense Approach to Web Usability (New Riders, 2014), a la gente no le gusta pensar más de lo necesario: ¡es trabajo! Pero si la interfaz presenta una o dos opciones obvias que el usuario ve inmediatamente, lo intentará. Hay muchas probabilidades de que sea la opción correcta, y si no, no cuesta mucho echarse atrás y probar otra cosa (suponiendo que la interfaz admita la Exploración Segura).

Esto significa varias cosas para los diseñadores:

• Utiliza "llamadas a la acción" en la interfaz. Da indicaciones sobre qué hacer primero: escribe aquí, arrastra una imagen aquí, toca aquí para empezar, etc.

• Haz que las etiquetas sean breves, con palabras claras y rápidas de leer. (Esto incluye elementos de menú, botones, enlaces y cualquier otra cosa identificada por texto). Serán escaneadas y adivinadas; escríbelas de modo que la primera suposición de un usuario sobre el significado sea correcta. Si se equivoca varias veces, se sentirá frustrado y ambos empezaréis con mal pie.

• Utiliza la disposición de la interfaz para comunicar el significado. El Capítulo 4 explica en detalle cómo hacerlo. Los usuarios "analizan" el color y la forma a simple vista, y siguen estas pistas con más eficacia que las etiquetas que hay que leer.

• Haz que sea fácil moverse por la interfaz, sobre todo para volver a donde se pudo haber hecho precipitadamente una elección equivocada. Proporciona "escotillas de escape" (véase el Capítulo 3). En los sitios web típicos, utilizar el botón Atrás es fácil, por lo que diseñar una navegación fácil hacia delante/atrás es especialmente importante para las aplicaciones web, las aplicaciones instaladas y los dispositivos móviles.

• Ten en cuenta que una interfaz complicada impone un gran coste cognitivo a los nuevos usuarios. La complejidad visual suele tentar a los no expertos: buscan lo primero que pueda funcionar.

La satisfacción es la razón por la que muchos usuarios acaban teniendo hábitos extraños después de haber estado utilizando un sistema durante un tiempo. Hace mucho tiempo, un usuario puede haber aprendido la Ruta A para hacer algo, y aunque una versión posterior del sistema ofrezca la Ruta B como una alternativa mejor (o tal vez haya estado ahí todo el tiempo), no ve ninguna ventaja en aprenderla -después de todo, requiere esfuerzo- y sigue utilizando la Ruta A, menos eficiente. Romper viejos hábitos y aprender algo nuevo requiere energía, y una pequeña mejora puede no merecer la pena para el usuario.

Cambios en Midstream

"Cambié de opinión sobre lo que estaba haciendo".

Ocasionalmente, la gente cambia lo que está haciendo mientras está en el medio de hacerlo. Alguien puede entrar en una habitación con la intención de encontrar una llave que se había dejado allí, pero mientras está allí, encuentra un periódico y empieza a leerlo. O puede que visiten Amazon.com para leer reseñas de productos, pero acaben comprando un libro en su lugar. Puede que simplemente se desvíen; puede que el cambio sea deliberado. En cualquier caso, el objetivo del usuario cambia mientras utiliza la interfaz que has diseñado.

Esto significa que los diseñadores deben ofrecer oportunidades para que la gente lo haga. Ofrece opciones. No encierres a los usuarios en un entorno sin opciones, sin conexiones con otras páginas o funcionalidades, a menos que haya una buena razón para hacerlo. Esas razones existen. Consulta los patrones denominados Asistente(Capítulo 2) y Panel Modal(Capítulo 3) para ver algunos ejemplos.

También puedes facilitar que alguien inicie un proceso, se detenga a la mitad y vuelva a él más tarde para retomarlo donde lo dejó, lo que suele denominarse reentrada. Por ejemplo, un abogado puede empezar a introducir información en un formulario en un iPad. Luego, cuando un cliente entra en la sala, el abogado apaga el dispositivo, con la intención de volver más tarde para terminar el formulario. La información introducida no debería perderse.

Para soportar la reentrada, puedes hacer que los cuadros de diálogo y los formularios web recuerden los valores tecleados previamente, y normalmente no necesitan ser modales; si no son modales, pueden arrastrarse a un lado de la pantalla para su uso posterior. Las aplicaciones de estilo constructor -editores de texto, entornos de desarrollo de código y programas de pintura- pueden permitir que un usuario trabaje en varios proyectos de a la vez, permitiéndole así dejar a un lado cualquier número de proyectos mientras trabaja en otro. Para más información, consulta el patrón Muchos espacios de trabajo en el Capítulo 2.

Opciones aplazadas

"No quiero responder a eso ahora; ¡déjame terminar!".

Esto se debe al deseo de gratificación instantánea de las personas. Si haces preguntas innecesarias en el proceso a un usuario centrado en la tarea, puede que prefiera saltárselas y volver a ellas más tarde.

Por ejemplo, algunos tablones de anuncios en Internet tienen procedimientos largos y complicados para registrar a los usuarios. Nombres de pantalla, direcciones de correo electrónico, preferencias de privacidad, avatares, autodescripciones... la lista es interminable. "Pero yo sólo quería publicar una cosita", dice el usuario. ¿Por qué no permitirles que se salten la mayoría de las preguntas, respondan lo mínimo y vuelvan más tarde (si es que vuelven) para rellenar el resto? De lo contrario, podrían estar allí media hora respondiendo preguntas de redacción y buscando la imagen de avatar perfecta.

Otro ejemplo es crear un nuevo proyecto en un editor de vídeo. Hay algunas cosas que tienes que decidir por adelantado, como el nombre del proyecto, pero otras opciones -¿en qué parte del servidor vas a poner esto cuando termines? Aún no lo sé! -pueden aplazarse fácilmente.

A veces, es sólo cuestión de no querer responder a las preguntas. Otras veces, puede que el usuario aún no tenga suficiente información para responder. ¿Qué pasaría si un paquete de software de composición musical te preguntara por adelantado el título, la clave y el tempo de una nueva canción, antes incluso de que hayas empezado a escribirla? (Véase GarageBand de Apple para este trozo de "buen" diseño).

Las implicaciones para el diseño de la interfaz son sencillas de entender, aunque no siempre fáciles de poner en práctica:

• En primer lugar, no acoses al usuario con demasiadas opciones por adelantado.

• En los formularios que tengan que utilizar, indica claramente los campos obligatorios frente a los opcionales, y no hagas obligatorios demasiados. Deja que sigan adelante sin responder a los opcionales.

• A veces puedes separar las pocas preguntas u opciones importantes de otras que lo son menos. Presenta la lista corta; oculta la larga.

• Utiliza Buenos Predeterminados(Capítulo 10) siempre que sea posible, para dar a los usuarios algunas respuestas predeterminadas razonables con las que empezar. Pero ten en cuenta que las respuestas prefijadas siguen requiriendo que el usuario las mire, por si hay que cambiarlas. También tienen un pequeño coste.

• Haz posible que los usuarios vuelvan a los campos aplazados más tarde, y hazlos accesibles en lugares obvios. Algunos cuadros de diálogo muestran al usuario una breve declaración, como "Siempre puedes cambiar esto más tarde haciendo clic en el botón Editar proyecto". Algunos sitios web almacenan las entradas de formularios a medio completar de un usuario u otros datos persistentes, como carros de la compra con artículos sin comprar.

• Si es necesario registrarse en un sitio web que ofrece servicios útiles, es mucho más probable que los usuarios se registren si primero se les permite experimentar el sitio web -atraídos y comprometidos- y después se les pregunta quiénes son. Algunos sitios te permiten completar toda una compra sin registrarte y luego te preguntan al final si quieres crear un inicio de sesión sin complicaciones con la información personal facilitada en el paso de compra.

Construcción incremental

"Déjame cambiar esto. Eso no queda bien; déjame cambiarlo otra vez. Así está mejor".

Cuando la gente crea cosas, no suele hacerlo todo en un orden preciso. Ni siquiera un experto empieza por el principio, trabaja metódicamente en el proceso de creación y al final obtiene algo perfecto y acabado.

Todo lo contrario. En lugar de eso, empiezan con una pequeña parte, trabajan en ella, dan un paso atrás y la revisan, la prueban (si es código o alguna otra cosa "ejecutable"), arreglan lo que está mal y empiezan a construir otras partes. O quizá empiecen de nuevo, si realmente no les gusta. El proceso creativo va a trompicones. A veces retrocede tanto como avanza, y a menudo es incremental, se realiza en una serie de pequeños cambios en lugar de unos pocos grandes. A veces es descendente y otras ascendente.

Las interfaces de estilo constructor deben apoyar ese estilo de trabajo. Facilita a los usuarios la construcción de piezas pequeñas. Haz que la interfaz responda a cambios y guardados rápidos. La retroalimentación es fundamental: muestra constantemente al usuario el aspecto y el comportamiento del conjunto mientras trabaja. Si el usuario construye código, simulaciones u otras cosas ejecutables, haz que la parte de "compilación" del ciclo sea lo más corta posible, para que la retroalimentación operativa se sienta inmediata: deja poco o ningún retraso entre que el usuario hace cambios y ve los resultados.

Cuando las actividades creativas están bien respaldadas por buenas herramientas, pueden inducir un estado de flujo en el usuario. Se trata de un estado de absorción total en la actividad, durante el cual el tiempo se distorsiona, otras distracciones desaparecen y la persona puede permanecer ocupada durante horas: el disfrute de la actividad es su propia recompensa. Los artistas, los atletas y los programadores conocen este estado.

Pero las malas herramientas mantendrán distraídos a los usuarios, garantizado. Si el usuario debe esperar aunque sólo sea medio minuto para ver los resultados del cambio incremental que acaba de hacer, su concentración se rompe; el flujo se interrumpe.

Si quieres leer más sobre el flujo, hay varios libros del investigador Mihaly Csikszentmihalyi. Uno de ellos es Flow: The Psychology of Optimal Experience. (Harper Row, 2009).

Habituación

"Ese gesto funciona en todas partes; ¿por qué no funciona también aquí?".

Cuando utilizas una interfaz repetidamente, algunas acciones físicas frecuentes de se vuelven reflejas: pulsar Ctrl-S para guardar un documento, hacer clic en el botón Atrás para salir de una página web, pulsar Retorno para cerrar un cuadro de diálogo modal, utilizar gestos para mostrar y ocultar ventanas, incluso pisar el pedal de freno de un coche. El usuario ya no necesita pensar conscientemente en estas acciones. Se han convertido en habituales.

Esta tendencia ayuda a las personas a convertirse en usuarios expertos de una herramienta (y también ayuda a crear una sensación de fluidez). La habituación también mejora notablemente la eficacia, como puedes imaginar. Pero también puede tender trampas al usuario. Si un gesto se convierte en un hábito y el usuario intenta utilizarlo en una situación en la que no funciona -o, lo que es peor, hace algo destructivo-, el usuario se queda atrapado. De repente tiene que volver a pensar en la herramienta (¿Qué acabo de hacer? ¿Cómo hago lo que pretendía?), y puede que tenga que deshacer cualquier daño causado por el gesto.

Millones de personas han aprendido los siguientes atajos de teclado basándose en el uso de Microsoft Word y otros procesadores de texto:

Ctrl-X

Corta la selección

Ctrl-V

Pega la selección

Ctrl-S

Guardar el documento

Estos atajos son ahora verdaderos universales. La coherencia entre aplicaciones puede ser una ventaja para utilizar en el diseño de tu software. Pero igual de importante es la coherencia dentro de una aplicación. Algunas aplicaciones son malvadas porque establecen la expectativa de que algún gesto hará la Acción X, excepto en un modo especial en el que de repente hace la Acción Y. No hagas eso. Es una apuesta segura que los usuarios cometerán errores, y cuanto más experimentados sean -es decir, cuanto más habituados estén- más probable es que cometan ese error.

Considera esto cuidadosamente si estás desarrollando interfaces basadas en gestos para dispositivos móviles. Después de que alguien aprenda a utilizar su dispositivo y se acostumbre a él, dependerá de que los gestos estándar funcionen de forma coherente en todas las aplicaciones. Comprueba que todos los gestos de tu diseño hacen lo que se espera de ellos.

Ésta es también la razón por la que los cuadros de diálogo de confirmación a menudo no funcionan para proteger al usuario contra cambios accidentales. Cuando aparecen cuadros de diálogo modales, el usuario puede deshacerse de ellos fácilmente haciendo clic en Aceptar o pulsando Retorno (si el botón Aceptar es el botón predeterminado). Si los cuadros de diálogo aparecen todo el tiempo cuando el usuario hace cambios intencionados, como borrar archivos, hacer clic en OK se convierte en una respuesta acostumbrada. Entonces, cuando realmente importa, el cuadro de diálogo no tiene ningún efecto, porque pasa desapercibido para el usuario.

Nota

He visto al menos una aplicación que configura los botones del cuadro de diálogo de confirmación de forma aleatoria de una invocación a otra. De hecho, ¡tienes que leer los botones para saber qué pulsar! No es necesariamente la mejor forma de hacer un cuadro de diálogo de confirmación -de hecho, es mejor no tenerlo en la mayoría de las circunstancias-, pero al menos este diseño evita la habituación de forma creativa.

Microbreaks

"Estoy esperando el tren. Déjame hacer algo útil durante dos minutos".

La gente se encuentra a menudo con unos minutos de tiempo de inactividad. Puede que necesiten un descanso mental mientras trabajan; puede que estén en la cola de una tienda o sentados en un atasco. Pueden estar aburridos o impacientes. Quieren hacer algo constructivo o entretenido para pasar el tiempo, sabiendo que no tendrán tiempo suficiente para meterse de lleno en una actividad online.

Este patrón es especialmente aplicable a los dispositivos móviles, porque la gente puede sacarlos fácilmente en momentos como éste. El enorme éxito del sector tecnológico de los medios sociales se construyó en gran parte aprovechando esto. Los juegos sociales y casuales, Facebook, Instagram, Snap... todos se disfrutan en microbreaks.

He aquí algunas actividades típicas durante las micro pausas:

• Comprobar el correo electrónico

• Lectura de flujos y feeds (en el capítulo 2) como Facebook o Twitter

• Visitar un sitio de noticias para enterarte de lo que pasa en el mundo

• Ver un vídeo corto

• Haciendo una búsqueda rápida en Internet

• Leer un libro online

• Jugar un partido corto

La clave para apoyar las micro pausas es hacer que una actividad sea fácil y rápida de alcanzar: tan fácil como encender el dispositivo y seleccionar una aplicación (o sitio web). Que no requiera una configuración complicada. No tardes una eternidad en cargar. Y si el usuario necesita iniciar sesión en un servicio, intenta conservar la autenticación anterior para que no tenga que hacerlo cada vez.

Para los servicios "Stream y Feed", carga el contenido más fresco lo antes posible y muéstralo en la primera pantalla que vea el usuario. Otras actividades, como juegos, vídeos o libros en línea, deben recordar dónde las dejó el usuario la última vez y restaurar la aplicación o el sitio a su estado anterior, sin preguntar (apoyando así la reentrada).

Si estás diseñando una aplicación de correo electrónico o cualquier otra para la que el usuario necesite hacer "limpieza" para mantener el orden, dale una forma de clasificar los elementos de forma eficiente. Esto significa mostrar suficientes datos por elemento para que puedan identificar, por ejemplo, el contenido y el remitente de un mensaje. También puedes darles la oportunidad de "marcar" o anotar de otro modo los elementos de interés, eliminar elementos fácilmente y escribir respuestas breves y actualizaciones.

Los tiempos de carga largos merecen otra mención. Tardar demasiado en cargar el contenido es una forma segura de hacer que los usuarios abandonen tu aplicación, ¡especialmente durante las micro pausas! Asegúrate de que la página está diseñada para que el contenido legible y útil se cargue primero, y con muy poco retraso.

Memoria espacial

"Juro que ese botón estaba aquí hace un minuto. ¿Adónde se ha ido?"

Cuando las personas manipulan objetos y documentos, suelen volver a encontrarlos más tarde recordando dónde están, no cómo se llaman.

Por ejemplo, el escritorio de Windows, Mac o Linux. Mucha gente utiliza el fondo del escritorio como lugar para colocar documentos, aplicaciones de uso frecuente y otras cosas por el estilo. Resulta que la gente tiende a utilizar la memoria espacial para encontrar cosas en el escritorio, y es muy eficaz. La gente idea sus propias agrupaciones, por ejemplo, o recuerda que "este documento estaba arriba a la derecha, junto a tal y tal cosa". (Naturalmente, también hay equivalentes en el mundo real. Los escritorios de muchas personas son un "caos organizado", un aparente desorden en el que el dueño de la oficina puede encontrar cualquier cosa al instante. Pero el cielo no quiera que alguien se lo limpie).

Muchas aplicaciones colocan sus botones de diálogo -OK, Cancelar, y etc.- en lugares predecibles, en parte porque la memoria espacial para ellos es muy fuerte. En aplicaciones complejas, la gente también puede encontrar cosas recordando dónde están en relación con otras cosas: herramientas en las barras de herramientas de, objetos en jerarquías, etc. Por lo tanto, debes utilizar con cuidado patrones como la Habilitación responsiva(Capítulo 4). Añadir elementos a los espacios vacíos de una interfaz no causa problemas, pero reordenar los controles existentes puede alterar la memoria espacial y hacer que las cosas sean más difíciles de encontrar. Depende. Pruébalo con tus usuarios si no estás seguro.

Muchas aplicaciones y juegos para móviles constan de unas pocas pantallas. A menudo, la pantalla de inicio está diseñada para ser donde los usuarios pasen todo su tiempo. Puede que no haya navegación aparente. Pero los usuarios aprenden a deslizar el dedo a izquierda, derecha, arriba o abajo para llegar a las otras pantallas (como la de mensajería o ajustes). Estas otras pantallas están ahí, justo al lado. Snap es un buen ejemplo de aplicación móvil diseñada para utilizar la memoria espacial de las personas.

Junto con la habituación, que está estrechamente relacionada, la memoria espacial es otra razón por la que es buena la coherencia entre las aplicaciones de una plataforma y dentro de ellas. La gente puede esperar encontrar funcionalidades similares en lugares similares. Para ver un ejemplo, consulta el patrón Herramientas de inicio de sesión(Capítulo 3).

La memoria espacial explica por qué es bueno proporcionar zonas organizadas por el usuario para almacenar documentos y objetos, como el escritorio antes mencionado. Este tipo de cosas no siempre son prácticas, sobre todo con grandes cantidades de objetos, pero funciona bastante bien con cantidades pequeñas. Cuando la gente ordena las cosas por sí misma, es probable que recuerde dónde las puso. (El patrón Paneles móviles del Capítulo 4 describe una forma concreta de hacerlo.

Además, esta es la razón por la que cambiar los menús dinámicamente a veces puede ser contraproducente. La gente se acostumbra a ver determinados elementos en la parte superior e inferior de los menús. Reorganizar o compactar los elementos del menú de forma "útil" puede ir en contra de la habituación y provocar errores en el usuario. Lo mismo puede ocurrir al cambiar los menús de navegación de las páginas web. Intenta mantener los elementos del menú en el mismo lugar y en el mismo orden en todas las subpáginas de un sitio.

Por cierto, las partes superior e inferior de las listas y los menús son lugares especiales, cognitivamente hablando. La gente se fija más en ellos y los recuerda mejor que los elementos del centro de una lista. Los primeros y los últimos elementos de una lista tienen más probabilidades de llamar la atención. Por tanto, si quieres llamar la atención sobre uno o dos elementos de una lista de elementos, colócalos al principio o al final. Los elementos colocados en el medio tienen menos probabilidades de llamar la atención o de ser recordados.

Memoria prospectiva

"Pongo esto aquí para recordarme que tengo que ocuparme de ello más tarde".

La memoria prospectiva es un fenómeno bien conocido en psicología que todavía no parece haber ganado mucha tracción en el diseño de interfaces. Pero creo que debería.

Ejercemos la memoria prospectiva cuando planeamos hacer algo en el futuro, y organizamos alguna forma de recordarnos a nosotros mismos que debemos hacerlo. Por ejemplo, si tienes que llevar un libro al trabajo al día siguiente, la noche anterior podrías ponerlo en una mesa junto a la puerta de entrada. Si tienes que responder al correo electrónico de alguien más tarde (¡pero no ahora mismo!), podrías dejar ese correo en tu pantalla como recordatorio físico. O si tiendes a faltar a las reuniones, puedes hacer que Outlook o tu dispositivo móvil emitan un tono de alarma cinco minutos antes de cada reunión.

Básicamente, esto es algo que hace casi todo el mundo. Forma parte de cómo afrontamos nuestras complicadas vidas, altamente programadas y multitarea: utilizamos el conocimiento "en el mundo" para ayudar a nuestros propios recuerdos imperfectos. Tenemos que ser capaces de hacerlo bien.

Algunos programas sí admiten el recuerdo prospectivo. Outlook y la mayoría de las plataformas móviles, como ya se ha mencionado, lo implementan directa y activamente; tienen calendarios y hacen sonar alarmas. Trello es otro ejemplo; es un tablero Kanban de tarjetas. Las ayudas para la memoria que utilizan las personas pueden ser las siguientes:

• Notas para uno mismo, como "notas adhesivas" virtuales

• Ventanas dejadas en pantalla

• Anotaciones puestas directamente en los documentos (como "¡Termina conmigo!")

• Marcadores del navegador, para ver sitios web más tarde

• Documentos almacenados en el escritorio en lugar de en los lugares habituales del sistema de archivos

• El correo electrónico se guarda en una bandeja de entrada (y tal vez se marca) en lugar de archivarse

La gente utiliza todo tipo de artefactos para apoyar el recuerdo prospectivo pasivo. Pero fíjate en que casi ninguna de las técnicas de la lista anterior se diseñó pensando en eso. Para lo que fueron diseñadas es para la flexibilidad y para una actitud de laissez-faire respecto a la forma en que los usuarios organizan sus cosas. Un buen cliente de correo electrónico te permite crear carpetas con los nombres que quieras, y no le importa lo que hagas con los mensajes de tu bandeja de entrada. A los editores de texto no les importa lo que escribes, ni lo que significa para ti un texto magenta gigante en negrita; a los editores de código no les importa que tengas un comentario "Finaliza esto" en la cabecera de un método. A los navegadores no les importa por qué guardas ciertos marcadores.

En muchos casos, ese tipo de flexibilidad sin intervención es todo lo que realmente necesitas. Da a la gente las herramientas para crear sus propios sistemas de recordatorio. Pero no intentes diseñar un sistema que sea demasiado inteligente para su propio bien. Por ejemplo, no des por sentado que, sólo porque una ventana lleve un tiempo inactiva, nadie la está utilizando y debe cerrarse. En general, no limpies "útilmente" archivos u objetos que el sistema pueda considerar inútiles; puede que alguien los esté dejando por ahí por alguna razón. Tampoco organices ni clasifiques las cosas automáticamente, a menos que el usuario se lo pida al sistema.

Como diseñador, ¿hay algo positivo que puedas hacer por la memoria prospectiva? Si alguien deja un formulario a medias y lo cierra temporalmente, podrías retener los datos que contiene para la próxima vez: ayudará a recordar al usuario dónde lo dejó. (Consulta el patrón de Opciones Diferidas.) De forma similar, muchas aplicaciones recuerdan los últimos objetos o documentos que editaron. Podrías ofrecer listas de "objetos de interés" -tanto pasados como futuros- similares a los marcadores, y hacer que esas listas estén fácilmente disponibles para su lectura y edición. Puedes implementar Muchos Espacios de Trabajo(Capítulo 2), que permite a los usuarios dejar abiertas páginas inacabadas mientras trabajan en otra cosa.

He aquí un reto mayor: si el usuario inicia tareas y las abandona sin terminarlas, piensa en cómo dejar algunos artefactos por ahí, aparte de las ventanas abiertas, que identifiquen las tareas inacabadas. Otra idea: ¿cómo podría un usuario reunir recordatorios de distintas fuentes (correo electrónico, documentos, calendarios, etc.) en un solo lugar?

Repetición racionalizada

" ¿Cuántas veces tengo que repetirlo?"

En muchos tipos de aplicaciones, los usuarios a veces se ven en la necesidad de realizar la misma operación una y otra vez. Cuanto más fácil les resulte, mejor. Si puedes ayudar a reducir esa operación a una pulsación o clic por repetición -o, mejor, a unas pocas pulsaciones o clics para todas las repeticiones- ahorrarás mucho tedio a los usuarios.

Los cuadros de diálogo Buscar y reemplazar, que suelen encontrarse en los editores de texto (Word, compositores de correo electrónico, etc.), son una buena adaptación de a este comportamiento. En estos cuadros de diálogo, el usuario escribe la frase antigua y la nueva. Entonces, sólo se necesita un clic en el botón Reemplazar por cada ocurrencia en todo el documento. Y eso sólo si el usuario quiere ver o vetar cada sustitución. Si está seguro de que realmente debe reemplazar todas las ocurrencias, puede hacer clic en el botón Reemplazar todo; un solo gesto hace todo el trabajo.

He aquí un ejemplo más general. Photoshop te permite grabar "acciones" cuando quieras realizar alguna secuencia arbitraria de acciones con un solo clic. Si quieres cambiar el tamaño, recortar, aclarar y guardar 20 imágenes, puedes grabar esos cuatro pasos mientras se realizan en la primera imagen, y luego hacer clic en el botón Reproducir de esa acción para cada una de las 19 restantes. Para más información, consulta el patrón Macros en el Capítulo 8.

Los entornos de scripting son aún más generales. Unix y sus variantes te permiten programar cualquier cosa que puedas escribir en un intérprete de comandos. Puedes recuperar y ejecutar comandos individuales, incluso largos, con un Ctrl-P y Retorno. Puedes tomar cualquier conjunto de comandos que envíes a la línea de comandos, ponerlos en un bucle for y ejecutarlos pulsando una vez la tecla Retorno.

O puedes ponerlos en un script de shell (o en un bucle for de un script de shell) y ejecutarlos como un único comando. Las secuencias de comandos son muy potentes y, cuando son complejas, se convierten en programación en toda regla.

Otras variantes incluyen la capacidad de copiar y pegar (evitando la necesidad de volver a escribir lo mismo en un millón de sitios), "atajos" definidos por el usuario para aplicaciones en escritorios de sistemas operativos (evitando la necesidad de encontrar los directorios de esas aplicaciones en el sistema de archivos), marcadores de navegador (para que los usuarios no tengan que escribir URLs), e incluso atajos de teclado.

La observación directa de los usuarios puede ayudarte a determinar qué tipo de tareas repetitivas necesitas apoyar. Los usuarios no siempre te lo dirán abiertamente. Puede que ni siquiera sean conscientes de que están haciendo cosas repetitivas que podrían racionalizarse con las herramientas adecuadas; puede que lleven tanto tiempo haciéndolo que ya ni siquiera se den cuenta. Observándoles trabajar, puede que veas lo que ellos no ven.

En cualquier caso, la idea es ofrecer a los usuarios formas de agilizar las tareas repetitivas que, de otro modo, podrían ser lentas, tediosas y propensas a errores. Para más información, consulta Macros en el Capítulo 8.

Sólo teclado

"Por favor, no me hagas utilizar el ratón".

Algunas personas tienen verdaderos problemas físicos para utilizar el ratón. Otras prefieren no tener que alternar entre el ratón y el teclado porque eso lleva tiempo y esfuerzo; prefieren tener las manos en el teclado en todo momento. Otras no pueden ver la pantalla, y sus tecnologías de apoyo suelen interactuar con el software utilizando sólo la API del teclado.

Por el bien de estos usuarios, algunas aplicaciones están diseñadas para ser "manejadas" totalmente mediante el teclado. Normalmente también se manejan con el ratón, pero no hay ninguna operación que deba hacerse sólo con el ratón: los usuarios que sólo utilizan el teclado no están excluidos de ninguna funcionalidad.

Existen varias técnicas estándar para utilizar sólo el teclado:

• Puedes definir atajos de teclado, aceleradores y mnemotécnicos para operaciones accesibles a través de las barras de menú de las aplicaciones, como Ctrl-S para Guardar. Consulta la guía de estilo de tu plataforma para conocer los estándar.

• La selección de listas, incluso la selección múltiple, suele ser posible utilizando las teclas de flecha en combinación con modificadores (como la tecla Mayúsculas), aunque esto depende del conjunto de componentes que utilices.

• La tecla Tab normalmente mueve el foco del teclado -el control que recibe las entradas del teclado en ese momento- de un control al siguiente, y Mayúsculas-Tab se mueve hacia atrás. A esto se le llama a veces desplazamiento con tabulador. Muchos usuarios esperan que funcione en interfaces de tipo formulario.

• La mayoría de los controles estándar, incluso los botones de opción y los cuadros combinados, permiten a los usuarios cambiar sus valores desde el teclado mediante las teclas de flecha, la tecla Retorno o la barra espaciadora.

• Los cuadros de diálogo y las páginas web suelen tener un "botón predeterminado": un botón que representa una acción que dice "Ya he terminado con esta tarea". En las páginas web, suele ser Enviar o Hecho; en los cuadros de diálogo, Aceptar o Cancelar. Cuando los usuarios pulsan la tecla Retorno en esta página o cuadro de diálogo, esa es la operación que se produce. Entonces, se mueve al usuario a la página siguiente o se le devuelve a la ventana anterior.

Hay más técnicas. Los formularios, los paneles de control y las páginas web estándar son bastante fáciles de manejar desde el teclado. Los editores gráficos, y cualquier otra cosa que sea principalmente espacial, son mucho más difíciles, aunque no imposibles.

El uso exclusivo del teclado es especialmente importante en las aplicaciones de introducción de datos. En ellas, la velocidad de introducción de datos es crítica, y los usuarios no pueden permitirse mover las manos del teclado al ratón cada vez que quieran pasar de un campo a otro o incluso de una página a otra. (De hecho, muchos de estos formularios ni siquiera requieren que los usuarios pulsen la tecla Tabulador para pasar de un control a otro; lo hace automáticamente).

Medios sociales, prueba social y colaboración

"¿Qué han dicho los demás sobre esto?"

Las personas somos sociales. Por muy firmes que sean a veces nuestras opiniones, tendemos a dejarnos influir por lo que dicen y hacen nuestros iguales. Y estamos muy acostumbrados a buscar la aprobación de los demás y a pertenecer a un grupo. Mantenemos identidades en las redes sociales. Contribuimos a grupos y personas que nos importan.

El consejo de los compañeros, ya sea directo o indirecto, influye en las elecciones de las personas cuando deciden cualquier cantidad de cosas. Encontrar cosas en Internet, realizar transacciones (¿Debería comprar este producto?), jugar a juegos (¿Qué han hecho otros jugadores aquí?), e incluso construir cosas: la gente puede ser más eficaz cuando cuenta con la ayuda de otros. Si no, al menos pueden estar más contentos con el resultado.

Es mucho más probable que miremos, leamos, compremos, nos unamos, compartamos, comentemos o realicemos cualquier otra acción si vemos que alguien que conocemos lo ha recomendado, lo ha hecho o está presente. Esto se llama prueba social.

Todas estas dinámicas del mundo real sustentan la escala masiva y el éxito de la informática social en sus múltiples formas. Es justo decir que un aspecto o capa social forma parte de casi todo el software actual. Habilitar la dinámica social en tu software puede aumentar la participación, la viralidad, la comunidad y el crecimiento.

Aquí tienes algunos ejemplos de funcionalidad social:

Opiniones y comentarios generados por los usuarios

Permiten a los individuos hacerse una idea de la sabiduría de la multitud. Las opiniones pueden calificarse, y los participantes pueden ganar fama u otras recompensas por ser calificados como buenos críticos.

Todo es un objeto social

Mensajes de texto, imágenes, vídeos, check-ins, casi cualquier cosa que los usuarios creen en las redes sociales se convierte en un objeto en torno al cual la gente puede reunirse virtualmente. Cualquier cosa puede compartirse, valorarse, tener un hilo de debate adjunto, y actividades similares.

Colaboración

Software de productividad y comunicación empresarial se ha transformado gracias a un software que permite que personas separadas por el espacio y el tiempo se reúnan en hilos de discusión, revisiones de documentos, videoconferencias, seguimiento del estado, comunicaciones en directo y asíncronas, y muchas otras actividades.

La prueba social motiva a la gente a actuar. La identidad del grupo social, la participación y el reconocimiento son poderosamente gratificantes para las personas.

Diseñar estas capacidades en tu interfaz crea la oportunidad de que las dinámicas sociales aumenten el compromiso, la recompensa y el crecimiento de tus audiencias.

De los patrones de este libro, Sistemas de ayuda(Capítulo 2) es el que aborda más directamente esta idea; una comunidad de ayuda en línea es una parte valiosa de un sistema de ayuda completo para algunas aplicaciones.

Para profundizar en el diseño para las redes sociales, consulta Designing Social Interfaces: Principles, Patterns, and Practices for Improving the User Experience, de Christian Crumlish y Erin Malone (O'Reilly, 2015).

Conclusión

Este capítulo te ha ofrecido un recorrido por el contexto vital para cualquier diseño de interacción de éxito: comprender quién va a utilizar tu software. Esta es la base de unos diseños que se ajusten a su finalidad y puedan entenderse fácilmente. Para conseguirlo, fundamenta tu proceso de diseño en las cuatro partes descritas en este capítulo. En primer lugar, comprende el contexto. Esto significa tener claro para qué tipo de personas estás diseñando, el tema o ámbito de trabajo para el que estás diseñando y el nivel de conocimientos de tus usuarios. En segundo lugar, es importante comprender sus objetivos. Este es el marco de los flujos de trabajo, las tareas y los resultados para los que vas a diseñar. En tercer lugar, la investigación de usuarios es una actividad y una habilidad valiosas para ayudarte a comprender a los usuarios y sus objetivos. Esbozamos una serie de actividades de investigación entre las que puedes elegir. Por último, examinamos una serie de patrones del comportamiento, la percepción y el pensamiento humanos que son relevantes para el diseño de interfaces. Estos cuatro elementos constituyen la base de tu proceso de diseño. En el Capítulo 2, veremos cómo crear una base organizativa sólida para tu software o aplicación en sí.

¹ Se trata del mismo principio que subyace a una técnica muy conocida llamada análisis de causas raíz. Pero el análisis de la causa raíz es una herramienta para solucionar fallos organizativos; aquí, utilizamos sus "cinco porqués" (más o menos) para comprender los comportamientos cotidianos de los usuarios y las peticiones de funciones.

² Nielsen, Jakob. "10 Usability Heuristics for User Interface Design," Nielsen Norman Group, 24 abr. 1994. www.nngroup.com/articles/ten-usability-heuristics.