Pioneros y hacedores 2: fundamentos y casos de diseño de interacción con estándares de accesibilidad y usabilidad / Bill Buxton...[et al.] ; compilado por Lorena Paz; Sebastian Betti. - 1a ed. - Ciudad Autónoma de Buenos Aires: Universidad de Flores, 2016.

Libro digital, PDF

Archivo Digital: descarga y online

ISBN 978-987-710-067-9

1. Nuevas Tecnologías. I. Buxton, Bill II. Paz, Lorena, comp. III. Betti, Sebastián, comp.

CDD 005.1

La versión digital de esta compilación es un EPUB accesible y libre

Universidad de Flores

Rector

Mg. Néstor Blanco

Vicerrectora Académica

Arq. Ruth Fische

Compiladores:

Sebastián Betti y Lorena Paz

Traductores:

Sebastián Betti, Paz Marenco, Mariana Calcagno  

Correctores:

Hernán Cortés

María de los Ángeles Mendoza (capítulo “Análisis de agrupamientos en arquitectura de información: un caso práctico de card sorting sin usuarios”, de Dani Armengol Garreta)

Editora

Lorena Paz

Diseño

Franco Montanari

Logo

Nicolás Scalise

Indice

Agradecimientos

Palabras Editora: “Captar emociones para diseñar realidades”

Prólogo

Agrupamiento, fraseo y el diseño de diálogos humano-computadora

Bill Buxton

La naturaleza de la práctica de diseño y las consecuencias para la investigación en diseño de interacción

Erik Stolterman

Atender a las intenciones, no a los procesos

Indi Young

Reclutamiento durante comportamiento

Indi Young

Por qué sólo hace falta probar con 5 usuarios (Explicado)

Jeff Sauro

La perspectiva psicológica del diseño UX

Susan Weinschenk

Experiencia etnográfica con estudiantes con discapacidad visual: la Universidat Oberta de Catalunya como estudio de caso

Pablo Rebaque-Rivas, Eva Gil-Rodríguez y Llorenç Sabaté-Jardí.

Análisis de agrupamientos en arquitectura de información: un caso práctico de card sporting sin usuarios

Dani Armengol Garreta

Percepción e interacción

Daniel Mordecki

Accesibilidad primero: guía de accesibilidad móvil

Julio Incarbone

La relación entre UX Y el ROI

Víctor Malumián

Experiencia de usuario en dispositivos móviles

Jordi Almiral López

Disolución de fronteras: tecnologías sociales y participación en el diseño

Penny Hagen y Tony Robertson

El diseño de interacción y la amanualidad en Álvaro Vieira Pinto

Rodrigo Freese Gonzatto y Luiz Ernesto Merkle

Diseño de experiencias continuas

Sebastian Vetter, Kelly Ann McKercher y Jess Howell

Descubriendo modelos mentales: el caso de una visualización interactiva que propicia la I+D mediante el cruce entre la academia y la industria TIC

Lorena Paz y Martín Szyszlican

La nueva página de las charlas TED: una breve historia

Aaron Weyenberg

Patricia San Martín, Andrea Guisen, María Inés Laitano y Marisa Cenacchi de DHD-IRICE

Analizando las OLPC mediante heurísticas de usabilidad

Ivana Harari y Paola Amadeo

Diseño centrado en los usuarios: el caso Kokori

Eduardo Mercovich y Mariela Szwarcberg

Agradecimientos

- A todos los autores que han cedido sus artículos, especialmente a “Bill” Buxton por su generosidad en reescribir una versión para latinoamericanos.

- A Néstor Blanco, rector de la Universidad de Flores, y a Ruth Fische, vicerrectora académica, por apoyar financieramente la publicación.

- A Cecilia Policastro, por su meticulosidad en el Laboratorio de Usabilidad y Accesibilidad Móvil.

- A Agustín García Aramburu, partner en el Proyecto AbuelosTEC, por su paciencia de Samurai.

- A Ivana Harari, por su humildad y generosidad al brindar sus conocimientos de experta en inspección heurística.

- A todos los miembros de Sugarlabs, por aportar al desarrollo de un futuro lúdico, libre y colaborativo.

Palabras Editora

“En la construcción de la realidad tecnológica no existe una cosa como un orden científico puramente racional; el proceso de la racionalidad tecnológica es un proceso político. Sólo en el medio de la tecnología, el hombre y la naturaleza se hacen objetos fungibles de la organización. La efectividad y productividad universal del aparato al que están sometidos vela por los intereses particulares que organizan al aparato.”

Herbert Marcuse 1

“Captar emociones para diseñar realidades”

En 1830, un joven llamado Charles Darwin comienza a observar los gestos que expresan los estados mentales de los ancestros del homínido y recoge unas notas en un cuaderno que abandona cuarenta años. Luego de desplegar su revolucionaria teoría sobre el origen de las especies, un Darwin ya anciano vuelve a estar interesado en la expresión de las emociones, y con la ayuda de sus hijos actualiza esas primeras observaciones, le incorpora ilustraciones y fotografías y las compila como La expresión de las emociones en el hombre y en los animales.2

El naturalista inglés usó los mismos métodos de medición que despliega un etnógrafo a la hora de poder evaluar una interacción. Observó gestos y actitudes en relación a un objetivo que se propuso indagar y tomó en cuenta información aleatoria, elaboró sus propios cuestionarios y diseño las métricas. Por ese motivo, también Charles Darwin fue un pionero y hacedor en nuestro campo.

Aunque el proceso de Investigación de Usuarios en interacción con las TIC da un paso más, requiere acción, captar emociones con una intencionalidad declarada: desarrollar sistemas que sean eficientes y eficaces. Captar emociones para diseñar realidades requiere de obtener otros datos menos visibles que las expresiones pero igual de mensurables. Hay una información por fuera de la interacción específica del usuario que hace o completa el análisis integral. Estos datos sobrevuelan y direccionan el análisis de la experiencia de los usuarios. Tienen forma de preguntas de investigación. ¿Quiénes crearon el proyecto/dispositivo X? ¿Para qué y para quiénes crearon el proyecto X? ¿Lo inventaron para locales o lo copiaron e importaron? ¿Cuán necesario le es X al “proyecto” X? ¿Se podría hacer X de otra manera que no sea con tecnología por fuera de los casos de uso? Y en el kernel, en el núcleo de cualquier sistema socio-tecnológico, cabe preguntarse: ¿cómo funciona la organización X?, ¿cómo trabaja el líder del proyecto, ¿qué entes están involucrados en el diseño y en el desarrollo?, ¿cómo son las alianzas que permiten que ese artefacto/aplicación exista?, ¿qué impacto ecológico tiene el modelo de negocio X?

En este tipo de indagaciones aparece en escena el pensamiento sistémico intentando comprender cada unidad de análisis en su dimensión y en su universo. Pensamiento, método científico, que aterriza en la realidad fáctica perturbando porque compromete ética e ideológicamente. ¿Diseñamos qué y para quién? ¿Reportamos qué y para quién? Es claro que mientras indagamos estas cuestiones nos indagamos. No existe neutralidad si no se asume que somos parte del problema y del objetivo de investigación. Y no es casualidad, sino más bien es la causalidad, de que inmersos en una doble realidad (y más de una vida virtual), portemos dispositivos que nos demandan y controlan.

Por ello, al editar esta segunda versión de Pioneros y Hacedores, al objetivo primario de difundir e inyectar más cientificidad al campo del diseño de experiencia de usuarios y a estas nuevas disciplinas, se le suma el de incorporar más humildad y ética (o por lo menos coherencia), empezando por cuestionar: ¿cómo podemos pretender desenmarañar algo tan complejo como las intenciones humanas de otros si desconocemos las nuestras propias? Si sufrimos a diario la exigencia mental y física del manejo de grandes caudales de información intermitentemente, si saturados de conectividad, nos desconectamos de nosotros mismos. ¿Cómo podemos, obnubilados por artefactos e interfaces que nos conectan y desconectan, si perdemos conocimiento de nuestras necesidades, deseos e interacciones vitales?

Por todas estas incertidumbres, la labor de diseñar centrándonos se hace vital, tan necesario como conocer más acerca de nosotros mismos: de los “factores humanos”, de nuestro cerebro, de nuestras emociones. Indagar en el tipo de relación corpórea que tenemos con las herramientas y con las máquinas y con los objetos que creamos. Debemos poner, y ponernos a prueba, con los artefactos y sistemas en relación con el esfuerzo, la fatiga y la satisfacción que logramos con los productos que consumimos, con los productos que producimos y con los que consumimos para producir. Esa es la tarea. Ahora bien, develada la identidad del problema, ¿cómo hallar la solución y tomar el toro por las astas? O valga la metáfora con tanta ama de casa conectada a la net, ¿cómo tomar la sartén por el mango? Ejerciendo investigación con acción, reconociendo que en el problema está la solución; empezando por tocar nuestro botón de encendido y detener el flujo de información. Volver a nosotros, a nuestras necesidades reales, y sólo desde ahí: crear experiencias necesarias desde nosotros para otros. Preservándonos, para evolucionar.

Lorena Paz, julio de 2017

Notas

1 “One-Dimensional Man”, Herbert Marcuse (1964).

2 "The Expression of the Emotions in Man and Animals”, Charles Darwin (1872).

Prólogo

“Para predecir las interacciones sociales de los humanos en el futuro, basta con que nos imaginemos cuáles eran nuestras interacciones sociales hace 100.000 años y las multipliquemos por mil millones”

Michio Kaku 3

Esta selección de textos está signada por la misma referencia al Homo habilis mencionada en la primera compilación de Pioneros y Hacedores en la que se menciona cómo las herramientas más interactivas requieren de pequeños gastos energéticos para su elaboración. Volver a centrarnos en las interacciones sociales de nuestro pasado ancestral, es un intento más por entender el fracaso de tantas predicciones tecnológicas o teorías no materializadas, en pos de anticiparnos a las interacciones sociales del futuro.

Por eso este segundo compendio de ideas y casos tiene el mismo propósito: contribuir al avance de la disciplina del diseño mediante la difusión de estudios del comportamiento humano en la interacción. Para ello, hemos convocado a una serie de pioneros y hacedores que han contribuido con sus visiones y proyectos con el afán de que lleguen al lector y contribuir así al avance y difusión en Latinoamérica del diseño centrado en las personas. Recorremos temas clásicos con Buxton y Sauro; material de reflexión para la investigación contemporánea con Stolterman, Hagen, Vetter, McKercher, Howell y Armengol Garreta; e indagamos en las percepciones con Young, Weinschenk y Mordecki.

Retomamos el compromiso del volumen anterior con la inclusión y la accesibilidad, desde la etnografía digital, con el caso de estudio de Rebaque-Rivas, Gil-Rodríguez y Sabaté-Jardí. Desde el diseño para dispositivos móviles, con Incarbone y Almiral López, y como es ineludible, incluimos la reflexión filosófica con “Amanualidade”, de Freese Gonzatto y Merkle. Aportamos a las nuevas generaciones de profesionales UX con la descripción paso a paso de casos de Diseño Centrado en el Usuario con Paz y Szyszlican, Weyenberg, Mercovich y Szwarcberg, y el proceso de un análisis heurístico con Harari y Amadeo que incluye el aporte de miembros de SugarLabs. Asimismo, para entender el diseño de interacción y la usabilidad como negocio, incluimos en este volumen la postura de Malumián sobre la relación entre UX y ROI.

Cada capítulo ha sido minuciosamente analizado con cada autor, en particular desde la propuesta de valor. A modo de ejemplo, me gustaría citar el caso de Bill Buxton, y al exponer su caso, agradecer a todos los autores por su tan generosa participación. Respecto de su artículo publicado aquí, Bill Buxton dice que le parece un candidato “especialmente relevante, dado el interés actual en los gestos” y que “es un artículo que de tan viejo puede parecer irrelevante pero que sin embargo, confieso que el contenido de este artículo sobrevuela casi todo lo que hago".

Del mismo modo, cada autor nos ha ofrecido una mirada Nicaea, y es por ello que expresamos nuestro más sincero agradecimiento por el tiempo que nos han dedicado, por su calidad, y su calidez.

Sebastián Betti, agosto de 2016

Notas

3 Michio Kaku (加來 道雄) es un físico teórico estadounidense, especialista destacado de la teoría de campo de cuerdas. Además, es futurista y divulgador científico. http://mkaku.org/

Agrupamiento, fraseo y el diseño de diálogos humano-computadora

Texto original: Bill Buxton (http://www.billbuxton.com/chunking.pdf)

Traducción: Sebastián Betti

William Arthur Stewart “Bill” Buxton es pionero en el estudio de la interacción persona-computadora; es científico, diseñador, escritor y orador con más de 30 años dedicados al estudio de los aspectos humanos de la tecnología, especialmente en aplicaciones creativas como la música, el cine y el diseño industrial. Bill es investigador principal en Microsoft Research, profesor de la Universidad Técnica de Eindhoven y de la Universidad de Toronto. Antes de unirse a Microsoft, Bill era investigador de Xerox PARC, científico en jefe de Alias Research y SGI Inc. En 2010, fue nombrado por la revista Business Week entre los “diseñadores más influyentes del mundo”. Y es el autor del libro Sketching User Experience 4, publicación de culto entre los profesionales y estudiantes del diseño de experiencias de usuario.

Introducción

No es secreto para nadie que la interfaz de usuario de muchos sistemas informáticos podría mejorarse. Los sistemas a menudo son intimidantes, propensos a errores, y requieren mucho esfuerzo antes de poder emprender un trabajo productivo. Desear hacer más fácil el uso de los sistemas es un buen punto de partida, pero no podemos llegar muy lejos sin un poco de teoría sobre cómo lograrlo.

“Más fácil de usar” es fácil de decir, pero dice poco acerca de cómo reducir errores y frustración y fomentar un aprendizaje más rápido. Para avanzar en esta dirección, podríamos reformular el problema y plantearlo en estos términos: “¿Cómo podemos acelerar el proceso por el cual los novatos empiezan a comportarse como expertos?” Subyace a esta formulación el supuesto de que existe una diferencia cualitativa entre la forma en la que novatos y expertos logran objetivos particulares. Este supuesto se apoya en gran parte de la literatura reciente vinculada a la resolución de problemas y adquisición de habilidades cognitivas.

Expertos y novatos difieren en la tosquedad de granularidad con la que ven los elementos constitutivos de un problema o tarea particular. Los novatos están atentos a los detalles de bajo nivel. Por ejemplo, detalles operativos tales como encontrar un carácter específico en el teclado o recordar el nombre de un comando, para el novato implican un problema a resolver. Como resultado, se distraen recursos cognitivos valiosos de la tarea central a realizar.

Los expertos resuelven estos detalles de bajo nivel en forma automática. Por consiguiente, el tamaño de los agrupamientos del problema a los que están atentos son muchos más grandes. Las habilidades que permiten realizar estas tareas en forma automática, no obstante, requieren mucho aprendizaje, que en general es resultado de la repetición. La adquisición de habilidades, por lo tanto, puede caracterizarse como el desarrollo de la capacidad para realizar agrupamientos cada vez más grandes de un problema en forma automática.

Podemos volver ahora a la reformulación del problema en cuestión: “¿Cómo podemos acelerar el proceso por el cual los novatos empiezan a comportarse como expertos?”. Nuestra premisa es que debería existir una concordancia lo más cercana posible entre la estructura con la cual pensamos los problemas y el lenguaje o la representación que usamos para resolverlos. En lo que sigue sostendremos que tal concordancia puede lograrse diseñando la pragmática del diálogo humano-computadora para reforzar el agrupamiento que creemos usaría un experto que trabaja en el dominio. En otras palabras, consideramos que la estructura del diálogo –en especial la pragmática–, puede ser diseñada para maximizar la compatibilidad con el dominio del problema.

Sintaxis: Dos enfoques

El diseño de la sintaxis tiene un efecto notable en la calidad de la interfaz de usuario de un sistema interactivo. Afecta tanto al aprendizaje, la frecuencia y la naturaleza de los errores del usuario, como a la velocidad de ejecución de tareas y la retención de habilidades en usuarios no habituales. Un problema importante para los usuarios es la carga cognitiva impuesta para recordar los componentes de un comando y su orden.

Un enfoque que han usado los diseñadores para evitar tales problemas es limitar la cantidad de argumentos de un comando. La interfaz de usuario de una computadora Macintosh, por ejemplo, limita los operadores a un solo argumento explícito. Esto causa problemas, no obstante, para operaciones que requieren tanto un objeto directo como uno indirecto tales como mover. Para abordar este problema, aplicaciones como MacWrite reemplazan el comando mover por dos comandos de más bajo nivel: cortar y pegar.

Si bien las nuevas primitivas tienen una sintaxis más simple, el modelo mental del usuario debe reestructurarse para mapear el concepto mover a estas dos nuevas primitivas. En vez de simplificar la interfaz de usuario, por lo tanto, es posible que la estrategia de usar un solo operando por verbo simplemente redistribuya la carga cognitiva.

Existe una estrategia de diseño alternativa. Si mover, por ejemplo, es la primitiva que se corresponde más cercanamente con el modelo del usuario, luego el problema de diseño consiste en usarlo y a la vez minimizar la carga de recordar los argumentos y la secuencia. Los símbolos de corrección de pruebas ofrecen un enfoque para lograrlo. La Figura 1 muestra un ejemplo.

Figura 1. Símbolo de corrección de pruebas que especifica “Mover”. Nótese el contraste de lo directo que resulta en comparación con la estrategia “cortar y pegar” de MacWrite.

Hay al menos tres puntos que vale la pena mencionar sobre este ejemplo, en especial para distinguirlo de la estrategia cortar y pegar para especificar esta misma operación:

• Toda la transacción, el verbo, el objeto directo y el objeto indirecto se especifican en un solo gesto.

• Nunca habrá error de sintaxis porque el orden está implícito en el gesto.

• La operación se especifica usando habilidades existentes y no requiere reestructurar los modelos mentales existentes.

Fraseo y gestos

Podemos pensar los componentes del comando moverdel ejemplo previo como entretejidos por una trama de continuidad similar a la que liga un fraseo musical. La “declaración” se inicia con un estado de neutralidad, se articula con un gesto continuo y, al cerrar, regresa al estado neutral en el que cualquiera de las partes puede presentar otra frase. Como en la música, el fraseo está caracterizado por la tensión (en este caso muscular) y el estado neutral delimita el inicio y el fin mediante la relajación.

Uno de nuestros principales argumentos es que podemos considerar el uso de la tensión y la clausura características del fraseo musical y aplicarlos al desarrollo de una estructura de fraseo para nuestros diálogos humano-computadora con el propósito de que colaboren en el refuerzo del agrupamiento que tratamos de establecer.

En el “lenguaje corporal” de entrada háptica, la tensión kinestésica y muscular son la materia prima para establecer una estructura de fraseo. Con el gesto viene la actividad cerebral y la ejecución intensificadas, y en los períodos de relajación, una indicación clara de que es correcto ser interrumpido, o pasar a la etapa siguiente.

Figura 2. Ley Yerkes-Dodson que relaciona el rendimiento con la actividad cerebral.

Tareas compuestas

Los problemas que vimos previamente en la sintaxis de un comando simple también aparecen en otro nivel del diálogo humano-computadora. En aplicaciones reales, muchas de las transacciones que realizamos consisten en tareas complejas. Seleccionar un componente eléctrico y ubicarlo en un circuito sería un ejemplo de tarea de selección/posición. De manera similar, identificar una palabra buscándola en un documento y luego seleccionarla, sería un ejemplo de tarea de navegación/selección.

En muchos de los casos citados, podríamos argumentar que el usuario modela la tarea compuesta como una entidad simple. En tales ocasiones, tener que abordar las sub-tareas de manera independiente puede resultar en una carga adicional comparable a usar cortar y pegar en vez de mover. Consideramos que el uso del fraseo mediante gestos kinestésicos puede ser utilizado para sortear este problema y los menús emergentes son un buen ejemplo para ilustrar nuestra idea.

En general, uno consideraría que hacer una selección simple en un menú emergente es una tarea simple. Sin embargo, al verlo más de cerca, advertimos que se trata de tres sub-tareas:

• Invocar el menú: presionar el botón del mouse;

• Navegar la selección: mover el ratón con el botón presionado;

• Seleccionar y regresar: liberar el botón del ratón.

En este caso, el “pegamento” que une las tres sub-tareas es la tensión de mantener presionado el botón del ratón durante la transacción. Diseñando el diálogo de este modo, es prácticamente imposible que se produzcan errores de sintaxis o de modo, pues la acción de finalización (articulada por la liberación del botón del ratón) es la Nicaea consecuencia natural de la acción inicial (presionar el botón del ratón). Además, la tensión del dedo que mantiene presionado el botón da retroalimentación constante de que estamos en un estado o modo temporal. (Es una leve ironía, dado que es precisamente en las interfaces denominadas “no modales” donde se encuentran con mayor frecuencia los menús emergentes).

Fraseo y habilidades cognitivas

En su estudio de 1983, Card, Moran y Newell discutieron cómo los expertos descompusieron las tareas de bajo nivel de la edición de texto en “subrutinas” cognitivas que denominaron “habilidades cognitivas de rutina”. Anderson describe la adquisición de tales habilidades como basadas en la compilación y procedimentación de conocimiento sobre las sub-tareas subyacentes. Al respecto, consideramos que el fraseo puede usarse en la organización de las sub-tareas para acelerar este proceso.

La pragmática y los componentes de entrada

Si las habilidades cognitivas de rutina de Card, Moran y Newell son compilaciones de primitivas de bajo nivel, uno podría tratar de determinar los bloques básicos de construcción. Una respuesta posible viene de Foley, Wallace y Chan. Ellos trataron de caracterizar el ingreso de datos a los sistemas informáticos desde la perspectiva del usuario. Al hacerlo, plantearon seis primitivas básicas:

Selección de un elemento en 1, 2 o 3D;

Posición de un elemento en 1, 2, o 3D;

Orientación (rotación) de un elemento en 1, 2 o 3D;

Especificación de un camino, como entintar en un programa de pintura;

Cuantificación, o especificación de un valor numérico;

Ingreso de texto, como en el procesamiento de palabras.

En un análisis más pormenorizado, no obstante, vemos que estas primitivas no necesariamente están al mismo nivel. Usemos la primitiva de posición por ejemplo.

Si usamos un ratón o una tableta, ubicar un objeto en 2D puede verse como una tarea simple. Sin embargo, el momento en que cambiamos de transductor y usamos un teclado QWERTY, especificar las mismas coordenadas requiere dos primitivas, a saber, la cuantificación de X y la cuantificación de Y.

Figura 3. La posición como agregación de 2 tareas de cuantificación.

Vemos con este ejemplo que incluso las seis primitivas de Foley, Wallace y Chan tienen una estructura profunda. Aunque las sub-tareas se perciban deliberadamente, no obstante, están muy influidas por el gesto (y transductor de captura) usado. Cuando corresponda, un gesto simple (apuntar) puede usarse para articular un concepto simple (posición).

Siguiendo la línea del ejemplo anterior, veamos un sistema simple para transcribir notación musical común. Las notas se ingresan usando notación simple de apuntes. Con una pluma y una tableta digitales el usuario apunta donde tiene que aparecer una nota, e ingresa uno de los símbolos de apuntes de la Figura 4.

Figura 4. Símbolos de apuntes para transcribir notación musical.

Figura 5. Ingreso de una nota semicorchea usando un gesto simple.

La estructura subyacente de añadir notas utilizando esta técnica, se muestra en la Figura 6. Vemos que añadir una nota, al igual que el posicionamiento, en realidad están constituidos por un conjunto de sub-tareas. No obstante, si se lo implementa como se describe, estas sub-tareas se reducen a la primitiva simple añadir nota.

Figura 6. Jerarquía de tareas en tarea “Añadir Nota”.

Gramática, pragmática y complejidad

Si las sub-tareas de un concepto de nivel más alto como añadir nota pueden reducirse a un gesto simple, ¿hay algún modelo que ayude a predecir el ahorro? Un enfoque, apoyado en estudios recientes, trata de obtener una medida de la dificultad de una interfaz de usuario analizando su gramática subyacente. Este trabajo iniciado por Reisner, más adelante fue desarrollado por Green y Payne, y Green, Payne, Gilmore y Mepham.

En su obra original, Reisner desarrolló un conjunto de heurísticas que ella utilizó para analizar la gramática del lenguaje de interacción de un sistema particular. A partir de este análisis, ella derivaría un valor que daría una medida de la facilidad de aprendizaje del sistema y propensión a errores. Las heurísticas que usó se basaban en:

• Cantidad de producciones

• Cantidad de terminales

• Longitud de las producciones

A continuación, mostraremos la aplicación de este análisis a la gramática de nuestra primitiva Añadir Nota:

Añadir Nota:= cuantificar Duración Posición Tiempo Tono

Posición Tiempo Tono:= cuantificar Tono cuantificar Tiempo Inicio

Podemos aplicar una aproximación de la heurística de Reisner a esta gramática en la que suponemos que el peso de cada producción y de cada terminal es 1 unidad. Dado que tenemos dos producciones y tres terminales, el peso total sería, en consecuencia, de 5.

Sin embargo, si usamos la técnica de reconocimiento de caracteres descripta anteriormente, argumentaríamos (a partir de la experiencia) que el peso real de toda la transacción es cercano al peso aportado por un terminal simple, a saber el peso 1. Ante esta situación, nuestra explicación es que el usuario no necesita detalles operativos de las sub-tareas constitutivas. El concepto completo puede expresarse en un gesto simple fluido compatible.

Gesto y pragmática

La noción de gesto físico es central en prácticamente todos los ejemplos discutidos. En cada caso, la clave para usar un gesto particular es tener el transductor apropiado. A la inversa, el factor limitante principal que restringe el rango de gestos disponibles en nuestro repertorio, es el estado lamentable en que se encuentra la práctica actual en lo que respecta a la entrada. La falta de dispositivos sensibles a la presión (como botones de ratón para controlar el grosor de la línea), controles de pies, y entradas para dos manos, son sólo ejemplos obvios. Si bien hasta ahora todos nuestros ejemplos tenían ligazones secuenciales, como muestra el caso del cambio de marchas en la transmisión manual, la ligazón entre tareas relacionadas puede ser en paralelo y entre extremidades. Esto ha sido demostrado en un estudio de Buxton y Myers.

Conclusiones

Hemos argumentado que la pragmática de la interfaz de usuario puede diseñarse para acelerar la adquisición de habilidades operativas de experto. La clave es el fraseo basado en gestos para agrupar el diálogo en unidades significativas para la aplicación. Cualquier concepto o transacción que pueda describirse con una palabra o una frase debería poder articularse en un gesto simple. Esta correspondencia deseada uno-a-uno entre concepto y gesto lleva a interfaces más compatibles con el modelo del usuario.

A modo de síntesis final, haremos un breve repaso de las respuestas que hemos dado al interrogante que planteamos en un comienzo: ¿cómo podemos acelerar el proceso por el cual los novatos empiezan a comportarse como expertos?

A lo largo del artículo hemos sostenido que la pragmática de la interfaz de usuario puede diseñarse y que tal diseño puede acelerar la adquisición de habilidades operativas de experto por parte de un usuario novato. Para tal fin propusimos que la clave se encuentra en un fraseo basado en gestos que permita agrupar las operaciones básicas que intervienen en el diálogo humano-computadora en unidades que resulten significativas para el sistema informático en que se implementen. En este sentido, es de esperar que cualquier concepto o transacción que pueda describirse con una palabra o una frase logre ser articulada en un gesto simple. Estamos convencidos que de alcanzarse la correspondencia uno-a-uno entre concepto y gesto, estaremos en condiciones de diseñar interfaces más compatibles con el modelo del usuario.

El trabajo desarrollado tiene base más en la práctica y la experiencia que en la experimentación formal. Es preliminar, y todavía resta mucha investigación por hacer. No obstante, consideramos que los ejemplos discutidos son suficientemente persuasivos como para orientar una eventual revisión de la práctica del diseño de interfaces de usuario.

Notas

4 Buxton, William (2007), Sketching User Experiences: Getting the Design Right and the Right Design, Estados Unidos, Morgan Kaufmann.

La naturaleza de la práctica de diseño y las consecuencias para la investigación en diseño de interacción

Texto original: Erik Stolterman (http://www.ijdesign.org/ojs/index.php/IJDesign/article/view/240/139)

Traducción: Sebastían Betti

Erik Stolterman es profesor y director del programa de HCI de la Facultad de Informática de la Universidad de Indiana. La investigación de Stolterman se centra en el diseño de interacción, la filosofía de diseño, tecnología de la información y sociedad, diseño de sistemas de información, y filosofía de la tecnología. Stolterman ha publicado su investigación en artículos y en cinco libros, incluyendo Thoughtful Interaction Design (2004, MIT Press), The Design Way (2003, ITP) y Methods-in-Action (2002, McGraw-Hill).

La idea central de este artículo es la investigación en diseño de interacción dirigida a apoyar la práctica del diseño de interacción. El argumento principal es que este tipo de investigación en diseño de interacción no siempre ha sido exitosa, y que esto se debe a que la investigación no se ha guiado por un entendimiento suficiente de la naturaleza de la práctica de diseño. Mediante una comparación entre la noción de complejidad en la ciencia y en el diseño, se afirma que la ciencia no es el mejor lugar para buscar enfoques y métodos para abordar la complejidad del diseño. En cambio, se fundamenta que cada intento de investigación en diseño de interacción debe tener su raíz en un entendimiento esencial de la naturaleza de la práctica de diseño. Un entendimiento tal puede evolucionar a un conjunto rico de métodos y técnicas bien fundamentados, rigurosos y disciplinados, adecuados a las necesidades y deseos de los diseñadores practicantes.

Palabras clave: Investigación en diseño, diseño de interacción, naturaleza del diseño.

Importancia para la práctica del diseño: Este artículo fundamenta que la investigación en diseño dirigida a mejorar la práctica del diseño debe tener su raíz en un entendimiento profundo de la naturaleza de la práctica del diseño.

Introducción

Lidiar con una tarea de diseño en una situación desconocida o parcialmente conocida, con clientes y usuarios más exigentes y destacados, con nueva tecnología y nuevos materiales, con tiempo y recursos limitados, con un conocimiento y habilidades limitadas y con herramientas inadecuadas, es una situación común para cualquier diseñador de interacción. Tratar con esas situaciones “terribles” y desordenadas constituye el contexto normal y cotidiano de cualquier práctica de diseño (Alexander, 1964; Dunne, 1993; Cruz, 2001; Schön, 1983; Pye, 1995; Heskett, 2002; Rove, 1987; Lawson, 2005; Thackara, 2005).

La investigación sobre la práctica de diseño ha demostrado que los diseñadores que pueden manejar con éxito situaciones de diseño complejas utilizan un enfoque a veces tildado como una manera de pensar y de actuar afín al diseño (Cruz, 2001; Buxton, 2007; Moggridge, 2007). Existe también últimamente un interés más general y creciente en lo que se ve como una creciente complejidad en nuestra sociedad y en cómo lidiar con ella (Castells, 1996; Coburn, 2006; Friedman, 2005; Gladwell, 2005; Rosa, 2005).

Una parte sustancial de la investigación en diseño de interacción durante algunas décadas desarrolló enfoques teóricos, métodos, herramientas y técnicas encaminadas a apoyar a los diseñadores de interacción en su práctica. Esta investigación ha mostrado avances significativos, y el campo es hoy rico y cuenta con un conjunto diverso de enfoques, métodos y técnicas. Algunos de estos enfoques son nuevas construcciones, pero muchos de ellos tienen raíces intelectuales en otras áreas académicas, tales como la ciencia, la ingeniería, las ciencias sociales, las humanidades, y en las disciplinas tradicionales del arte y el diseño (Carroll, 2003; Rogers, 2004). En este documento, se utilizan en forma indistinta los términos investigación en Interacción Humano-Computadora, HCI por sus siglas en inglés, e investigación en diseño de interacción.

En los últimos años, se ha planteado la crítica en relación al éxito de algunas de estas contribuciones. Se ha argumentado que los resultados no siempre son útiles para los profesionales, y que los enfoques desarrollados son demasiado lentos, demasiado difíciles para aprender, demasiado abstractos y teóricos, o que no conducirán a los resultados deseados si se utilizan en la práctica. Rogers (2004) tiene una excelente visión y formulación de esta crítica. Presenta un análisis exhaustivo de la situación de los principales enfoques teóricos en HCI en relación a la práctica. Ella también presenta resultados empíricos que confirman su análisis teórico. El análisis de Rogers muestra de manera convincente que si la medida del éxito para este tipo de investigación es que se entiende y se utiliza realmente en la práctica, entonces los resultados son menores.

Una de las hipótesis en este trabajo es que la crítica presentada por Rogers es válida y que constituye un problema grave y real para la comunidad de investigación de la interacción. Sobre la base de ese supuesto, examinaré por qué parece tan difícil para la investigación en HCI producir resultados apreciados y útiles dentro de la práctica del diseño de interacción.

Es importante reconocer que existen muchos ejemplos la investigación exitosa en HCI que llegan e influencian a una gran población de practicantes. Rogers también reconoce esto, y es algo que discutiré más adelante en este documento. También es importante reconocer que este trabajo no versa sobre todas las formas de investigación en HCI. Aborda solamente la investigación destinada a mejorar la práctica del diseño de interacción.

Mi argumento principal es que una de las razones por las cuales la investigación en HCI (destinada a apoyar la práctica del diseño) no ha sido (siempre) exitosa es porque no se ha basado y guiado por una comprensión suficiente y una aceptación de la naturaleza de la práctica de diseño. Como consecuencia, la investigación en HCI ha desarrollado y/o pedido prestados enfoques y métodos no siempre adecuados para la práctica del diseño de interacción, si bien pueden tener éxito en sus respectivos campos “base” o entornos de investigación. En este documento la noción de complejidad, y en especial el concepto de complejidad del diseño, será un punto focal de análisis. Como se mencionó anteriormente, la práctica de diseño consiste en gran medida en manejar la complejidad y una realidad “desordenada”. Sin embargo, fundamentaremos que la complejidad en el diseño no es en absoluto el mismo tipo de complejidad que se observa en otras áreas de la actividad humana. Por lo tanto, se comparará la noción de complejidad en el diseño en contraste con la complejidad en la ciencia. El propósito es mostrar cómo la filosofía y los principios subyacentes en un área, en este caso la ciencia, podrían ser inconmensurables en otro campo, en este caso el diseño. El mensaje general de este trabajo es que la investigación en HCI emprendida con la finalidad de apoyar la práctica del diseño tiene que tener raíz en una comprensión profunda del diseño como actividad humana única de investigación y acción. Soy consciente de que esto no es una novedad para todos los lectores, pero creo que la corriente dominante de investigación en HCI está aún lejos de reconocer esto, y por tanto vale la pena explorarlo.

La estructura del artículo es la siguiente: La primera sección posicionará brevemente el análisis y la discusión en relación a la investigación actual en HCI y a los estudios de diseño. En el siguiente apartado examinaré la noción de complejidad en el diseño y la ciencia, fundamentando que tomar prestado los métodos y enfoques de la ciencia puede no ser adecuado para la práctica del diseño. Después de esto, argumentaré que la práctica de diseño cuenta con un rigor y una disciplina propios que pueden ser más desarrollados y explicados. Terminaré el artículo con algunas sugerencias sobre cómo la investigación en HCI puede tener éxito en el apoyo a la práctica.

Antecedentes

La investigación en HCI en muchos sentidos ha tenido un gran éxito a través de los años. El repertorio de herramientas básicas para la práctica del diseño de interacción, que se enseña en la mayoría de los programas de HCI, es utilizado una y otra vez por los practicantes en la industria. Así que, ¿cuál es el problema?

Rogers (2004) informa que casi todos los encuestados en su estudio “utilizan una serie de métodos de diseño, incluyendo escenarios, guiones gráficos (storyboards), prototipos de baja fidelidad y software de creación de prototipos, grupos de enfoque, entrevistas, estudios de campo, cuestionarios y casos de uso” (p. 123). Por otro lado, casi nadie utiliza “métodos de modelado predictivo, como GOMS, y solo unos pocos usan métodos de ingeniería de software (8 %), experimentos (10 %), diseño contextual (10 %) o directrices (5 %)” (p. 124). En materia de interpretación de datos y conclusiones que se reúnen en el proceso de diseño, el 85 % dijo que se basan principalmente en su propia intuición y experiencia. A pesar de no usar enfoques teóricos, los encuestados dijeron que “usan” conceptos individuales, tales como prestación percibida (affordance), contexto, contextualización, etc. (Rogers, 2004).

Muchos de los encuestados respondieron que estaban familiarizados con la mayoría de los principales enfoques teóricos en HCI, pero que no los utilizaron. Rogers (2004) afirma que “el problema parece ser la brecha entre la demanda de hacer diseño y la forma en que se conceptualiza la teoría” (p. 123). El estudio de Rogers revela resultados positivos y problemáticos al investigar cómo ven y usan la investigación en HCI los profesionales. Una de las interpretaciones, según el argumento de este trabajo, es que el repertorio de herramientas básicas, usado por muchos, puede describirse como herramientas de diseño. Este tipo de herramientas tienen cualidades que tradicionalmente los diseñadores reconocen como útiles.

Eso significa que son herramientas claramente definidas con un propósito preciso que tiene que ser usado hábilmente por un diseñador competente para ser útil. Estas herramientas no eliminan ningún “poder” o libertad del diseñador. Estas herramientas no prescriben el proceso ni reclaman una secuencia específica, paso a paso, de actividades que podrían afectar la manera propia del diseñador de hacer sus cosas. Estas herramientas no exigen ninguna comprensión ni conocimiento sofisticado o teórico. Esto está en consonancia con el hecho de que los modelos más complejos que requieren más del diseñador (como el diseño contextual, los experimentos, los métodos de ingeniería) fueron menos utilizados en el estudio de Rogers (2004). Mi hipótesis es que estos métodos serían reconocidos como menos afines al diseño a juicio de diseñadores experimentados.

Con base en la obra de Rogers, yo diría que es posible predecir el éxito potencial de nuevos enfoques, métodos y herramientas en función de lo afines al diseño que sean. Es evidente, sin embargo, que cualquier predicción de este tipo debe basarse en una comprensión fundamental de lo que significa afín al diseño. En este trabajo se examinará en qué consiste tal entendimiento y cuáles son las condiciones previas para el éxito del desarrollo de nuevos enfoques y herramientas destinadas a apoyar la práctica afín al diseño.

En los últimos años ha existido un interés creciente en el papel y la naturaleza del diseño en la investigación en HCI (Winograd, 1996; Zimmerman, Forlizzi y Evenson, 2007; Löwgren y Stolterman, 2004; Fällman, 2003; Atwood, McCain y Williams, 2002; Bartnek, 2007). También hemos visto últimamente algunas contribuciones basadas en el conocimiento destinadas a la práctica de diseño que son genuinamente afines al diseño y con base en un firme entendimiento de la práctica del mismo. Estas contribuciones han tenido cierto impacto y aumentado el interés en una comprensión más profunda de la práctica de diseño.

Ejemplos de esto son los libros recientes de Buxton (2007), Moggridge (2007) y Kolko (2007). Estas contribuciones pueden verse como ejemplos de lo que estoy defendiendo en este trabajo, es decir, conocimiento que se produce con el objetivo específico de apoyar una práctica de diseño firmemente basada en un profundo conocimiento de la misma. Es de destacar que estos tres libros son obra de escritores que se describen más como profesionales que como investigadores.

Todos tienen gran experiencia en diseño y una larga experiencia en la práctica del diseño. También ha habido una serie de artículos que abogan por la importancia de distinguir entre el diseño y la investigación en HCI (Fällman, 2003; Dourish, 2006; Bartnek, 2007; Wania, Atwood y McCain, 2006; Taylor, 2003), o que el diseño es un modelo apropiado para la investigación “real” (Zimmerman y otros, 2007), o que la práctica del diseño tiene su propio rigor (Wolf, Rode, Sussman, y Kellogg, 2006; Buxton, 2007; Bartneck, 2007). Estos avances, junto a los demás (Laurel, 2003; Winograd, 1996), son prometedores y con el tiempo influirán en la forma de hacer investigación en HCI. Sin embargo, ninguno de estos intentos se refiere específicamente a la cuestión planteada en este trabajo, que es la forma de mejorar la investigación en HCI dirigida al apoyo de la práctica de diseño.

Después de este breve resumen, es momento de entrar en la argumentación general del artículo. En la siguiente sección examinaré, como parte de mi razonamiento, la noción de complejidad en la práctica de diseño y lo relacionaré con la noción de complejidad en la ciencia.

Complejidad en el diseño

La complejidad en el diseño se define aquí como la complejidad que experimenta un diseñador cuando se enfrenta a una situación de diseño. Casi todas las situaciones de diseño ofrecen fuentes potencialmente infinitas e ilimitadas de información, requisitos, exigencias, deseos y necesidades, limitaciones y oportunidades. Estas “fuentes infinitas e ilimitadas” suelen presentarse en forma de diversas posibilidades tecnológicas, de factores contextuales numerosos y constantemente cambiantes y de precondiciones sociales, clientes sofisticados y/o no informados, clientes y demandas y deseos de usuarios. A pesar de que todas estas fuentes pueden informar al diseñador sobre un potencial de diseño, no es posible explorar exhaustivamente toda la información potencialmente útil. Enfrentar este tipo de fuentes “infinitas” de información podría llevar al diseñador (incluso a uno con experiencia) a experimentar una complejidad de diseño abrumadora. El diseñador tiene que tomar todo tipo de decisiones y emitir juicios, tales como cómo enmarcar la situación, a quién escuchar, a quién prestar atención, a quién ignorar y cómo explorar, extraer, reconocer y elegir información útil de todas estas fuentes potenciales. Un diseñador inexperto puede sufrir de “parálisis de diseño” al enfrentar esas oportunidades ilimitadas. Estas situaciones de diseño a veces se describen como problemas “subdeterminados” o, en palabras de Schön, situaciones “desordenadas” o, en palabras de Rittel, “problemas perversos” (Schön, 1983; Rittel y Webber, 1974).

De acuerdo con la definición que aquí se presenta, no es posible medir objetivamente la complejidad del diseño. No podemos, en base a alguna medida objetiva, argumentar que “esta situación tiene una mayor complejidad de diseño que esa situación”. En lugar de ello, la complejidad en el diseño es la experiencia subjetiva de complejidad que tiene el diseñador. Esta experiencia es una consecuencia de la naturaleza de la tarea en la situación específica, en relación con el propósito específico, y en relación con la aptitud profesional, la competencia y la experiencia del diseñador. Esto significa que un diseñador podría experimentar una situación particular de diseño muy compleja, mientras que otro puede que no. La complejidad en el diseño, como se define aquí, no es nada nuevo. Es un problema clásico que se ha tratado en muchas disciplinas de diseño académicas, y el diseño de interacción no es una excepción. El supuesto antes expuesto –de que los diseñadores están experimentando un aumento global en la complejidad del diseño– ha sido reconocido en el campo del diseño de interacción, a pesar de no siempre enmarcarse como complejidad del diseño (Carroll, 2003; Löwgren y Stolterman, 2004; Maeda, 2006; Norman, 2004; Krippendorff, 2006).

Algunos de los intentos teóricos establecidos hacen fuerte hincapié en encontrar maneras de lidiar con la complejidad, por lo general ofreciendo enfoques destinados a desmantelar la complejidad de la realidad y al mismo tiempo ofrecer formas de entender su riqueza (Carroll (2003) y Rogers (2004) ofrecen detalles). Hay también algunos intentos más recientes en el campo de la HCI centrados explícitamente en la complejidad (Johnson, 2005).

La mayoría de los enfoques y métodos tienen como objetivo reducir la complejidad de alguna manera, pero reducir la complejidad del diseño no es una tarea fácil. Si lo fuera, probablemente veríamos gran cantidad de enfoques que ofrecerían soluciones simples a un bajo “costo”. En cambio, al parecer, como muestra Rogers, en muchos casos los intentos por reducir o controlar la complejidad del diseño llevan a enfoques intensivos en tiempo y energía. Parece como si los propios enfoques de diseño se tornaran demasiado complejos.

Complejidad, control y riqueza

Cuando se trata de la realidad tal y como la experimentamos nuestro mundo en la vida, es como si los seres humanos, al menos en las sociedades occidentales, nos esforzáramos por tener el control, y tratáramos de alejarnos de lo natural, o de la naturaleza (McCullogh, 2004; Buchanan, 1992; Thackara, 2005). Parece como si la cultura occidental se inclinara a crear ambientes artificiales en los que todo puede ser controlado.

En el intento de crear entornos deseables, los seres humanos tratamos de reducir la complejidad, para establecer un control, haciendo las cosas más simples (Greenfield, 2006; Janlert y Stolterman, 1997; Maeda, 2006; Norman, 2005; Thackara, 2005). Pero en lugar de ser un ideal humano universal, la simplicidad recibe la desaprobación y el menosprecio en nuestra vida cotidiana. La “simplicidad” a veces provoca condescendencia e incluso desprecio. Los seres humanos parecemos buscar y disfrutar de ciertas experiencias de complejidad. En algunos contextos, la complejidad puede ser entendida como riqueza, generalmente se ve como una calidad positiva y deseada. La experiencia de estar en un bosque, con su inmensa riqueza de diferentes formas de vida y estructuras naturales, es vista como más rica que estar en el entorno controlado y simplificado de un parque. Cuanto más simple un entorno, más fácil es entenderlo y tratarlo, pero al mismo tiempo, más carece de la riqueza y estímulo que parecemos apreciar y disfrutar (Csikszentmihalyi, 1990; Norman, 2004). Por eso, la complejidad no sólo trae problemas, también trae experiencias positivas. La complejidad no es solo un “mal” necesario.

Dadas las circunstancias correctas, los encuentros directos con la complejidad de un sistema pueden darnos experiencias positivas de desafío, plenitud y entretenimiento, así como experiencias estéticas y sublimes, y pueden estimular y desarrollar nuestras habilidades y ambiciones, y quizá incluso nos empujen a desarrollar nuestra mente y carácter (Csikszentmihalyi, 1990; Nelson y Stolterman, 2003).

Aparentemente hay algo intrigante en la complejidad. Constituye un reto, algo que podemos explorar y experimentar, algo que podemos intentar aprender, dominar, algo que puede llevarnos a nuevas e inesperadas direcciones, casi como una aventura. Parece como si la complejidad del diseño también pudiera tener valores positivos, quizá incluso un valor de entretenimiento. Una tarea de diseño demasiado simple podría considerarse aburrida. Es, en cierta medida, la complejidad de la tarea de diseño lo que hace del diseño una empresa tan entretenida y gratificante para el diseñador.

Este aspecto de la complejidad como equilibrio entre el reto, la habilidad, el logro y como fuente de disfrute personal y de desarrollo ha sido explotado en detalle en el concepto de “flujo” (Csikszentmihalyi, 1990).

La complejidad del diseño, por tanto, no es necesariamente en sí misma un problema. Evidentemente, es algo que da a los diseñadores experiencias ricas y variación, y les posibilita ser sorprendentemente creativos en sus aventuras de diseño. La complejidad es probablemente incluso una condición necesaria y propicia para el diseño innovador y creativo.

A pesar de que muchos estarían de acuerdo con esta comprensión positiva de la complejidad del diseño, todavía existe un gran deseo y una lucha por enfoques que se pueden utilizar para manejar la complejidad de una manera más estructurada y organizada. En la búsqueda de tales enfoques, parece que muchos recurren a la ciencia, una tradición conocida por su capacidad para hacer frente a la complejidad y sus métodos bien desarrollados para hacerlo. La pregunta entonces es: ¿Puede la ciencia brindarle al diseño de interacción herramientas adecuadas para manejar la complejidad en el diseño?

Complejidad en la ciencia y en el diseño

En general se acepta que la ciencia ha sido extremadamente exitosa en el tratamiento de la complejidad en el proceso de descubrimiento de los mecanismos y la estructura de la realidad. Pero, los principios subyacentes de los métodos y enfoques científicos, ¿son transferibles y adecuados para la práctica del diseño? Argumentaré que, en general, no lo son. Soy consciente de que esto no es noticia dentro de la comunidad internacional de investigación en diseño, donde se ha estudiado la cuestión de la relación entre la ciencia y el diseño y donde dicho estudio ha dado lugar a aportaciones teóricas que han demostrado ser muy valiosas en esta discusión (Simon, 1969; Rittel y Webber, 1974, Alexander, 1964; Cruz, 2001; Pye, 1995; Krippendorff, 2006; Nelson y Stolterman, 2003; Lawson, 2005).

Cuando los métodos y enfoques son tomados de la ciencia sin un conocimiento suficiente de la práctica de diseño, a veces llevan a situaciones en las que se adaptan y cambian radicalmente los principios de la metodología científica para adaptarse mejor a la práctica de diseño. Esto ha llevado en algunos casos a una crítica severa, ya que se ha visto como el resultado de versiones distorsionadas, de un uso “descuidado” de métodos científicos establecidos, como es el caso entre la etnografía “real” y la muy popular etnografía “rápida y sucia” (Dourish, 2006). Otro ejemplo de un enfoque basado en la ciencia adaptado por el diseño es el experimento controlado. Este método ha sido principalmente adaptado y utilizado en el área de la usabilidad de interacción. Un experimento controlado es, en la ciencia, un modo para restringir y aislar las variables que podrían influir en el resultado del experimento. El objetivo es encontrar una manera de medir el rol de un pequeño número de variables. Sin embargo, con la creciente comprensión de la interacción como una experiencia global que incluye todos los aspectos del diseño, y la importancia de los estudios in situ, y la noción de las cualidades emergentes como resultado de la composición diseñada, el experimento controlado –si se copia desde la ciencia– no satisface las necesidades de la práctica del diseño.

Argumentaré que el remedio para esta situación es una mejor comprensión de la diferencia entre los principios fundamentales de la metodología científica y lo que se necesita en la práctica de diseño. Esto, por supuesto, no es importante para el bienestar de la tradición científica y su práctica, pero es importante para construir y formular una base filosófica independiente para el diseño que pueda inspirar nuevos enfoques afines al diseño

Complejidad en la ciencia

La complejidad en la ciencia tiene su lugar dentro de todas las formas de actividad científica y de investigación, e influye en nuestra capacidad de explorar, comprender y explicar la realidad tal como es. La realidad es, por supuesto, de infinita complejidad y puede por lo tanto nunca ser plenamente explorada o entendida. El tiempo y los recursos, sin embargo, no limitan la ciencia como proyecto. La ciencia es, si se considera como un proyecto, algo en lo que los humanos seguiremos trabajando para siempre, o siempre que sea necesario, o el tiempo que conservemos la curiosidad. El objetivo de la ciencia es formular conocimiento universal que explique la complejidad de la realidad a un nivel donde se elimina lo específico y lo particular. A riesgo de ser demasiado ingenuo, quiero citar la definición de “ciencia” del diccionario Webster: “conocimiento o sistema de conocimientos que cubre verdades generales o la operación de leyes generales en especial que se obtienen y se demuestran a través del método científico” y el “método científico” se define como: “los principios y procedimientos para la búsqueda sistemática del conocimiento que implican el reconocimiento y la formulación de un problema, la recopilación de datos a través de la observación y la experimentación, y la formulación y comprobación de hipótesis”.

Dentro del proyecto científico, el enfoque está en las regularidades, mecanismos, patrones, relaciones y correlaciones para formularlos como conocimiento, preferiblemente en forma de teorías. La intención es formar teorías que constituyen el conocimiento válido y verdadero, en todo momento y en todas partes. El conocimiento también debería ser algo que otros investigadores puedan reproducir y debería estar completamente separado y no ser influenciado por el investigador. No puede haber ninguna influencia de la persona que realiza la investigación. Si la ciencia es exitosa, es decir, si el conocimiento y las teorías son creados y corroborados en una comunidad de investigación, a continuación, la complejidad de la realidad se ve en cierto grado explicada o, al menos, reducida.

Esta descripción de la ciencia es, por supuesto, extremadamente cruda y no tiene en cuenta la gran riqueza, diversidad y controversias que existen en las diferentes comunidades científicas, que están bien documentadas dentro de las disciplinas de la sociología y la filosofía de la ciencia. Pero esta descripción de la ciencia, tan cruda como podría ser, todavía es útil en el presente contexto y para la argumentación específica en cuestión. Nos proporciona una descripción simple de una tradición intelectual relativamente bien conocida y una práctica contra la cual el diseño, como otra tradición de investigación y acción, se puede contrastar.

Complejidad en el diseño

Pasemos al segundo tipo de complejidad, la complejidad en el diseño. En contraste con el enfoque científico en lo universal y lo existente, el diseño trata con lo específico, lo intencional y lo inexistente. Curiosamente, tratar la complejidad del diseño implica metas y precondiciones casi fundamentalmente opuestas a las del enfoque científico. Esto es especialmente cierto cuando se trata de la noción de universalidad. En la práctica del diseño, el objetivo consiste en crear algo no universal. Consiste en crear algo en el mundo con un propósito específico, para una determinada situación, para un cliente y usuario específico, con funciones y características específicas y hacerlo en un tiempo limitado y con recursos limitados. El diseño tiene que ver con lo único, lo particular, o incluso con la esencia de lo particular. Los diseñadores tienen que atender a las personas y situaciones que tienen a mano, y los deseos y necesidades que tienen, y al mismo tiempo tener en cuenta el tiempo y los recursos limitados de los que disponen (Buchanan, 1992; Krippendorff, 2006; Nelson y Stolterman, 2003). Esto puede ser visto como invariante del diseño y como características universales “de los entornos de trabajo de diseño” (Goel y Pirolli, 1992).

La práctica del diseño aborda la creación de una realidad deseada que se manifiesta como lo particular esencial. Lo particular esencial es un concepto de diseño que tiene la misma dignidad e importancia que la verdad para la ciencia (Nelson y Stolterman, 2003). Lo particular esencial es el resultado manifiesto final real y, como tal, producto de un proceso de diseño intencional. Un artefacto digital o un sistema de información implementado en una organización específica es lo particular esencial. Una esencia tal de lo particular, puede parecerse a un tipo o clase específica de sistemas, pero no deja de ser un particular único.

Por eso si el sistema no satisface las demandas y necesidades de la organización, no es razonable argumentar que, “Dado que este sistema funciona bien en otra organización, no puede ser que esté causando problemas” o “Como este sistema fue diseñado siguiendo los métodos y técnicas acordados, no puede haber nada de malo en el sistema”. Cada sistema, cada diseño, siendo incluso exactamente igual a otro, constituye un particular esencial que tiene que ser entendido de modo afín al diseño como evocador de cualidades emergentes en la composición del sistema y de la organización en conjunto.

El significado de lo particular esencial no debe confundirse con si el diseño es único o no. Un objeto es único sólo si existe en uno o tal vez pocos ejemplares. No es único si es producido en masa y existen del mismo miles o millones de copias. Sin embargo, cada uno de estos ejemplos sigue siendo un particular esencial en su contexto de uso específico. Y un diseñador siempre diseña para un contexto de uso específico. Esta es la razón por la cual las nociones de cualidades en el uso y experiencia se han convertido últimamente en conceptos centrales del diseño de interacción (NHE y Löwgren, 1997; McCarthy y Wright, 2004).

La práctica del diseño se diferencia también, como mencioné anteriormente, de la ciencia en que siempre hay limitaciones de tiempo y recursos. La ciencia tiene limitaciones similares, pero dado que la ciencia en tanto “gran” proyecto, está dirigida a revelar la verdad, las limitaciones son solo locales y temporales. De allí que en la ciencia exista la noción de producción de conocimiento acumulativo, en el que cada nuevo aporte solo tiene que lidiar con un aspecto minúsculo o una parte del campo, y aun así puede ser valioso. En el diseño hay que diseñar el “todo” y no se puede reducir la complejidad del diseño, limitándose a esas cosas que uno tiene tiempo de hacer, ni a los recursos que maneja, o a las cosas que uno conoce y de las que tiene información suficiente. Por ejemplo, no se puede limitar el diseño de un nuevo reproductor de mp3 a cuestiones de figura y forma del objeto físico sin tener en cuenta sus aspectos funcionales e interactivos. En la ciencia esto se hace mediante la separación deliberada y cuidadosa de los aspectos, con el propósito de reducir la complejidad, centrándose en un aspecto o variable relevante a la vez.

En el diseño, por otra parte, los métodos y los enfoques tienen que considerar toda la composición, las cualidades emergentes del todo que, por supuesto, crea requisitos metodológicos distintos a la hora de la prueba y la evaluación.

Por último, mientras que la medida del éxito de la ciencia tiene que ver con lo bien que el investigador ha llevado a cabo el proceso de investigación en conformidad con las normas metodológicas acordadas, la medida de éxito en el diseño tiene que ver con el resultado. La calidad del resultado final (el diseño) no es una cuestión de qué tan bien el diseñador realiza el proceso de diseño, o si el diseñador sigue un proceso correcto de diseño, sea lo que sea que signifique eso.

Esto ha sido reconocido en el diseño de interacción con el advenimiento de nociones tales como el diseño de la experiencia (McCarthy y Wright, 2004). La medida final del éxito de un diseño es algo revelado en el sitio, en el uso real, y con el tiempo.

Contrastando las dos formas de complejidad

Por desgracia, las dos formas de complejidad descritas aquí comúnmente son mezcladas y vistas como cosas relacionadas o incluso similares y, en consecuencia, el remedio para hacer frente a un tipo de complejidad se copia de una a la otra. Varios pensadores influyentes del diseño han abordado históricamente la relación y la diferencia entre la ciencia y el diseño que discutimos aquí. Herbert Simon discutió esto en sus famosos escritos sobre diseño (Simon, 1969). No propuso abandonar la idea de los métodos científicos como base para el diseño, pero sí afirmó que estos métodos tienen limitaciones y que solo podíamos hablar de una “racionalidad limitada” al hablar de diseño. También hizo una distinción clara e importante entre la naturaleza del mundo “real” (el reino de la ciencia), y el mundo artificial (el reino del diseño). Rittel y Webber (1974) argumentaron, además, que los problemas del mundo real tienen la característica de ser “problemas perversos”, y como tales, no son “solucionables” y por ende deben abordarse usando medios completamente diferentes.

Donald Schön (1983) desarrolló una idea similar, pero más radical. Según Schön, la gente trata de usar la “racionalidad técnica” para resolver problemas que “no tienen solución” o, para ser más precisos, que ni siquiera son “problemas”. Para Schön, el diseño consiste en “enmarcar el problema” no en “resolver el problema”. Afirma también que el diseño consiste en “situaciones desordenadas”.

En situaciones desordenadas, los principios metodológicos subyacentes desarrollados dentro de la tradición de la ciencia no necesariamente son apropiados; de hecho, Schön señala que provocan más problemas de lo que resuelven (Schön, 1983). Schön estructuró su discurso en el marco de la educación. Sostuvo que si se usa la “racionalidad técnica” como pilar de la educación superior, se le impide a los estudiantes el desarrollo de competencias y habilidades reales de diseño, al tiempo que se les forma en técnicas y habilidades que no son adecuadas para las situaciones (desordenadas) del diseño.

Quizá sea justo decir que mientras Simon intentó conciliar los enfoques de la ciencia y el diseño de manera combinada, tanto Rittel y Webber como Schön sostuvieron que son inconmensurables. Las ideas de Schön tienen raigambre profunda en la tradición filosófica del pragmatismo y se inspiran fuertemente en el pensamiento del filósofo John Dewey. Con base en la tradición del pragmatismo, se hace hincapié más en la noción de resultado (producto) que en la de método (proceso).

Para Dewey y Schön la verdad no está definida por el nivel de refinamiento metodológico ni por lo bien que se haya seguido la metodología (como en la ciencia) sino que el resultado tiene una entidad especial respecto de la intención y el valor. Zimmerman y otros (2007) presentaron un modelo de investigación en el diseño con influencia fuerte de estas ideas. Sostienen que es posible usar las prácticas de diseño como modelo para la investigación en la interacción humano-computadora, HCI por sus siglas en inglés. Es una sugerencia excelente que enriquece nuestra comprensión de la investigación en HCI y abre nuevas e interesantes formas de investigación en HCI.

Es importante recordar que el argumento aquí no sostiene que no puede hacerse investigación en diseño de manera científica. La investigación en diseño realizada siguiendo procedimientos científicos específicos puede aportar conocimiento de alto valor para los diseñadores. Para resumir esta sección, defendí la idea de que tratar la complejidad en la ciencia y en el diseño son actividades diferentes, que tienen propósitos, resultados y métricas de éxito diferentes.

Operar con la complejidad del diseño de forma afín al diseño requiere enfoques, métodos, técnicas y habilidades adecuados. La ciencia, con el correr del tiempo, desarrolló una comprensión detallada, rica y diversa de sus propósitos y enfoques. El rigor metodológico y la disciplina son centrales para la actividad científica. Yo sostengo que se requiere en la investigación en HCI una comprensión filosófica y metodológica similar de qué constituye el rigor y la disciplina en la práctica del diseño, para dar un mejor respaldo a esa práctica.

Actuando con la disciplina y el rigor que requiere el diseño

Si bien hemos demostrado la dificultad para manejar la complejidad del diseño, es obvio que los buenos diseñadores pueden hacerlo de manera que conduzca a resultados innovadores y sorprendentes que la gente aprecie y valore como ejemplos maravillosos de buen diseño. Incluso en situaciones más exigentes, en las que la mayoría de las personas estaría de acuerdo en que es de una complejidad abrumadora, algunos diseñadores siguen siendo capaces de ofrecer un diseño que parece “conquistar” la complejidad y al mismo tiempo ser sorprendentemente funcional y atractivo. Por ende, la complejidad en el diseño aparentemente es posible de tratar, y parece existir un enfoque afín al diseño que es práctico y que puede, a pesar de la complejidad, ofrecer buenos resultados de diseño.

Wolf y otros (2006) sostienen que actuar conforme a diseño en el diseño de interacción requiere un proceso muy disciplinado y riguroso. Uno de los malentendidos más comunes sobre diseño es que, puesto que no se ha desarrollado y refinado tanto en lo intelectual y metodológico como el método científico, es visto como difuso, intuitivo, subjetivo, y difícil de entender. A veces esta falta de claridad incluso se ve y es tildada de irracional. Y, por supuesto, a veces lo es. La práctica del mal diseño es tan difusa e irracional como la mala práctica científica. La idea es que a pesar de que el proceso de diseño no se estructura de igual forma que otros procesos racionales, eso no quiere decir que tenemos que ver al proceso como un “arte oscuro” (Wolf y otros, 2006). En cambio, el diseño tiene su propia estructura interna, procedimientos, actividades y componentes bien reconocidos por diseñadores expertos, que también están explicados en la literatura de diseño mencionada anteriormente.

A lo largo de la historia el ser humano ha “usado” un enfoque afín al diseño, en momentos en que se acercó y trató con un entorno inmediato, rico y complejo, y cambió ese ambiente para que se alineara con sus necesidades y deseos. Sin embargo, esta no es una tradición que se haya convertido en un discurso intelectual con las teorías y puntos de vista externalizados de la misma manera en que lo ha hecho en la tradición científica, o en otras tradiciones, como la religión o el arte. Pero, existen bases y fundamentos intelectuales que sustentan el pensamiento y la acción en diseño, y existe un rigor y una disciplina en el diseño. A continuación, haré referencia brevemente a algunos de los aspectos que constituyen el rigor y la disciplina del diseño. Esto está lejos de una visión global, pero es un comienzo.

Entendimiento existente en el diseño

A pesar de que he argumentado que se requiere desarrollar una comprensión de la práctica del diseño, no hay necesidad de empezar desde cero. Si volvemos a los campos genéricos de las teorías y de la filosofía de diseño podemos encontrar excelentes textos que ofrecen entendimientos fundamentales del diseño. Hay una serie de investigadores que han aportado ideas que ya se consideran seminales (Cruz, 2001; Dunne, 1993; Krippendorff, 2006; Nelson y Stolterman, 2003; Lawson, 2005; Rove, 1987; Pye, 1995; Schön, 1983).

Estos textos, en su conjunto, describen la progresión intelectual de una comprensión temprana basada en la ingeniería del diseño, alentada por una tradición científica, que se ha convertido en un moderno entendimiento afín al diseño de la práctica del diseño. Estos autores no proporcionan una comprensión clara o una teoría del diseño; en vez de eso nos dan varias explicaciones diferentes, y a veces incluso contradictorias, de lo que son los fundamentos de diseño. Pero todos argumentan que existe algo que podemos etiquetar como enfoque afín al diseño, y que el diseño es una actividad humana única que merece su propio tratamiento intelectual.

Todos ellos también están de acuerdo en que un enfoque de este tipo es diferente del enfoque científico y se basa sólidamente en la práctica del diseño y en lo situado y lo concreto. Es un enfoque que se ocupa de los detalles y de la riqueza de la realidad, para crear y formar nuevas realidades.

Estos autores también argumentan, a su manera, que las herramientas y métodos que crean formas predefinidas de acercarse a la realidad no son útiles en el diseño. En cambio, todas las herramientas, técnicas y métodos que supuestamente apoyan la práctica del diseño tienen que ser intencionalmente incorporados como parte de un enfoque afín al diseño, por parte del diseñador actuante. Como consecuencia de esto, se vuelve importante para los que producen el apoyo a los profesionales de diseño hacer posible esa “incorporación” en el propio enfoque del diseñador.

Por ejemplo, Rogers (2004) sostiene que aunque los diseñadores no necesariamente “utilizan” determinados conceptos teóricos, los reconocen y son influenciados por ellos, como puede verse con la noción de potencialidad. La idea de la potencialidad no predefine de modo alguno el proceso de diseño de interacción, pero un diseñador puede “utilizarlo” como “herramienta” en busca de inspiración. Esto significa, por ejemplo, que un diseñador puede incorporar fácilmente la noción de prestación percibida (affordance) y adaptarla a cualquier tipo de proceso que sea adecuado para una situación específica.

Preparado para la acción, no guiado en la acción

Estos autores argumentan que los métodos y los enfoques encaminados a la mejora de la práctica del diseño tienen que ser diseñados con un respeto sincero y una comprensión de los aspectos positivos de la complejidad y la riqueza de las cualidades particulares del caso en cuestión. La mayor parte de estos autores sostienen que la única manera de mantener esa riqueza es que el diseñador se sumerja totalmente en el contexto del caso y que le dé sentido a ese contexto en función de la comprensión de la situación particular, y luego cree un enfoque adecuado para la tarea de diseño específica que nos ocupa. Esta idea fundamental puede condensarse en la noción de que los diseñadores pueden ser preparados para la acción, pero no guiados en la acción mediante detallados procedimientos prescriptivos.

Cuando un diseñador se encuentra en una situación de diseño compleja, tiene que actuar en esa situación respecto a la totalidad de su riqueza y complejidad, y de una manera apropiada para las características específicas de esa situación. La enseñanza del diseño puede preparar para este tipo de situaciones, pero no puede prescribir cómo actuar en ellas. Si alguien no está dispuesto para manejar esta complejidad, los métodos y técnicas no pueden ser “garantía” de guiar a nadie a través de este tipo de situaciones. Un ejemplo de enfoque que se las apaña para cumplir con este requisito se manifiesta en las nociones de reflexión en la acción, reflexión sobre la acción y en el repertorio de diseño de Schön (1983). Con estos conceptos Schön pretende dar a los diseñadores herramientas para la reflexión que pueden utilizar para desarrollar continuamente sus habilidades de diseño.

A través de estos procesos de reflexión, un diseñador puede desarrollar un repertorio útil de ideas de diseño y conceptos de diseño que utilizará en futuras situaciones de diseño. El enfoque de diseño que sostiene Schön y los conceptos que presenta han sido influyentes entre los profesionales. Schön se las ingenió para encontrar una manera de describir una práctica de diseño que puede ser reconocida por la práctica de los diseñadores, así como proporcionar conceptos que se pueden utilizar como herramientas intelectuales en la planificación y el desarrollo del proceso de diseño. Y él hizo esto sin prescribir el proceso a nivel de detalle. En consecuencia, su enfoque es un buen ejemplo de una estrategia basada en el entendimiento de que los diseñadores deben ser apoyados mediante una “preparación para la acción” y no “guiados en la acción”.

Racionalidad del diseño

Comúnmente se describe a los diseñadores en acción como intuitivos o sensibles a una situación. A veces el proceso es incluso visto como mal estructurado, subjetivo, o difuso. Este mismo proceso puede, sin embargo, también ser visto como una forma muy rigurosa y disciplinada de actuar si se ve desde un punto de vista afín al diseño. Es posible comprender y describir la racionalidad subyacente del diseño, y una comprensión tal de la racionalidad del diseño ha sido etiquetada con conceptos como diseñador reflexivo (Löwgren y Stolterman, 2004) y practicante reflexivo (Schön, 1983). Estos autores, y otros como Buxton (2007) y Krippendorff (2006), han delineado lo que ven como la racionalidad del diseño y la actividad disciplinada de diseño. Es evidente que muchos de estos intentos muestran fuertes similitudes en cuanto a lo que ven como un actuar racional como diseñador.

Esto significa que dado que parece posible hablar de una racionalidad de la práctica del diseño, también es posible construir una comprensión más profunda y explicada de lo que define el comportamiento disciplinado de un diseñador. Pueden encontrarse más descripciones detalladas de lo que significa ser un diseñador disciplinado en Kolko (2007), Buxton (2007), y Moggridge (2006). Estos autores muestran, por ejemplo, que el boceto es el núcleo de diseño. Bocetar es una forma disciplinada de explorar las relaciones entre las diversas ideas de diseño, entre el todo y los detalles, entre la forma y la función, entre la apariencia y los materiales, etc. Estos autores también mencionan que un diseñador racional trabaja en muchos diseños alternativos en paralelo de forma iterativa, al tiempo que van y vienen entre el todo y los detalles. Esta forma de hacer diseño no es una opción. Se encuentra en el núcleo de lo que significa actuar de una manera racional, disciplinada, afín al diseño.

Juicio de diseño

Actuar de una manera afín al diseño, y para poder utilizar el juicio y la intuición como herramientas intelectuales precisas en la situación correcta y para los fines adecuados, es por supuesto muy difícil y ejerce mucha presión en el diseñador. Por esta razón el juicio del diseñador se convierte en la “herramienta” principal para hacer frente a la complejidad del diseño de una manera afín al mismo. Una forma de desarrollar las habilidades de una práctica de diseño rigurosa y disciplinada es centrar la capacitación y la educación de los diseñadores en torno al concepto de “repertorio” de Schön y ayudar a los estudiantes a construir deliberadamente una sensibilidad aumentada de calidad y composición, todo con el fin de prepararse para la acción.

Dentro de varios campos del diseño esto se ha convertido en estructuras y procesos construidos en torno a una educación disciplinada, a conceptos y actividades tales como el uso de estudios de diseño y al acto de la crítica de diseño. La arquitectura, el diseño de productos, el diseño visual, y otros campos han, hasta cierto detalle, refinado estos enfoques mientras que estos enfoques en gran medida no se han desarrollado en la enseñanza del diseño de interacción, a pesar de que hay un creciente interés. Estos enfoques educativos son similares a lo se utiliza realmente en la práctica del diseño, y hay varias razones anecdóticas y con base en la experiencia para creer que sirven bien a su propósito; por ejemplo, algunas empresas de diseño de gran éxito, como IDEO, son famosas por su enfoque riguroso afín al diseño.

Argumentación de diseño

Otro aspecto de la idea de actuar de una manera disciplinada es que, tanto en la ciencia como en el diseño, tenemos que abogar por nuestros resultados y su valor. En la ciencia esto se realiza demostrando convincentemente que la investigación se ha llevado a cabo conforme a las normas y procedimientos de un método científico acordado. En la práctica de diseño esto se consigue dándole visibilidad a nuestros juicios y abriéndolos a la crítica. Un aspecto único del diseño es la forma en la que el diseño en sí se convierte en una parte vital del argumento (Krippendorff, 2006; Schön, 1983). Se han presentado ideas similares en HCI con la noción de “artefactos como teorías” (Zimmerman y colaboradores, 2007; Dillon, 1995; Carroll y Kelloww, 1989). Los diseñadores necesitan argumentar sus diseños, pero las bases de lo que constituye un buen argumento son diferentes de las que constituyen un argumento a favor de un resultado científico.

Diseño del proceso de diseño

Un último aspecto de ser riguroso y disciplinado se ocupa de la conciencia del proceso. Tanto el diseño como la ciencia requieren mucha atención al proceso, pero por razones diferentes. Mientras que los investigadores pasan tiempo diseñando y planificando su proceso de investigación para que cumpla con las normas establecidas universales de la ciencia, los diseñadores necesitan diseñar su proceso para que dé cabida a las características específicas y a las condiciones únicas de la tarea en cuestión. Buxton (2007) escribe: “Para crear productos exitosos, es tan importante (si no más) invertir en el diseño del proceso de diseño, como en el diseño del propio producto” (p. 408).

Tomados en conjunto, estos aspectos constituyen solo una pequeña fracción de lo que se puede ver como el núcleo de la disciplina y el rigor de la práctica del diseño. El mensaje de este trabajo es que la investigación en HCI debería adoptar una mayor exploración y desarrollo del rigor de diseño y de la disciplina de la práctica de diseño en el diseño de interacción como una parte importante de su programa de investigación.

Consecuencias para la investigación

Existe un interés creciente en la investigación destinada a apoyar al diseño. Esto se ve, por ejemplo, en el fuerte interés por la noción de ciencia del diseño, un concepto que recientemente exploran muchos investigadores fuertemente empujados por los organismos de financiación. En la Fundación Nacional para la Ciencia de EE.UU. (2004), en una sinopsis del programa Ciencia del Diseño se afirma que “las interdependencias complejas merman nuestra capacidad de crear, mantener, comprender y controlar estos sistemas”. Afirma, además, que para corregir este problema “el objetivo de esta Ciencia del Diseño es desarrollar un conjunto de principios científicos para guiar el diseño de sistemas intensivos en software”. La idea básica parece ser el hacer un diseño más confiable que “se parezca más a la ciencia”. El éxito de esta iniciativa, por lo tanto, depende de lo bien que los métodos de la ciencia puedan transferirse al diseño. La medida del éxito para el programa se presenta así: “Dentro de diez años, el diseño, la construcción, las pruebas, la puesta en servicio, y la modificación de sistemas complejos intensivos en software deben basarse en un corpus coherente y sistemático de conocimientos científicos y experiencia racionalizada”.

Por supuesto, es posible desarrollar enfoques rigurosos que puedan apoyar ciertas formas específicas de la práctica de diseño, especialmente el diseño de sistemas tecnológicos complejos que necesitan soluciones confiables que puedan garantizar estructuras y mecanismos estables. Yo diría, sin embargo, que sería lamentable si el enfoque de la ciencia del diseño se adoptara también para el diseño de sistemas interactivos.

Si eso sucede, es probable que el diseño de interacción termine tomando prestado enfoques, métodos y técnicas que no son en absoluto adecuados para hacer frente a la complejidad del diseño de interacción. De hecho, es incluso posible argumentar que en algunos casos estas técnicas empeorarán las cosas, ya que aumentarían la complejidad del diseño en vez de reducirla. En cambio, lo que se necesita es que la investigación en HCI dirigida a apoyar la práctica del diseño se base en una comprensión bien desarrollada y afín al diseño del proceso de diseño. Es posible sugerir actividades de investigación necesarias para establecer tal entendimiento.

Fundamentos teóricos

En un nivel práctico, esto podría significar llevar las lecturas de la teoría y la filosofía del diseño a los planes de estudio en HCI y en especial a los programas de doctorado en HCI. La buena noticia es que ya hay una cantidad sustancial de literatura que puede servir a este propósito. Deben requerirse tales lecturas también a cualquier investigador en HCI que trate de mejorar la práctica de diseño mediante la creación y el desarrollo de enfoques, métodos, técnicas, o el apoyo a las herramientas de software.

El estudio de la práctica

Otra consecuencia para la investigación en HCI es que una parte del tiempo y el esfuerzo ahora destinados al desarrollo de nuevos modelos, métodos y herramientas para la práctica deben dedicarse a estudios minuciosos y detallados existentes de la práctica de diseño de interacción. Para cambiar la práctica del diseño, necesitamos más investigación que examine, descubra, analice e interprete lo que los diseñadores de interacción ya están haciendo.

Resonancia de racionalidad

Los estudios sobre la práctica existente son importantes por muchas razones, incluso desde una perspectiva pedagógica. Los practicantes suelen no inclinarse a escuchar a los investigadores que no expresan sincero respeto a su práctica y que no pueden demostrar que tienen un profundo conocimiento de las condiciones previas y la realidad de esa práctica. Esta relación entre la práctica sugerida y la práctica existente se denomina resonancia de racionalidad (Stolterman, 1994; Russo y Stolterman, 1998). Cualquier intento de introducir una nueva “racionalidad” en la práctica tiene que resonar con la racionalidad ya existente. Sin tal resonancia la introducción será muy difícil. Es razonable suponer que los enfoques no utilizados por los practicantes (como muestra Rogers, 2004) no resuenan con lo que experimentan los practicantes como la naturaleza de su práctica existente. El estudio serio de la práctica es una fuente de riqueza invaluable para cualquier área que trata de apoyar a una práctica específica.

Formas de apoyo al diseño

Hay una necesidad de estudios sobre qué tipo de apoyo le preocupan y ven con interés los practicantes del diseño de interacción. Se han realizado algunas investigaciones dentro de estudios de diseño más generales (Schön, 1983; Krippendorff, 2006). Según estos y otros estudios, parece que los practicantes de diseño (de interacción) se inclinan a apreciar y utilizar: I) herramientas o técnicas precisas y simples (bocetos, prototipos, entrevistas, encuestas, observaciones, etc.), II) marcos que no prescriben, pero que apoyan reflexión y toma de decisiones (patrones de diseño, formas de utilización de prototipos, estilos de interacción, etc.), III) conceptos individuales intrigantes y abiertos a la interpretación y a la reflexión sobre la forma en que se pueden utilizar (affordance, personaje, sondeo, etc.), IV) ideas de alto nivel teórico y/o filosóficas y enfoques que amplían el pensamiento de diseño pero que no determinan las acciones de diseño (la práctica reflexiva, el diseño centrado en el usuario, el diseño de experiencias, la justificación de diseño, etc.). Esta lista está soportada al menos en parte por los resultados en Rogers (2004). Yo no pretendo decir que la lista es correcta o en cierta forma completa, pero diría que estudios más específicos e intentos de crear una mejor comprensión de una lista como esta es una tarea importante para la investigación en HCI. Tal comprensión apoyaría enormemente el campo en sus propios intentos por evaluar y predecir la utilidad de los intentos de investigación.

Medida de éxito de la investigación de interacción

Si la investigación de interacción es capaz de proporcionar apoyo a la práctica del diseño, luego, se hace evidente otra pregunta, a saber, cómo medir el éxito de este tipo de investigación. Rogers (2004) informa un estudio en el que el éxito de los enfoques teóricos en la práctica se mide por cuánto saben los practicantes sobre los enfoques desarrollados por la investigación y por la medida en que se utilizan realmente. Esto es, por supuesto, una primera condición para el éxito.

Si los practicantes no prestan atención a los resultados de la investigación que son supuestamente para apoyar la práctica, luego no se logra nada. Sin embargo, el hecho de que los métodos se utilicen en la práctica no necesariamente hacen al éxito de la investigación. Un método podría ser usado, pero no en un camino que conduzca a los resultados previstos por el investigador. La cuestión en cambio podría ser: ¿Se han utilizado los resultados de la investigación y dio lugar a las mejoras previstas en el resultado final diseñado? Todo esto abre lo que podrían considerarse como preguntas esenciales cuando se trata de investigación destinada a apoyar la práctica.

Estas preguntas tienen que ver con el propósito de la pretendida mejora. El investigador que crea el apoyo a la práctica se guía por algunos valores básicos y por las intenciones subyacentes a sus intentos. ¿Hacia dónde se supone que deberían llevarnos los resultados de la investigación? ¿Es para mejorar la eficiencia del proceso o la calidad del producto? ¿Es para dar lugar a nuevos diseños creativos e innovadores? ¿Es para dar lugar a diseños competitivos de éxito comercial? ¿A quién se supone que el apoyo debe servir? ¿Hay un cliente “final”? ¿Es el propósito apoyar la práctica del diseño para que conduzca a un “mundo mejor”?

La ciencia tradicional se guía por la búsqueda de la verdad, mientras que la investigación que apunta a cambiar y mejorar la “realidad” siempre asume la responsabilidad en relación a quién o a qué sirve. Esto significa que la investigación en HCI dirigida a cambiar la práctica existente debe asumir la responsabilidad de su propio éxito final. Si el cambio se lleva a cabo, si los practicantes utilizan realmente los resultados de la investigación, ¿hacia dónde nos lleva eso y cuál es la responsabilidad del investigador? El argumento general de este trabajo es que cuestiones como las anteriores solo pueden ser respondidas y manejadas si la investigación tiene base en una comprensión bien desarrollada de la práctica del diseño.

Conclusión

Este artículo se basa en la idea de que tenemos que reconocer y aceptar la complejidad del diseño como un problema real y práctico que enfrenta todo diseñador de interacción. También tenemos que aceptar que la complejidad del diseño no es algo que pueda abordarse mediante el uso de enfoques y herramientas dirigidas a reducir la complejidad pidiendo “prestados” métodos y enfoques de la esfera de la ciencia. En cambio, las disciplinas de diseño, como el diseño de interacción, tienen que desarrollar y fomentar su propio enfoque afín al diseño para la educación y la práctica. La buena noticia es que no tenemos que empezar desde cero.

Existe mucha y excelente teoría y filosofía del diseño producida por pensadores del diseño contemporáneo. Estos autores han producido en las últimas décadas una base intelectual fecunda y diversa de conocimientos de diseño y puntos de vista muy adecuados para el campo del diseño de interacción. Existe también una sólida comprensión de la naturaleza del diseño entre los practicantes avezados. Esta es una fuente que no ha sido explorada ni explotada completamente en relación con el valor potencial que traería. Por lo tanto, hay mucho trabajo por hacer. Una práctica basada en acciones y una comprensión filosófica cabal de la práctica del diseño de interacción pueden convertirse en un conjunto de métodos y técnicas de diseño ricos, rigurosos y bien fundamentados, adecuados a la necesidades y deseos de los diseñadores.

Referencias

Alexander, C. (1964), “Notes on the synthesis of form”, Harvard University Press, Cambridge, MA.

Atwood, M. E., McCain, K. W., y Williams, J. C. (2002), “How does the design community think about design”, en: Proceedings of the 4th Conference on Designing Interactive Systems, pp. 125-132, ACM Press, Nueva York.

Bartneck, C. (2007), “Design methodology is not design science”, en: CHI 2007 workshop: Converging on a ‘science of design’ through the synthesis of design methodologies, San Jose, CA.

Bartneck, C. (2007), “Quality criteria for design and science”, en: CHI 2007 workshop: Exploring design as a research activity, San Jose, CA.

Buchanan, R. (1992), “Wicked problems in design thinking”, 8 (2), pp. 5-21, Design Issues.

Buxton, B. (2007) Sketching user experience – Getting the design right and the right design, San Francisco, Morgan Kaufman.

Carroll, J. M. (2003), HCI models, theories and frameworks, Oxford, Elsevier Publishing.

Carroll, J. M. y Kellogg, W. A. (1989), “Artifact as theorynexus: Hermeneutics meets theory-based design”, 20 (SI), pp. 7-14, ACM SIGCHI Bulletin.

Castells, E. (1996), Rise of the network society, Cambridge, Blackwell, MA.

Coburn, P. (2006), The change function – Why some technologies take off and others crash and burn, New York, Penguin Books.

Cross, N. (2001), “Designerly ways of knowing: Design discipline versus design science”, 17 (3), pp. 49-55, Design Studies.

Csikszentmihalyi, M. (1990), Flow: The psychology of optimal experience, Nueva York, Harper y Row.

Dillon, A. (1995), “Artifacts as theories: Convergence through user-centered design”, en: 58th annual meeting of the American Society for Information Science, Medford, NJ,. http://faculty-l.slis.kent.edu/~drobins/publications.html Accedido el 17 de noviembre de 2007.

Dourish, P. (2006), “Implications for design”, en: Proceedings of the SIGCHI Conference on Human Factors in Computing Systems, pp. 541-550, Nueva York, ACM Press.

Dunne, J. (1993), Back to the rough ground: “Phronesis” and “Techné” in modern philosophy and in Aristotle, University of Notre Dame Press.

Ehn, P., y Löwgren, J. (1997), “Design for quality-in-use: Human-computer interaction meets systems development”, en: M. Helander, T. K. Landauer, y P. V. Prabhu (Eds.), Handbook of Human-Computer Interaction, 2th ed., pp. 299-313, Nueva York, Elsevier.

Fallman, D. (2003), “Design-oriented human-computer interaction”, en: Proceedings of the SIGCHI Conference on Human Factors in Computing Systems, pp. 225-232, Nueva York, ACM Press.

Friedman, T. L. (2005), The world is flat: A brief history of the twenty-first century, Nueva York, Farrar, Straus and Giroux.

Gladwell, M. (2005), Blink: The power of thinking without thinking, Nueva York, Little, Brown and Company.

Goel, V., y Pirolli, P., “The structure of design problem spaces”, 16 (33), pp. 395-429, Cognitive Science, 1992.

Greenfield, A. (2006), Everyware: The dawning age of ubiquitous computing, Berkeley, New Riders, CA.

Heskett, J. (2002), Design: A very short introduction, Oxford, Oxford Press.

Janlert, L. E. y Stolterman, E. (1997), The character of things. Design Studies, 18 (3), pp. 297-314.

Johnson, C. (Ed.) (2005), “Proceedings of the 2nd Workshop on Complexity in Design and Engineering”. En: Department of Computing Science, Glasgow, Universidad de Glasgow.

Kolko, J. (2007), Thoughts on interaction design, Savannah, Brown Bear, GA.

Krippendorff, K. (2006), The semantic turn: A new foundation for design, Boca Raton, Taylor & Francis.

Laurel, B. (2003), Design research: Methods and perspectives”, Cambridge, MIT Press, MA.

Lawson, B. (2005), How designers think: The design process demystified, Boston, Architectural Press.

Löwgren, J., & Stolterman, E. (2004), Thoughtful interaction design: A design perspective on information technology, Cambridge, MIT Press, MA.

Maeda, J. (2006), The laws of simplicity: Design, technology, business, life, Cambridge, MIT Press, MA.

McCarty, J., y Wright, P. (2004), Technology as experience, Cambridge, MIT Press, MA.

McCullogh, M. (2004), Digital ground architecture, pervasive computing, and environmental knowing, Cambridge, MIT Press, MA.

Moggridge, B. (2007), Designing interactions, Cambridge, MIT Press, MA.

National Science Foundation (2004), “Science of design: Program solicitation”. http://www.nsf.gov/pubs/2004/nsf04552/nsf04552.htm Accedido el 1 de noviembre de 2007.

Nelson, H. y Stolterman, E. (2003), “The design way: Intentional change in an unpredictable world”, Englewood Cliffs, NJ: Educational Technology Publications.

Norman, D. (2004), Emotional design: Why we love (or hate) everyday things, Nueva York, Basic Books.

Pink, D. H. (2005), A whole new mind: Moving from information age to the conceptual age, Nueva York, Riverhead Books.

Pye, D. (1995), The nature and aesthetics of design (reimpresión), Bethel, Cambium Press, CT.

Rittel, H. W. y Webber, M. M. (1974), “Dilemmas in general theory of planning”, 8(1), pp. 31-39, Design Research and Methods.

Rove, P. (1987), Design thinking, Cambridge, MIT Press, MA.

Rogers, Y. (2004), “New theoretical approaches for human computer interaction”, en: B. Cronin (Vol. Ed.), Annual review of information, science and technology: Vol. 38, pp. 87-143, Information Today, Medford, NJ.

Russo, N. y Stolterman, E. (1998), “Uncovering the assumptions behind information systems methodologies: Implications for research and practice”, en: “Proceedings of the 6th European Conference on Information Systems”, pp. 896-909, Granada, Euro-Arab Management School.

Schön, D. A. (1983), The reflective practitioner, Nueva York, Basic Books.

Science. (n.d.). en: “Merriam-Webster’s online dictionary”. http://www.merriamwebster.com/dictionary/science Accedido el 20 de octubre de 2007.

Simon, H. (1969), The science of the artificial, Cambridge, MIT Press, MA.

Stolterman, E. (1994), “The transfer of rationality: Adaptability, acceptability and the transparency of methods”, en: W. Baets (Ed.), Proceedings of the 2nd European Conference on Information Systems, pp. 533-540, Breukelen, Nijenrode University Press.

Taylor, P. (2003), “Designerly thinking: What software methodology can learn from design theory”, en: Proceedings of the 36th Annual Simulation Symposium, pp. 107-116, Washington DC, IEEE Computer Society.

Thackara, J. (2005), In the bubble: Designing in a complex world, Cambridge, MIT Press, MA.

Wania, C. E., Atwood, M. E., y McCain, K. W. (2006), “How do design and evaluation interrelate in HCI research”, en: Proceedings of the 6th Conference on Designing Interactive Systems, pp. 90-98, Nueva York, ACM Press.

Winograd, T. (1996), Bringing design to software, Reading, Addison-Wesley, MA.

Wolf, T. V., Rode, J., Sussman, J. y Kellogg, W., (2006), “Dispelling design as the black art of CHI”, en: Proceedings of the SIGCHI Conference on Human Factors in Computing Systems, pp. 521-530, Nueva York, ACM Press.

Zimmerman, J., Forlizzi, J. y Evenson, S. (2007), “Research through design as a method for interaction design research in HCI”, en: Proceedings of the SIGCHI Conference on Human Factors in Computing Systems, pp. 493-502, Nueva York, ACM Press.

Atender a las intenciones, no a los procesos

Texto original: Indi Young (http://indiyoung.com/support-intentions-not-existin/)

Traducción: Mariana Calcagno

Cuando la académica Indi Young fundó Adaptive Path, el mercado vio nacer la primera empresa de diseño estratégico que se basaba en la “empatía” y en los “modelos mentales”. Pionera y hacedora, Indi Young nos marcó un antes y un después en el mundo UX alineando estrategia de diseño con el comportamiento humano. La aparición de su libro Modelos Mentales 5 no deja dudas de esto.

Esta semana estuve conversando con una mujer que trabaja en una organización que aún no reconoce el valor de las investigaciones generativas previas a la definición de un producto. Ella me dijo, con un tono exasperado: “Los gerentes de producto (product managers) siguen dando vueltas recolectando las necesidades de nuestros clientes y trayendo listas de cosas para implementar”. Tenía algo de dinero que había sobrado de un presupuesto (¡¿Dinero de sobra?! Eso no pasa muy seguido) y quería invertirlo en un pequeño proyecto de investigación que diera con la raíz de lo que la gente estaba haciendo –gente que no era cliente todavía. Su sueño era poder mostrarles a los gerentes de producto y a los ejecutivos de su compañía los resultados de una investigación generativa que dieran luz sobre varias y nuevas actividades, previamente inexploradas, que su compañía pueda apoyar.

Su situación me puso a pensar cómo emprenden el diseño de un producto la mayoría de las organizaciones. En general, se focalizan en las prácticas actuales de los consumidores usando productos existentes, pero de las otras compañías. Se le pone muchísimo esfuerzo a captar el procedimiento paso a paso que los consumidores realizan cuando adquieren algo. Se hacen un montón de diagramas de flujo que retratan todos los matices del proceso de consumo. Se invierte una gran cantidad de tiempo y sudor para construir esos diagramas con precisión, lo que en mi opinión es innecesario. Si el esquema preciso sólo rastrea las soluciones provisorias que un sujeto lleva a cabo para hacer que las cosas sucedan como él pretende, entonces sólo se está perpetuando un defecto. Seguro, la gente paga por productos y servicios defectuosos, pero no porque quiera, sino porque no tiene otra opción.

Ya es hora de ir más allá de los procesos existentes y entrar en las intenciones de la gente.

Actor | Paso en el proceso | Intenciones
Químico de laboratorio | Documenta un experimento | Recordar los elementos testeados para probar otros o descubrir nuevos
Soltero con apuro | Se inscribe en un gimnasio | Presentarse en un lugar donde haya gente que pueda interesarle y ser compatible.
Persona con hambre | Decide comprar comida rápida | Darse más tiempo para estar con su pareja en lugar de perderlo haciendo compras y cocinando.
Persona con alta presión arterial | Cuida la cantidad de sal que consume | Vivir más tiempo para poder disfrutar y ayudar a los nietos.

En cada uno de estos ejemplos, podrían imaginarse varias alternativas para ayudar al actor. Tomemos a la mujer que tiene hambre, que sólo quiere pasar tiempo con su marido después de un largo día de trabajo. Cocinar y hacer las compras son sólo dos cosas que ella puede eliminar de su esquema diario. También podría dejar de pasar por la tintorería o de hacer los cheques para pagar las cuentas. Pero digamos que ustedes poseen una organización que comercializa productos orgánicos. Su filosofía de base es ayudar a la gente a comer comida más saludable.

Ofrecen un servicio semanal de entrega a domicilio de una caja de frutas y verduras locales de estación. Junto con eso, publican en internet una selección especial de recetas para ayudar a la gente a cocinar los vegetales que no conoce. Durante años, han estado discutiendo sobre cómo convencer a la gente de que abandone la comida rápida, pero la facilidad de obtener algo para comer rápido, barato (a menudo dulce, grasoso y producido en algún lugar muy lejos de casa) y esto parece demasiado difícil de vencer. Observemos el motivo que ella resalta: pasar más tiempo con su marido. Imaginemos que ya han copado el mercado de aquellos que cocinan felizmente y han logrado convencer a sus parejas de cocinar juntos. Eso nos deja a la pareja a la que no le gusta cocinar. ¿Qué pasa si consiguen una habilitación de cocina profesional y crean algunas “cenas para comer frente a la tele”, simples y saludables, orgánicas, envasadas en cajas de comida para llevar hechas de papel reciclable, que se entregan a domicilio semanalmente? Es cierto, es un riesgo de negocio y probablemente cueste casi lo mismo producirlo que lo que se podría cobrar, pero vale la pena explorarlo, teniendo en cuenta que la infraestructura de entrega a domicilio ya está funcionando. Si a esta persona le motiva más el tiempo de calidad que el precio, es probable que tengamos una buena idea entre manos.

Cuando tengan la oportunidad de pasar tiempo con gente que pueda convertirse en usuario o cliente de lo que produzcan, concéntrense en encontrar sus intenciones subyacentes. Pasen de largo sobre los detalles sobre cómo ejecutan sus acciones y, en lugar de eso, utilicen su tiempo en averiguar qué hay detrás de cada una de las etapas del proceso que realizan. ¿Qué están tratando de lograr además de la acción en sí misma? Muchas veces sucede que la gente no se ha dedicado a pensar realmente más allá del proceso que lleva a cabo y la conversación se transforma en algo parecido a una sesión de terapia, guiando a la persona a encontrar esas cuestiones subyacentes y describirlas. Cuando esto pasa, significa que van por buen camino. Con los resultados de varias conversaciones como estas, ustedes podrán llevar a su compañía hacia áreas que nunca antes habían considerado o ni siquiera conscientes de su existencia. Este camino nos guía hacia productos y servicios que atienden a lo que la gente realmente quiere hacer y lo que les hace la vida más fácil. Y esta es una propuesta más que atractiva para la mayoría de nosotros.

Notas

5 Young, Idi (2007), Mental Models. Aligning Design Strategy with Human Behavior, Nueva York, Rosenfeld.

Reclutamiento durante comportamiento

Texto original: Indi Young (Recruting Across Behaviors 2013. Versión original en inglés en archivo de artículos en http://indiyoung.com/)

Traducción: Mariana Calcagno

Un día recibí un entusiasta pero desorientado pedido de ayuda de una diseñadora UX de Sudáfrica, Jeanne Marias. Me escribió: “Estoy liderando un proyecto de diseño de servicios, parte del cual quiero hacer con el Modelo Mental de El camino del miembro nuevo. Ya me lancé a la carga y tuve a todo el equipo emocionado con los modelos mentales, pero luego de leer la sección de su libro sobre la definición de segmentos de audiencia basados en tareas, me estoy sintiendo un poco desalentada y desbordada. Especialmente cuando se habla sobre la Historia, el Arte y el continuum de la compañía”.

Ella quería saber si había un modo más sencillo y amigable de armar los segmentos de audiencia, similares a la historieta que explica los modelos mentales. No importa que no sepan para qué industria es esto, “los miembros nuevos” aparecen en muchos ámbitos diferentes, como en la industria de los seguros, sindicatos de docentes, clubes de lectura. Entonces, no se preocupan por la industria de la que está hablando.

Hay una historieta sobre “personajes”, pero los personajes se obtienen luego de hacer las entrevistas. Para las audiencias hipotéticas antes del reclutamiento, solo deben tener en cuenta una cosa: tradicionalmente, las organizaciones hacen sus reclutamientos por demografía (edad, experiencia o frecuencia). Esta vez deben estar seguros de cubrir todas las clases de comportamiento que son importantes para ustedes en esta ronda de entrevistas. Las clases de comportamiento son como estilos para tomar decisiones, objetivos, motivaciones, actitud, etcétera. Además recuerden que no necesitan armar segmentos hipotéticos si ya los tienen de investigaciones previas, y no son segmentos ni demográficos ni de mercado. Úsenlos como una base para el reclutamiento, o incorporen grupos adicionales si su negocio lo requiere en este momento.

El ejemplo de mi libro es un poco complejo. Su situación puede ser más simple. Analicemos un ejemplo nuevo. Imaginemos que su negocio es “perder peso”, y los nuevos miembros son personas que se inscriben en uno de los programas. Dejemos de lado datos demográficos como edad, género, estado físico, cantidad de veces que ha tratado de bajar de peso previamente, nivel de ingreso, etc. En su lugar, concéntrense en el comportamiento que observan en los ingresantes. Podrían caer en dos categorías: “Necesito bajar 10 kilos para mi casamiento, y no estoy pensando más allá de eso” y “Necesito una nueva perspectiva para llegar fácilmente y mantenerme en mi peso saludable”. Podría haber otra categoría de comportamiento, “Mi médico me dijo que tenía que bajar de peso pero nunca he tenido éxito antes”.

Descarten todo lo que escribí en el libro y sólo observen a sus “nuevos miembros” desde el punto de vista de las actitudes y las conductas. Quizás necesiten hablar con algunas de las personas de distintos puntos de venta que acostumbran a tratar con los ingresantes, para ver si ellos refieren algún tipo específico de personalidad.

Recuerden: la única razón por la cual se realizan estos segmentos de audiencia hipotéticos es para asegurarse que el reclutamiento incluya a miembros de todos los grupos. No son personajes, y no importan después. De hecho, los eliminan cuando hayan recolectado todas las historias. No se queden atrapados en los detalles de estos grupos hipotéticos.

Por qué sólo hace falta probar con 5 usuarios

Texto original: Jeff Sauro (http://www.measuringusability.com/five-users.php)

Traducción: Sebastián Betti

Jeff Sauro es director fundador de Measuring Usability LLC, analista estadístico especializado en Seis Sigma y pionero en la cuantificación de la experiencia del usuario. Se especializa en hacer de los conceptos estadísticos algo comprensible y aplicable. Jeff ha publicado más de quince artículos de investigación revisados por pares y presenta tutoriales y documentos regularmente en las principales conferencias de HCI: CHI, UPA y HCII y HFES. Es autor de cuatro libros, entre ellos el reciente Quantifying the User Experience: Practical Statistics for User Research 6, junto a James Lewis.

Una pregunta que me hacen mucho es, para hacer una prueba con usuarios, ¿sólo se necesitan 5 usuarios? Hay opiniones muy contundentes sobre el mágico número 5 en pruebas de usabilidad y mucho se ha escrito sobre eso. Como podrás imaginar no hay un número fijo de usuarios que siempre sea correcto (a los cuantitativos nos encanta decir eso), pero probar con 5 usuarios puede ser todo lo que se necesita para descubrir problemas en una interfaz, dadas algunas condiciones.

La cantidad de 5 usuarios viene de la cantidad de usuarios necesarios para detectar aproximadamente el 85 % de los problemas en una interfaz, dado que la probabilidad de que un usuario encuentre un problema es de un 31 %. La mayoría de la gente deja afuera la última parte o no está segura de lo que significa.

Esto no se aplica a todas las situaciones de prueba, tales como la comparación de dos productos o cuando se trata de obtener una medida precisa de los tiempos de trabajo o las tasas de terminación, sino para descubrir problemas con una interfaz. ¿De dónde viene el 31 %? Se llegó a esto como una frecuencia media a partir de varios estudios. 5 usuarios sólo funciona para descubrir problemas, no para comparar interfaces o estimar un tiempo de tarea o una tasa de finalización. Por ejemplo, el calendario en Hertz.com tiene un problema con las fechas. Imaginemos que esto afectará negativamente al 31 % de las reservas, lo cual es bastante. Entonces la pregunta es, si se produce un problema con esta frecuencia (afecta a todos estos usuarios), ¿cuántos usuarios hay que observar para tener una probabilidad del 85 % de verlo durante una prueba de usabilidad? Se podría tener la tentación a pensar que solo se necesita que 3 usuarios lo vean una vez, pero las fluctuaciones probabilísticas no funcionan de esa manera con muestras de tamaño pequeño. En realidad se necesitan 5, y esto viene de la probabilidad binomial.

Lanzar una moneda (50 % de probabilidad)

Todos sabemos que hay un 50 % de probabilidad de que salga cara y un 50 % de probabilidad de que salga cruz al lanzar una moneda al aire. Si quisiéramos saber cuántas veces se debe lanzar una moneda para ver cruz al menos una vez, usando la fórmula binomial, la respuesta es 3. Uno puede comprobarlo por su cuenta; arroja una moneda hasta que sale cruz. El 85 % de las veces no serán necesarias más de 3 veces. Puede repetirse este ejercicio y ver la cantidad de tamaños de muestra mayores a 3. Con el tiempo, un poco más del 85 % de todas las muestras será de 3 o menos.

P: ¿Cuántas veces hay que lanzar una moneda para tener un 85 % de seguridad de ver cruz al menos una vez?

R: 3 o menos.

Cada vez que se arroja la moneda, la probabilidad es del 50 % de ver cruz.

Lanzar un dado (16,7 % de probabilidad)

Hay una posibilidad de 1/6 de que salga un número dado en un dado de 6 caras. Por eso en cualquier tiro hay una probabilidad de 16,667 %  de que salga 1. La fórmula binomial predice que será necesario lanzar un dado, en promedio, 10 veces para tener un 85 % de seguridad de que salga un 1.

Q: ¿Cuántas veces hay que tirar un dado para tener un 85 % de seguridad de que salga un 1 al menos una vez?

R: 10 o menos.

En cada tiro hay una probabilidad de 16,667 % de ver un 1.

Problemas en la IU

Ahora tengo tres problemas de interfaz de usuario que se producen el 31 %, el 10 % y el 1 % del tiempo.

Detección de problemas que afectan al 31 % de los usuarios:

P: ¿Con cuántos usuarios hay que probar para tener una seguridad del  85 % de ver al menos una vez que ocurra un problema que afecta al 31 % de los usuarios?

R: 5 o menos.

Cómo detectar problemas que afectan al 10 % de los usuarios:

P: ¿Con cuántos usuarios hay que probar para tener una seguridad del 85 % de ver al menos una vez que ocurra un problema que afecta al 10 % de los usuarios?

R: 18 o menos.

Cómo detectar problemas que afectan al 1 % de los usuarios:

P: ¿Con cuántos usuarios hay que probar para tener una seguridad del 85 % de ver al menos una vez que ocurra un problema que afecta al 1 % de los usuarios?

R: 189 o menos.

¿Cuántos usuarios se necesitan entonces?

Si uno planea la prueba con 5 usuarios, sabe que no es probable que veamos la mayoría de los problemas, es probable que veamos los problemas que afectan del 31% al 100% de la población, y a este conjunto de tareas. Por supuesto, no todos los problemas afectan al 31 % de los usuarios. De hecho, en software o sitios web productivos, la probabilidad de encontrar un problema podría rondar del 5 % al 10 %. Cuando los problemas son mucho menos propensos a ser “detectados” por los usuarios que interactúan con el software, uno necesita probar con más usuarios para tener una oportunidad decente de observarlos en un test de usabilidad. Por ejemplo, dado un problema que solo afecta al 10 % de los usuarios, es necesario planificar pruebas con 18 usuarios para tener una probabilidad del 85 % de ver la ocurrencia una vez. Grafiqué la diferencia en la siguiente figura. La línea azul muestra los problemas que afectan al 10 % de los usuarios y la roja a los que afectan al 31 % de los usuarios.

La diferencia en el tamaño de las muestras necesarias para tener una probabilidad del 85 % de detectar un problema que afecta al 10 % de los usuarios versus el 31 % de los usuarios. Habría que planificar pruebas con 18 usuarios para tener un 85 % de probabilidad de detectar los problemas que afectan al 10 % de los usuarios.

¿Por qué la controversia?

No hay preocupación por la fórmula binomial (o su equivalente de Poisson), la controversia es en torno a la frecuencia con que realmente se producen los problemas de interfaz de usuario. En realidad no son un porcentaje fijo como el 31 % o el 10 %, en cambio éstos representan un promedio de frecuencia del problema.

Los problemas no afectan de manera uniforme a los usuarios. El 31 % es una frecuencia media de muchos estudios, para aplicaciones productivas la frecuencia es probablemente menor al 10 %. Los problemas en realidad no afectan a los usuarios de manera uniforme, ni afectan a los usuarios de manera fácilmente predecible. Si bien es difícil saber con qué frecuencia se producen los problemas, como regla general, para los primeros diseños será más alta (31 % o más) y para aplicaciones que están en uso con muchos usuarios es probable que sea por debajo del 10 %. Por supuesto, uno desconoce la probabilidad de ocurrencia de un problema para un usuario. De hecho, a menudo uno ni siquiera sabe que hay un problema. De saberlo, ¡lo arreglaría!

Como estrategia, tomemos un porcentaje de ocurrencia de un problema, por ejemplo del 20 %, y la probabilidad de descubrirlo, digamos del 85 %, lo que significaría que habría que probar con 9 usuarios. Después de probar con 9 usuarios, uno sabría que ha visto la mayoría de los problemas que afectan a un 20 % o más de los usuarios. Para estar más seguros de los resultados, a continuación, aumentamos la probabilidad de detección, por ejemplo, al 95 %. En ese caso el tamaño de la muestra aumentaría a 13 usuarios.

La mejor estrategia es traer a un conjunto de usuarios, encontrar los problemas que tienen, arreglar esos problemas, y luego traer a otro conjunto de usuarios como parte de un diseño iterativo y estrategia de prueba. Al final, aunque nunca se está probando más de 5 usuarios a la vez, en total, uno puede probar con 15 o 20 usuarios. De hecho, esto es lo que recomienda Nielsen en uno de sus artículos, no sólo probar con 5 usuarios en total.

Por eso, si uno planea probar con 5 usuarios, sabe que no es probable que veamos la mayoría de los problemas, que son sólo probabilidades de ver la mayoría de los problemas que afectan a entre el 31 %  y el 100 % de los usuarios, para esta población y ese conjunto de tareas. También veremos algunos de los problemas que afectan a menos del 31 % de los usuarios, no solo al 85 % de ellos. Por ejemplo, un tamaño de muestra de 5 debe recoger aproximadamente el 50 % de los problemas con probabilidades de ocurrencia de 15 %, 75 % de los problemas con probabilidades de 25 %, y así sucesivamente. Si cambiamos las tareas o el tipo de usuarios, necesitaremos una nueva muestra de usuarios.

Notas

6 Sauro, Jeffrey y Lewis, James (2012), Quantifying the User Experience: Practical Statistics for User Research, Massachusetts, Morgan Kaufmann.

La perspectiva psicológica del diseño UX

Texto: Susan Weinschenk

Traducción: Mariana Calcagno

Susan Weinschenk es psicóloga por práctica y formación. Sus 10 puntos son como dogmas o mandamientos porque ayudan a un diseñador, a un investigador, a un usuario, a un cliente a comprender el funcionamiento del cerebro a través de la interacción con una interfaz.

Este artículo ofrece un panorama de la perspectiva psicológica del elefante. La parte del elefante que yo percibo se aplica a lo que conocemos sobre las personas y cómo aplicamos ese conocimiento al diseño UX. Tomo las investigaciones y el conocimiento sobre el cerebro, el sistema visual, la memoria y la motivación, y desde ahí extraigo los principios del diseño UX. Quizás hayan oído alguna vez la siguiente historia sobre el elefante. Un rey manda a traer seis hombres a un edificio completamente oscuro. No pueden ver nada. El rey les dice: “He comprado este animal desde tierras salvajes. Se llama elefante”. “¿Qué es un elefante?”, preguntan los hombres. El rey les responde: “Toquen al elefante y descríbanmelo”. El primer hombre toca una pata y dice que el elefante es como una columna; otro le toca la cola y dice que es como una soga. El tercero siente la trompa y dice que los elefantes son como ramas de árboles; otro acaricia una oreja y dice que el elefante es como un abanico, el quinto toca su panza y dice que los elefantes son como paredes; el último siente los colmillos y dice que los elefantes son como caños. “Todos tienen razón”, dice el rey, “Cada uno de ustedes está tocando sólo una parte del animal”. La historia del elefante me recuerda a las diversas perspectivas sobre el diseño que tiene la gente con diferentes orígenes, formación y experiencia. El diseñador de comunicación visual se acerca al diseño UX desde un punto de vista, el diseñador de interacción, desde otro, y el programador, desde otro diferente. Podría ser útil comprender e incluso experimentar la parte del elefante que los otros están percibiendo.

1. La gente no quiere trabajar ni pensar más de lo necesario

Los usuarios harán la menor cantidad de trabajo posible para lograr una tarea determinada.

Es mejor ofrecer pequeñas porciones de información y dejar a los usuarios elegir si desean conocer más detalles. El término correcto para esto es “revelación progresiva”, sobre el que escribí un post en mi blog hace poco.

En lugar de presentar sólo descripciones, ofrezcan un ejemplo.

Presten atención a la potencialidad de los objetos en la pantalla, página o dispositivo que estén diseñando. Si algo es cliqueable, asegúrense de que luzca como tal.

Presenten sólo los elementos que la gente realmente necesita. No confíen en lo que ustedes creen que ellos necesitan. Hagan investigaciones sobre los usuarios para averiguarlo. Darle a la gente más de lo que necesita sólo estorba la experiencia.

Ofrezcan opciones por defecto. Éstas permiten hacer menos trabajo para obtener el mismo resultado.

2. Las personas tienen limitaciones

La gente sólo puede prestar atención a cierta cantidad de información o leer determinada cantidad de texto sin perder el interés. Proporcionen únicamente la información que sea necesaria en el momento (ver “revelación progresiva” en el punto 1).

Asegúrense de que la información sea fácil de escanear.

Usen títulos y bloques cortos de información o texto.

La gente no puede hacer varias tareas a la vez. Las investigaciones son muy claras en este punto, así que no pretendan lo contrario.

La gente prefiere las oraciones cortas, ¡pero lee mejor las largas! Es un misterio, entonces deberán decidir ustedes entre preferencia y desempeño dependiendo de lo que sea más importante en su caso particular; pero sepan que la gente siempre va a pedir cosas que no siempre son lo mejor para ellos.

3. La gente se equivoca

Supongan que los usuarios van a cometer errores. Anticipen cuáles podrían ser y traten de prevenirlos.

Si el resultado de un error es grave, entonces usen confirmaciones antes de actuar sobre el error del usuario.

Asegúrense de que sea fácil “deshacer”.

Prevenir errores siempre es mejor que ayudar a la gente a corregirlos una vez cometidos. El mejor mensaje de error es que no haya mensaje de error.

Si una tarea es propensa a errores, divídanla en pequeñas partes.

Si el usuario comete un error y se puede corregir, corríjanlo pero indíquenle cómo lo hicieron.

Quien sea que esté a cargo del diseño UX también puede equivocarse, así que asegúrense de que haya tiempo y energía para la repetición, la devolución de los usuarios y testeos.

4. La memoria humana es complicada

La gente reconstruye sus recuerdos, lo que significa que cambian todo el tiempo. No se puede confiar demasiado en lo que los usuarios afirmen como verdad. Es mejor observarlos en acción que tomar su palabra como cierta.

La memoria humana es frágil. Se degrada rápidamente y está sujeta a miles de errores. No pretendan que la gente recuerde tarea por tarea o página por página

Podemos recordar entre tres y cuatro elementos al mismo tiempo. La regla de “7 + - 2” es una leyenda urbana. Las investigaciones muestran que el número real es entre tres y cuatro

5. Las personas son seres sociales

La gente siempre tratará de usar la tecnología para interactuar. Esto ha sido así por miles de años.

La gente busca ayuda en otras personas sobre lo que tiene que hacer, sobre todo si están inseguros. Esto se llama validación social. Es por esto que los ratings y las reseñas son tan poderosas para los sitios web.

Cuando las personas hacen algo juntas al mismo tiempo (comportamiento sincrónico), eso los une; se producen reacciones químicas reales en el cerebro. La risa también conecta a la gente de esa manera.

Si me haces un favor, me voy a sentir en deuda para devolvértelo (reciprocidad). Los estudios demuestran que si queremos que un usuario llene un formulario, debemos darle primero algo que él quiera y después pedirle que haga lo nosotros queremos que haga, y no al revés.

Cuando vemos a alguien realizando cualquier actividad, se activan las mismas partes del cerebro que se activarían si estuviéramos haciéndolo nosotros mismos. Nuestra biología está programada para imitar. Si quieren que la gente haga algo, entonces muéstrenle a otra persona haciendo lo mismo.

Se pueden tener lazos profundos sólo con 150 personas aproximadamente. Los lazos profundos se definen como aquellos que establecemos con las personas con las que tenemos proximidad física cercana. Pero lazos débiles podemos tener miles y son muy influenciables (a la Facebook).

6. Atención

Estoy empezando a pensar que todo el tema de la atención es clave para diseñar una UI (Interface de Usuario) atractiva. Ya escribiré más al respecto en futuros artículos. Captar y mantener la atención, evitar distraer a alguien cuando está prestando atención a algo son preocupaciones fundamentales

La gente está programada para prestarle especial atención a lo diferente o lo innovador. Si producen algo diferente, se va a distinguir.

Habiendo dicho esto, debe decirse que la gente también puede no ver cambios producidos en su campo visual. A esto se lo llama “ceguera al cambio”. Se pueden ver algunos videos divertidos en los que alguien comienza a hablar con una persona en la calle (que los ha parado previamente para pedirle direcciones) y luego no notan el momento en el que esta cambia su lugar con otra.

Pueden aprovechar los sentidos para atraer la atención. Colores brillantes, fuentes grandes, beeps y tonos lograrán captar la atención de los usuarios.

Las personas se distraen con facilidad. Si no quieren que se distraigan, no hagan que aparezcan cosas en la página de forma repentina ni pongan videos que se reproduzcan automáticamente. Sin embargo, si quieren llamar su atención, hagan todo eso.

7. La gente busca información

La dopamina es un químico que hace que la gente busque comida, sexo, información. Aprender es dopaminérgico, no podemos evitar querer más información.

Normalmente la gente quiere más información de la que en realidad puede procesar. Tener más información los hace sentir con más opciones. Tener más opciones los hace sentir que tiene el control. Sentir que tiene el control les hace sentir que sobrevivirán mejor.

La gente necesita una devolución. La computadora no necesita decirle al humano que está descargando un archivo. Es el humano el que necesita saber lo que está pasando.

8. Procesamiento inconsciente

La mayor parte del procesamiento mental ocurre de manera inconsciente.

Si logran que la gente se comprometa a realizar una pequeña acción (registrarse para una suscripción gratuita), luego será mucho más factible que se comprometa con una acción más importante (por ejemplo, ascender a una cuenta premium).

El núcleo central del cerebro nos permite tomar decisiones o al menos tiene gran incidencia en ellas. Esta parte del cerebro es la que la se ocupa de la supervivencia y la reproducción: comida, sexo y peligro. Es por eso que estos tres mensajes pueden captar nuestra atención.

El cerebro emocional se ve afectado por las imágenes, especialmente por fotos de personas, así como por las historias. El cerebro emocional tiene un enorme impacto en nuestras decisiones.

El comportamiento se ve gravemente afectado por factores de los que ni somos conscientes. Las palabras “jubilado”, “Florida” y “cansado” pueden lograr que incluso gente joven camine más lento por un pasillo.

Tanto el núcleo central del cerebro como el cerebro emocional actúan sin que nosotros tengamos conocimiento de ello. Siempre trataremos de atribuir la toma de una decisión a una causa racional, consciente, pero nunca será la razón entera, e incluso a veces ni siquiera forma parte de ella.

9. La gente construye modelos mentales.

Todos tenemos un modelo mental sobre determinado objeto o tarea (pagar las cuentas, leer un libro, usar el control remoto).

El modelo mental que las personas tienen sobre una tarea particular puede hacer que sea más fácil o más difícil el uso de la interface que hayan diseñado.

Para crear una experiencia de usuario positiva, pueden o bien emparejar el modelo conceptual de su producto o sitio web al modelo mental de los usuarios, o bien tratar de pensar cómo “enseñarles” a construir un modelo mental diferente.

Las metáforas ayudan a “comprender” modelos conceptuales. Por ejemplo, “esto es igual que leer un libro”.

La razón más importante para hacer investigaciones sobre los usuarios es obtener información acerca de sus modelos mentales.

10. Sistema visual

Si las páginas están abarrotadas, los usuarios no pueden encontrar lo que necesitan. Agrupen la información para ayudar al ojo a enfocar su atención.

Las cosas que se presentan juntas, se consideran que “van juntas”.

Utilicen fuentes lo suficientemente grandes. No elijan tipografías muy decorativas, para facilitar su lectura.

Las investigaciones demuestran que la gente usa la visión periférica para encontrar lo que buscan. Los estudios sobre el seguimiento de la vista son interesantes, pero que alguien esté mirando un elemento directamente no quiere decir que le esté prestando atención.

Los colores más difíciles de mirar juntos son el rojo y el azul. Traten de evitar colocar textos rojos sobre fondos azules y viceversa.

La gente tiende a reconocer mejor los objetos en la pantalla cuando están apenas inclinados y se presentan desde una perspectiva que los ubica ligeramente hacia arriba (perspectiva canónica).

El color puede ser usado para indicar que dos cosas van juntas. Asegúrense de usar otra forma de mostrar lo mismo teniendo en cuenta que algunas personas son daltónicas.

Experiencia etnográfica con estudiantes con discapacidad visual: la Universidat Oberta de Catalunya como estudio de caso

Texto: Pablo Rebaque-Rivas, Eva P. Gil-Rodríguez, Llorenç Sabaté-Jardí.

Universitat Oberta de Catalunya (UOC)

Pablo Rebaque-Rivas es especialista en UX. Trabaja desde hace 5 años en la UOC para mejorar la experiencia de usuario de estudiantes y profesores en su relación con la plataforma tecnológica de la UOC.

Eva P. Gil-Rodríguez es doctora en Psicología Social especializada en UX. Actualmente es directora del departamento Aplicaciones para la Comunidad de UOC, donde lidera proyectos UX aplicados a entornos de e-learning.

Llorenç Sabaté-Jardí es diplomado en informática y especialista en accesibilidad. Trabaja desde 1998 en la UOC para mejorar la accesibilidad de la plataforma tecnológica de la UOC.

Resumen

En este artículo mostramos cómo hemos empleado una metodología de análisis contextual (Beyer y Holtzblatt, 1998) con estudiantes con discapacidad visual de la Universitat Oberta de Catalunya, institución de educación superior a distancia que proporciona sus estudios exclusivamente mediante un entorno virtual de aprendizaje (EVA). El objetivo no ha sido otro que el de extraer una serie de recomendaciones de diseño universal específicas para estudios on-line y entornos virtuales de aprendizaje. Estas recomendaciones manifiestan la importancia de la formación en accesibilidad de las personas encargadas de proporcionar y elaborar los contenidos educativos y de la personalización como modo de tener en cuenta las necesidades de los estudiantes con discapacidad visual. En el caso del EVA, el uso de widgets como modo de organizar y acceder al contenido facilita esta personalización. Para obtener estas recomendaciones, 15 estudiantes con discapacidad visual fueron entrevistados en profundidad en su contexto de estudio (sus hogares) para conocer su día a día como estudiantes y las características y artefactos que conforman su lugar habitual de estudio. También se realizaron tests de usabilidad in situ del EVA con un laboratorio de accesibilidad especialmente adaptado.

1. Introducción

En entornos virtuales de aprendizaje (EVA), seguir los estándares de accesibilidad y una adecuada usabilidad es fundamental para garantizar que los estudiantes con discapacidad visual no tengan dificultades a la hora de acceder a las diferentes partes del campus virtual, pudiendo así llevar a cabo su formación en igualdad de condiciones y con la misma facilidad que los estudiantes sin discapacidad. Con la aparición de los cursos masivos abiertos online (Massive Open Online Courses en inglés – MOOCs) y la proliferación del e-learning y de la modalidad de blended learning en nuestras universidades, este aspecto adquiere todavía más importancia.

No obstante, seguir los estándares de accesibilidad no siempre garantiza una experiencia de usuario satisfactoria en este tipo de estudiantes (Lazar, Allen, Kleinman y Malarkey, 2007; Ribera, Térmens Graells y García , 2008; Sloan, Kelly, Heath, Petrie, Fraser y Phipps, 2006; Theolanos y Redish 2003), por lo que se hace necesario conocer de una manera más directa al usuario final en su contexto real para garantizar que realmente su interacción con el entorno sea la mejor posible (Ribera y otros, 2008; Theolanos y Redish 2003; Sloan y otros, 2006).

Sin embargo, esta metodología de estudio y análisis de contexto no es usada habitualmente cuando se trata de evaluar la accesibilidad de entornos virtuales de instituciones universitarias. Generalmente se hace uso de herramientas automáticas para la detección de errores de accesibilidad (por ejemplo, en Kane, Shulman, Shockley y Ladner, 2007) o se evalúa en base a experiencias del autor (Burgstahler, 2002; Cooper, 2006) para ofrecer recomendaciones de diseño accesible. En este sentido, estamos de acuerdo con Cándido (2008) respecto a la falta de investigación cualitativa con estudiantes con discapacidad visual sobre su experiencia y percepciones sobre el on-line learning.

En este artículo describiremos cómo con una aproximación cualitativa hemos recogido requisitos de usuario y necesidades de estudiantes con discapacidad visual de la Universitat Oberta de Catalunya (UOC), institución de educación superior a distancia que proporciona sus estudios exclusivamente mediante un entorno virtual de aprendizaje. Concretamente, se empleó la metodología de análisis contextual (Beyer y Holtzblatt, 1998), a la que se sumaron tests de usabilidad in situ del EVA a 15 estudiantes con discapacidad visual en sus hogares, su contexto habitual de estudio, mediante un laboratorio de accesibilidad adaptado. En base a este estudio de caso de la UOC, hemos extraído una serie de recomendaciones de diseño específicas para estudios on-line y entornos virtuales de aprendizaje enfocadas al diseño universal (Stephanidis, 2001), es decir, al diseño de productos y servicios que cubren las necesidades de los usuarios independientemente de su diversidad funcional, habilidades y preferencias. Estas recomendaciones hacen énfasis en la importancia de la personalización, y buscan garantizar una experiencia de usuario satisfactoria para los estudiantes con discapacidad visual.

2. Objetivos

Nuestra investigación tenía dos objetivos principales: por un lado, y mediante una aproximación cualitativa, queríamos explorar cómo es la cotidianidad del estudiante con discapacidad visual en relación con la UOC con el fin de averiguar las principales dificultades y necesidades con las que se encuentran y cómo las resuelven. Para ello se realizaron observaciones etnográficas y entrevistas en profundidad.

Por otro lado, también se perseguía evaluar la usabilidad y accesibilidad del EVA, el punto de partida y principal medio para la formación online del estudiante. Para ello se realizó un test de usabilidad que tenía el propósito de recoger una serie de recomendaciones útiles para el diseño de EVAs, asegurando su accesibilidad y una experiencia de usuario satisfactoria para los estudiantes con discapacidad visual.

Ambos estudios nos permitieron establecer una serie de recomendaciones de diseño universal específicas para estudios on-line y entornos virtuales de aprendizaje.

A continuación describimos en detalle la metodología, las características de la muestra estudiada, los resultados del trabajo de campo y las recomendaciones extraídas, así como las conclusiones finales.

3. Metodología

Como se dice en Ribera, Térmens y Frías (2009), las mejores prácticas actuales sobre accesibilidad incorporan la filosofía del Diseño Centrado en el Usuario (DCU). Uno de los métodos del DCU es el análisis contextual, el cual es un tipo específico de recogida de datos en el mismo contexto del usuario (Beyer y Holtzblatt, 1998). Bajo esta perspectiva, tanto las entrevistas en profundidad como los tests de usabilidad tuvieron lugar en la casa de los estudiantes.

El objetivo de esta observación participante era, por un lado, observar con detalle cómo es su contexto cotidiano de estudio para entender mejor cómo utilizan las diferentes herramientas tiflotécnicas y otras tecnologías y artefactos.

Respecto a las entrevistas en profundidad, éstas pretendían conocer las acciones que realizan en su día a día como estudiante on-line, y conocer qué interacciones llevan a cabo no sólo con el entorno virtual sino también con otras personas o artefactos necesarios para realizar cualquier paso dentro de su proceso de aprendizaje (personal de gestión de la universidad, profesorado, contenidos didácticos, otros materiales, etc.).

Por otro lado, realizar el test de usabilidad en sus hogares garantizaba que se hiciera en la familiaridad de su contexto natural de estudio. En este sentido, los tests de usuario se realizaron sobre un rediseño del EVA de la UOC. Para este rediseño se puso énfasis en la mejora de la personalización y la flexibilidad, siguiendo la tendencia innovadora y cada vez más extendida sobre la base de la transformación de los Sistemas de Gestión de Aprendizaje en Entornos Personales de Aprendizaje (PLE) (Lubensky, 2006). De este modo, el entorno fue finalmente diseñado de modo que el usuario encuentra un menú horizontal al principio de la misma con diferentes servicios, y una serie de widgets que funcionan como atajos a los contenidos más relevantes para el estudiante, como el correo, la agenda, las aulas, noticias de interés, etc., siendo estos widgets personalizables, en el sentido de que se pueden añadir, borrar, desplazar o cambiar el color (ver Figura 1).

Fig. 1. Entorno virtual de aprendizaje de la UOC, en donde se aprecia el widget de correo electrónico en la izquierda, los widgets de las aulas en el centro y el widget de agenda en la derecha.

Para realizar el test se empleó un laboratorio de accesibilidad equipado con un portátil, dos lectores de pantalla (Jaws 10.0 y NVDA 2009), un magnificador de texto (ZoomText 9.1), un editor de textos en Braille (Quick Braille 1.2), una línea de braille, un software de captura de la navegación (Morae 2.0) y una Webcam (ver Figura 2), de modo que queda registrada la interacción del usuario con el entorno virtual de aprendizaje, así como sus verbalizaciones y reacciones emocionales espontáneas, respectivamente.

Fig. 2. Laboratorio móvil de accesibilidad.

4. Muestra

Del total de estudiantes con discapacidad visual de la UOC contactados, 15 accedieron a colaborar en este estudio, de los cuales eran 4 hombres y 11 mujeres, entre 22 y 64 años.

Respecto a las herramientas tiflotécnicas utilizadas:

4 estudiantes utilizan un lector de pantalla (uno de ellos desde hace un mes).

5 estudiantes utilizan magnificador de pantalla.

6 estudiantes utilizan el zoom del PC. Estos estudiantes suelen caracterizarse por no tener tanta pérdida de visión como los estudiantes que emplean magnificador, por conservar la visión en un ojo, por tener una afección visual que cursa en crisis, o por tener fotofobia.

5. Resultados

A continuación describimos los resultados del análisis de contenido (Krippendorff, 2004) efectuado de la transcripción de las entrevistas, así como los resultados obtenidos mediante las tareas realizadas durante los tests de usuario.

5.1 Resultados de la entrevista contextual

De las entrevistas en profundidad realizadas en los contextos de estudio habituales de los estudiantes con discapacidad visual hemos obtenido resultados acerca de a) la planificación, tiempo y características del lugar de estudio, b) los materiales y métodos de estudio utilizados y c) las dificultades encontradas a la hora de llevar a cabo las diferentes tareas asociadas con el proceso formativo.

a) Planificación, tiempo y lugar de estudio

Los estudiantes con discapacidad visual no muestran diferencias significativas respecto al proceso de estudio de cualquier estudiante en esta universidad. Diariamente se conectan al campus virtual para ver las novedades del correo, mensajes del profesor, foros y debates, leen o escuchan el contenido didáctico y, una vez realizada esta lectura, hacen las actividades de aprendizaje (cada nueva actividad de aprendizaje es enviada por el profesor cada 2 o 3 semanas, ya que la evaluación es continua).

El lugar habitual para hacer estas tareas es el propio hogar. No obstante, algunos estudiantes también aprovechan otros momentos y situaciones como trayectos y momentos de espera para leer y escuchar contenido, y horas muertas en el trabajo para preparar y escribir una respuesta para el debate o foro. De este modo, los estudiantes planifican sus actividades en función de las diferentes situaciones con las que cuentan. Así, si tienen que hacer un trayecto, o saben que durante el día va a haber un tiempo muerto de espera, se preparan el material necesario para aprovechar ese tiempo: “Cuando tengo que esperar a mi hijo que acabe del conservatorio, ya me llevo las grabaciones para escucharlas”.

Por ejemplo, otro usuario realiza las actividades evaluativas, resumen del contenido y el acceso a contenidos complementarios en casa, y en los trayectos escucha los contenidos con el formato Daisy (formato de audio específico para estudiantes con discapacidad visual).

Sin embargo, para su planificación tienen en cuenta que en la realización de una actividad emplearán más tiempo que los estudiantes sin discapacidad visual debido a que:

Deben emplear tiempo para resolver problemas de accesibilidad de los contenidos didácticos.

El uso de herramientas tiflotécnicas o adaptativas disminuye la velocidad de interacción con la web y de lectura: “cuanto más amplías la pantalla, más lento vas porque pierdes campo visual”.

Tienen que descansar la vista de la pantalla del ordenador debido a la fatiga que produce la luz de la pantalla.

b) Métodos de estudio y materiales

El método de estudio de los estudiantes con discapacidad visual no difiere del método empleado por un estudiante sin discapacidad visual. Básicamente, se ayudan de herramientas tiflotécnicas para poder leer y estudiar el contenido, y aprovechan las ventajas de otros formatos, como el audio, para optimizar el estudio. Los estudiantes entrevistados emplean los siguientes formatos y materiales:

Papel: Sólo unos pocos estudiantes de los que utilizan un magnificador y el zoom del PC también utilizan el formato papel, ya sea por preferencia personal o por no tener disponible el contenido en audio. Este uso de papel suele ser con telelupa, lupa o sin ninguna herramienta adicional. También es habitual que los estudiantes que utilizan el zoom del PC y empleen el formato papel lo hagan ayudados de un atril.

Audio: Ya sea mp3 o Daisy, es un formato utilizado por bastantes estudiantes, independientemente de la herramienta tiflotécnica que utilicen. Para algunos incluso es el formato ideal: “Me iría muy bien poder reconvertir todo a sonido”. La mayoría de los audios que emplean los estudiantes son las grabaciones hechas por ellos mismos o por algún familiar. Las razones para usar el audio son:

Repasar, estudiar o tener idea general de un contenido.

Leer PDFs largos y descansar la vista.

Más eficacia en la planificación: resulta un formato óptimo cuando se va apurado de tiempo.

Falta de accesibilidad del material original: en esos casos el estudiante lo tiene que convertir a formato audio.

PDF: Es utilizado por la gran mayoría de los estudiantes (es el formato estándar de los contenidos didácticos proporcionados por la Universidad), ya sea usando un magnificador, un lector de pantalla o el zoom del ordenador. Sin embargo, es el que da más problemas de accesibilidad.

Word: Es el formato empleado por estudiantes que utilizan ZoomText o lector de pantalla al cual convierten los PDF no accesibles. Para ello, escanean con un OCR (reconocimiento óptico de caracteres) el documento para pasarlo a Word, o hacen una copia y pega del PDF al Word. Sin embargo, ambos métodos puede crear problemas de maquetación y además se pierden las imágenes. Algunos estudiantes convierten el PDF en Word porque así pueden realizar anotaciones y subrayar y tener otro Word abierto para tomar notas.

Braille: sólo 2 estudiantes de los entrevistados suelen usar la línea braille para leer contenido para:

Facilitar la comprensión y la memorización.

Leer documentos cortos.

Leer contenidos con datos económicos, tablas, puntos jurídicos, argots, etc., ya que son más difíciles de escanear y de escuchar.

c) Principales dificultades

Los estudiantes con discapacidad visual se enfrentan a diversas dificultades a la hora de poder llevar a cabo sus estudios. La principal y más grave dificultad es encontrarse con contenidos no accesibles en el contenido didáctico y en las actividades de aprendizaje como PDFs no accesibles, PDFs escaneados, imágenes, vídeos y formatos en flash.

Como consecuencia, la elección del formato preferido para interactuar se ve condicionada por si ese formato en concreto es accesible o no. Si bien algunos prefieren usar varios formatos, como audio y texto, la mayoría de los estudiantes se decantan finalmente por el formato Word porque es el que menos problemas da para leer utilizando el lector de pantalla o el magnificador, y además permite ser editado y subrayado: “A mí me gustaría subrayar porque si no cuando te lo vuelves a leer tienes que leértelo otra vez”.

Por otro lado, cuando un estudiante se encuentra con un contenido didáctico no accesible se ve en la obligación de invertir un tiempo en conseguir que ese contenido sea accesible, ya sea pidiendo ayuda al profesor, siendo el propio estudiante quien adapte el contenido (por ejemplo, convirtiendo el PDF a Word, realizando autograbaciones del contenido para luego escucharlo), o pidiendo ayuda a algún familiar: “Si en algún material tengo problemas, primero se lo digo al profesor. Si no se puede solucionar, lo hago por mi cuenta o intento que alguien me ayude”.

Estos contratiempos respecto a la falta de disponibilidad de los contenidos hace que el tiempo de espera sea angustiante: “Crea mucha ansiedad porque no puedes empezar”. Además, dicho tiempo de espera condiciona la participación en los debates y foros virtuales centrados en estos contenidos.

Esta inversión de tiempo también tiene como consecuencia que los estudiantes dispongan luego de menos tiempo para poder realizar las actividades de aprendizaje, por lo que la calidad en la realización de las mismas puede verse reducida. Por otro lado, cuando una actividad de aprendizaje se plantea mediante el visionado de imágenes o videos para responder a preguntas al respecto, ocurre normalmente que el profesor no ha preparado una actividad alternativa que no incluya imágenes o videos, por lo que los estudiantes se ven privados de poder hacer esta actividad en igualdad de condiciones que los estudiantes sin discapacidad visual.

Otra dificultad encontrada surge cuando los estudiantes tienen que consultar otros contenidos para la realización las actividades de aprendizaje que no están en el contenido didáctico oficial, como por ejemplo páginas web u otros documentos. Esto implica tener que pasar más tiempo del previsto delante del ordenador, lo que para algunos estudiantes no es recomendable debido a su discapacidad, y tener que consultar otras páginas webs u otros documentos donde la accesibilidad quizás no esté garantizada.

Se ha comentado anteriormente cómo el estudiante se encuentra con contenidos didácticos y con actividades de aprendizaje no accesibles. Ante la comunicación de esta inaccesibilidad al profesor, ocurre a veces que las soluciones propuestas no son adecuadas, seguramente porque éste no es del todo consciente sobre qué significa que un contenido sea accesible, o simplemente porque no tenga suficientes conocimientos sobre accesibilidad. Un estudiante comentó: “A veces digo que no veo las imágenes, pero me contestan que las amplíe, pero aunque las amplíe tampoco las veo, y me dicen pues que me lea esto, pero impreso tampoco puedo leer”. Y tal y como dijo otro estudiante: “Seguro que a personas sordas nunca les pasan un audio”.

Por último, otro factor a tener en cuenta es la posibilidad de que el alumno comunique o no que tiene una discapacidad visual para asegurarse que los contenidos didácticos que tenga sean accesibles; cabe señalar que no todos los estudiantes entrevistados se decantan por comunicar que tiene una discapacidad visual ya que se sienten incómodos y temen parecer pesados en sus quejas: “Si tengo que repetir en cada asignatura que no veo me siento quejita y pesada”. O recibir discriminación positiva: “Las personas tienen tendencia a hacerte discriminación positiva, y yo no quiero. No quiero que sepan que tengo este problema y que vengan ‘ay pobrecito’”.

5.2 Resultados del test de usuario

En general la gran mayoría de los estudiantes realizaron con éxito las diversas tareas propuestas. Independientemente de la herramienta adaptativa utilizada, los estudiantes destacaron positivamente tener el contenido relevante para sus estudios (como el correo, las aulas, etc.) organizados en widgtes, ya que todo el contenido que más les interesa se encuentra en la misma página. Es decir, los estudiantes no tienen que abrir nuevas ventanas o pestañas para acceder a ese contenido. Además, los estudiantes valoraron positivamente la posibilidad de poder mover los widgets alrededor de la página, pudiéndolos organizar según sus preferencias. La posibilidad de poder personalizar el color de los widgets también fue bien valorada.

Otro comentario positivo fue que el widget del calendario tenía como una alternativa al calendario una lista de los próximos eventos, lo que les hacía más fácil su lectura.

Y, por último, los estudiantes que utilizan la función de zoom del PC valoraron positivamente el diseño líquido del entorno virtual, ya que el contenido se reorganiza cuando los estudiantes utilizan el zoom para ampliar el contenido. Por ejemplo, cuando se utiliza la función de zoom, los widgets reajustan su tamaño, de modo que los estudiantes pueden seguir viendo el mismo contenido sin tener ningún fuera de la pantalla.

Los principales problemas de usabilidad y accesibilidad encontrados son los que habitualmente se encuentran en otros trabajos en donde también se han hecho tests de usabilidad con usuarios finales, como por ejemplo la falta de texto alternativo en las imágenes (Lazar y otros, 2007), empezar las frases con palabras irrelevantes (Theolanos y Redish 2003), emplear las mismas palabras para enlaces o funciones diferentes (Theolanos y Redish 2003), etc.

Teniendo en cuenta el objetivo de la investigación no detallaremos aquí recomendaciones ya detectadas en otras investigaciones para entornos web en general, de forma que en el apartado de recomendaciones destacaremos solo aquello que sea relevante para el diseño de un entorno virtual de aprendizaje.

6. Recomendaciones de diseño universal

A continuación presentamos las recomendaciones extraídas de los resultados de nuestra investigación, las cuales garantizarían una experiencia satisfactoria de estudio on-line.

6.1 Recomendaciones para una experiencia satisfactoria en estudios on-line

Proporcionar todos los formatos posibles | Proporcionar el contenido didáctico en todos los formatos posibles (audio, Word, PDF, braille, web, etc.) facilita que los estudiantes con discapacidad visual escojan aquel formato en función de sus propias necesidades.
Proporcionar materiales no sólo accesibles sino también usables | Se debe mejorar la experiencia de usuario en el uso de diferentes formatos, ya que enriquece y agiliza las actividades formativas de los estudiantes.
Formación al profesorado en accesibilidad | Se conseguiría que el contenido y las actividades de aprendizaje sean accesibles y que el profesorado tome plena conciencia de las dificultades con las que se encuentren los estudiantes con discapacidad visual.
Proporcionar antes los materiales didácticos y los enunciados de evaluación | Del mismo modo que disponen de más tiempo en los exámenes.
Tener disponibles materiales didácticos accesibles alternativos | Especialmente en aquellos casos en los que desde un punto de vista pedagógico sea recomendable proporcionar materiales didácticos no accesibles, como vídeos o imágenes.
Acceso universal a los materiales accesibles | De modo que los estudiantes con discapacidad visual no tengan que identificarse como estudiantes con discapacidad visual.

6.2 Recomendaciones de diseño para un entorno de aprendizaje online

A continuación se describen una serie de recomendaciones de diseño útiles para un entorno de aprendizaje online, las cuales se caracterizan por ofrecer soluciones accesibles gracias a la personalización y flexibilidad que permite el uso de widgets.

Widgets como modo de mostrar y acceder el contenido
Esto permite que los estudiantes tengan acceso a los contenidos más relevantes así como a la información actualizada (por ejemplo, las notificaciones de los correos, del tablón de los profesores, de los mensajes en los foros o en los grupo de trabajo) en relación a sus estudios ubicados en una misma página, sin necesidad de abrir nuevas ventanas o pestañas para acceder a ellos. En el caso de estudiantes que utilizan lectores de pantalla, el uso de unas estructuras de cabeceras en los widgets les permiten fácilmente acceder y navegar por los ellos así como acceder a los contenidos dentro de los mismos.

Personalizar dónde ver el contenido
Mediante el desplazamiento de widgets, el estudiante puede escoger dónde y cómo colocar el contenido más importante para él/ella, por ejemplo colocando los widgets más relevantes al principio de la página, evitando así tener que “buscar lo que necesitan”. En el caso de estudiantes que usan magnificadores, colocar los widgets en columna evita que tengan que desplazarse horizontalmente por la página (Theolanos y Redish 2005).

Personalizar qué contenido ver
Además de permitir enlaces directos personalizables, poder escoger los widgets que habrá en el entorno web.

Personalizar colores
En el caso de estudiantes con restos de visión suficiente, permitir cambiar los colores de los elementos que enmarquen contenidos o enlaces facilita su identificación sin la necesidad de leer.

Colores y contraste accesible
A parte de ser algo fundamental para la accesibilidad, permite que los estudiantes distingan rápidamente si ha habido una notificación nueva en las aulas o un mensaje nuevo en el correo.

Un listado de próximas citas como alternativa al calendario
Una agenda o calendario es útil para estudiantes sin discapacidad visual, pero poco práctico para estudiantes que utilizan Jaws o ZoomText. Es aconsejable sin embargo ofrecer una alternativa a la agenda, como por ejemplo un listado con las próximas citas.

Página líquida y/o diseño responsive
Permitir poder ampliar la letra un tanto por ciento determinado de modo que no desaparezca información ni que aparezcan nuevos scrolls horizontales y verticales en los widgets. Y si fuese necesario, que se reorganice la página cuando haya zoom. Un diseño responsive permite el acceso al entorno mediante otros dispositivos, como móviles o tablets.

7. Conclusiones finales

En esta investigación se han recogido los requisitos y necesidades de estudiantes con discapacidad visual que realizan estudios mediante un entorno de aprendizaje on-line, de los que se han podido extraer una serie de recomendaciones que persiguen facilitar el día a día de los estudiantes con discapacidad.

El carácter fundamentalmente visual de nuestra conciencia y pensamiento hace que las personas sin discapacidad visual comuniquen en base a referentes visuales, por lo que puede resultar más difícil llegar a tomar conciencia de qué referentes visuales son invisibles y/o poco útiles para personas con discapacidad visual. De este modo, nuestras recomendaciones señalan cómo la formación en accesibilidad de las personas encargadas de proporcionar y elaborar los materiales resolvería las principales dificultades con las que se encuentran los estudiantes, a saber, los contenidos didácticos y las actividades de aprendizaje no accesibles.

Estas recomendaciones también apuntan hacia la importancia de ofrecer personalización a los estudiantes con discapacidad visual. Al ser un colectivo muy heterogéneo (tienen diferentes grados de discapacidad, utilizan diferentes herramientas, utilizan diferentes contextos y formatos, y tienen diferentes preferencias a la hora de estudiar), es necesario que las instituciones educativas atiendan a esta hetereogeneidad, por ejemplo proporcionando el contenido didáctico en todos los formatos posibles (algo también apuntado en Burgstahler, Corrigan y McCarter, 2004), siendo esto también beneficioso para el resto de estudiantes (Burgstahler, 2002; Edmonds, 2004).

En cuanto al entorno virtual, ofrecer personalización y flexibilidad también resulta significativo (Cooper, 2006), algo que se puede conseguir mediante el uso de widgets en el entorno virtual como modo de organizar y acceder al contenido. Por ejemplo, con los widget los estudiantes pueden decidir qué contenido ver o dónde colocarlo. Estas conclusiones siguen la línea de proporcionar una web que pueda ser adaptada y personalizada por los usuarios en función de sus preferencias o necesidades, e independientemente de su discapacidad (Theolanos y Redish 2005). Aplicado a un EVA, si éste es flexible, personalizable y accesible a todos los niveles, al estudiante con discapacidad visual se le facilita su día a día y se le ayuda a optimizar el tiempo invertido que pasa interactuando con la página web.

8. Agradecimientos

Quisiéramos agradecer los resultados de este trabajo al proyecto “eduWAI: Plataforma para la creación de contenido inclusivo educativo y para el empleo para personas con discapacidad”, financiado por el Ministerio de Industria, Turismo y Comercio – Programa Avanzado de I+D (AETSI Avanza I+D 2009) TSI-020312-2009-27; al programa UNIDISCAT de la Agencia para la administración de becas universitarias y de investigación (AGAUR, Generalitat de Catalunya), Caso No. 11; y al proyecto MAVSEL: Minería, Análisis y Visualización de Datos basada en modelos sociales en E-Learning, TIN2010-21715-C02-02.

Referencias:

Beyer, H. y Holtzblatt, K. (1998), Contextual Design: Defining Customer - Centered Systems, San Francisco: Morgan Kaufmann.

Burgstahler, S. (2002), “Distance learning: Universal design, universal access”, en: Educational Technology Review 10 (1), 32-61.

Burgstahler, S., Corrigan, B. y McCarter, J. (2004), “Making distance learning courses accessible to students and instructors with disabilities: a case study”, en: Internet and Higher Education 7, 233–246.

Candido, J. (2008), en: “Visual impairment in a visual medium: Perspectives of online learners with visual impairments”. Ph.D. dissertation, Drexel University, United States -- Pennsylvania. Retrieved August 30, 2010, from Dissertations & Theses: Full Text. (Publication Nº AAT 3338731).

Cooper, M. (2006), “Making online learning accessible to disabled students: an institutional case study”, en: ALT-J, 14: 1, 103 — 115.

Edmonds, C.D., “Providing Access to Students With Disabilities in Online Distance Education: Legal and Technical Concerns for Higher Education”, en: American Journal of Distance Education, 18: 1, 51 – 62, 2004 [retrieved 29.04.2011] DOI: 10.1207/s15389286ajde1801_5 URL: http://dx.doi.org/10.1207/s15389286ajde1801_5

Kane, S.K., Shulman, J. A., Shockley, T. J. y Ladner, R. E. (2007), “A web accessibility report card for top international university web sites”, en: W4A '07: Proceedings of the 2007 international cross-disciplinary conference on Web accessibility (W4A), 148 - 156, New York, NY, USA, ACM.

Krippendorff, K. (2004), en: Content Analysis: An Introduction to Its Methodology (2nd ed), Thousand Oaks, CA: Sage.

Lazar, J., Allen, A., Kleinman, J. & Malarkey, C. (2007), “What frustates screen readers users on the web: a study of 100 blind users”, en: In Internation Journal of Human –Computer Interaction, 22(3), 247–269, Lawrence Erlbaum Associates, Inc.

Lubensky, R. (2006), en: The present and future of Personal Learning Environments (PLE), 2006 Retrieved 14th November 2013 from http://www.deliberations.com.au/2006/12/present-and-future-of-personal-learning.html

Ribera, M., Térmens, M. y Frías, A. (2009), “La accessibilidad de las webs de las universidades españolas. Balance 2001-2006”, en: Revista Española de Documentación Científica, 32, 3, julio-septiembre, 2009.

Ribera, M., Térmens Graells, M. y García, M. (2008), “Cómo realizar tests de usabilidad con personas ciegas”, en: El profesional de la información 17(1), 99-105.

Sloan, D., Kelly, B., Heath, A., Petrie, H., Fraser, H. y Phipps, L. (2006), “Contextual Web Accessibility - Maximizing the Benefit of Accessibility Guidelines”, en: Proceedings of the 2006 international cross-disciplinary workshop on Web accessibility (W4A). New York: ACM Press, 121-131.

Stephanidis, C. (ed) (2001), en: User Interfaces for All—concepts, methods, and tools. Lawrence Erlbaum Associates, Mahwah, NJ.

Theofanos, M. F. y Redish, J. C. (2003), “Guidelines for accessible and usable web sites: Observing users who work with screen readers”, en: Interactions, 10(6), 38-51.

Theofanos, M. F. y Redish, J. C. (2005), “Helping Low-vision and Other Users with Web Sites That Meet Their Needs: Is One Site for All Feasible?”, en: Technical Communication, 52(1), 9-20.

Análisis de agrupamientos en arquitectura de información: Un caso práctico de card sorting sin usuarios

Texto: Dani Armengol Garreta

Dani Armengol Garreta es licenciado en ingeniería informática por la Universidad Politécnica de Barcelona (2005). Se desempeña como consultor independiente de usabilidad e interfaces de usuario y como profesor-colaborador en la Escuela Superior de Diseño e Ingeniería de Barcelona y en la Universidad Autónoma de Barcelona. Es co-fundador del servicio de ofertas de empleo UXPLORA.

http://daniarmengol.com| @darmng

Resumen

En este texto se presenta un caso de análisis de agrupamientos en el que no se realizó una ordenación explícita de tarjetas con la participación de personas como en un card sorting tradicional. Se partió de datos extraídos de un análisis de competencia y  se obtuvo una representación gráfica tipo dendrograma de las agrupaciones.

Introducción

El card sorting es una técnica utilizada en arquitectura de información para descubrir el modelo mental que tienen los usuarios de un cierto espacio de información. La técnica permite extraer, combinar y representar ciertos conocimientos de usuarios para así contribuir a generar esquemas organizativos fáciles de utilizar y que cumplan sus expectativas.

Para realizar un card sorting se parte de una serie de ítems que se desea clasificar. Estos ítems son representados por tarjetas, físicas o virtuales, que los usuarios participantes deberán organizar según crean conveniente en grupos lógicos para ellos.

Para organizar las tarjetas hay distintos enfoques, que según Morville y Rosenfeld se pueden clasificar en dos tipos: cerrados y abiertos. En un card sorting cerrado se ofrece un conjunto predefinido de categorías y los participantes deben indicar y situar en cuál de ellas va cada tarjeta. En cambio, en un card sorting abierto los participantes pueden juntar las tarjetas libremente en los grupos que ellos definan o consideren.

Una vez realizada la técnica con varios participantes, los resultados pueden ser analizados cualitativa o cuantitativamente. El análisis cualitativo requiere de un moderador que haya observado el comportamiento de los participantes al agrupar tarjetas. El moderador puede determinar cuándo un participante tiene dudas, prestando atención a comentarios y gestos, o también comprender las razones que lo han llevado a realizar una cierta organización. Por otro lado, el análisis cuantitativo agrega y trata estadísticamente las agrupaciones finales que proponen los participantes para obtener tendencias y puntos de acuerdo.

Presentación del caso: card sorting de productos de supermercado

El caso que se presenta en este artículo forma parte de un proyecto de definición de un agregador de supermercados españoles. El agregador debía ofrecer al visitante la opción de comparar y comprar más de 10.000 productos distintos, lo que suponía un reto organizativo.

Para enfocar el proyecto se realizaron unas primeras entrevistas no dirigidas con usuarios que habían comprado previamente en supermercados por Internet. Las entrevistas permitieron confirmar que una vez elegido un tipo de producto había dos características a los que los usuarios daban importancia: el formato (envase, cantidad, etc.) y la marca.

Se planteó un esquema de organización en el que sus últimos niveles permitieran elegir entre estos dos aspectos. Tomada esta decisión, la cantidad de productos a organizar en los primeros niveles decreció prácticamente en dos órdenes de magnitud.

En los primeros niveles se ofrecería una organización por tipo de producto; pero a diferencia de organizar por marca o formato, que son algo objetivo, con secciones bien definidas y exclusivas, organizar por tipo es ambiguo y muy subjetivo.

Decidimos hacer algunas primeras categorizaciones, asumiendo por ejemplo que todos los tipos de vinos iban a ir organizados en una misma categoría, “Vinos”, independientemente de su tipo u origen, o que todas las cereales de desayuno irían en “Cereales de desayuno”, más allá de si eran de trigo o de arroz, o con chocolate o con miel.

Pero una vez realizadas estas agrupaciones, nos preguntábamos ¿debían ir los cafés con las cervezas por ser bebidas?, ¿los quesos debían asociarse con la leche por ser lácteos?, ¿los cereales del desayuno debían ir agrupados con la pasta por ser el ingrediente principal el mismo?

Ante esta situación, consideramos que un card sorting era la técnica ideal para resolver nuestras dudas y obtener información sobre cómo esperaban encontrar organizada la  información los usuarios.

Contábamos con una ventaja: este tipo de ítems ya han sido organizados cientos de veces y cada supermercado había realizado un mayor o menor esfuerzo para hacer su propia clasificación. ¿Por qué no aprovechar este conocimiento? Es más, teniendo en cuenta que el perfil de usuario del agregador era cliente previo de otros supermercados por Internet, ¿por qué no aprovechar también su familiaridad con otros esquemas organizativos?

Decidimos revisar manualmente cómo organizaba los productos la competencia y usar las agrupaciones de cada uno de los supermercados en lugar de realizar ordenaciones con usuarios. Cada supermercado se había convertido, pues, en un participante no humano de un card sorting.

El concepto de “similitud”

En un card sorting, asumiendo que la muestra es estadísticamente significativa, si todos los participantes agrupan dos tarjetas conjuntamente podemos afirmar que la población entera de usuarios del sistema interactivo que estamos diseñando va a esperar también que esos dos ítems estén agrupados. En estos casos diremos que estos dos ítems, o tarjetas, tienen un alto grado de “similitud” o son, simplemente, “similares”.

En el caso contrario, cuando dos tarjetas no son agrupadas conjuntamente por ninguno de los participantes, podemos asumir que los usuarios no esperarán encontrar tampoco agrupados estos ítems. En este caso consideraremos que no son ítems “similares”.

Más allá de estos dos casos extremos, en general no siempre existirá un acuerdo claro de si dos ítems deben ser agrupados conjuntamente o no. De hecho lo habitual será que para un mismo par de tarjetas, algunos participantes las agrupen conjuntamente y otros no.

En estos casos podemos definir grados intermedios de similitud. Podemos afirmar, por ejemplo, que dos tarjetas que son agrupadas por algunos participantes, aunque no por todos, son más similares que dos tarjetas que no son agrupadas por ningún participante.

Esta idea se puede generalizar y de ella obtener para cada par de tarjetas un cierto grado de similitud según si hay mayor o menor acuerdo entre los participantes en que deben ir agrupadas.

En nuestro card sorting con supermercados pudimos hacer exactamente lo mismo. Por ejemplo, vimos que la mayoría de ellos ofrecían el café en un grupo de alimentación general (llamado a veces simplemente “Alimentación”, a veces “Alimentación general” o incluso “Ultramarinos”) junto a otros productos como el aceite, la sal o los cereales de desayuno. Algunos supermercados, pues, nos estaban sugiriendo que consideraban el “Café” similar a la “Sal”. Por otro lado, ningún supermercado agrupaba el café con el agua, con lo que ya empezábamos a obtener respuesta a nuestras dudas iniciales: el café y el agua pueden ser bebidas, pero los supermercados, y por extensión sus usuarios, no los consideran productos “similares”.

Agrupaciones: el análisis jerárquico

La similitud entre productos es un dato interesante, pero ¿cómo lo convertimos en propuestas de agrupaciones?

Existen varias formas de hacerlo, pero para este caso decidimos utilizar el análisis de agrupamientos jerárquico. Por su sencillez y por estar implementado en la mayoría de software que se utiliza habitualmente para analizar los resultados de card sorting.

Para usar este método de análisis, empezaremos con tantos grupos como ítems se quiere agrupar; cada grupo contiene un solo elemento, que podríamos decir que es similar a sí mismo.

Este punto de partida es poco práctico: ¿cómo reducimos este conjunto inicial de grupos? Para ello seguiremos una estrategia simple: juntar aquellos que tengan un grado de similitud superior a un cierto umbral. Esta misma estrategia la podemos repetir varias veces, bajando el umbral a cada paso y así creando nuevos grupos con un “derecho de admisión” más permisivo.

Veamos un ejemplo real a partir de un subconjunto de los productos que se organizaron en el caso.

Imaginemos que empezamos con 6 productos, de los que hemos calculado su similitud (“baja”, “media” o “alta”) a partir del consenso o coincidencia que tienen los supermercados en agruparlos. Representamos esta información en una tabla o matriz de similitudes:

(Para ver el cuadro en mayor detalle es conveniente achicar el tamaño de letra).

| Platos preparados | Conservas | Legumbres | Pasta | Purés | Sopas
Platos preparados | - | Baja | Baja | Baja | Baja | Baja
Conservas | Baja | - | Media | Media | Media | Media
Legumbres | Baja | Media | - | Alta | Media | Media
Pasta | Baja | Media | Alta | - | Media | Media
Purés | Baja | Media | Media | Media | - | Alta
Sopas | Baja | Media | Media | Media | Alta | -

Empezamos con un grupo para cada ítem, como comentábamos. Así:

{Platos preparados}

{Conservas}

{Legumbres}

{Pasta}

{Purés}

{Sopas}

Aplicamos la estrategia de agrupación: observando la tabla de similitudes vemos que las legumbres y la pasta tienen similitud alta (de hecho todos los supermercados que se analizaron mostraban estos productos agrupados), así que creamos un grupo para estos dos productos. También son muy similares los purés y las sopas, por lo que los nuevos grupos quedan así:

{Platos preparados}

{Conservas}

{Legumbres, Pasta}

{Purés, Sopas}

Para reducir el número de grupos podemos aplicar la misma estrategia de nuevo, bajando el umbral exigido. Pero esta vez no podemos comparar directamente similitudes entre ítems, ya que ahora tenemos grupos con más de un ítem. ¿Cómo sabemos si dos grupos son similares? Hay varias aproximaciones. Las más conocidas son:

Podemos afirmar que dos grupos tienen una similitud “S” si el primer grupo contiene al menos un ítem de similitud “S” con otro ítem del segundo grupo. Esta aproximación se conoce como “vinculación única” (single linkage).

Otra opción es afirmar que dos grupos tienen una similitud “S” sólo si los ítems menos similares entre los dos grupos tienen esa similitud. Se conoce como “vinculación completa” (complete linkage) y es más estricto que el anterior a la hora de aceptar ítems en un grupo.

O incluso podríamos calcular una media de la similitud entre todos los ítems de un grupo con los de otro. Esto sería una “vinculación media” (average linkage).

Todas son formas válidas de hacerlo y nos permitirán ir reduciendo el total de agrupaciones de nuestros conceptos, hasta llegar al absurdo de tener solo un grupo con todos los ítems.

En nuestro ejemplo de 6 ítems cualquiera de estas tres aproximaciones daría el mismo resultado:

| Platos preparados | Conservas | Legumbres, Pasta | Purés, Sopas
Platos preparados | - | Baja | Baja | Baja
Conservas | Baja | - | Media | Media
Legumbres, Pasta | Baja | Media | - | Media
Purés, Sopas | Baja | Media | Media | -

Con esta nueva matriz de similitudes entre grupos, vemos que “Legumbres y pasta” es de similitud media con “Purés y sopas”. También vemos que el grupo que contiene sólo “Conservas” es también de similitud media con “Legumbres y pasta” y “Purés y sopas”.

Los “Platos preparados”, sin embargo, tienen una similitud baja con todos los demás grupos. Juntamos pues los tres grupos con una similitud media en uno solo y obtenemos:

{Platos preparados}

{Conservas, Legumbres, Pasta, Purés, Sopas}

Nos quedan ahora sólo dos grupos. Independientemente de la similitud entre ellos si seguimos aplicando la misma estrategia llegará un momento en que bajaremos tanto el umbral que se juntaran en un único grupo final, igual de poco práctico, eso sí, que el conjunto inicial de un grupo para cada ítem:

{Platos preparados, Conservas, Legumbres, Pasta, Purés, Sopas}

Análisis mediante dendrograma

Las similitudes entre productos y cómo se van agrupando entre sí se puede representar gráficamente para facilitar el análisis.

Para ello se acostumbra a utilizar un diagrama tipo árbol llamado dendrograma, donde los conceptos se van juntando entre sí a medida que se va reduciendo el umbral de similitud o nuestras “exigencias”.

En el siguiente fragmento del dendrograma obtenido en el proyecto, vemos la similitud relativa entre algunos productos. Se observa claramente, por ejemplo, que la cerveza es más similar a un licor que al vino (se unen antes), o que los refrescos y los zumos tienen también un alto grado de similitud. Si seguimos las líneas observamos como “Refrescos y zumos”, “Cerveza y licor” y el grupo que contienen únicamente “Vino” se juntan formando un único grupo, que excluye el agua, el producto menos similar con los demás.

En otro fragmento del dendrograma del proyecto vemos que la leche y los yogures se unen inmediatamente. ¿Qué significa? Pues que su grado de similitud es “máximo”, es decir, todos los supermercados tienen la leche y los yogures en la misma categoría.

Aquí podemos observar algo que quizás no esperábamos: los huevos son más “similares” a la leche y al yogur que no los quesos, que en este fragmento de dendrograma ni siquiera aparecen.

Es importante entender que un análisis cuantitativo de este tipo no nos ofrece respuesta a “por qué se han realizado estas agrupaciones”. Sólo mediante un análisis cualitativo podemos entender los motivos por los que dos ítems acaban juntos.

Para nuestro análisis, decidimos examinar qué nombres se utilizaban para las categorías de los grupos en los supermercados participantes. De esta forma observamos por ejemplo que los yogures acostumbran a estar en una categoría de “Lácteos”, pero que en varios supermercados se llama “Lácteos y huevos”. ¿Y los quesos? Hay disparidad de agrupaciones, para algunos supermercados los quesos tienen entidad propia, están dentro de la categoría de “Quesos”, pero en muchos otros están en “Charcutería y quesos”.

Esta información adicional nos ayuda a entender el dendrograma y hacer conjeturas. Una de ellas es que los supermercados por Internet analizados no han abandonado el sistema organizativo de los supermercados físicos: la charcutería y los quesos son productos de corte. Esto es lo que probablemente los hace similares y esta similitud se ha extendido al canal online.

Organización final y validación

El dendrograma general de organización puede “cortarse” verticalmente para obtener una propuesta de grupos. Con ello básicamente establecemos un umbral de similitud que consideramos aceptable y obtenemos los grupos que quedaron establecidos según la estrategia de agrupamiento para ese umbral.

Si cortamos al principio, es decir, más a la izquierda del diagrama, donde el umbral de similitud es más restrictivo, obtendremos grupos con un grado de “acuerdo” grande entre supermercados. Los productos de estos grupos serán muy similares entre sí, por lo que probablemente la mayoría de usuarios no tendrán problemas en entender qué hay en cada uno, una vez tengamos un buen nombre para ellos. El problema, sin embargo, es que saldrán muchos grupos, lo que aumentará el tiempo de decisión de los usuarios.

Por otro lado, si nos movemos hacia la derecha del dendrograma, obtendremos menos grupos, pero de mayor ambigüedad, ya que nuestro umbral de similitud es más laxo y por lo tanto estamos agrupando ítems entre sí en grupos menos consensuados. Algunos usuarios pueden decidir entrar en un grupo y resultar que el producto que buscaban está en otro.

Sea como sea, el dendrograma debe tomarse como un punto de partida y en general no es aconsejable que se traslade literalmente a un menú de navegación. Si lo hiciéramos estaríamos obviando variables importantes, como las necesidades propias del negocio, y asumiríamos ambigüedades entre grupos que quizás podemos paliar gracias a información cualitativa.

Así, por ejemplo, en el proyecto decidimos incorporar una categoría llamada “Lácteos y huevos” (con yogures, leche, huevos y similares) y otra para “Charcutería y quesos” (para productos de corte). Pero conscientes que algunos usuarios pueden considerar que dentro de “lácteos” habrá quesos, decidimos situar en el menú de navegación “Charcutería y quesos” inmediatamente antes que “Lácteos y huevos”. Utilizar una ordenación al revés sería más susceptible de que los usuarios entraran en “Lácteos y huevos” sin seguir leyendo el resto del menú.

Conclusiones y preguntas abiertas

Las mismas técnicas de análisis, herramientas y enfoque clásico de un card sorting se pueden utilizar sin realizar una ordenación explícita de tarjetas con usuarios. Podemos obtener información agregada sobre el comportamiento y preferencias  de los usuarios a través de otras fuentes de “similitudes” entre conceptos. Eso no sólo incluye agrupaciones previas, como en el caso que se ha expuesto, sino también a través del análisis de búsquedas, estadísticas de navegación, filtrado colaborativo, etc.

Algunas preguntas, sin embargo, quedan abiertas:

¿Cómo hubiera funcionado un card sorting tradicional? ¿Habrían agrupado los usuarios, por ejemplo, las tarjetas de “Leche” y “Huevos”? ¿Habría sido un resultado mejor o peor para la tarea específica de realizar una compra?

¿La observable tendencia de los supermercados a utilizar las agrupaciones de sus tiendas físicas en sus sitios web es una buena práctica? ¿Otra técnica nos hubiera permitido obtener un método de organización absolutamente distinto a las ataduras físicas? ¿Sería bueno prescindir de la familiaridad de los usuarios en este caso con las organizaciones que ya conocen?

En general, ¿hacemos bien de asumir que las agrupaciones previas que hacen otras organizaciones van estar bien orientadas a los usuarios? ¿Y si nos estamos basando en malas organizaciones?

Agradecimientos

El autor quiere agradecer a Armando Fidalgo García y Roger Ferrer Ibáñez sus aportaciones y comentarios para mejorar este capítulo.

Percepción e interacción

Texto: Daniel Mordecki

Daniel Mordecki es uruguayo, especialista en Usabilidad, docente en la Universidad ORT y consultor en Concreta, empresa dedicada a la Usabilidad y Estrategia en Internet. Ha publicado numerosos artículos y dos libros que son de lectura ineludible: Miro y Entiendo 7 y Pensar Primero 8. Su sitio personal es http://www.mordecki.com/

Podemos definir la interfaz de un sistema como el conjunto de sus componentes perceptibles y accionables. Dicho de otra forma, componen la interfaz aquellos elementos del sistema que los usuarios pueden percibir a través de sus sentidos y con los que pueden además interactuar. Es una definición compacta y simple, muy útil a la hora de entender exactamente qué es la interfaz y cuál es el alcance de la tarea de diseñarla.

A partir de esta definición se deriva que la interacción a través de la interfaz es un diálogo de ida y vuelta, en el que por un lado el sistema emite información perceptible y por otro el usuario emite información comprensible por el sistema. Es por ello que las metodologías y técnicas que se aplican al diseño de interfaces tienen dos apoyos teóricos fundamentales. Por un lado, la sistematización del conocimiento adquirido en la evaluación de interfaces: lo que sabemos a partir de los test con usuarios, de la analítica de los datos de comportamiento y muchas otras técnicas que permiten arribar a conclusiones y generalizarlas sobre qué funciona y qué no en una interfaz. Por otro, un grupo de disciplinas cuyo eje es el estudio de la percepción, la memoria y la inteligencia, el aprendizaje y la toma de decisiones.

Independientemente de cuál sea la causa, parece bastante claro que el conjunto de materiales que se generan sobre Usabilidad, diseño de interfaces y diseño de la interacción, así como los artículos y bibliografía disponible sobre estos temas, tienen un sesgo hacia el primer apoyo, en detrimento del segundo. Es poco frecuente encontrar materiales de Usabilidad, o de diseño de la interacción, que deriven sus conclusiones a partir de cómo los humanos perciben el conjunto de estímulos que reciben, cómo procesan esa información y en función de ella, cómo generan las respuestas que compondrán la interacción. Pero que no sea frecuente, no quiere decir que no sea de extrema relevancia.

Cómo percibimos los estímulos

El ser humano, mientras está despierto, recibe a través de sus sentidos un conjunto de estímulos denso, continuo en el tiempo e infinito en volumen. Es muy común que cuando se habla de percepción se asuma percepción consciente de estímulos puntuales y de gran relevancia para el individuo, pero muy por el contrario la percepción es un fenómeno ininterrumpido, en el que el cerebro aplica un análisis extremadamente potente y sofisticado a un conjunto inconmensurable de información, del cual la percepción consciente y atenta es apenas un botón de muestra.

Por ejemplo, nuestros ojos no solo perciben lo que estamos mirando, sino todos los colores y brillos que entran en nuestro campo visual. Es el cerebro el que hace la magia de generar un frente y un fondo para nuestra percepción visual y nos permite atender unos estímulos en detrimento de otros.

Para entender este mecanismo y poder aprovecharlo en el diseño de interfaces, podemos pensar que todos los estímulos son recibidos por un área del cerebro que los analiza y toma una de tres opciones:

Descartar: si el estímulo no es central al fenómeno que estamos atendiendo y coincide con las previsiones que el cerebro tiene acerca del contexto en el que este fenómeno se desarrolla; o dicho de otra forma, si el cerebro evalúa que el estímulo ni es relevante ni genera un desequilibrio, lo descarta sin más trámite. La mayoría absoluta de los estímulos son sencillamente descartados por irrelevantes.

Respuesta inconsciente: algunos estímulos generan desequilibrios para los que el cerebro tiene preparadas respuestas que no requieren atención consciente. Hay dos fuentes para estas respuestas: el instinto y la intuición. El instinto es innato y nos provee con una batería de respuestas inmediatas a situaciones predefinidas, fundamentalmente aquellas que nos generan miedo, fastidio o atracción sexual. El segundo está compuesto por una amplia gama de respuestas entrenadas, ya sea de forma deliberada o casual, en las que el cerebro realiza una acción que responde a un estímulo sin necesidad de una decisión plenamente consciente. La mayoría de las acciones que realizamos al manejar, al andar en bicicleta, o al digitar en el teclado entran en esta categoría.

Respuesta consciente: el pequeñísimo conjunto de estímulos que ni son descartados ni obtienen una respuesta inconsciente, son tratadas con las armas más potentes que tiene el cerebro: la atención consciente, la memoria y la inteligencia. Se trata de la elite de los estímulos, solo aquellos pocos elegidos que consiguieron burlar los mecanismos inconscientes, mostrándose lo suficientemente atractivos o implicando un desequilibrio lo suficientemente importante como para que el perezoso cerebro movilice su armamento más poderoso.

Este mecanismo de decisión frente a los estímulos, a pesar de ser una versión hiper-simplificada, permite extraer un volumen importante de conclusiones relevantes para el diseño de interfaces fáciles de usar.

Lo inconsciente precede a lo consciente

Sólo aquellos estímulos que no fueron ni descartados ni tuvieron una respuesta inconsciente llegan al análisis consciente. Este es un hecho de vital importancia, porque todos aquellos elementos de la interfaz que obtienen respuesta en alguno de los primeros dos pasos del proceso jamás reciben tratamiento consciente.

Esto explica, por ejemplo, por qué algunos usuarios no perciben elementos de la interfaz que tienen delante de su nariz, y se van sin cumplir sus objetivos a pesar de que la solución está fácilmente accesible: sencillamente les resulta invisible ya que el estímulo fue descartado (probablemente en forma errónea) y por tanto, nunca llega a la conciencia para ser evaluado como una solución válida.

También explica por qué muchos usuarios nunca corrigen una acción errónea que repiten una y otra vez. Por ejemplo, hacer doble click en vínculos y botones a diestra y siniestra: sencillamente responden inconscientemente al estímulo y realizan dos clicks en rápida sucesión. La mayoría de las veces obtienen lo que esperaban, lo mismo que si hubieran hecho un solo click, pero algunas veces el segundo click tiene consecuencias no deseadas. Sin embargo, cuando el usuario se enfrenta a la situación inesperada e intenta deducir sus causas, el doble click no aparece entre los posibles culpables, porque fue una acción inconsciente.

En el diseño de la interacción es sustantivo tener presente que el análisis de la interfaz que realizan los usuarios no es ni completo ni racional, sino que por el contrario, la mayoría de los elementos son descartados o reciben respuestas inconscientes, y que estas decisiones prácticamente nunca se modifican. Si lo títulos parecen párrafos, o las noticias parecen publicidad, o el menú parece una galería de fotos, es muy probable que los usuarios no consigan usarlos, y lo que es peor, jamás lleguen a darse cuenta de ello.

Las asociaciones y la jerarquía se determinan antes de razonar sobre el contenido. Dentro de las decisiones que responden al segundo grupo, el de las respuestas inconscientes, se encuentran dos de una relevancia inconmensurable para la facilidad de uso de una interfaz: las asociaciones y la jerarquía.

Las asociaciones determinan las relaciones de los elementos de la pantalla: qué fotos se corresponden con qué textos, qué etiquetas conforman un menú, qué subtítulo precede a qué párrafo. Por su parte la jerarquía explica la importancia relativa de los elementos de la pantalla: cuál es el título principal de la página, qué opción de menú es de primer nivel y cuál de segundo, cuál noticia es más importante que otra.

Las respuestas inconscientes son inmediatas, es más, son casi inevitables. Se necesita una acción consciente y premeditada muy decidida por parte del usuario para evitarlas. Lo mismo sucede para los estímulos que se descartan. En una fracción de segundo el estímulo obtiene respuesta o se descarta, y esto es siempre antes de que el usuario tenga conciencia plena de lo que está percibiendo, algo que algunos neurocientistas denominan “pre-percepción”. Es por ello que cuando toma conciencia y comienza a razonar sobre lo que ve en la pantalla, su cerebro ya decidió por él qué es importante, qué no es importante y qué elementos de interfaz componen cada uno de estos grupos.

Muchas interfaces son concebidas con la idea de que el usuario va a analizar racionalmente todas y cada una de las opciones disponibles y solo al final elegirá la que más le convenga. Lamentablemente en la realidad las cosas no suceden así. El conjunto de opciones disponibles es filtrado con agresividad, dejando un sub-conjunto de alternativas sensiblemente menor que el original. A ello se suma que estas alternativas llegan a la conciencia del usuario asociadas y jerarquizadas en función de su apariencia y no de su contenido, y es dentro de este pequeño conjunto de opciones filtradas, asociadas y jerarquizadas que tomará decisiones el usuario. Tanto las opciones descartadas como cualquier otro sistema de asociación y jerarquía no serán siquiera considerados, tal y como si no existiera otra forma de ver la interfaz.

La propuesta rebuscada de algunos diseñadores para sus interfaces choca de frente con el hecho de que las asociaciones y las jerarquías se resuelvan en su mayoría de forma inconsciente y casi instantánea, mucho antes de que el usuario comience a razonar sobre las sutilezas escondidas en las asociaciones y pretendidas jerarquías donde lo más grande es menos importante que lo más pequeño, y lo que está más arriba viene después de lo que lo sigue debajo.

Todo lo que aparece en la pantalla compite por la atención

El flujo de estímulos es continuo, no se detiene nunca. Todos los elementos de la pantalla (y los del entorno físico que rodea la pantalla) son percibidos e interpretados para ser descartados, respondidos inconscientemente o razonados.

El caso más sencillo es el de una pantalla estática, donde los estímulos no varían a pesar de que pase el tiempo y por tanto coinciden a la perfección con la previsión del cerebro, generando un equilibrio total. A medida que en la pantalla varía con el paso del tiempo, introduciendo cambios, inclusive los más nimios, éstos rompen el equilibrio en mayor o menor medida y requieren más o menos esfuerzo de procesamiento, llegando muchas veces al procesamiento consciente. Como caso extremo se encuentran las animaciones, que rompen el equilibrio de forma continua, exigiendo permanentemente una porción de atención.

Si queremos que los usuarios atiendan, comprendan y retengan nuestros contenidos, debemos eliminar los estímulos de poca importancia y e intentar que solo se muestren estímulos relevantes. En particular, es imposible leer atentamente con una animación al lado del texto, sin excepciones.

Cuando un medio de comunicación basa su negocio en la publicación de banners animados, hay una comprensión implícita de que la pérdida de Usabilidad se justifica por la necesidad de financiar el proyecto. Cuando una organización hace publicidad propia con banners animados, está torpedeando la posibilidad de que sus visitantes lean y retengan sus contenidos. Algo tan imperdonable como frecuente.

Los estándares producen facilidad de uso

Las respuestas inconscientes tienen como punto de partida el instinto y el aprendizaje previo del individuo. Este último puede ocurrir de forma deliberada cuando la persona estudia o se entrena, pero la mayoría de las respuestas inconscientes tiene como base aprendizaje también inconsciente. La repetición de una acción una y otra vez le permite al cerebro grabar en la memoria una secuencia de estímulos y asociar a éstos una respuesta, y los humanos tenemos la habilidad de aprender a ejecutar este ciclo sin necesidad de tener consciencia de ello.

En la interacción con sitios Web y aplicaciones de todo tipo, los usuarios realizan este proceso de aprendizaje/entrenamiento sin esfuerzo alguno, detectando los patrones que se repiten de una interfaz a la siguiente y aprendiendo a dialogar en un lenguaje de interacción que cruza horizontalmente todas las interfaces que componen el medio. Y los patrones que se repiten de una interfaz a la siguiente no son otra cosa que estándares, sean estos de facto, aceptados por su implementación ubicua, o formales, generados por el consenso deliberado de organizaciones y comunidades.

Cuando el usuario aterriza en nuestra interfaz trae consigo un enorme bagaje de conocimiento de interfaces, resultado de la aplicación de numerosos estándares por los demás diseñadores.

Cuando nuestra interfaz no respeta los estándares, ocurren dos cosas, ambas no deseables:

El usuario pierde el valor de su conocimiento previo y es por lo tanto sensiblemente más lento, porque las respuestas inmediatas desaparecen y por tanto recurre a métodos más potentes de análisis, que llevan más esfuerzo y más tiempo.

Se utiliza potencia de razonamiento, atención y memoria para desentrañar la interfaz, y por tanto hay menos potencia de razonamiento, atención y memoria para las tareas centrales del sitio, con las que el usuario cumplirá sus objetivos.

Muchos diseñadores piensan que el respeto de los estándares los vulgariza, los mimetiza con el entorno. Así deciden comunicar lo normal en rojo y los errores en verde, colocar el logo de la empresa a la derecha y el título de la página en medio del texto. Es una forma de razonar pobre, porque los usuarios no ingresan a un sitio a valorar la interfaz, sino a cumplir un objetivo. La originalidad debe estar orientada a aumentar la eficiencia y la eficacia del usuario para cumplir ese objetivo, a buscar formas más rápidas y con menos probabilidad de error de cumplir con las tareas. En esa línea, respetar los estándares va a favor del usuario y no en su contra.

Esfuerzo cero: reconocer es más fácil que pensar

Tal vez la consecuencia más relevante de una interfaz diseñada tomando en cuenta cómo funciona la percepción, es el mínimo esfuerzo que requiere su utilización. Porque tanto los estímulos que se descartan como las respuestas inconscientes pueden ser consideradas de esfuerzo cero. Y no hay nada que haga más feliz a un usuario que el esfuerzo cero.

Es difícil sobrevalorar la capacidad del cerebro para reconocer series o patrones de estímulos y reaccionar a ellos sin necesidad de pensar. Hay algunos con los que vivimos desde que nacimos y que utilizamos día a día sin siquiera saberlo. Por ejemplo, todos los humanos cuentan hasta cuatro con solo mirar. Si alguien entra a un bar, las mesas ocupadas por grupos de hasta 4 personas no requieren ser contadas, sino solamente miradas. Nadie necesita contar dos lapiceras o tres cuadros en la pared. Los mira y entiende, con esfuerzo cero.

Con la lectura sucede algo similar. La capacidad de reconocer palabras muy utilizadas, y algunas frases cortas excede el mecanismo habitual de la lectura, se vuelven imágenes que son leídas con solo mirarlas. Y no solamente palabras como Nike o Coca Cola. También muchas otras comunes y corrientes, como por ejemplo “Imprimir”.

Si en una interfaz un usuario tiene que leer cuatro o cinco etiquetas para determinar que ese componente es un menú, y usar su razonamiento para contextualizarlo, la interacción será pobre, como por ejemplo cuando un ministerio decide poner las siglas de las unidades que lo componen como menú principal. Si por el contrario, el menú se reconoce mirando, y las etiquetas se decodifican sin necesidad de pensar, la facilidad de uso aumenta de forma explosiva. Y los usuarios adoran esas interfaces, porque no hay nada que lastime más a un usuario que una interfaz que lo obliga a pensar.

La percepción está sesgada por la experiencia

Y muy fuerte: donde los geógrafos ven ciudades, los adolecentes ven cuadros de futbol. Donde los adultos ven artistas, los niños ven Tortugas Ninja. Mientras que los pacientes toman medicamentos los médicos los recetan. Y la lista continúa infinitamente.

La experiencia, almacenada en la memoria del usuario, tiñe de color el lente con que percibe la interfaz en grado sumo, mucho más de lo que se podría pensar. Esto obliga a tomar en consideración el contexto en el que se utiliza la interfaz. Y no solamente para los problemas más obvios como el idioma, la jerga técnica o evitar los colores y expresiones asociados con la muerte.

Cosas mucho más triviales como por ejemplo hacia qué lado queda el futuro: a la derecha en las culturas que escriben de izquierda a derecha y al revés para quienes escriben en sentido contrario. Un formulario es más fácil de usar si sus botones de acción respetan esta lógica, haciendo que el flujo positivo, el que completa el formulario ocurra hacia el futuro, las opciones de corrección de la pantalla actual estén en el centro y los botones que permiten ir hacia atrás vayan hacia el pasado.

Los objetivos también sesgan la percepción que tenemos del entorno. Precisamente por eso somos capaces de hacer compras en el supermercado. ¿Cómo sino podríamos elegir 30 o 40 productos en un universo de 50.000? Nuestra mirada experta encuentra en instantes nuestra marca preferida de café entre decenas de opciones parecidas. Un segundo después somos incapaces de decir demasiado sobre los productos descartados: nuestro café nos llamaba como un imán luminoso porque coincidía exactamente con nuestro objetivo, por eso lo tomamos y asunto finalizado.

Los usuarios llegan a una pantalla con un objetivo determinado. Es necesario optimizar la interfaz, generando los imanes luminosos en los lugares adecuados para que los usuarios los identifiquen rápidamente y los asocien con su objetivo, una idea que se contrapone a la inagotable sucesión de opciones en la pantalla, hijas de la ilusión de que cuantas más funciones tiene el software mejor es.

Dos caminos para un mismo objetivo

No debería sorprendernos que lo que aprendemos en la evaluación de interfaces y las conclusiones que derivan del estudio de la percepción coincidan en un cuerpo único de conocimiento. Por el contrario, sería paradójico que la observación de los usuarios utilizando una interfaz arrojara resultados contradictorios con la forma en que los mismos usuarios perciben e interpretan los estímulos que reciben.

Para un diseñador de interfaces, ambas fuentes son de vital importancia, ya que mientras la experiencia práctica nos conecta con la tecnología disponible en cada momento y con el surgimiento de nuevas posibilidades para construir interfaces, el estudio de la percepción nos aporta una visión independiente de la tecnología y estable en el tiempo, ya que los mecanismos de la percepción no varían con cada nuevo modelo de tableta que aparece en el mercado. El equilibrio entre las dos fuentes genera una visión integral, multifacética, articulada, uno de los pilares más sólidos a la hora de diseñar interfaces tan fáciles de usar como duraderas.

Notas

7 Mordecky, Daniel (2012), Miro y entiendo, Montevideo, Biblioteca Concreta.

8 Mordecky, Daniel (2004), Pensar primero, Montevideo, Biblioteca Concreta.

Bibliografía

Johnson, Jeff (2010), Designing with the Mind in Mind: Simple Guide to Understanding User Interface Design Rules, Massachusetts, Morgan Kaufmann.

Hawkins, Jeff (2005), On Intelligence, Nueva York, St. Martin's Griffin.

Carr, Nicholas G. (2011), Superficiales: ¿Qué está haciendo Internet con nuestras mentes?, Madrid, Taurus.

Accesibilidad primero: Guía de accesibilidad móvil

Texto: Julio Incarbone

Julio Incarbone es analista de sistemas, profesor en disciplinas industriales y encargado de User Experience (UX) en CDT Soluciones Tecnológicas. Fue coordinador académico y profesor en la “Especialización en Diseño de Interacción con estándares de Accesibilidad y Usabilidad” (DIEAU) del Instituto Nacional Superior del Profesorado Técnico (INSPT - UTN). Es Miembro del equipo de investigación-acción “Sinapsis”.

Introducción

La web debe ser accesible a todos y para todos con el dispositivo o plataforma que se disponga. Con este objetivo en mente se presenta la siguiente guía de accesibilidad móvil en la que se reúnen los lineamientos necesarios para la construcción de una aplicación móvil accesible.

Se cree que la tarea de construir pensando “la accesibilidad primero” es una labor titánica, pero no es así cuando individualizamos los pasos a seguir. Para tal fin se brindan las herramientas teórico-prácticas necesarias para que la tarea de construir, priorizando la accesibilidad, resulte un trabajo simple y rápido que redunde en la usabilidad de las herramientas que creamos.

Luego de recorrer las pautas y principios rectores de la accesibilidad, surcaremos brevemente los caminos de la usabilidad. Dichos caminos, surgen de las premisas que la accesibilidad menciona en sus diferentes directrices, ya que como lo anuncia el título de este capítulo la accesibilidad está primero. Esto nos permite satisfacer las necesidades de la persona que utilice nuestra herramienta, y al mismo tiempo, ampliar las capacidades humanas, nuestras potencialidades sensoriales y cognitivas, para convertir lo que queremos hacer en lo que podemos hacer.

Una de las definiciones oficiales de accesibilidad la caracteriza como “la posibilidad efectiva de que el mayor número de personas puedan acceder de manera satisfactoria a la web y hacer uso de sus contenidos, independientemente de cualquier limitación personal o derivada del entorno, es decir, en igualdad de condiciones y oportunidades con el conjunto de la sociedad”.

Aunque correcta, esta definición nos resulta un poco acotada. Veremos, en este capítulo, a la accesibilidad dentro de un marco más amplio. Diremos entonces, que además de la posibilidad de inclusión social y de igualdad de condiciones, la accesibilidad incluye la independencia de dispositivos, el acceso universal, ayuda técnica o la plataforma. La web, en definitiva, debe ser accesible a todos y para todos con el dispositivo o plataforma que dispongamos en ese momento.

Supongamos que debemos hacer un nuevo desarrollo, toda una nueva plataforma móvil. ¿Cómo encarar tal desafío desde el minuto cero con las pautas de accesibilidad? ¿Qué es lo que debemos tener presente cuando desarrollamos contenidos y aplicaciones accesibles? ¿Cuáles son los lineamientos principales? Veremos las premisas que te acompañarán, no sólo en el inicio del proyecto, sino como parte de cada una de las iteraciones que se hagan a lo largo de los diferentes estadios del proyecto.

Tengamos en cuenta que antes de pensar en la accesibilidad debemos realizar múltiples tareas, algunas de las mismas están numeradas y divididas en dos grandes grupos:

Aprender: Sobre el sitio web o aplicación, las necesidades de los usuarios, los objetivos de negocio, la industria y la competencia.

Generar: Ideas, soluciones y “artefactos” de comunicación que ayuden a alinear el equipo y dar forma al producto.

Aprender

-Análisis de sitios web (website analytics)

-Recorrido cognitivo (cognitive walkthrough)

-Evaluación heurística (heuristic evaluation)

-Entrevistas con los interesados (stakeholder interviews)

-Análisis FODA (SWOT analysis)

-Entrevistas a los usuarios (user interviews)

-Pruebas de usabilidad (usability testing)

-Investigación contextual (contextual inquiry)

-Ordenar tarjetas (Card Sorting)

-Mapeo de afinidad (affinity mapping)

Generar

-Personajes (personas)

-Personalidad de la marca (brand persona)

-Patrones de navegación (navigation patterns)

-Patrones de búsqueda (search patterns)

-Estrategia de contenido (content strategy)

-Talleres de ideación (ideation workshops)

-Tareas y casos de uso (tasks and use cases)

-Flujos de trabajo (workflows)

-Prioridades página (page priorities)

-Prototipos (prototype)

-Patrones de interfaz de usuario (UI patterns)

Características principales de los dispositivos móviles

Son aparatos pequeños.

Tienen capacidad de procesamiento limitadas.

Poseen conexión permanente o intermitente a una red.

Incluyen memoria limitada.

Son de propósito general.

Se asocian al uso personal.

Podemos ampliar algunas de estas apreciaciones dirigiéndonos a las guías para desarrolladores que nos provee Google.

Habiendo dado un marco a nuestro proceso podemos decir que estamos en condiciones de comenzar a crear nuestra aplicación móvil.

La aplicación que nos va a servir de ejemplo para este capítulo es un producto que se utilizará en dispositivos móviles (celulares) para una importante empresa del ramo de la salud en Argentina. Esta aplicación móvil contará con las funcionalidades que actualmente tiene el sitio Web de la empresa pero se re adaptarán al nuevo entorno de uso.

La aplicación móvil permitirá efectuar trámites sobre los datos de la cuenta del afiliado, consultas de estudios médicos, solicitud de turnos para diversas especialidades, visualizar los centros de atención más cercanos al lugar donde se encuentre el asociado, entre otras funcionalidades.

El usuario que va a utilizar esta herramienta es del más variado que podamos encontrar. Por tanto la aplicación debe responder no sólo a diferentes personas y tareas, sino que también debe ser independientemente de la situación o contexto en la que se use. Los ambientes que tenemos en cuenta para las pruebas son: edificios donde la conexión es lenta y un medio de transporte en movimiento.

El alcance de este desarrollo se encuentra limitado por los siguientes elementos:

Cantidad de programadores (5).

Conocimiento de los desarrolladores involucrados en el proyecto (desarrolladores Front-end), con amplio conocimiento en Web.

Cantidad de horas para el desarrollo y la puesta en productivo del software (2.880 horas).

Metodologías Ágiles de desarrollo de software.

Poco o nulo mantenimiento para este proyecto particular.

Como mencionamos, el equipo no cuenta con el suficiente conocimiento técnico necesario para la implementación de una app móvil tanto para Android como para Mac (se genera para estos dos Sistemas Operativos, por ser los más populares hoy en día) con lo que no existe una posibilidad de realizar una app móvil que permita el uso de los features del equipo (celular) que el usuario posea.

El primer inconveniente con el que se encuentra el equipo de desarrollo es el hecho de que el actual sitio no se encaró desde un comienzo siendo responsive.

Esto nos plantea el desafío de generar una reestructuración del desarrollo anterior y la posibilidad de incluir etiquetas y atributos necesarios para mejorar o ampliar su accesibilidad.

Primero lo primero, Accesibilidad primero

Debemos tener presente que esta guía está ubicada y contextualizada dentro de un proyecto (caso mencionado anteriormente) que, si bien está comenzando, no parte de una idea o lluvia de ideas de un equipo, sino que pretende ser una mejora (contemplar desarrollo responsive y accesibilidad Web) a un sistema que ya se usa en la Web, pero volcado a un dispositivo móvil.

Debemos pensar antes que nada en las necesidades de nuestros futuros usuarios. Esta es una forma de trabajo que nos propone el Diseño Centrado en el Usuario (DCU). La accesibilidad toma de ella las bases para lograr un “diseño universal”. No podemos realizar algo “para todos” si no ubicamos en la escena central a los usuarios.

Para poder cumplir con estos requerimientos se decidieron los siguientes aspectos:

Comprender las características del usuario: Se armaron personajes que responden a nuestros usuarios modelos. Éstos poseen las características que en el equipo requerimos para las pruebas de la aplicación.

Los aspectos ambientales de un dispositivo móvil: Se incluyen el uso del manos libres, uso del Google Talkback y Siri según corresponda.

Las pruebas de usabilidad: Se incluyen a participantes con discapacidad visual y movilidad reducida.

Puntos a tener presente

Estos pasos, al igual que los otros mencionados a lo largo de toda la guía, podrán realizarse por completo o parcialmente, en cada step o ciclo iterativo para no perder de vista los objetivos que nos planteamos en el inicio de nuestro proyecto.

Validar HTML y CSS con herramientas semi-automáticas.

Un equipo se basa en la confianza que comparten sus integrantes y en las habilidades individuales y grupales que posean. Pero como sabemos, somos todos humanos y podemos cometer errores. Por ello es muy importante validar la aplicación antes de comenzar a desarrollarla al igual que en cada uno de los pasos del ciclo iterativo.

Validar el HTML.

Validar el CSS (hoja de estilos).

Encontraremos muchos validadores disponibles en la Web que son totalmente gratuitos, como por ejemplo:

Taw (http://www.tawdis.net/)

Cynthia Says (http://www.cynthiasays.com/) (en inglés)

Examinator (http://examinator.ws/)

W3C Markup Validation Service (http://validator.w3.org/)

Validador CSS del W3C (http://jigsaw.w3.org/css-validator/)

Plug-in de Firefox (http://goo.gl/bjdRhb)

Esto puede resultar complejo. Para hacerlo más sencillo te sugerimos seguir estos consejos:

Declarar el DOCTYPE.

Recordar cerrar las etiquetas.

Se recomienda usar minúscula para escribir las etiquetas del documento.

Utilizar ficheros externos para CSS y Java Script.

Enlazar los CSS externos al principio.

Enlazar los Java Script externos al final o el uso de JavaScript no intrusivos.

Usar el atributo “alt” en todas las imágenes.

Utilizar <title> representativos para los nombres de tus Web.

Evitar repetir los id en el HTML.

Utilizar código semánticamente correcto (usar cada tag para la finalidad que se necesite, por ejemplo: el uso de <li> para elementos de una lista).

Utilizar metaetiquetas como “description” y “keywords”.

Evitar el abuso de <div>.

Imágenes y texto alternativo

En el mundo de la accesibilidad vemos, como este tema del texto alternativo (<alt>) se repite hasta el cansancio.

El principio que regula la generación del texto es sencillo: ¡Dar significado a las palabras! Debemos hacer que por medio de ellas la persona pueda entender el porqué de la imagen.

Asegúrese de que funciona sin flash

La utilización de flash en dispositivos móviles está en un desuso total. Tengamos en cuenta que los grandes sistemas operativos actuales (IOS y Android) han dejado de darle su respaldo. Problemas como la caída de la performance o la falta de seguridad que Flash proporcionaba son algunas de las causas de esta “eliminación” casi total en los dispositivos móviles.

No obstante, flash no murió, ni lo hará. Adobe, responsable del producto, reanudó esfuerzos para darle pelea al HTML5 en los sitios utilizados en desktop y demás plataformas.

Queremos desmitificar el uso de flash como el gran destructor de la accesibilidad en los sitios Web. Muchas veces se lo responsabiliza de bloquear, impedir o dificultar a los usuarios con discapacidad el uso de los sitios Web. Déjenme dejarlo claro, ¡no es tan cierto como parece!

No es flash el responsable de la inaccesibilidad sino el desconocimiento de técnicas para hacerlo accesible.

A continuación compartiremos algunas técnicas:

La estructura de un objeto Flash se basa en jerarquías de capas y niveles de abstracción (objetos gráficos, variables, clips de película, etc.) por lo tanto deberíamos fijar una estructura estándar para poder utilizar esta herencia.

Proporcionar a cada objeto del árbol de contenidos propiedades de accesibilidad propias, el entorno de desarrollo facilita un cuadro diálogo específico (menú Ventana–Otros paneles–Accesibilidad).

Activar las opciones de accesibilidad para objetos determinados.

Los campos Nombre, Descripción y Método Abreviado permiten asociar información textual alternativa y funcionalidad accesible.

Proporcionar características de Accesibilidad a través de Action Script.

Establecer un orden de lectura.

Generar navegación alternativa por teclado.

Proporcionar el contraste correcto.

Garantizar el control de los medios tempodependientes (videos y audios).

Estas son sólo algunas de las consideraciones que podemos establecer a la hora de generar algún contenido con flash en nuestros sitios. Para ponerlo en práctica, podemos recurrir a la guía que brinda INTECO a tales fines.

De todas maneras debemos tener presente que el uso de HTML5 y CSS3 han marcado un nuevo horizonte en el diseño de las interfaces a tener más que presentes en nuestro día a día.

Aumentar el tamaño del texto

Existen múltiples sitios que utilizan este artilugio de CSS para poder cumplir con lo que las pautas de accesibilidad pretenden conseguir.

Dos consideraciones al respecto:

El usuario que necesita una ayuda técnica, ya la posee: Cuando un usuario con dificultades en su visión requiere una ayuda técnica por lo general la necesita siempre. Esto no es algo particular de internet o un sitio web específico. Existe una enorme multiplicidad de programas que se utilizan para magnificar la pantalla. De hecho, todos los sistemas operativos, proveen magnificadores de pantallas para el uso cotidiano. Los usuarios no requieren un diseño de sitio en particular sino que necesitan el correcto uso de las etiquetas y CSS. El sitio (en especial los textos) debe poder ser ampliado hasta un 200% más que su tamaño original. Esto significa que el maquetado del sitio debe ser lo suficientemente elástico para garantizar esta particularidad desde el diseño.

El tamaño sí importa: En dispositivos móviles tenemos pantallas de 5´, 7´, 7,5´, 10´, etc. ¿El tamaño del texto y del sitio deberá ser estático para cada uno de estas pantallas o dispositivos? ¡Claro que no!

El texto debe adaptarse a la resolución del dispositivo, sin dejar de contemplar la posibilidad del uso de gestos, para ampliar el tamaño del mismo.

Marcas semánticas (WAI-ARIA)

La W3C define a WAI-ARIA como: “La forma para crear contenido Web y aplicaciones Web que sean accesibles para las personas con discapacidad”. Para poder explicar el impacto que tendrá el uso de WAI.-ARIA en nuestro sitio web debemos comprender el uso de ajax.

Podemos definir a ajax como una técnica de desarrollo web para crear aplicaciones interactivas o RIA (Rich Internet Applications). Estas aplicaciones se ejecutan en el cliente, es decir, en el navegador de los usuarios mientras se mantiene la comunicación asíncrona con el servidor en segundo plano.

Volviendo a WAI-ARIA debemos mencionar cuáles son las funciones que este tipo de marcado tiene en el contenido del sitio.

Identificar el rol del elemento: ¿Qué es?

Conocer su estado y propiedades: ¿Cómo se encuentra?

Capturar su comportamiento: ¿Qué hace?

Cuando los programadores deciden armar un sitio web que utiliza ajax se encuentran con el dilema de “avisar” o controlar el “comportamiento” de los elementos de la interfaz que han sido modificados a los usuarios.

Para esto, en la aplicación se utilizaron los siguientes “roles” que denotan una determinada propiedad o estado.

-Alert: Se trata de un mensaje con algún tipo de importancia que es dependiente del tiempo.

-Alertdialog: Es un tipo de diálogo que advierte sobre un asunto.

-Application: Es una región considerada aplicación en contra de otras partes que son de tipo documento web.

-Article: Es una sección del documento cuya composición forma una parte independiente del documento.

-Banner: Región en la que se incluye algún tipo de publicidad o anuncio.

-Button: Es una entrada de datos que mediante la pulsación o la activación genera una acción o evento.

-Checkbox: Es una entrada con tres tipos de estados: true, false o mixed.

-Columnheader: Es una celda que contiene información de la columna.

-Combobox: Tipo de selección de texto en forma de lista.

-Complementary: Es una sección del documento que complementa a una principal del mismo.

-Contentinfo: Es una región que contiene información sobre el documento padre.

-Definition: Definición de un concepto.

-Dialog: Es una ventana de aplicación que interrumpe el proceso actual para proporcionar información o atender a una respuesta necesaria.

-Directory: Es una lista de miembros de un grupo.

El objetivo de WAI-ARIA es aportar información acerca de las diferentes partes que constituyen los contenidos dinámicos generados normalmente por medio de scripts. Toda esta información será utilizada por los productos de apoyo (por ejemplo: lectores de pantalla) para la interacción con el usuario final.

Uso de lector de pantalla predeterminado en el dispositivo

Para comenzar a entender cómo es la experiencia de uso de nuestra aplicación debemos al menos ponernos en el lugar del otro durante un tiempo. Por eso les acercamos estos dos recursos: Voxound y Blind y también el conocido VoiceOver.

Estas herramientas nos permitirán vivir, parcialmente, las sensaciones, emociones y por qué no, las frustraciones de nuestra aplicación a medida que la vayamos desarrollando con el tiempo.

Utilizar la aplicación en diferentes SO y dispositivos

Los test también son fundamentales como parte del proceso del desarrollo de un software accesible. Recordemos que no sólo es importante, como menciona nuestra definición de accesibilidad, la persona sino también el contexto y el dispositivo empleado para tal fin. La accesibilidad nos permitirá, si se utiliza a conciencia, generar aplicaciones que puedan funcionar en la gran cantidad de dispositivos que existen hoy en día sin muchos inconvenientes.

Probar nos permitirá garantizar que nuestra interfaz cumpla con las pautas que hayamos establecido como norma de calidad (al menos nivel AA).

El contraste de colores

Sobre este tópico nos centraremos en las dificultades visuales que son, en sus distintos grados, desde la baja visión a la ceguera total, además de problemas para distinguir colores (daltonismo).

Para corroborar si los colores utilizados son los correctos o al menos nos permiten cumplir con el suficiente grado de contraste para ser percibidos por las personas, podemos utilizar algunas de las siguientes herramientas Web.

http://www.checkmycolours.com/

http://www.dasplankton.de/ContrastA/

Ambas herramientas online nos permitirán validar los colores que formen parte de nuestro sitio Web.

No sólo se efectuaron estas validaciones en los dispositivos móviles sino que en pos de mejorar cualquier futura implementación, también se hicieron pruebas en PC.

Como resultado de las mismas podemos decir que muchas de las cosas que vimos y que se consensuaron oportunamente con el equipo de marketing, publicidad y diseño de la empresa debieron ser modificados para cumplir con las pautas de accesibilidad. Esto nos obligó a concertar nuevas reuniones y a generar un sprint (en este caso un sprint de una semana) particular para arreglar estos desajustes (contraste erróneo, familia tipográfica inadecuada, tamaño tipográfico no escalable en algunos casos).

Consideraciones pertinentes en PC

-Navegadores de sólo texto (Lynx).

-Instalar plug-in de firefox.

Juicy Studio Accessibility Toolbar 1.7

Accessibility Evaluation Toolbar 1.5.7.1

FoxyVoice

Illinois Center for Information Technology and Web Accessibility

-Uso de lector de pantalla.

NVDA

ORCA

JAWS

-Utilización de lupa.

-Navegación mediante teclado.

Estas consideraciones globales (móviles y desktop) nos permite abarcar la totalidad de casos de accesibilidad y usabilidad que se puedan estar presentando en este momento (en nuestro proyecto solo la fase móvil) como en un futuro.

Luego la Usabilidad móvil

Premisas antes de arrancar la labor de usabilidad y User Experience Design

Buscar el correcto equilibrio entre diseño e información: Este balance debe ser tan preciso que logre satisfacer a los usuarios en su búsqueda de información y que sea agradable para ellos su utilización.

Evocar emociones positivas: Por medio del diseño visual y arquitectónico (Arquitectura de la información) debemos provocar las sensaciones de confianza en la información brindada, facilidad de uso y agilidad en las respuestas a acciones que el usuario realice.

Menos es más: Los usuarios de dispositivos móviles, como lo son los celulares, pasan poco tiempo mirando las pantallas de los mismos ya que en su mayoría además de usar el celular, se encuentran haciendo otras tareas de manera simultánea. En un abrir y cerrar de ojos debemos darle al usuario lo que espera ver en cada instante.

Optimizar lo suficiente: Los usuarios no suelen tomar la decisión correcta todo el tiempo cuando están sosteniendo sus celulares o dispositivos móviles.

Las principales problemáticas que detectamos en las app móvil

El tamaño del dispositivo, de su pantalla y sus múltiples variantes en el mercado.

Las prestaciones tecnológicas (capacidades de procesamiento y memoria interna, cámara, Wi-Fi, etc.).

La interacción (teclado, Touch o voz).

La movilidad (motricidad fina).

Contexto de uso (oficina, plazas, casa o restaurant, etc.).

La luz solar y el uso de los colores apropiados (colores corporativos vs. utilidad en el contexto).

Orientación vertical y horizontal del dispositivo.

La escritura de formularios (principal complicación para los usuarios).

El tamaño de los controles en la interfaz (garantizar la menor tasa de errores motrices posible).

¿Qué buscamos detrás de todos estos pasos?

1. Claridad: Debemos evitar siempre colocar elementos que el usuario no logre entender. La gente ignora a menudo las cosas que no pueden entender.

2. Ley de acción preferente: El usuario se siente más cómodo cuando entiende lo que la acción seleccionada hará.

3. Ley de contexto: El usuario espera ver los controles de interfaz cerca del objeto que quiere controlar.

4. Ley de default: El usuario rara vez cambia la configuración predeterminada. Los valores predeterminados son de gran alcance (la mayoría de la gente tiene un fondo predeterminado y tonos de llamada en sus teléfonos).

5. Ley de acción guiada: El usuario probablemente va a hacer algo si se le pide que lo haga.

6. Ley de la retroalimentación: El usuario se siente más seguro si le proporcionan información clara y constante. Gmail es un gran ejemplo de un buen feedback.

7. Ley de facilitar: El usuario está más predispuesto a realizar una acción compleja si se divide en pasos más pequeños.

8. Adaptabilidad: La adaptabilidad de un sistema se refiere a su capacidad de comportarse de manera contextual y de acuerdo a las necesidades y preferencias del usuario.

9. Manejo de errores: Medios disponibles para prevenir o reducir los errores o recuperarse ante la ocurrencia de los mismos.

Conclusión

El diseño de una buena herramienta debe satisfacer las necesidades y al mismo tiempo amplificar las capacidades humanas, nuestras potencialidades sensoriales y cognitivas, para convertir lo que podemos hacer en lo que queremos hacer.

Todos los sitios deben tomar nota de la accesibilidad Web. Las personas con discapacidad visual utilizan lectores de pantalla para “leer” las páginas web. Éstos requieren imágenes que se describen en los textos alternativos y los lectores de pantalla también luchan para leer el contenido no HTML, como Flash.

Por suerte, los motores de búsqueda, como Google o Bing, tienen preferencias similares a los lectores de pantalla. Esto permite afirmar que el SEO se ve beneficiado sustancialmente.

Como podemos observar es imprescindible el uso del Diseño Universal y el diseño centrado en el usuario para poder satisfacer la gama de usuarios y contextos a los que se enfrenta nuestra aplicación.

Si tenemos en cuenta los criterios que hemos aplicado para el caso mencionado arriba, podemos concluir que las directrices de accesibilidad utilizadas en primera instancia nos permitirán satisfacer las necesidades de nuestros usuarios ampliamente.

Bibliografía

http://accesibilidadweb.dlsi.ua.es/?menu=hr-trabajar-color

http://accesibilidadenlaweb.blogspot.com.ar/2009/03/color-y-contraste.html

http://nosolousabilidad.com/

http://olgacarreras.blogspot.com.es/

http://es.wikipedia.org/wiki/Accesibilidad

http://www.justinmind.com/

http://ami.responsivedesign.is/

http://alistapart.com/article/aria-and-progressive-enhancement

http://www.proyectosagiles.org/

http://mobiforge.com/design-development/why-mobile-web-accessibility-matters-best-practices-make-your-mobile-site-accessi

http://uiaccess.com/justask/es/background.html

http://www.nosolousabilidad.com/articulos/dcu.htm

La relación entre UX y el ROI

Texto: Víctor Malumián

Víctor Malumián es licenciado en Cs. de la Comunicación (UBA) y realizó la especialización en Accesibilidad y Usabilidad en la UTN. Se desempeña como UX Consultant. Durante su carrera profesional, trabajó para clientes como Microsoft, Starbucks, MetLife, Visa, Banco Piano, Banco Macro, Car One, Mercado Libre, Pago Mis Cuentas, VW, Audi, Zurich, Discovery Channel, Cablevisión y Securitas, entre otros. Es director en Ediciones Godot.

En un contexto donde todavía grandes empresas piensan los desarrollos puertas adentro sin contacto con sus usuarios, entregan documentos de cientos de páginas a una agencia o software factory para que les desarrolle un sistema sin antes validarlo con quienes van a operarlo diariamente, es importante pensar la estrecha relación entre la Experiencia de Usuario (UX) y el Retorno de la inversión (ROI). Existen varias aristas en la relación entre la UX y el ROI, por ejemplo, una visión relacionada a la eXperiencia HUmana (HUX) abordada por Eduardo Mercovich 9. Y otro enfoque posible podría ser la Gestión de Riesgo y la UX como un mitigador para esa problemática. La Gestión de Riesgo entendida como la exposición (qué tan grave puede ser lanzar este nuevo producto/funcionalidad para la marca) o de probabilidad (¿qué tengo que hacer para minimizar la probabilidad de que suceda lo peor?).

En este artículo nos vamos a centrar en la faceta más económica de la relación, el eficiente uso de los recursos disponibles para lograr el mejor de los resultados posibles.

Lo testeamos cuando esté online. Existe un video genial de Susan Weinschenk donde en pocos minutos se marcan los puntos álgidos del análisis Why Software fail. Este informe comenta a grandes rasgos que en Estados unidos se invierten aproximadamente 1 trillón de dólares al año en proyectos. De ese trillón el 15% se abandonan, de los cuales el 5% del total del proyecto va a IT y si la empresa es de telecomunicaciones probablemente el número trepa al 10%. Lo preocupante es que el 50% de ese tiempo es re-trabajo que podría ser evitado.

Por cada dólar que se gasta en arreglar un error en la etapa de diseño, se gastan 10 para solucionarlo cuando la línea de código ya está escrita, y el costo de arreglar ese mismo error después de publicada la aplicación es 100 veces más caro que en la etapa de diseño. Aún más deprimente es pensar que: de las 12 razones por las cuales falla un proyecto 3 están directamente relacionadas a UX, como ser:

Mala definición de las necesidades del usuario.

Pobre comunicación entre los usuarios, clientes y desarrolladores.

Malas políticas de quienes toman las decisiones a lo largo del proyecto.

Todos solucionables por una buena práctica de UX sin demasiado costo directo. Smashing Magazine se animó a realizar un calculador de ROI en un escrito de Anders Hoff donde se explica cómo calcular la mejora en el retorno de la inversión en un trabajo de UX antes de comenzar.

La procesión va por dentro

Mencioné los costos directos: horas de programación desperdiciadas, funcionalidades que no sirven, costo de oportunidad perdido, etc. Pero qué pasa con aquellos costos del orden de lo intangible.

Un ejemplo son las preguntas frecuentes que reflejan la necesidad de contar una historia por parte de la empresa más que solucionar los problemas de los usuarios, preguntas que se traducen en un mayor impacto en llamadas al call center. ¿Qué pasaría si las preguntas frecuentes estuvieran pensadas en torno a las tareas recurrentes que realizan los usuarios dentro del sitio?

Otro ejemplo son las botoneras que representan un mapa mental de la organización interna de un banco en lugar de las tareas que quieren realizar los clientes, sin lugar a dudas se traduce en mayores operaciones presenciales en lugar de virtuales.

Primer caso

Con las manos en el barro

Un importante cliente de pagos online de servicios y productos desea lanzar su billetera virtual como aplicación mobile. Definimos las tareas sobre las que nos queremos enfocar y las ordenamos según las ejecuta el usuario:

Generar una cuenta en la app.

Realizar un pago.

Importar usuarios desde tu libreta de direcciones del celular.

El primer paso para aplicaciones transaccionales es el registro. Es muy complejo, no sólo porque entran en juego los problemas propios del tamaño de la pantalla del dispositivo, sino obligaciones legales sobre las normativas de seguridad que impactan de lleno en la cantidad y tipo de datos que se solicitan.

Todos sabemos que existe una variable entre la cantidad de datos, la sensibilidad o privacidad que implican y la tasa de deserción que tiene un registro. Más todavía si sumamos que la norma para el usuario, es actualmente, primero probar las apps o herramientas y luego comprometer sus datos en un registro. Práctica, tan extendida, que ya se recomienda desde iOS Human interface Guide para IOS7 retrasar el logueo lo más posible, para que el usuario experimente la app y luego, casi a modo de voto de confianza, genere una cuenta con nosotros. Por otra parte, los usuarios están acostumbrados a que una importante mayoría de las aplicaciones te permiten usarlas sin tener que otorgar datos sensibles o loguearte.

Permitir el uso de la billetera virtual sin antes identificar al usuario no era una opción. Aunque hay ejemplos de simuladores que le permiten al usuario anticipar cómo será una transacción para que gane confianza y termine por usar la aplicación, no hay métricas fehacientes que avalen su efectividad en relación al esfuerzo que implica.

Los campos obligatorios (algunos impuestos por normativas de seguridad del Banco Central otros por el equipo de seguridad informática interno) eran:

Username

Password

Mail (para realizar pagos por mail)

Cuenta Bancaria: Desde dónde se moverán los fondos.

CBU

DNI

Número celular: (para realizar pagos por celular)

Compañía de celular

Número de celular

Crear una cuenta

El primer flujo que se pensó fue tipo panel de control. El usuario veía una pantalla con tres opciones: validar teléfono, validar email y validar cuenta bancaria. Los botones estaban ordenados a modo de lista. Cada vez que presionaba un botón iniciaba el proceso de validación del dato.

Al terminar el proceso de validación del primer dato el usuario volvía a la primera pantalla pero con un feedback positivo donde la interfaz, tanto visualmente (ícono + color) así como textualmente le informaba que había sido validado el dato y debía seguir con el próximo paso.

Los usuarios no veían una relación de continuidad entre la validación del primer dato y del segundo, es decir no veían en esa lista una continuidad de acción. Tampoco la entendían como un feedback en cuanto a la duración del proceso. En la primera iteración en papel descubrimos que los usuarios con baja y media alfabetización digital no comprenden esta lógica, o al menos no les resultaba intuitiva.

De 5 usuarios, 3 no pudieron completarla. Al contrario con los usuarios de alta frecuencia de uso con apps para smartphones entendían y terminaban el proceso. La idea detrás del panel de control era permitirle al usuario abandonar la adhesión y al retomarla tener un claro indicador de lo que ha hecho y lo que le restaba realizar.

La confirmación de la cuenta bancaria solicitaba algunos datos como CBU que no son particularmente recordables por el usuario, por eso era importante que el usuario pudiera abandonar la aplicación para buscar un dato y retomar el registro en otro momento. Habíamos pensado el flujo de forma concéntrica. Ciclos de validación que se repiten en el funcionamiento pero nunca vuelven al exacto mismo paso, sino al mismo template. Es decir, partimos del mismo lugar, pero al volver esa interfaz que nos es familiar tiene un claro indicador de que hemos cumplido ese primer ciclo, que podría ser validar el teléfono, por ejemplo.

Teníamos un primer dato, los usuarios no veían como evidente el próximo paso.

En una segunda iteración cambiamos el flujo. En lugar generar un panel de control donde el usuario tuviera como primer dato el estado y dependiera de él tomar el camino hacia la segunda validación, generamos un proceso lineal y automático. En el nuevo flujo el usuario tenía un pequeño indicador que le mostraba el punto del proceso donde estaba y cuántos pasos le faltaban para terminar.

Las validaciones se daban una atrás de la otra, es decir, terminaba el usuario de validar el tipo de dato, veía un mensaje de éxito y al cerrarlo le pedimos que valide el siguiente dato. Los espacios más prominentes estaban reservados a dejar bien claro el próximo paso en el proceso. Este nuevo flujo tenía algunos pasos más que reforzaban el feedback textual hacia el usuario.

Bajo este nuevo flujo todos los usuarios terminaron el proceso exitosamente. No sólo lograron completarlo, sino que fueron más eficientes reduciendo el tiempo de ejecución a pesar de tener más pantallas.

Como habíamos incrementado la cantidad de pantallas nos interesaba saber la percepción del usuario sobre el tiempo que le llevó terminar el proceso, que no siempre coincide con la duración real de la prueba. Los usuarios habían percibido un proceso corto con pocas pantallas. Recuerdo cómo las palabras de Kruge retumbaban en nuestras cabezas, no son tan importantes los pasos de un proceso como la auto-evidencia del próximo paso.

Las pruebas las realizamos todas con prototipos de alta fidelidad pero en papel. Con pequeños recortes que hacían las veces de mensaje de error. Entre iteración e iteración no pasaron más de dos días. En menos de una semana teníamos un flujo de registro que funcionaba.

Uno de los puntos más interesantes era haber aprendido de un error que ni siquiera estaba en nuestro campo de posibilidades, ni siquiera imaginábamos. No sólo teníamos ese dato, también estábamos un paso más cerca en nuestro conocimiento del usuario.

En casos como este es relativamente más fácil medir el ROI dado que las empresas saben el promedio de retorno que tiene por usuario. Si la aplicación se hubiera lanzado con el flujo de registro que habíamos pensado como más “práctico para el usuario”, 3 de cada 5 usuarios no hubieran entrado a la aplicación. Lo interesante a tener en cuenta es que lo que a nosotros nos puede parecer lógico a simple vista está sesgado por una infinidad de prácticas y costumbres que nuestros usuarios pueden no compartir.

Segundo caso

Un ecosistema en permanente evolución

Hasta acá vimos el ejemplo de un proyecto que nace con nuestra participación. Ahora bien, ¿qué pasa cuando trabajamos sobre un sitio existente?

La nueva funcionalidad

Sin importar el origen del pedido, asumamos por un segundo que un área de la empresa requiere que se desarrolle una nueva funcionalidad en el sitio. Antes de sentarnos a pensar cómo deberíamos prototipar esa funcionalidad, o bien en qué contexto se inserta en la tarea que el usuario quiere realizar, estamos obligados a preguntarnos: ¿es realmente necesaria esta funcionalidad? ¿Le agrega valor al usuario?

Parte de tener una interfaz enfocada a las tareas del usuario es saber decir que no ante la avalancha de más y más funcionalidades. Entonces tenemos un doble problema, por un lado cómo descubrir si realmente es necesaria esa funcionalidad y en segundo lugar cómo justificar nuestra respuesta para poder guiar el desarrollo en el camino correcto.

Supongamos que trabajamos en un sitio donde se puede escuchar música online gratis a través de distintas listas de música. Las listas por momentos se caen, o a veces simplemente tienen un cupo y a una determinada cantidad de usuarios no permiten el ingreso. Desde el lugar del usuario, poco importa la razón técnica por la cual él está impedido de escuchar su música.

Supongamos también, que el product manager decide que es una buena idea que cuando el usuario intenta escuchar una lista de reproducción y por la razón que fuere, no se le puede dar acceso, proponerle que deje su email y avisarle cuando o bien se liberó el cupo o bien se restableció el sonido.

Esta tarea que pareciera tan lógica como simple, tiene sus matices. Entre las acciones que tenemos que programar contamos con:

Detectar que una lista no funciona.

Disparar un mensaje cuando esto sucede.

Tomar el mail del usuario asociado a la lista que intentó escuchar.

Correr un cron por las listas para saber cuándo vuelven a estar activas.

Cuando se detecta una lista que estaba rota y vuelve a estar activa buscar el ID de los usuarios asociados que estén esperando ser notificados.

Encolar un mail con el aviso y un link dinámico a la lista para que el usuario lo reciba y pueda acceder de forma rápida y cómoda a su música preferida.

Descartemos por el momento problemáticas asociadas al espacio en la base de datos o performance del sitio en pos de hacer más simple el ejemplo.

Esta funcionalidad que parecía muy simple, ya muestra que va a conllevar varias horas de desarrollo, algunas más de testeo y por supuesto su correspondiente publicación en producción. Un enfoque interesante a tomar desde nuestro lugar como obrero de UX es preguntarnos cómo podemos testear de una forma barata que esto que a nosotros nos suena lógico e interesante a nuestros usuarios también.

Un primer acercamiento podría ser una encuesta. Cuando se dispara el evento (que no se pueda escuchar una lista) mostrarle al usuario una encuesta donde le preguntamos si esta funcionalidad le sería de utilidad. Es un buen primer enfoque pero tiene sus problemas. El primero es que el usuario no está depositando un voto a conciencia. Puede votar en el apuro por SI o NO sin brindarle demasiada importancia. Un segundo problema, muy típico en las encuestas, es que la primera opción siempre recibe más votos. Este factor se puede solucionar rotando todos los días (algunos servicios lo hacen automáticamente) el orden de las respuestas.

Si pensamos un poco más, podemos encontrar una forma más eficaz de medir el interés del usuario. Una forma donde el usuario también ponga un poco de esfuerzo simbólico, que en gran parte, es a sus vez un voto más real. Podemos armar una maqueta, sin programación casi, de la funcionalidad en cuestión. Mostrarle el mensaje al usuario e invitarlo a dejar su mail, a modo de voto de confianza, a sabiendas de lo que representa para cualquiera dejar su mail. Con este dato tenemos una sensación más real si le interesa realmente que desarrollemos o no esa funcionalidad.

Esta táctica es una adaptación de lo que se llama corrientemente MVP (minimum viable product), donde simulamos los valores más importantes de nuestra propuesta sin desarrollarla por completo. Entonces podemos mostrar un campo donde dejar el email, devolver un mensaje de éxito ante un mail suscripto y así tener nuestras métricas.

Es verdad que unos cuantos usuarios quedarán a la espera de un mail que no llegará. Podemos luego, enviarles un mail comentándoles que estamos terminando de desarrollar esa funcionalidad y que serán los primeros en acceder a ella. De paso, tenemos usuarios para hacer las primeras pruebas. Es importante en estos experimentos tomar muestras que sean significativos para el caudal de tráfico del sitio. Existen varios calculadores online.

Es importante estipular nuestras expectativas antes de realizar el experimento. Con esto apunto a delimitar ANTES de correr nuestra prueba cuántos usuarios deberían dejarnos el mail para que consideremos que vale la pena desarrollar la nueva funcionalidad. Si no corremos el riesgo de dejarnos llevar por las circunstancias en las cuales compilamos los resultados.

A nadie le interesa

Tomemos el primer resultado posible: no llegamos a los niveles de aceptación que esperábamos. La cantidad de horas que ahorramos en recursos escasos como son los programadores, maquetadores, diseñadores y líderes de proyecto es fácilmente medible.

En segundo término, la cantidad de recursos de hardware que ahorramos al no generar una funcionalidad que nuestros usuarios no quieren también es medible. Ya en un campo más difícil de medir, no expusimos a la gran mayoría de nuestros usuarios a contaminación visual de una funcionalidad que no deseaban. Por último, siempre recordemos que el consumo del desarrollo no está solamente en lo que conlleva desde la generación de la funcionalidad hasta que se publica, sino que tenemos que sumar sus horas de mantenimiento y debugeo.

Con los resultados en la mano es muy fácil despegarse de las opiniones y las conjeturas internas de una empresa o un cliente y mostrar lo que lo usuarios han dicho.

¿Cómo no lo pensamos antes?

Resuelto el primer resultado posible, pensemos en el segundo. El experimento fue un éxito. Lo interesante de mediar el experimento primero, no es sólo que ahora estamos seguros del camino que tomamos, sino que tenemos una primera experiencia de la cual podemos extraer conclusiones. Podemos tomar este experimento como el “control” para las conversiones de los usuarios y comenzar a iterar en un loop de optimizaciones. Podemos probar con nuestros usuarios qué tipo de call to action los interpela más eficientemente a dejar sus emails. Podemos hacer pruebas sobre nuestros copys para saber si son claros al momento de comunicar los beneficios de la funcionalidad. Dimos el primer paso hacia la entrega de una especificación precisa a los desarrolladores pero en base a las necesidades de los usuarios.

Conclusiones

Las principales excusas para no hacer un breve experimento generalmente son dos: el tiempo y el costo. Nada lleva más tiempo que el re-trabajo de una funcionalidad que no fue pensada en conjunto con el usuario y testeada de la misma manera. Si tenemos en cuenta que el retorno de la inversión es una relación entre el costo y la ganancia, se torna más evidente que cuanto más dinero invirtamos en las primeras etapas del proyecto para garantizar que cada peso esté bien invertido, más amplias son nuestras chances de elevar a nuestro favor la ecuación del ROI.

Si en la primera iteración los resultados son excelentes, desconfiá: algo no salió bien desde la aplicación de la metodología. Si todo está correcto en el método, volvé a desconfiar. Es más difícil que puedas aprender de un experimento que salió perfecto que de tus errores.

En relación al ROI y la usabilidad IBM, Susan Weinschenk dejó en claro su postura: “For developers and manufacturers, the advantages of creating usable products far outweigh the costs. The rule of thumb: Every dollar invested in ease of use returns $10 to $100.” 10

Al principio de este texto vemos cómo la ausencia de pruebas con usuarios y la correcta investigación de sus hábitos/usos tienen un impacto enorme a nivel económico. Quizás no sea ese el hallazgo más interesante, sino la constante de siempre sorprenderse con los descubrimientos al investigar y realizar pruebas, dado que es imposible para un mortal poder prever y articular de antemano todas las soluciones a las necesidades de los usuarios. Rara vez son previsibles los resultados que nos devolverá la correcta aplicación de metodologías ligadas a la investigación con usuarios. Son esos descubrimientos los que evitarán el malgasto de desarrollos fútiles y optimizará la relación entre los costos y la ganancia. Hay una sola forma de descubrirlo.

Notas

9 http://www.tedxcarloscasares.com.ar/oradores/eduardo-mercovich.html

10 “Para desarrolladores y fabricantes, las ventajas de crear productos usables superan con creces los costos. La regla de oro: Cada dólar invertido en facilidad de uso devuelve de 10 a 100 dólares”

Experiencia de usuario en dispositivos móviles

Texto: Jordi Almirall López

Jordi Almirall López es ingeniero técnico de Informática de Sistemas por la Universidad Pompeu Fabra y máster en Sociedad de la Información y el Conocimiento por la Universidad Oberta de Catalunya. Como consultor de experiencia de usuario, ha participado en proyectos para ámbitos diversos. Actualmente, es docente de los ciclos formativos de Desarrollo de aplicaciones web y de Sistemas microinformáticos y redes. Se desempeña también como profesor asociado del Área de Diseño Centrado en el Usuario para trabajos de final de carrera de Desarrollo de aplicaciones sobre dispositivos móviles en la Universidad Oberta de Catalunya y autor de material docente para la misma, y como profesor invitado de la especialización en Diseño de Interacción con estándares de accesibilidad y usabilidad de la Universidad Tecnológica Nacional. Además de la experiencia de usuario, entre sus intereses también se encuentra la gamificación.

LinkedIn: es.linkedin.com/in/jordialmirall/

Twitter: https://twitter.com/jordialmirall

Los smartphones y las tabletas cada vez tienen una presencia mayor en nuestras vidas, y es que en muy poco tiempo han revolucionado el modo en que nos informamos, comunicamos, entretenemos y trabajamos. Evidentemente diseñar para estos dispositivos significa hacerlo para una pantalla pequeña y considerando variedad de modalidades de interacción (tacto, voz, movimiento, orientación, ubicación…) pero no únicamente eso. Su multifuncionalidad, portabilidad, dimensiones, autonomía limitada y conexión a la Red que no siempre existe o es la mejor implica conocer las características del entorno en el que se usará el producto interactivo. Ya que éste tiene una incidencia importante en la interacción de los usuarios. Considerando aspectos tecnológicos (conectividad, velocidad de conexión, nivel de batería, etc.), sociales (gente que hay alrededor, convenciones culturales, privacidad, etc.) o ambientales (luz, ruido, temperatura, etc.).

También implica conocer sobre las distintas soluciones tecnológicas en las que el producto se puede presentar, las particularidades de cada terminal y el comportamiento de sus usuarios. Entender a los usuarios es crucial si queremos diseñar y desarrollar aplicaciones o webs móviles que aporten valor añadido, que sean útiles, usables, fáciles de aprender, atractivas, y que en definitiva transmitan una experiencia de uso positiva. Por esta razón la metodología del Diseño Centrado en el Usuario cobra una gran importancia en el proceso de creación de productos interactivos móviles.

1. Apps, webapps, webs multidispositivo y apps híbridas

Una de las disyuntivas que deben resolverse al plantear un proyecto móvil, es decidir si será desarrollado como una aplicación nativa, como una web móvil, como una web multidispositivo o bien una como aplicación híbrida.

1.1. Aplicación móvil

Las aplicaciones móviles (apps) son aplicaciones desarrolladas específicamente para el sistema operativo móvil en el que se ejecutarán.

Pros:

Pueden aprovechar todas las funcionalidades y características del dispositivo, repercutiendo positivamente en la velocidad de ejecución y en una experiencia de usuario más rica.

En las tiendas de aplicaciones, los usuarios pueden encontrar categorizadas todas las apps disponibles para su terminal.

La monetización puede ser más directa mediante el pago por descarga.

Puede llegar a funcionar total o parcialmente sin conexión a Internet.

Al instalar la aplicación, el usuario dispone de un icono de acceso directo a la misma en su dispositivo.

Contras:

Es preciso desarrollar distintas versiones de la aplicación para cada sistema, con el consiguiente coste que implica.

Las tiendas de aplicaciones pueden exigir el cumplimiento de unos requisitos para poder publicar las apps y sus actualizaciones.

Es necesaria su instalación en el terminal para usarla.

Pueden estar funcionando a la vez varias versiones de la aplicación: las actualizadas y las no actualizadas.

1.2. Web específica para móvil

Una web específica móvil (webapp) es una página web diseñada para ser visualizada y utilizada exclusivamente en dispositivos móviles.

Pros:

Son compatibles independientemente de las plataformas y terminales.

La publicación de una web móvil no requiere la aprobación de una tienda de aplicaciones.

Las actualizaciones son instantáneas, lo que propicia que todos los usuarios usen la última versión.

No es necesaria una instalación en el dispositivo.

Contras:

El acceso a las características y funcionalidades del dispositivo es limitado.

Generalmente siempre necesitan conexión a Internet para a funcionar.

Para colocar un icono de acceso es necesaria la intervención del usuario.

Las webs móviles no disponen de una tienda de aplicaciones centralizada, por lo que su localización y monetización es más costosa.

Se ejecuta dentro de un navegador de Internet, por lo que ambas interfaces deben convivir.

1.3. Web multidispositivo

La opción multidispositivo permite que un único sitio web se presente de forma distinta, según la pantalla en que se visualice. Sin necesidad de confeccionar proyectos (apps o webs) diferentes para diferentes dispositivos, los diseños fluido responsive permiten disponer de un único sitio web que se adapta automáticamente dependiendo del tamaño y orientación del dispositivo.

1.3.1. Diseño fluido

El diseño fluido (o líquido) hace referencia a las páginas web que escalan y encajan su contenido automáticamente según el tamaño de la pantalla. El desarrollo es más sencillo que en responsive, ya que solo hay un diseño para todos los dispositivos, pero no garantiza una experiencia de usuario satisfactoria en todos ellos. El problema más evidente en este sentido lo vemos cuando el contenido de un diseño fluido se lee correctamente en la pantalla de un ordenador de sobremesa, y al escalarlo para su visualización en un smartphone, dicha lectura se complica debido al empequeñecimiento excesivo de los caracteres.

Una estrategia para solventar esta problemática es diseñar primero pensando en los dispositivos móviles: corriente llamada mobile first. De este modo, el escalado se hace de pequeño a grande y asegura la visibilidad en todos los dispositivos.

Lectura para ampliar:

Sobre el paradigma de diseñar primero para móviles: Wroblewski, L. (2011), Mobile First, Nueva York, A Book Apart.

1.3.2. Diseño responsive

El diseño responsive es un paradigma de diseño y desarrollo en el que una página web adapta su contenido y aspecto al tamaño de la pantalla y orientación en la que se accede. A diferencia del diseño fluido, hay más de un diseño líquido para un mismo proyecto, que se activan automáticamente al detectar un determinado tamaño de la pantalla.

La experiencia de usuario que se logra suele ser mejor, pues los usuarios lo perciben como si la web estuviese diseñada específicamente para el dispositivo y condiciones en que se muestra.

Figura 1 La revista Time es un buen ejemplo de diseño responsive (Imagen: cortesía de Josh Chan).

Lectura para ampliar:

Patrones de Navegación para diseño responsive:

http://bradfrostweb.com/blog/web/responsive-nav-patterns/

1.4. Aplicación híbrida

Una tercera opción son las aplicaciones híbridas. Son aplicaciones desarrolladas total o parcialmente con tecnología web, pero que en vez de ser ejecutadas por el navegador, se ejecutan en una aplicación nativa que las contiene, y por lo tanto pueden estar disponibles para descargar desde tiendas de aplicaciones.

2. Los usuarios y el contexto de uso

A diferencia de los entornos de escritorio donde el contexto –es decir, las condiciones en las que los usuarios interactúan– puede predecirse con más facilidad, los dispositivos móviles plantean un reto en este sentido. Ya que debido a su naturaleza portátil, su contexto es cambiante, y repercute en el uso que cómo usuarios hacemos.

Conocer sobre el contexto en el que se usará una web o aplicación móvil, en ocasiones puede resultar una tarea compleja, pues vienen determinados por múltiples factores. Cómo el lugar, los objetivos, el momento en que los usamos, la posición en que lo hacemos, durante cuánto tiempo, en qué entorno o del modo en que los usamos conjuntamente con otros dispositivos.

Fruto de la observación y de estudios diversos, existe información sobre los patrones de comportamiento y uso de los usuarios móviles, que nos permiten saber las peculiaridades de los usuarios móviles.

2.1. ¿Cómo somos los usuarios móviles?

Los usuarios de smartphones y tabletas presentamos cuatro rasgos comunes, que hay que tener en cuenta al diseñar productos para estos aparatos:

Nos distraemos: Los usuarios móviles no acostumbramos a prestar toda la atención a las aplicaciones o webs móviles que usamos, y solemos estar sometidos a constantes interrupciones durante nuestra interacción.

Somos imprecisos: Los dedos no son unos punteros de gran precisión, hecho que nos complica tocar unívocamente ciertos elementos de la interfaz táctil. Además los sistemas que basan su interacción con la voz de los usuarios, todavía están lejos de entender palabras o frases, como si de otra persona se tratara. Motivo por el cual la expresión oral de los usuarios deviene imprecisa.

No vemos bien: Poder usar estos dispositivos en movimiento conlleva que no veamos en detalle la pantalla, circunstancia que se acentúa si tenemos en cuenta las reducidas dimensiones de la misma.

No tenemos paciencia: Son pocas las aplicaciones que una vez instaladas en el dispositivo acaban siendo de uso habitual por el usuario. Ésta realidad es fruto en buena medida de las mínimas oportunidades que los usuarios concedemos a las aplicaciones: o nos seducen en los primeros instantes, o las dejamos de usar. Ya sea a favor de otra aplicación/web móvil, o para prestar atención a otro estímulo.

2.2. Diferencias de comportamiento entre usuarios de smartphones y tabletas

Las singularidades de ambos tipos de aparatos, conlleva una serie de comportamientos distintos en su uso:

| Smartphones | Tabletas
¿Dónde los usamos? | Tanto en casa, como fuera de ella. | Mayoritariamente en los hogares
¿En qué momentos fundamentalmente? | En los ratos libres y mientras miramos la televisión. | Viendo la televisión y en la cama.
¿Durante cuánto tiempo? | Las interacciones medias son de unos diecisiete minutos. Son interacciones fragmentadas. | Las interacciones medias son de una media hora. Son interacciones menos fragmentadas que en los smartphones.
¿En qué posición? | Cualquier posición. Cómoda e incómoda. | Posiciones cómodas. Por ejemplo, en el sofá.
¿Con quién los compartimos? | Nadie. Son dispositivos eminentemente personales. | Una misma tableta suele ser usada con más personas de nuestro entorno, como pueda ser la familia.

Lectura para ampliar:

- Wroblewski, L. (2011), Data Monday: Are Tablets Mobile Devices?, Mobile First, Nueva York, A Book Apart. http://www.lukew.com/ff/entry.asp?1571

- Nielsen, J. y Budiu, R. (2012), In the U.S., Tablets are TV Buddies while eReaders Make Great Bedfellows, Mobile Usability, Berkeley, New Riders. http://blog.nielsen.com/nielsenwire/?p=27702

3. Investigar sobre los usuarios y su contexto

Cada aplicación o web móvil es un caso a analizar, así que aunque dispongamos de la anterior información sobre dónde, cuándo y cómo los usuarios hacemos uso de los teléfonos inteligentes y tabletas, no dejan de ser un punto de partida para investigar sobre los usuarios y el contexto de uso del producto.

Las investigaciones son beneficiosas, tanto si el proyecto en cuestión ya es una realidad, si se está confeccionando, o bien si todavía solo es una idea.

En el campo de la Experiencia de Usuario, disponemos de una filosofía y metodología de diseño que sitúa a los usuarios en el centro de todo el proceso: el Diseño Centrado en el Usuario (DCU). Hay multitud de variantes en las fases a seguir durante el proceso del DCU, pero todas ellas se fundamentan en:

Conocer a los usuarios y su contexto.

Conceptualizar/Diseñar un producto según el conocimiento de estos usuarios.

Evaluar el diseño.

Iterar entre estas fases hasta –idealmente– lograr el mejor producto posible.

Para llevar a cabo cada una de estas fases existen variedad de técnicas, que se emplean unas u otras dependiendo de las características del proyecto y de los participantes en el mismo.

En referencia a los métodos que sirven para conocer a los usuarios y su contexto, se clasifican según el tipo de información que se obtiene en técnicas cualitativas, cuantitativas o cualitativas y cuantitativas.

Cualitativas:

Técnica | ¿En qué consiste?
Entrevista | Entrevistas individuales con usuarios.
Dinámica de grupo | Conversación moderada por el observador entre un grupo de usuarios.
Observación contextual | Observación de las personas en su contexto.
Shadowing (método de seguimiento) | Observación de los comportamientos de los usuarios en los distintos contextos en los que se desenvuelve en su cotidianidad. En esencia, consiste en observar al participante (o los participantes), siguiéndolo, como si el observador fuera su sombra.
Diario | Recopilación por parte del mismo participante de sus acciones, comportamientos, sensaciones, etc. Siguiendo las directrices que le sean marcadas pero sin ser observado por el investigador.
Recorrido cognitivo | Revisión por un experto según escenarios de uso.
Test con usuarios | Análisis del uso que hacen potenciales usuarios del producto interactivo.

Cuantitativas:

Técnica | ¿En qué consiste?
Cuestionario | Respuestas de usuarios a una lista de preguntas estructuradas.
A/B Testing | Análisis comparativo de dos versiones del proyecto o prototipo del mismo.
Logging | Análisis de la actividad de los usuarios registrada por un sistema informático.
Eyetracking | Análisis de del movimiento ocular de los usuarios durante el uso de un producto interactivo.

Cualitativas y Cuantitativas:

Técnica | ¿En qué consiste?
Análisis de la competencia | Análisis de productos que comparten similitudes con el proyecto en curso.
Card Sorting | Analizar cómo los usuarios clasifican la información.
Evaluación heurística | Revisión experta basándose en principios heurísticos.

Lectura para ampliar:

Sobre el análisis de la competencia en iPhone, extendible al resto de smartphones: Ginsburg, S. (2010), Designing the iPhone User Experience, Kendallville, Addison-Wesley, Capítulo 5.

Estos métodos de investigación que habitualmente se llevan a cabo en la metodología de Diseño Centrado en el Usuario para entornos de escritorio, son igualmente útiles para el caso móvil y no varían sustancialmente en su aplicación para un entorno de movilidad. No obstante existen dos métodos que resultan especialmente adecuados para conocer acerca de los objetivos, necesidades, motivaciones y capacidades de los usuarios en el contexto móvil: El método de seguimiento y el del diario.

Lectura para ampliar:

- Sobre el método de seguimiento: McDonald, Seonaidh, (2005), “Studying actions in context: a qualitative shadowing method for organizational research”, en: Qualitative Research, Vol. 5, Nº 4, 455-473.

- Sobre el método de diario: Martin, B., y Hanington, B. (2012), Universal Methods of Design, Beverly, Rockport, Capítulo 30.

4. Conceptualizar el producto

Con el objetivo de interpretar, entender y transmitir la información recopilada en la fase de investigación, disponemos de una serie de técnicas que nos sirven para modelar estos datos. Su empleo en entornos de escritorio y entornos móviles no comporta cambios significativos. Eso sí, debe prestarse especial atención a los distintos contextos de uso, que, tal y como se ha podido comprobar, pueden ser cambiantes y repercutir en el uso de los usuarios.

Las técnicas de modelado de usuarios que se emplean habitualmente en DCU son:

Técnica | ¿En qué consiste?
Personas | Descripciones de usuarios arquetípicos. Suelen incluir información sobre su biografía (edad, profesión, etc.), objetivos, comportamientos y necesidades.
Escenarios | Descripción de situaciones hipotéticas en las que los usuarios (o personas) hacen o harían uso del producto interactivo.
Flowcharts | Representación de los caminos que pueden tomar los usuarios en el uso del producto interactivo.
User journeys maps (o Costumer journey maps) | Visualización de las tomas de decisiones y experiencias (pensamientos, motivaciones, etc.) de los usuarios cuando interactúan con un producto interactivo. Pueden combinarse con las tres técnicas anteriores.

Lectura para ampliar:

- Sobre el valor de los user journeys maps en el campo de la Experiencia de Usuario: http://www.uxmatters.com/mt/archives/2011/09/the-value-of-customer-journey-maps-a-ux-designers-personal-journey.php

- Explicación sobre como confeccionar user journeys maps: http://www.ux-lady.com/diy-experience-map/

El siguiente paso consiste en conceptualizar cómo será la aplicación teniendo en cuenta toda la información procesada. Para ello disponemos de las técnicas siguientes:

Técnica | ¿En qué consiste?
Sketches | Primeros argumentos de diseño realizados a mano alzada. Pueden tomar formas diversas: pantalla comentada, viñetas de cómic, storyboards, etc.
Prototipo en papel | Prototipo del producto realizado sobre papel. Suele ser un paso previo a los prototipos estáticos o dinámicos. Aunque con la técnica del Mago de Oz pueden usarse para realizar tests con usuarios.
Prototipo estático | Prototipo desarrollado con una programa informático (herramientas de prototipado, de tratamiento de imágenes, tecnología web, aplicación de diseño de pantallas del SDK de desarrollo de la app, etc.) que muestra las pantallas del producto sin interactividad.
Prototipo interactivo | Prototipo desarrollado con una programa informático (herramientas de prototipado, de tratamiento de imágenes, tecnología web, aplicación de diseño de pantallas del SDK de desarrollo de la app, etc.) que muestra las pantallas del producto y se puede interactuar con él.

4.1. Sketches

En el caso móvil las técnicas de sketching son especialmente útiles. Al realizarlos se pueden combinar dibujos y texto, y sin necesariamente prestar atención a su estética. Ya que su principal objetivo es el de explorar cómo será el proyecto de forma rápida, pudiendo refinar los bocetos iterativamente. Otra de sus ventajas es que permiten plantear soluciones de diseño mostrando cómo los usuarios experimentarán su uso, conceptualizando sin ninguna pauta establecida ciertos aspectos de la interacción como por ejemplo la vibración, los gestos o el sonido.

Figura 2. Sketches de una aplicación para iPhone (Autor: Kurt Gannon).

Lectura para ampliar:

Introducción al uso de los storyboards: http://johnnyholland.org/2011/10/storyboarding-ux-part-1-an-introduction/

4.2. Prototipado

Posteriormente, y validados en mayor o menor mesura los diseños conceptualizados en los sketches, es preciso avanzar hacia la fase de prototipado. Los prototipos son modelos del producto final que permiten evaluar el diseño del mismo sin necesidad de desarrollar todo el producto. Así, es posible introducir repetitivamente cambios a un coste bajo.

Para el prototipado en dispositivos móviles, aparte de las herramientas habituales para el prototipado de productos y servicios de escritorio, pueden usarse las aplicaciones de diseño de pantallas de las que disponen los entornos de desarrollo (SDK). De esa forma se pueden aprovechar para las fases posteriores de programación.

5. Evaluar los diseños

Evaluar los diseños es una parte fundamental para determinar si el diseño creado es usable, y en un espectro más amplio si la experiencia de usuario que proporciona es satisfactoria. Esta evaluación puede llevarse a cabo de dos maneras: con los usuarios finales o sin ellos.

5.1. Test con usuarios

El test con usuarios nos permite evaluar la usabilidad de un producto interactivo, gracias a observar y analizar cómo usuarios reales interactúan con él.

Se acostumbra a asociar el test con usuarios a las etapas finales de evaluación de un prototipo, sin embargo, también es de gran utilidad en las primeras fases de investigación para evaluar un producto existente (análisis de la competencia).

En los entornos móviles, estas pruebas tienen unas peculiaridades:

5.1.1. La importancia (o no) del contexto

Realizar los test en el contexto no es siempre necesario. Dependiendo de la importancia y características del mismo los test pueden realizarse en laboratorio, en un contexto estático o en uno móvil.

La modalidad de laboratorio acostumbra a ser más sencilla de llevar a la práctica que las demás, pero no permite la observación en contexto. Puede ser útil para evaluar aplicaciones en las que el contexto no es determinante, o para evaluar ciertos aspectos de la interfaz en los que el contexto no influya, como por ejemplo el flujo de navegación.

Los test en contexto móvil permiten captar el uso de los usuarios en distintos contextos. Esta modalidad ofrece una observación de los usuarios teniendo en cuenta la naturaleza móvil. Sin embargo su complejidad para el registro hace necesario plantearse si en la evaluación el contexto cambiante tiene un protagonismo esencial para plantearse llevar a cabo éste tipo de test.

A medio camino de los test en laboratorio y los test en contexto móvil se encuentran los test en contexto fijo. Sabiendo o previendo el entorno en el que los usuarios harán uso de la aplicación o web móvil, puede trasladarse el test a ese lugar.

Modalidad
Ejemplos de productos para los que sería adecuado

Laboratorio
Juego de plataformas.

Arquitectura de la información de la web móvil de un ayuntamiento.

Contexto móvil
Aplicación de rutas en bicicleta. Aplicación de control de calorías ingeridas durante todo el día.

Contexto fijo
Aplicación para el control de asistencia de alumnos en una escuela.

Aplicación de guía para una exposición de arte.

Lectura para ampliar:

Artículo en que se comparan los test en laboratorio y los test en el contexto:

Kaikkonen, A., Kallio, T., Kekäläinen, A., Kankainen, A. & Cankar, M. (Noviembre / 2005), “Usability Testing of Mobile Applications: A Comparison between Laboratory and Field Testing”, Journal of usability studies, 1 (1), 4-16.

5.1.2. Mejor con los terminales de los usuarios

En los test con ordenadores de sobremesa, el tipo de terminal no tiene una incidencia importante en los usuarios. Y los resultados que se obtienen son esencialmente los mismos que si se hiciese el test en su ordenador habitual. Pero en el caso móvil el tipo de terminal sí tiene incidencia. Pues usar uno en que los participantes no estén habituados les exigirá aprender su uso, y la evaluación del producto interactivo en sí no se asemejará a su uso cotidiano.

5.1.3. Grabación de los test

La grabación de las pantallas mientras los usuarios hacen los test debe ser transparente, sin que este hecho interfiera en las evoluciones de los participantes, y que al mismo tiempo capte sus gestos.

Estos dos condicionantes son difíciles de satisfacer, pues en ciertas tiendas de aplicaciones no existen apps de grabación de pantalla, y las que hay no siempre solucionan al mismo tiempo las necesidades de registro de los test: grabación de la voz, cara de los participantes, vista en tiempo real, redacción de anotaciones.

Si es necesario instalar en los dispositivos de los participantes aplicaciones de este tipo, precisará superar su posible reticencia a tener instaladas aplicaciones que les graben en sus aparatos.

Otra opción es el uso de los sleds, que son construcciones formadas por una cámara que graba al terminal, y si se desea otra haciendo lo propio con el usuario. Estas estructuras permiten grabar usuario y pantalla, captar sus gestos y reacciones o con el software necesario ver el test en tiempo real. En su contra, los sleds pueden tener un impacto en el uso, pues estará condicionado (peso o movilidad) por la convivencia con la estructura.

Los sleds pueden comprarse ya hechos, o bien se puede seguir alguno de los muchos tutoriales existentes en la Red en los que explican cómo hacerse uno propio de forma económica.

Figura 3. Sled Mr. Tappy.

5.1.4. El Mago de Oz

Si nuestros prototipos están hechos en papel o bien no se les ha programado interactividad, una técnica que nos permite evaluarlos es la del Mago de Oz. En esta técnica el evaluador simula el comportamiento del sistema.

Este método también es de utilidad a la hora de evaluar interacciones difíciles de programar en un prototipo interactivo. Como por ejemplo las que se basan en el lenguaje natural del usuario.

Lectura para ampliar:

Sobre el método del Mago de Oz:

http://www.usabilitybok.org/wizard-of-oz

5.2. Evaluación heurística

La evaluación heurística (de usabilidad) consiste en inspeccionar detalladamente un producto interactivo según una serie de principios de usabilidad. Reglas que deben tenerse en cuenta también durante el proceso de diseño.

Hay varios de estos principios que han sido publicados desde finales de la década de los ochenta hasta hoy por diversos autores del mundo de la Interacción Persona-Ordenador. Entre los que destacan las “Ocho reglas de oro de Shneriderman” o los “Diez principios heurísticos de Nielsen”, que aunque dejan fuera del alcance algunos aspectos de la interacción móvil, son perfectamente aplicables en dicha área.

Lectura para ampliar

- Sobre los diez principios heurísticos de Nielsen:

Nielsen, J. (1994), “Enhancing the explanatory power of usability heuristics”. En: Proceedings on the ACM CHI’94 Conference, Boston, (24-28 de abril, pags. 152-158).

- Las ocho reglas de oro de Shneiderman: http://faculty.washington.edu/jtenenbg/courses/360/f04/sessions/schneidermanGoldenRules.html

Más recientemente autores como Bertini, Gabrielli y Kimani (Bertini, Gabrielli y Kimani, 2006) o Savio y Braiterman (Savio y Braiterman, 2007) han publicado guías heurísticas específicas para el diseño móvil. Y de igual forma lo han hecho los equipos de diseño y experiencia de usuario de los principales sistemas operativos en sus guías de diseño.

Lectura para ampliar:

- Artículo con los diez principios de Savio y Braiterman: Savio, N. & Braiterman, J. (2007), Design Sketch: The Context of Mobile Interaction.

- Los heurísticos de Bertini, Gabrielli y Kimani: Bertini, E., Gabrielli, S. y Kimani, S. (2006), “Appropriating and Assessing Heuristics for Mobile Computing”, Proceedings of the International Conference in Advanced Visual Interfaces (AVI), Venecia, 23-26/mayo/2006.

Una estrategia eficaz para evaluar heurísticamente aplicaciones o webs móviles es la de combinar los principios heurísticos clásicos teniendo en cuenta las peculiaridades móviles. Para ello, a continuación se propone una guía heurística para la experiencia de usuario móvil.

5.2.1. Guía heurística para la experiencia de usuario móvil

Con el fin de disponer de unas pautas para crear mejores experiencias de usuario para dispositivos móviles, se presentan diez puntos a seguir para ello.

Punto 1: Causar una buena impresión

Causar una buena impresión cuando un usuario empieza a utilizar una aplicación o web móvil es crucial. Si un usuario no experimenta como mínimo un primer contacto satisfactorio, comportará probablemente que la abandone a favor de otra.

Punto 2: Simplificar la navegación

La navegación el caso móvil debe ser lo más sencilla e intuitiva posible. Propiciando que los usuarios sean capaces de acceder a los contenidos que precisan de una forma evidente.

Punto 3: Facilitar la lectura

Cuanto menor es la pantalla en la que se lee un contenido, más costosa es su comprensión. Además si el lector está moviéndose o prestando atención a otros estímulos a parte de la aplicación o web móvil, la simplificación de la lectura, la minimización de los elementos que aparecen en la interfaz y la reducción de la carga cognitiva adquieren un protagonismo especial en el caso móvil. En esta misma línea, los diseños deben estar preparados para que los usuarios, después de interrumpir la atención al dispositivo, puedan proseguir su actividad en éste sin esfuerzo.

Punto 4: Tamaño y separación para unos dedos imprecisos

En las interfaces táctiles interactuamos con nuestros dedos. Por un lado esto nos da una sensación más natural en la interacción, pero por otro lado perdemos precisión (en comparación, por ejemplo con el ratón del ordenador). Para minimizar la imprecisión de nuestros dedos, los elementos de las interfaces táctiles deben ser lo suficientemente grandes y estar dispuestos con suficiente separación entre sí.

Punto 5: Personalizar

Con el objetivo de ofrecer una experiencia lo más acorde con los objetivos y necesidades de cada persona, la personalización toma una especial notoriedad en los dispositivos móviles.

Punto 6: Agilizar la entrada de datos

En comparación con un ordenador de sobremesa, la escritura en dispositivos móviles es incómoda. Por esta razón hay que minimizar la entrada de datos por parte de los usuarios con el teclado, y en su defecto proporcionar atajos para que la escritura sea mínima.

Punto 7: Asegurar la visibilidad

En los dispositivos de interfaz táctil se actúa directamente sobre la pantalla. Lo que significa que en mayor o menor medida hay partes de esta que quedan ocultas. Se requiere, pues que las partes que se oculten no impidan una fluida interacción del usuario con la aplicación o web móvil.

Punto 8: Usar estándares

Emplear convenciones y gestos estándar facilita el uso de la aplicación o web móvil. Ya que los usuarios esperan que al actuar de una determinada forma sobre el sistema, éste responda según esperan.

Punto 9: Seguir las guías de diseño

Los principales sistemas operativos móviles disponen de unas guías de diseño para que los diseñadores consigan confeccionar las mejores aplicaciones según las características y estilo de cada sistema.

Punto 10: Aprovechar las funcionalidades del dispositivo

Los smartphones y tabletas disponen de multitud de funcionalidades, que varían según el terminal: teléfono, cámara, micrófono, altavoces, vibración, cambio de orientación, geolocalización, brújula, NFC, bluetooth, etc. Utilizar estas funcionalidades de forma adecuada en las aplicaciones o web móviles puede tener un impacto significativo la experiencia de uso.

6. Conclusiones

Una buena experiencia de usuario debe ser la piedra angular de cualquier proyecto móvil si queremos que sobresalga entre las millones de opciones que los usuarios tienen a su alcance.

Para ello no basta en hacer que las interfaces sean usables a pesar de su tamaño y condición táctil. Además demanda un conocimiento amplio de las opciones que la tecnología actual permite, características de los dispositivos y comportamientos de los usuarios, como nunca antes en otros sistemas interactivos.

En este capítulo se han expuesto unos patrones de comportamiento de los usuarios móviles, basados estudios empíricos y observaciones, con el objetivo de contextualizar el uso de estos dispositivos, y para servir de referencia en el proceso de Diseño Centrado en el Usuario (DCU).

Se han explicado ciertos matices y recomendaciones a considerar en la aplicación del DCU para el caso móvil en cada una de las fases de investigación, conceptualización y evaluación. Haciendo énfasis en los métodos de investigación que permiten captar la naturaleza del contexto móvil, la utilidad de los métodos de sketching o distintas consideraciones a tener en cuenta a la hora de realizar los test con usuarios.

Finalmente se ha presentado la “Guía heurística para la experiencia de usuario móvil” con la intención de definir un listado de puntos que los productos interactivos móviles deben satisfacer para pretender lograr una experiencia de usuario satisfactoria.

7. Obras recomendadas

Ballard, B. (2007), Designing the mobile user experience, West Sussex, Wiley.

Clark, J. (2010), Tapworthy, Sebastapol, O'Reilly.

Ginsburg, S. (2010), Designing the iPhone User Experience, Kendallville, Addison-Wesley.

Hinman, R., (2012), The Mobile Frontier, Nueva York, Rosenfeld Media.

Holtzblatt, K., Burns Wendell, J. y Wood, S. (2005), Rapid Contextual Design, San Francisco, Morgan Kauffmann.

Jones, M. y Marsden, G. (2006), Mobile Interaction Design, West Sussex, Wiley.

Nielsen, J. y Budiu, R. (2012), Mobile Usability, Berkeley, New Riders.

Wroblewski, L. (2011), Mobile First, Nova York, A Book Apart.

8. Bibliografia

Almirall, J., Diseño Centrado en el Usuario para dispositivos móviles. Material docente de la Universitat Oberta de Catalunya.

Ballard, B. (2007), Designing the mobile user experience, West Sussex, Wiley.

Bertini, E., Gabrielli, S. y Kimani, S. (23-26/maig/2006), “Appropriating and Assessing Heuristics for Mobile Computing”, Proceedings of the International Conference in Advanced Visual Interfaces (AVI), Venecia.

Google (Agosto 2012), “The New Multi-screen World: Understanding Cross-platform Consumer Behavior”.

Granollers, T. (2004), “MPIu+a. Una metodología que integra la ingeniería del software, la interacción persona-ordenador y la accesibilidad en el contexto de equipos de desarrollo multidisciplinares”. Obtenido de http://hdl.handle.net/10803/812

Martin, B. y Hanington, B. (2012), Universal Methods of Design, Beverly, Rockport.

Mor, E. y Garreta, M., Disseny Centrat en l'Usuari. Material docente de la Universitat Oberta de Catalunya.

Moule, J. (2012), Killer Ux Design, Melbourne, Sitepoint.

Nielsen (19 de mayo de 2011). Nielsen Wire. Recuperado el 17 de enero de 2013, de “In the U.S., Tablets are TV Buddies while eReaders Make Great Bedfellows”: http://blog.nielsen.com/nielsenwire/?p=27702

Nielsen, J. y Budiu, R. (2012), Mobile Usability, Berkeley, New Riders.

O2 (22 de junio de 2012). Making calls has become fifth most frequent use for a Smartphone for newly-networked generation of users. Recuperado el 27 de agosto de 2012, de O2 News Center: http://news.o2.co.uk/Press-Releases/Making-calls-has-become-fifth-most-frequent-use-for-a-Smartphone-for-newly-networked-generation-of-users-390.aspx

Reimann, R. y Cronin, D. (2007), About Face 3: The essentials of Interaction Design, Indianápolis, Wiley.

Savio, N. y Braiterman, J. (Juny/2007), “Design Sketch: The Context of Mobile Interaction”.

Wroblewski, L. (25 de junio de 2012). LukeW. Recuperado el 17 de enero de 2013, de “Data Monday: Are Tablets Mobile Devices?”: http://www.lukew.com/ff/entry.asp?1571

Wroblewski, L. (2011), Mobile First, Nova York, A Book Apart.

Disolución de fronteras: Tecnologías sociales11 y participación en el diseño

Texto original: Penny Hagen y Tony Robertson (Versión en inglés en el sitio del Interactión Design and Human Practice Laboratory, http://research.it.uts.edu.au/idhup/)

Traducción: Sebastián Betti

Penny Hagen ayuda a las organizaciones a aplicar enfoques afines al diseño para el diseño de estrategias, programas, políticas y servicios. En los últimos 15 años Penny ha diseñado y dirigido una serie de proyectos de codiseño en Australia y Nueva Zelanda, en múltiples sectores. Sus roles anteriores incluyen Directora de Proyectos de la agencia de diseño social Digital Eskimo, Sídney, y Directora de Experiencia de Digital Arts Network (DAN) en Auckland. Tiene un doctorado en Diseño Participativo y es profesora visitante en la Universidad de Tecnología. Le apasiona el valor de codiseño para la mejora de los resultados sociales, y brinda formación y tutoría a equipos y organizaciones que desean aumentar su impacto a través de la adopción de enfoques participativos.

Penny Hagen, Facultad de Ingeniería y TI de la Universidad de Tecnología de Sídney penny@smallfire.co.nz

Toni Robertson, Facultad de Ingeniería y TI de la Universidad de Tecnología de Sídney toni@it.uts.edu.au

Resumen

El énfasis en la participación en las tecnologías de medios sociales desafía algunos de nuestros supuestos tradicionales sobre el papel de los usuarios y los diseñadores en el diseño. También pone de manifiesto algunas de las limitaciones y suposiciones sobre el diseño de nuestros modelos y métodos tradicionales. Con base en una revisión de la práctica emergente presentamos cuatro perspectivas sobre el diseño en el contexto de las tecnologías de medios sociales. Con la presentación de esta “configuración de campo” buscamos contribuir al trabajo en curso sobre la naturaleza de la participación y el diseño en el contexto de las tecnologías de medios sociales. Prestamos particular atención a las formas de reasignar y redistribuir las funciones y responsabilidades en el diseño. Conforme se disuelven las fronteras tradicionales entre el diseño y el uso y el diseñador y el usuario, el diseño es cada vez más público. En el contexto de las tecnologías de medios sociales, el diseño se expone más y más a la intemperie.

Palabras clave:

Métodos de diseño, innovación abierta, diseño participativo, tecnologías de medios sociales, creación de prototipos, crowdsourcing.

Clasificación ACM:

H5.m: Interfaces de información y presentación (por ejemplo, HCI): Misceláneas.

Introducción

El tema de la participación se revitaliza en el diseño y la investigación de diseño (Binder y otros, 2008 p. 1).

Desde una perspectiva de diseño, las tecnologías de medios sociales presentan desafíos a los diseñadores, así como oportunidades. Permiten nuevas formas de participación de las personas en el diseño de productos y servicios y ofrecen nuevos canales por los que las empresas pueden comunicarse con los usuarios actuales y potenciales.

Como sugiere la cita de apertura, el tema de la participación en el diseño recibe una afluencia masiva de energía proveniente de una variedad de fuentes. Se replantea a los usuarios como codiseñadores, cocreadores y codesarrolladores. Las tecnologías de medios sociales desempeñan un papel fundamental en la motivación de este discurso.

Existe un acuerdo generalizado en que son necesarios nuevos enfoques para tener en cuenta la diversificación de contextos del diseño de la tecnología, de los que las tecnologías de medios sociales son una parte. Sin embargo, todavía estamos en el proceso de comprensión y en el desarrollo de tácticas y marcos apropiados (Lee, 2008).

Tanto profesionales como investigadores están comenzando a encontrarse con la capacidad limitada de los métodos de diseño de interacción existentes para dar cuenta de los nuevos espacios sociales de la tecnología de diseño, por ejemplo (Hart y otros, 2008, Holzapfel, 2008, Isbister y Höök, 2009). Además, las historias de éxito de las empresas de software social que han tenido un enfoque “probar y ver qué pasa”, por ejemplo (Merholz, 2006, Porter, 2006) podrían interpretarse como un desafío para el valor de la participación temprana en el diseño. En lugar de sugerir un papel menor para los métodos centrados en el usuario, nosotros defendemos la posición de que, como siempre, hay que preguntarse qué tipo de métodos de diseño son apropiados en este contexto.

En este trabajo esperamos contribuir a un debate sobre la naturaleza de la participación en el contexto de las tecnologías de medios sociales. El trabajo de este artículo no consiste en establecer definiciones, sino más bien hacer “una composición de campo”. Robertson y otros (2006) sugieren que las preguntas sobre la participación deben plantearse en el contexto en el que se diseñan, se construyen y utilizan determinadas tecnologías. En este trabajo fundamentamos nuestra discusión a través de una revisión de las tendencias actuales en la investigación y la industria. Mediante la observación de los cambios actuales en la práctica, es nuestra intención contribuir a una mejor comprensión de la naturaleza de la participación y el diseño en el contexto de las tecnologías de medios sociales.

Esta no es una revisión exhaustiva, sino que ofrece una vista filtrada de las tendencias y conceptos que hemos observado en el curso de nuestra propia investigación y que esperamos sea útil para otros investigadores y profesionales. Basamos nuestros ejemplos en una revisión de la literatura reciente sobre diseño participativo, así como en estudios de caso de la industria. También nos basamos en términos generales de la literatura reciente en HCI y de diseño que se ocupa de los cambios en las prácticas de diseño relacionadas con las tecnologías de medios sociales.

El artículo comienza con una definición de las tecnologías de medios sociales y el paisaje cambiante de diseño que estas representan. A continuación, agrupamos y describimos cuatro perspectivas sobre el diseño en el contexto de las tecnologías de medios sociales, con base en las tendencias actuales de la investigación y la práctica. Cada una de ellas permite la participación en el diseño de diferentes maneras. Algunas eluden los métodos tradicionales de diseño centrado en el usuario, mientras que otras los extienden. Tomando las cuatro perspectivas como puntos de referencia, luego reflexionamos sobre la forma cambiante del diseño. Hacemos especial hincapié en las formas de reasignación y redistribución de roles y responsabilidades en el diseño. También identificamos algunas de las preguntas que surgen de estos cambios y apuntamos a potenciales líneas de trabajo futuro.

Tecnologías sociales: una definición

Las tecnologías de medios sociales se refieren a las combinaciones de herramientas y sistemas móviles y en línea, que permiten y buscan la participación y las aportaciones de los usuarios. Como ejemplos podemos citar los SMS, Facebook, MySpace, Flickr, Twitter, YouTube y Digg, los blogs personales y las plataformas de debate, así como sitios de comunidad o de campaña más localizados. Estos sistemas son efectivamente contenedores o andamios que adquieren forma en función de la participación y de las contribuciones de los usuarios.

Si bien en este trabajo utilizamos el término “tecnologías sociales”, otras frases populares para denominarlas incluyen: software social (Boyd, 2009a), medios sociales (Näkki y otros, 2008) y Web 2.0 (O’ Reilly, 2005). Al calificar el término software social, Boyd (2007b) afirma: “el software social es un movimiento, no simplemente una categoría de tecnologías... ciertamente no es completo y como categoría, es difícil de delimitar”.

La definición de medios sociales que da el instituto finlandés de investigación, VTT, se refiere a los medios sociales como conjunto de herramientas y como modus operandi (Heinonen y Halonen, 2007). Es importante destacar que ambas definiciones refuerzan el énfasis dual en las tecnologías y en las prácticas sociales.

Aquí utilizamos el término tecnologías sociales porque hace clara alusión a la naturaleza socio-técnica del fenómeno que intentamos describir. Además, puede abarcar combinaciones de tecnologías móviles y/o en línea, indicando potencialmente algo más amplio que una sola pieza de software.

Tecnologías sociales: un fenómeno

El fenómeno de las tecnologías de medios sociales puede caracterizarse por una mayor participación social en contextos mediados (Boyd, 2007a). Términos como contenido generado por usuarios (Pierson y otros, 2008), crowdsourcing (Howe, 2008) y medios ciudadanos (Cruickshank y Evans, 2008) se refieren a las nuevas formas de participación social con el apoyo de las tecnologías de medios sociales.

De hecho, la facilidad con la que ahora podemos conectarnos, comunicarnos, producir, compartir, reproducir, localizar y distribuir información ha tenido, y sigue teniendo, un impacto profundo en nuestras prácticas sociales, culturales y tecnológicas (Boyd, 2009a, Shirky, 2008). Esta transformación ha sido posible gracias a la amplia disponibilidad y acceso a la tecnología. Lo más importante es que esto ha supuesto el desplazamiento en la apropiación de la tecnología desde las organizaciones y las empresas, hacia la gente común (Battarbee, 2003; Shirky, 2008).

Para los diseñadores, las tecnologías de medios sociales se convierten en una herramienta con la que diseñamos, en el tema de nuestro diseño y el contexto en que diseñamos. El énfasis en la participación en las tecnologías de medios sociales desafía algunos de nuestros supuestos tradicionales sobre el papel de los usuarios y los diseñadores. También expone algunas de las limitaciones y suposiciones sobre el diseño que se encuentra dentro de nuestros modelos y métodos tradicionales.

Retos para diseñar

Los diseñadores que intentan aplicar los métodos convencionales en el contexto de las tecnologías de medios sociales se enfrentan a varios retos. Por ejemplo, los métodos contextuales tradicionales suponen la capacidad de identificar y acceder al contexto de uso. Pero los usuarios de las tecnologías sociales son diversos y están geográficamente distribuidos (Bergvall-Kåreborn y Ståhlbröst, 2008); el uso es móvil, doméstico y está imbricado en contextos sociales complejos, que están en curso (Bødker 2006, Isbister y Höök, 2009); y nuestros usuarios son potencialmente anónimos o desconocidos (Clement, 2008; Ehn, 2008). También es muy posible que al principio del proceso de diseño no exista una comunidad claramente identificable de usuarios, sino que deba “crearse” como parte del proyecto (Disalvo y otros, 2007).

Además, se puede argumentar que las variables de uso son tan complejas, situadas y dependientes de las actividades de los demás, que la retroalimentación sobre su uso sólo cobra sentido en su contexto. Los métodos actuales para la creación de prototipos y pruebas antes de la liberación del software pueden ser inadecuados para la simulación de los futuros contextos de uso (Holzapfel, 2008). Esto podría entenderse como una cuestión de fidelidad. Como señalan Isbister y Höök: “No podemos depender de la reutilización de metáforas y estrategias de interfaz pre-existentes porque hay demasiadas variables nuevas de uso...” (2009 p.1).

Por último, los métodos de diseño centrado en el usuario (DCU), desarrollados en el contexto de las tecnologías corporativas y laborales, no es de esperar que tengan en cuenta las motivaciones para el uso como se hace con las tecnologías de medios sociales. Esto es particularmente cierto cuando los efectos de estas tecnologías son en sí mismos “emergentes”; por ejemplo Flickr, el SMS, Twitter y Facebook cumplen funciones radicalmente diferentes de las previstas en un principio por sus diseñadores.

Las tecnologías de medios sociales apoyan conductas como “pasar el tiempo” (Hart y otros, 2008), “perder el tiempo” (Horst y otros), “mirar, buscar, mantenerse al día” (Joinson, 2008). El uso a menudo está motivado por experiencias o factores emocionales como una experiencia compartida o intereses compartidos (Battarbee y Kurvinen, 2003, Hess y otros, 2008). La atención se centra en conectar e interactuar en torno de los objetos sociales (Engeström, 2005) y con otras personas, en lugar de hacerlo con el sistema (Shirky, 2003). Como destacan Hart y otros (2008) en su investigación, el apoyo a estos comportamientos no fue la motivación subyacente de criterios clásicos del DCU como las 10 heurísticas de Nielsen.

Es este tipo de desafíos lo que motivó la siguiente revisión de la forma en que tanto profesionales como investigadores están respondiendo a algunas de estas cuestiones, con especial énfasis en el apoyo a la participación en el diseño. En la siguiente sección repasamos las tendencias de la práctica de diseño actual que están surgiendo como resultado del, y en respuesta al, carácter participativo de las tecnologías de medios sociales.

Diseño y participación

Las categorías y los ejemplos que se presentan a continuación no son exhaustivos. Más bien son agrupaciones sueltas que se superponen y se cruzan. Juntos representan cuatro perspectivas de muy alto nivel sobre el diseño en el contexto de las tecnologías de medios sociales. En los dos primeros, “Iteración” y “Surgimiento”, las tecnologías de medios sociales son el tema para el diseño. En los dos posteriores, “Fuente” y “Apertura”, las tecnologías de medios sociales son herramientas para el diseño. Utilizamos una estrategia similar para agrupar y describir las tendencias que la utilizada en (Hagen y otros, 2005).

La Tabla 1 presenta un resumen de los enfoques y ejemplos, con una descripción más completa de cada uno en los apartados siguientes.

Modo | Descripción | Ejemplos
Tecnologías de medios sociales como tema para el diseño
Iteración | Se libera software mediante iteraciones con base en retroalimentación implícita y explícita. | (Boyd, 2007b; Burka, 2008; Porter, 2006; Sinha, 2007)
Surgimiento | Se liberan prototipos de semilla para posibilitar la coevolución comunitaria mediante el uso y la retroalimentación. | (Botero y Saad-Sulonen, 2008; Redhead y Brereton, 2008; Twidale y Floyd, 2008)
Tecnologías de medios sociales como herramienta de diseño
Recurso | Las tecnologías de medios sociales apoyan la tercerización de las ideas de diseño a los miembros del público (el recurso); las ideas aportadas por el usuario pueden conformar la base del diseño. | (Brabham, 2008; Füller y otros, 2006, Redesignme, 2009; Thredless, 2009; Wepc, 2009)
Apertura | Las tecnologías de medios sociales se utilizan para abrir el tradicional proceso de diseño DCU, posibilitando una forma de diseño comunitario conforme los usuarios aportan ideas de diseño y retroalimentación en varios niveles. | (Boulton, 2008, Hess y otros, 2008, Näkki y otros, 2008)

Tabla 1 – Resumen de enfoques de diseño.

Iteración

Figura 1. El diseño se itera mediante la participación en el uso.

En el enfoque “Iteración” los miembros de la comunidad participan en el diseño mediante el uso y la retroalimentación que aportan sobre un sistema después de su lanzamiento. Pueden ocurrir cambios en el diseño en respuesta a las peticiones del usuario, o como resultado de la observación de la forma en que los usuarios se apropian de la tecnología o de la forma en que interactúan con la misma (Boyd, 2009b). Myspace (Boyd, 2007b), Netflix (Porter, 2006), Digg (Burka, 2008) y Slideshare (Sinha, 2007) son los principales servicios web sociales que han desarrollado e iterado su software de esta manera.

El enfoque “Iteración” podría describirse como una forma de participación fortuita o casual resultante de la naturaleza de las tecnologías de medios sociales y de los cambios recientes en las prácticas de la tecnología. Para esto contribuyen factores como la aparición de servicios de Internet (de los que las tecnologías de medios sociales forman parte), la prominencia del software de código abierto y un desplazamiento hacia la programación rápida o ágil. En contraste con los métodos en cascada que tienen una gran fase de diseño inicial, el énfasis está en la implementación temprana y continua para agregar o quitar rápidamente características y correcciones (O'Reilly, 2005). Los usuarios se convierten en codesarrolladores y los sistemas se consideran servicios, no productos (ibídem).

Se puede pensar y prever de forma activa la participación en las iteraciones de diseño mediante versiones beta (o incluso mediante betas perpetuas) (O'Reilly, 2005). Pueden existir también canales formales de retroalimentación persistentes y en línea como por ejemplo, foros, cuentas de Twitter, etc. Alternativamente, la participación puede ocurrir en respuesta a reacciones negativas del público a las decisiones de diseño de la compañía. Se han producido algunas “revueltas de usuarios” de escala histórica, por ejemplo en Twitter (Corbin, 2009), Facebook (Spool, 2007) y Friendster (Boyd, 2005). En parte, como resultado de estos incidentes, las empresas han llegado a comprender mejor la necesidad de trabajar con su comunidad sobre los cambios de diseño. Si bien un enfoque iterativo pudo haber sido inicialmente una respuesta técnica a la naturaleza de los servicios web, en muchos casos esto se ha transformado en formas más sofisticadas de participación de los usuarios y de consultas posteriores al lanzamiento.

Surgimiento

Figura 2. El diseño surge a través de la participación.

El enfoque “Surgimiento” se inspira en la filosofía del desarrollo rápido, pero se centra en el uso de prototipos experimentales como punto de partida para explorar las prácticas y los usos (Botero y Saad-Sulonen, 2008; Redhead y Brereton, 2008; Twidale y Floyd, 2008). Las fases de diseño se mezclan con las fases de implementación (Twidale y Floyd, 2008). Por ejemplo, Redhead y Brereton (2008) desplegaron el prototipo de un tablero de notificaciones electrónicas en una comunidad. Luego el prototipo evolucionó in situ, en respuesta al uso y la retroalimentación de la comunidad.

El prototipado de retazos (patchwork) sigue un enfoque similar, con base en la combinación de herramientas de código abierto, código local y mashups de servicios existentes (Twidale y Floyd, 2008). Se trabajan juntos unos prototipos rudimentarios que de inmediato son integrados y utilizados como parte de la práctica diaria; es una manera fácil de apoyar la participación real de usuarios en el uso real (Twidale y Floyd, 2008). Es importante destacar que Jones y otros (2007) señalan que la creación de prototipos de retazos se observó como un fenómeno surgido de la práctica, en lugar de ser un método diseñado a priori. Desde entonces, hay investigadores que forman programas en torno a este enfoque.

Botero y otros (2008) también adoptaron un enfoque similar pero deliberado de “investigación viva” en el desarrollo del software Urban Mediator. Utilizaron prototipos de semillas en un proceso de codescubrimiento con la comunidad. En lugar de llevar a cabo evaluaciones de usabilidad tradicionales de componentes de software aislados, Botero y Saad-Sulonen (2008) resignificaron el software existente para crear “intervenciones concretas” que pudieran ser evolucionadas en conjunto.

Twidale y Floyd (2008) argumentan que este enfoque solo existe como resultado de la ecología actual de tecnologías de la información; el software social se presta para el despliegue de prototipos simples que pueden ser modificados y evolucionados mediante la propia retroalimentación (Brereton y Buur, 2008). Como predijo Lievrouw (2006), la reconfiguración de herramientas existentes se está convirtiendo en un tema clave de diseño en el nuevo espacio de comunicación.

Metodológicamente, el enfoque “Surgimiento” también puede vincularse con el diseño participativo (Schuler y Namioka, 1993) y con los movimientos de apoyo al desarrollo con usuarios finales, por ejemplo (Fischer y Giaccardi, 2006). Dentro de este enfoque existe la intención de desarrollar software con usuarios, en el uso. El diseño está guiado por las necesidades que surgen de la comunidad y que llegan a ser articuladas y visibles a través de su uso.

Recurso (tercerizado)

Figura 3. El diseño inicial terceriza las ideas al público (el recurso).

El enfoque “Recurso” hace hincapié en el desplazamiento hacia la participación pública en la ideación del diseño y la innovación. El énfasis de “Recurso” está puesto en el formato de convocatoria abierta de crowdsourcing, un modelo de resolución distribuida de problemas (Brabham, 2008). El crowdsourcing hace uso de los intereses y el esfuerzo de la gente común, a fin de lograr actividades que de otro modo podrían haber sido realizadas por proveedores o contratistas (Howe, 2006).

Por ejemplo, las camisetas que vende la empresa threadless.com han sido diseñadas por miembros del público. Cualquier persona puede presentar un diseño y los diseños que reciben calificaciones más altas, de parte de otros miembros de la comunidad en línea, se ponen en producción (Threadless, 2009). Redesignme.com y WEPC son versiones empresariales que fomentan las contribuciones de diseño de los miembros del público. Las contribuciones pueden ser discutidas y clasificadas por otros miembros y potencialmente van a influir en los diseños futuros. Doritos y Converse han adoptado un enfoque similar aprovechando la popularidad de los videos generados por los usuarios, haciendo que los miembros del público creen anuncios publicitarios de productos (Howe, 2008).

Metodológicamente, los enfoques “Recurso” están vinculados al modelo de negocio de la innovación abierta, que anima a las empresas a buscar ideas en fuentes externas (Chesbrough, 2003). La innovación abierta promueve una forma de codiseño o cocreación con los usuarios y anima a las empresas a aprovechar la innovación impulsada por el usuario (Von Hippel, 2001). La escala y la disponibilidad de medios sociales están reduciendo las barreras a la participación pública en los procesos de innovación. También están trastocando –y en algunos casos han eludido– al proceso de diseño de interacción tradicional y a sus profesionales usuales.

Apertura

Figura 4. La comunicad participa a través del diseño.

Los enfoques “Apertura” también aprovechan el potencial del crowdsourcing y la innovación abierta que son posibles gracias a las tecnologías de medios sociales. El énfasis de “Apertura” está en la apropiación de los medios sociales como forma de abrir el proceso de DCU tradicional a la comunidad. Se invita a los miembros del público a participar y contribuir en el diseño, el análisis, la toma de decisiones y la evaluación. La participación asíncrona en iteraciones de diseño como ideación, cardsorting, wireframing y prototipos están mediadas y facilitadas a través de plataformas en línea.

Por ejemplo, SOMED (medios sociales en la intersección de los mundos físicos, digitales y virtuales) es un proyecto de investigación de Finlandia que ha identificado el potencial de utilizar las redes sociales para apoyar formas abiertas y distribuidas de participación en el diseño (Näkki y Virtanen, 2007). Su laboratorio en línea, Owela, hace uso de diversas herramientas de medios sociales para permitir la participación en distintas fases del diseño (Näkki y otros, 2008).

El rediseño comunitario de drupal.org (el sitio web que representa el sistema de gestión de contenido de código abierto Drupal) fue un ejemplo radical de apertura del proceso de diseño mediante el uso de tecnologías de medios sociales (Boulton, 2008). Boulton y Reichelt fueron contratados como diseñadores para dirigir y facilitar el proceso, sin embargo, el diseño en sí debía ser abierto en consonancia con el espíritu de esa comunidad. Boulton y Reichelt trabajaron con la comunidad, experimentando diferentes maneras de crear un proceso de diseño abierto.

Si bien utilizaron los métodos estándar del DCU, la naturaleza de la participación fue muy diferente. Los miembros de la comunidad participaron en masa, en forma distribuida y asíncrona, y en actividades de diseño a distancia (por ejemplo, 70 cardsortings en 2 días). Además, en lugar de dar retroalimentación sobre los diseños, los miembros de la comunidad aportaron sus propios wireframes. A fin de facilitar la colaboración y la discusión en torno a ambos conceptos y procesos, Boulton y Reichelt utilizaron sus blogs personales, así como plataformas como Twitter, Flickr y YouTube. Encontraron que las diferentes herramientas cambiaron significativamente el alcance de la conversación y permitieron diferentes tipos de entrada y dieron lugar a distintas conversaciones (Reichelt, comunicación personal).

Los ejemplos “Apertura” se caracterizan por un compromiso en permitir una mayor participación y una mayor transparencia en el proceso de diseño a través de medios mediados. El enfoque “Apertura” combina el compromiso de diseño participativo (Schuler y Namioka, 1993) con el enfoque transparente guiado por la comunidad que está personificado en el movimiento del software de código abierto. Como señala Ehn (2008), este movimiento es una fuente creciente de inspiración para quienes están interesados en la participación y la apertura del diseño.

Discusión

Cada una de las perspectivas sobre el diseño presentadas anteriormente anticipa y permite la participación de diferentes maneras, potencialmente complementarias. Los enfoques “Iteración” y “Surgimiento” enfatizan el diseño en uso, mientras que “Recurso” y “Apertura” sugieren un proceso de diseño más público. Estas tendencias y actividades se pueden interpretar de varias maneras. En la siguiente discusión reflexionamos sobre la forma cambiante del diseño y el impacto de los cambios correspondientes, en los roles y responsabilidades de los diseñadores y usuarios. De este modo, llegamos a algunas de las preguntas planteadas por los investigadores y profesionales que utilizan estos enfoques.

Relaciones de diseño y uso

Figura 5. Fases lineales de diseño, construcción y uso.

La figura 5 representa un proceso de diseño de interacción tradicional que sigue un proceso lineal de diseño, construcción y luego uso. Aunque se trata, por supuesto, de una visión demasiado simplista del proceso de diseño, en su interior hay algunas suposiciones sobre el diseño que han tenido una influencia significativa en la mayoría de nuestros enfoques actuales. La primera es que el diseño precede al uso (Hess y otros, 2008; Ingbert y otros, 2007). La segunda es que el objetivo de la fase de diseño es el desarrollo de un producto relativamente final (Davis, 2008) (ver Figura 6). Estas suposiciones crean ciertas condiciones en torno a la forma en que se puede apoyar la participación en el diseño.

Figura 6. Interpretación del Diseño Centrado en el Usuario de los autores con base en Preece y otros (2002).

Los enfoques “Iteración” y “Surgimiento” marcan un quiebre en la noción de diseño como proceso lineal mediante la fusión de las fases de diseño y uso. Las actividades de diseño se redistribuyen a lo largo de todo el ciclo de vida del diseño (Ye y Fischer, 2007). En la medida en que esto sucede, se funden los límites convencionales entre el diseño y el uso.

Extender el diseño en uso

Como diseñadores, es posible que siempre hayamos entendido conceptualmente el diseño como lo describe Dourish (2001), como “actualizado” por el uso. De hecho, esta noción es central a la literatura de HCI arraigada en posiciones fenomenológicas sobre la interacción, como por ejemplo (Ehn, 1988; Suchman, 1987). Además, la idea de que el diseño se completa con el uso es un principio básico del diseño participativo (Henderson y Kyng, 1991).

Las tecnologías de medios sociales prestan una renovada atención a la noción de diseño en uso porque gran parte de su forma está constituida por el uso. Los enfoques “Iteración” y “Surgimiento” extienden la noción de diseño en uso mediante el desplazamiento de una parte significativa de la actividad de diseño a las fases del uso. En lugar de desarrollar productos finales, los diseñadores configuran las semillas que se pueden coevolucionar (Botero y Saad-Sulonen, 2008), subdiseñan en forma deliberada (Fischer, 2008) o se ponen como objetivo refinar productos en uso (Redheady Brereton, 2008).

Un enfoque “Iteración” requiere el desarrollo de métodos de diseño de interacción que hagan hincapié en la participación en el diseño, posterior al lanzamiento. Si bien las metodologías ágiles han sido un catalizador importante del diseño desplazado hacia la iteración en uso, todavía se está trabajando para establecer la integración de una perspectiva de diseño de interacción en este enfoque de desarrollo, por ejemplo (Haikara, 2007). Además, también se requieren nuevos modelos para evaluar y medir el valor y el impacto de sobre-tiempo, que den mejor cuenta de la naturaleza embebida, personal y social del uso de la tecnología.

Los enfoques “Surgimiento” son relativamente nuevos y sus métodos están aún en investigación. La naturaleza emergente del enfoque implica que no hay un resultado claro. Todavía es necesario comprender mejor las formas de articular esto como una oportunidad más que como un riesgo, sobre todo en un contexto comercial.

Roles y responsabilidades

Figura 7. Actividades de diseño redistribuidas.

La noción de que las actividades de diseño ocurren durante el uso destaca responsabilidades adicionales para los diseñadores más allá del punto en el que los diseños llegan a las comunidades (Binder y otros, 2008). La Figura 7 sugiere un estado más continuo del diseño conforme se desvanecen los límites entre fases. Si bien esto puede reflejar mejor la naturaleza del diseño y la participación en este contexto, Ehn nos desafía a considerar el papel del diseñador profesional y cómo podrían manejarse estas relaciones en curso (2008).

¿Qué cambios necesitamos en nuestra propia práctica para apoyar estas nuevas formas de participación y colaboración? ¿Qué nuevas responsabilidades, habilidades y roles asumimos como diseñadores profesionales? Según Reichelt y Boulton sus responsabilidades se extienden a “capacitar” a la comunidad de usuarios para que esta finalmente tome el control del proceso de diseño (Reichelt, 2009). Brereton y Buur hablan de “fomentar compromisos apropiados y defender y vigilar los valores fundamentales que subyacen a la filosofía de diseño” (2008).

Si como sugiere Ehn (2008), nos estamos moviendo más allá de la noción tradicional de un proyecto, ¿qué tipos de contratos o períodos de participación son adecuados? ¿Cómo debemos, como agencias de diseño y consultores, modelar nuestros servicios y relaciones con los clientes y usuarios? Los contextos comerciales podrían basarse en la información sugerida por Fischer (2008) de reelaborar el modelo tradicional de “mantenimiento” para reflejar mejor la cantidad significativa de trabajo de diseño que ocurre luego del lanzamiento del sistema. Merholz (2006) sostiene que para las agencias de diseño que reciben consultas de diseño “proyecto por proyecto”, la naturaleza emergente de las tecnologías de medios sociales plantea diferentes retos. En nuestros propios proyectos hemos analizado la investigación en diseño participativo en comunidades para comprender mejor estos temas, por ejemplo (Karasti y Syrjänen, 2004).

Las preguntas sobre el papel del diseño y las habilidades requeridas de los diseñadores se complican aún más por el uso de las plataformas existentes como punto de partida. Tradicionalmente los diseñadores han sido los responsables de la creación de una gama de artefactos. En este caso el diseño se convierte en un acto de reconfiguración y composición de software existente, en lugar de crearlo desde cero (Twidale y Floyd, 2008). Los límites tradicionales entre el diseño y el uso se están disolviendo de tal forma que a veces es difícil decir quién lo hace, o dónde se está haciendo el diseño (Balka, 2006).

Diseño a la intemperie

Otra forma de cambio en el diseño es a través de la apertura del proceso de diseño. El diseño ha salido a la intemperie (Hutchins, 1995). Los enfoques “Recurso” y “Apertura” apoyan la participación voluntaria, en masa y distribuida, de los miembros del público en el diseño. La discusión individual y comunitaria sobre el diseño se produce en el contexto de la vida cotidiana de las personas. El diseño está saliendo del estudio y entrando en lo que Lee (2008) describe como los lugares concretos en los que viven las personas.

Conforme esto ocurre a los usuarios se les asignan, o ellos toman, actividades de diseño que alguna vez eran propias de los diseñadores. Para quienes facilitan este tipo de actividades comprender cómo motivar a las personas para que participen se convierte en un tema clave de investigación, por ejemplo (Antikainen y Väätäjä, 2008). Todos los enfoques plantean preguntas acerca de la propiedad sobre el diseño y las decisiones de diseño. De acuerdo con la información disponible, threadless.com parece ser el único ejemplo en el que los participantes controlan la producción del diseño final. También es el producto más simple: una camiseta. En todos los demás casos, algún tipo de profesional gestiona y filtra las contribuciones. Las motivaciones y las filosofías de diseño de las empresas especializadas en crowdsourcing también es algo a considerar. ¿Cuán equitativa es la colaboración propuesta?

En los ejemplos de “Apertura” había un compromiso para permitir la participación de usuarios en el diseño (en lugar de reaccionar al diseño). El trabajo de (Hess y otros, 2008; Reichelt, 2009) pone de manifiesto la verdadera magnitud del esfuerzo y el tiempo requerido para el codiseño y la cocreación. Además de las nuevas herramientas para facilitar la comunicación con la comunidad, los diseñadores profesionales también necesitan nuevas habilidades para evitar el “diseño por comité” cuando coordinan la participación masiva, por ejemplo (Reichelt, 2009). El trabajo futuro incluye comprender tanto las posibles funciones desempeñadas por los usuarios en estos contextos como el desarrollo de estrategias para la gestión de estos aspectos complejos de participación.

Una comprensión más profunda de los compromisos con la participación que existe dentro de las cuatro perspectivas diferentes que se presentan en este artículo también sería fundamental para aportar información a las estrategias en torno al valor de los distintos enfoques en diferentes momentos.

Conclusión

En este trabajo hemos tratado de investigar cómo responden los profesionales e investigadores al nuevo panorama de las tecnologías de medios sociales. Hemos prestado particular atención a la forma en que se está gestionando y apoyando la participación en el diseño. Hemos tratado de obtener una “configuración de campo” mediante una revisión de la práctica actual. Al hacerlo, hemos identificado cuatro enfoques de diseño y participación que responden a la naturaleza de las tecnologías de medios sociales, o son posibles gracias a ellas.

El efecto global de estos cambios en la práctica del diseño es una apertura del proceso de diseño. Las actividades de diseño se están reasignando y redistribuyendo, y el diseño es cada vez más público. Los límites tradicionales entre el diseño y el uso y el diseñador y el usuario están comenzando a disolverse conforme cambian nuestros roles y responsabilidades. Si bien hemos presentado ejemplos de las cuatro perspectivas importantes, aún resta trabajo en el desarrollo de nuevos métodos y modelos de diseño que reconozcan tanto la naturaleza inmanente del diseño, como su naturaleza cada vez más pública y colaborativa.

Nuestra intención en este trabajo no era para presentar una revisión exhaustiva, sino más bien ofrecer una vista filtrada de las tendencias actuales de una manera que esperamos sea útil para otros investigadores y profesionales. Las tecnologías de medios sociales están promoviendo la participación como una preocupación central en el diseño y esto se manifiesta en una infinidad de formas. Para los que estamos comprometidos con el diseño participativo, ¡esto es muy emocionante!

Agradecimientos

Nos gustaría dar nuestro más sincero agradecimiento a Eskimo Digital, Inspire Digital y sus clientes y a las partes interesadas por la oportunidad de trabajar con ellos. También nos gustaría agradecer al Dr. Lian Loke, a nuestros compañeros de investigación en el laboratorio IDHuP en UTS y a nuestros revisores por sus comentarios. También nos gustaría reconocer a Minna Isomursu, Pirjo Näkki, Andrea Botero y Leisa Reichelt por su tiempo y generosa discusión de temas que contribuyeron a este artículo.

Notas

11 Nota de la Editora: El término “Tecnologías Sociales” en América Latina podría ser traducido como “redes sociales”. Sin embargo, tampoco respetaría con exactitud a lo que las autoras se refieren. Es un término polisémico y del que aún no hay un acuerdo académico universal sobre qué significa y qué son y qué no son tecnologías sociales. Por tal motivo hemos decidido respetar en el título y en todo el texto esta denominación, haciendo esta salvedad.

Referencias

Antikainen, M. y Väätäjä, H. (2008), “Rewarding in open innovation communities – How to motivate members?”, en XIX ISPIM Annual conference. Open innovation: Creating products and services through collaboration.

Balka, E. (2006), “Inside the belly of the beast: the challenges and successes of a reformist participatory agenda”. PDC'06, ACM Press.

Battarbee, K. (2003), “Co-experience: the social user experience”. CHI'03, ACM Press.

Battarbee, K. y Kurvinen, E. (2003), “Supporting creativity - co-experience in MMS. The Good, the Bad & the Irrelevant - the user and the future of information and communication technologies”. COST 269.

Bergvall-Kåreborn, B. y Ståhlbröst, A. (2008), “Participatory design: one step back or two steps forward”. PDC'08, ACM Press.

Binder, T., Brandt, E. & Gregory, J. (2008), “Design participation”, pp. 1-3, CoDesign, 4.

Bødker, S. (2006), “When second wave HCI meets third wave challenges”. Nordichi 2006, ACM Press.

Botero, A. & Saad-Sulonen, J. (2008), “Co-designing for new city-citizen interaction possibilities: weaving prototypes and interventions in the design and development of Urban Mediator”. PDC'09, ACM Press.

Boulton, M., Drupal.org, “Design iterations, and designing in the open”, 2008, http://www.markboulton.co.uk/journal/comments/drupalorg_design_iterations_and_designing_in_the_open/ Accedido en diciembre de 2008.

Boyd, D. (2005), “Revenge of the social network: lessons from Friendster”, http://www.danah.org/papers/2005.0204.Stanford.txt Accedido en agosto de 2005.

Boyd, D. (2007), “Social network sites: Public, private, or what?”, http://www.danah.org/papers/KnowledgeTree.pdf Accedido en agosto de 2007.

Boyd, D. (2007), “The Significance of Social Software”, en: Schmidt, T. N. B. A. J. (Ed.) Blog Talks Reloaded: Social Software Research& Cases Norderstedt.

Boyd, D. (2009), “Taken out of context: American teen sociality in networked publics”, PhD Thesis. Information Management and Systems, Berkeley, University of California.

Boyd, D. (2009), “Social media is here to stay... Nowwhat?”, http://www.danah.org/papers/talks/MSRTechFest2009.html Accedido en marzo de 2009.

Brabham, D. C. (2008), “Crowdsourcing as a model for problem solving: An introduction and cases”. Convergence, 14.

Brereton, M. y Buur, J. (2008), “New challenges for design participation in the era of ubiquitous computing”, pp. 101-113, CoDesign.

Burka, D. (2008), “Changing successfully: Adapting your interface over time”, http://www.webdirections.org/resources/daniel-burka-interaction-design-case-studies/#slides Accedido en diciembre de 2008.

Chesbrough, H. W. (2003), “Open innovation: the new imperative for creating and profiting from technology”, Harvard Business School Press.

Clement, A., Costantino; T., Kurtz, D., y Tissenbaum, M. (2008), “Participatory design and development of Web 2.0 sites: The case of PIPWatch - the collaborative privacy enhancing and accountability toolbar”. PDC'08, ACM Press.

Corbin, (2009), “Twitter reverses on reply tweak after backlash”, http://www.internetnews.com/webcontent/article.php/3820256/Twitter+Reverses+on+Reply+Tweak+After+Backlash.htm Accedido en mayo de 2009.

Cruickshank, L. y Evans, M. (2008), “Media communication, consumption and use: The changing role of the designer”. DRS 2008, Design Research Society.

Davis, M. (2008), “Why do we need doctoral study in design?”, pp. 71-79, International Journal of Design, 2.

Disalvo, C., Maki, J. y Martin, N. (2007), “Mapmover: a case study of design-oriented research into collective expression and constructed publics”, SIGCHI conference on human factors in computing systems, ACM Press,

Dourish, P. (2001), “Where the action is”, MIT Press.

Ehn, P. (1988), “Work-orientated design of computer artifacts”, Stockholm, Arbetslivscentrum.

Ehn, P. (2008), “Participation in design things”. PDC'08, ACM Press.

Engeström, J., “Why some social network services work and others don't — Or: the case for object-centered sociality”, agosto de 2005. http://www.zengestrom.com/blog/2005/04/why_some_s ocial.html Accedido en septiembre de 2007.

Fischer, G. (2008), “Rethinking software design in participation cultures automated software engineering”, pp. 365-377.

Fischer, G. y Giaccardi, E. (2006), “Meta-Design: A framework for the future of end user development”, en: Lieberman, H., Patern, F. y Wulf, V. (Eds.); “End user development — Empowering people to flexibly employ advanced information and communication technology”, Dordrecht, Kluwer Academic Publishers.

Hagen, P., Robertson, T., Kan, M. y otros (2005), “Emerging research methods for understanding mobile technology use”, OZCHI'05, ACM Press.

Haikara, J. (2007), “Usability in agile software development: Extending the interaction design process with personas approach”, en: Concas, G., Damiani, E. & Scotto, M. (Eds.); “Agile processes in software engineering and extreme programming”.

Hart, J., Ridley, C., Taher, F., y otros (2008), “Exploring the Facebook experience: a new approach to usability”, en: Proc Nordi Chi'08, pp. 471-474, ACM Press New York, NY, USA.

Heinonen, S. y Halonen, M. (2007), “Making sense of social media interviews and narratives”, en: SOMED Foresight Report 2.

Henderson, A. y Kyng, M. (1991), “There is no place like home: Continuing design in use”, en: Greenbaum, J. y Kyng, M. (Eds.) Design at Work. Lawrence Erlbaum Associates.

Hess, J., Offenberg, S. y Pipek, V. (2008), “Community-driven development as participation?- Involving user communities in a software design process”. PDC'08, ACM Press,

Holzapfel, N. (2008), “An unsuitable match: social media and user-centred design”, http://johnnyholland.org/magazine/2008/11/an-unsuitable-match-social-media-and-user-centred- design/ Accedido en diciembre de 2008.

Horst, P. G. L., Mahendran, D., Martinez, K., y otros, “Hanging out, messing around, geeking out: Living and learning with new media”, Cambridge: MIT Press, en preparación.

Howe, J. (2006), “The rise of crowdsourcing” http://www.wired.com/wired/archive/14.06/crowds.html Accedido en mayo de 2009.

Howe, J. (2008), “Crowdsourcing: Why the power of the crowd is driving the future of business”, Crown Publishing Group New York, NY, USA.

Hutchins, E. (1995), “Cognition in the wild”, MIT.

Ingbert, R. F., Jones, M. C., Rathi, D., y otros (2007), “Web mash-ups and patchwork prototyping: User-driven technological innovation with Web 2.0 and Open Source Software”, 40th Annual Hawaii International Conference on System Sciences, IEEE Computer Society.

Isbister, K. y Höök, K. (2009), “On being supple: in search of rigor without rigidity in meeting new design and evaluation challenges for HCI practitioners”, 27th annual SIGCHI conference on human factors in computing systems, ACM Press.

Joinson, A. N. (2008), “Looking at, looking up or keeping up with people?: Motives and use of Facebook”, Proceeding of the 26th annual SIGCHI conference on human factors in computing systems, ACM Press.

Jones, M. C., Floyd, I. R. y Twidale, M. B. (2007), “Patchwork prototyping with open source software”, en: St. Amant, K. & Still, B. (Eds.); “Handbook of research on open source software: Technological, economic, and social perspectives”, University of Illinois at Urbana-Champaign, USA, Information Science Reference.

Karasti, H. y Syrjänen, A. L. (2004), “Artful infrastructuring in two cases of community”, PD. PDC'04, ACM Press.

Lee, Y. (2008), “Design participation tactics: the challenges and new roles for designers in the co-design process”, 4, pp. 31-50, CoDesign.

Lievrouw, L. A. (2006), “Oppositional and activist new media: remediation, reconfiguration, participation”, PDC'06, ACM Press.

Merholz, P. (2006), “Embrace the chaos - designers and systems with emergent behavior”, http://www.peterme.com/archives/000793.html Accedido en marzo de 2009.

Näkki, P., Antikainen, M. y Virtanen, T. (2008), “Participatory design in an open web laboratory Owela”, CHI08, ACM Press.

Näkki, P. y Virtanen, T. (2007), “Utilising social media tools in user-centred design”. CHI2007 workshop: “Supporting non-professional users in the new media landscape”, CHI 07, ACM Press.

O’Reilly, T. (2005), “What is Web 2.0”,.http://www.oreillynet.com/pub/a/oreilly/tim/news/2005/09/30/what-is-web-20.html?page=1 Accedido en marzo de 2009.

Pierson, J., Mante-Meijer, E., Loos, E. y otros (Eds.) (2008), “Innovating for and by users”, COST.

Porter, J. (2006), “The freedom of fast iterations: How Netflix designs a winning web site”, http://www.uie.com/articles/fast_iterations/3/1/08 Accedido en marzo de 2009.

Preece, J., Rogers, Y. y Sharp, H. (2002), “Interaction design, beyond human-computer interaction”, NY, John Wiley & Sons.

Redhead, F. y Brereton, M. (2008), “Getting to the nub of neighbourhood interaction”, PDC'08, ACM Press.

Reichelt, L., “Openness and effectiveness in designing with a community”, abril de 2009. http://www.disambiguity.com/openness-and- effectiveness/ Accedido en mayo de 2009.

Robertson, T., Mansfield, T. y Loke, L. (2006), “Designing an immersive environment for public use”. PDC'06, ACM Press.>

Schuler, D. y Namioka, A. (Eds.) (1993), “Participatory design: Principles and practices”, Lawrence Erlbaum Associates.

Shirky, C. (2003), “Social software and the politics of groups”, http://www.shirky.com/writings/group_politics.html Accedido en mayo de 2004.

Shirky, C. (2008), “Here comes everybody”, Penguin Press.

Sinha, R. (2007), “10 lessons from the design of Slideshare”, http://www.slideshare.net/rashmi/10-lessons-from-the-design-of-slideshare Accedido en junio de 2008.

Spool, J. M. (2007), “Learning from the Facebook mini-feed disaster”, http://www.uie.com/articles/facebook_mini_feed/ Accedido en mayo de 2009.

Suchman, L. A. (1987), “Plans and situated actions: The problem of human machine communication”, Cambridge University Press.

Threadless, www.threadless.com Accedido en marzo de 2009.

Twidale, M. B. y Floyd, I. R. (2008), “Infrastructures from the bottom-up and the top-down: Can they meet in the middle?”, PDC'08, ACM Press.

Von Hippel, E. (2001), “User toolkits for innovation. Journal of Product Innovation Management”, 18, pp. 247-257.

Ye, Y. y Fischer, G. (2007), “Designing for participation in socio-technical software systems”, en: Proc 4th International Conference on Universal Access in Human-Computer Interaction, pp. 312- 321, Springer.

El diseño de interacción y la amanualidad en Álvaro Vieira Pinto

Texto original: Rodrigo Freese Gonzatto & Luiz Ernesto Merkle

Traducción: Paz Marenco

Rodrigo Freese Gonzatto es doctorando y magister en Tecnología y Sociedad por el PPGTE de UTFPR (Curitiba, PR, Brasil). Se desempeña como docente en el curso de Diseño Digital de la Escuela de Arquitectura y Diseño en la PUCPR (Curitiba, PR, Brsails).

Ernesto Merkle es doctor en Ciencias de la Computación por la Western University (London, ON, Canada). Se desempeña como profesor en la Universidad Tecnológica Federal de Paraná, en el Programa de Pos-grado de Tecnología en el Departamento Académico de Informática.

Resumen

En este texto planteamos cuestiones relativas a fundamentos teóricos de la relación entre personas y artefactos en el diseño de interacción y presentamos el concepto de amanualidad elaborado por Álvaro Vieira Pinto. Originado en la fenomenología y en las filosofías de la existencia europeas, la noción de amanualidad fue formulada por Vieira Pinto, con base en el concepto de trabajo, aproximándola al materialismo histórico. Entre las décadas de 1950 y 60, cuando escribe sobre amanualidad, Vieira Pinto la entiende como una categoría de análisis dialéctica, que permite una comprensión del subdesarrollo. En su concepto de amanualidad, el autor amplía el análisis de la relación entre sujetos y artefactos. Al considerar a los objetos como hechos por el trabajo humano, se hace necesario considerar la historicidad de las acciones, de las técnicas y de la realidad construida por las personas. La manipulación de artefactos es formulada como una compresión no-esencialista y no jerarquizada genéricamente, ampliando el horizonte de desarrollo de las capacidades humanas en relación al mundo, situado e histórico, las cuales, por medio del trabajo, se desarrollan socialmente de un grado a otro. Al indicar la no contemporaneidad de los conocimientos y de las habilidades entre diferentes grupos sociales, Vieira Pinto refuerza la necesidad de que cada persona sea considerada a partir de sus propios contextos socio-históricos, indicación, a nuestro criterio, útil para la problematización de fundamentos teóricos del uso y producción en diseño de interacción.

Presentación

Áreas como el Diseño de Interacción y la Interacción Humano-Computadora (IHC) aportan una diversidad de abordajes y tendencias, siendo algunas contradictorias y otras complementarias. Entre las diversas propuestas que pretenden fundamentar la relación entre las personas y los sistemas computacionales, tenemos teorías, técnicas y métodos que generalmente trabajan con recortes bastante enfocados en algunos aspectos, ya sea en los procesos de diseño/proyecto, en la arquitectura, o por ejemplo en algunos aspectos del uso de artefactos interactivos. El presente capítulo presenta una alternativa de fundamentación basada en el concepto de amanualidad de Álvaro Vieira Pinto, para quien las interacciones entre los seres humanos y las tecnologías son siempre producciones sociales, contextualizadas, históricas, culturales y axiológicas.

El concepto de amanualidad de Álvaro Vieira Pinto permite problematizar cuestiones sobre la relación entre seres humanos y objetos. La conceptualización del autor apunta a una comprensión de las técnicas y de los artefactos tanto en producción como en uso, de forma activa pero también política, situada y circunstanciada en el tiempo y en el espacio, sin jerarquizarlas abstractamente. Su propuesta tiene como horizonte el desarrollo de las capacidades humanas en relación al mundo a su alrededor, a aquello que está en la proximidad, inclusive epistemológicamente, a aquello que está al alcance de la manipulación. Las cuestiones que presentamos en este texto tienen como origen las reflexiones iniciadas en una investigación de maestría (Gonzatto, 2014) y que actualmente son desarrolladas en doctorando, en el área de Estudios en Ciencia, Tecnología y Sociedad (CTS).

El concepto de amanualidad

El concepto de amanualidad proviene de las filosofías fenomenológico-existenciales. Este concepto trata de las relaciones entre el ser humano en situación y los objetos a su alrededor, aquellos disponibles “al alcance de la mano”. A través de la amanualidad la manipulación de objetos circundantes al ser humano está directamente relacionada a su modo de existencia, de manera tal que la relación que se establece entre persona y cosa es una cuestión ontológica.

En IHC, Diseño de Interacción y áreas relacionadas, su uso ha sido poco explorado. No obstante, Terry Winograd y Fernando Flores (1987) –en el libro Understanding Computers and Cognition– proponen explorar nociones asociadas a la amanualidad de Martin Heidegger para comprender diversos aspectos de la interacción entre las personas y las computadoras. Presentadas como alternativas para la comprensión del uso de artefactos, Winogard y Flores también proponen la exploración de otras bases conceptuales para una comprensión de la cognición, del proyecto (diseño) o del uso de computadoras. Con una postura crítica de las perspectivas instrumentales, funcionalistas y cognitivistas de la tecnología, la amanualidad indica que los artefactos no se distinguen existencialmente de los sujetos que los utilizan (relación entre persona y artefacto que recibe el nombre de ready-to-hand, en inglés). La aparición de los artefactos como “objetos” externos ocurre solamente cuando del distanciamiento de los objetos, como en situaciones y operaciones que exigen su reparación, cuando se rompen o no funcionan (breakdown) para ciertos propósitos, o en análisis “científicos” o en reflexiones sobre sus características y sustancias (condición que en inglés recibe el nombre present-at-hand). Si bien la fenomenología de Heidegger ha sido discutida en este libro, no sería correcto afirmar que haya sido posteriormente discutida y adoptada por las comunidades de IHC y de Diseño de Interacción. En tanto que fundamento teórico de la relación entre las personas y las cosas, no tuvo los mismos desgloses que, por ejemplo, el concepto de affordance o la propiciación de la Psicología Ecológica de J. Gibson, propuesto por la lectura de Donald Norman (1988).

El Concepto de trabajo como una modalidad de amanualidad

La comprensión de Álvaro Vieira Pinto de la amanualidad parte de la referencia de las tradiciones fenomenológico-existenciales, pero la amplía, buscando articularla con la existencia humana y las situaciones concretas de vivencias. Heidegger entiende que el ser humano manifiesta su existencia a través de la acción de manipulación del mundo. En cambio en Vieira Pinto, mediante la noción materialista-histórica de trabajo, la amanualidad se caracteriza no sólo por el uso de los objetos circundantes sino también como un concepto que atraviesa las contradicciones encontradas en la cotidianeidad del trabajo, que demandan eventualmente la ideación y fabricación de estos artefactos. Esta relación dialéctica de demanda/fabrico por el trabajo nos interesa particularmente, dado que apunta no solo al uso de un cierto artefacto, el cual puede ser optimizado como propone la usabilidad, y tampoco solo para su proyección (diseño), sino que necesariamente la inscribe en una situación concreta, vivida, sea por proyectistas o utentes.

La amanualidad por el trabajo es el modo relacional que permite al ser humano el descubrimiento y conocimiento del mundo, realizado por la transformación de éste. Es también “la forma de creación del [ser humano] por la naturaleza y de la creación de la naturaleza por el [ser humano] (...) en el sentido de la conversión del medio natural bruto en espacio de convivencia humana” (Vieira Pinto, 1969, p. 339, inserciones nuestras). Al partir de la categoría de “trabajo”, el ser humano es comprendido como activo y actuante frente a su realidad, la existencia humana es entendida como siempre en construcción, producida mediante la constante manipulación hecha con y por medio de artefactos (en uso, en mediación) y en los artefactos (uso y mediación con artefactos para trabajar en otros artefactos; por el trabajo que construye herramientas/máquinas por medio de otras herramientas/máquinas).

Amanualidad, trabajo, técnica y acción están densamente entrelazadas para Vieira Pinto. El trabajo es un tipo de acción, un modo de operar la realidad en busca de la realización de una finalidad. La acción humana es técnica, pues el actuar es intencional y mediatizado por las cosas (Vieira Pinto, 1960 [II], p. 190), siendo que las cosas (y también el pensamiento, el cuerpo y la mano) cargan el trabajo que las generó. Así, también las cosas son producidas a través de la técnica: fueron hechas, con la utilización de otras cosas, en busca de una finalidad.

La cuestión técnica es discutida no como un “hacer mejor”, sino como un “hacer nuevo”. No existe un hacer “mejor” universal, o incluso una técnica que obtenga los mismos resultados en todos los tiempos y lugares, pues ésta debe ser considerada siempre históricamente en virtud de una situación. Lo “viejo” es el modo estabilizado de trabajo, aquello que en un determinado momento una sociedad conoce como lo mejor para llegar a un resultado deseado, y que configura la amanualidad de un determinado momento. La técnica “nueva” exige considerar lo nuevo producido por ella, ya que al crear la técnica nueva, con ella emergen también nuevos artefactos y nuevas posibilidades del ser humano.

En este sentido, los sistemas/artefacto producidos en la actualidad, como los computacionales, llamados, de forma simplificada, digitales, exigen o exigieron el desarrollo de técnicas, que son o fueron útiles en determinadas situaciones, para ciertos grupos sociales. No son o fueron la técnica más avanzada universalmente que un colectivo particular necesitó o necesita para su desarrollo en un cierto momento histórico. No existe objeto “acabado”, pues todos están siempre pasibles de nuevos desarrollos. Son las disponibles o posibles en determinado momento y contexto.

No es posible posicionar los resultados del trabajo humano, como los llamados digitales, como “superiores”, de modo genérico, frente a otros. O expresar que estos son condición necesaria para el desarrollo de cualquier sociedad. El desarrollo técnico debe darse a partir de la amanualidad, y no a pesar de ella (Gonzatto y Merkle, 2012). Tampoco es posible afirmar que en algunos lugares “exista tecnología” y en otros no, y es ingenuo creer que solamente algunas naciones tengan la capacidad de desarrollo tecnológico. De esta forma, el desarrollo de una sociedad (y, en tal caso, Vieira Pinto se refiere especialmente a las naciones subdesarrolladas) tiene que partir como continuidad de su propio proceso histórico, y no por la mera secuencia de camino trazado por quien realizó su desarrollo y que en la actualidad se encuentra como centro de las relaciones internacionales. Para Vieira Pinto, términos como “Sociedad de la Información”, “Era de la Informática”, “Revolución Tecnológica” son de una ingenuidad interesada, que implícitamente descalifica otros momentos, otras culturas, otros locales, y por lo general a favor de países o grupos dominantes.

Como ejemplo, el desarrollo de una técnica manual artesanal existente puede ser una producción más útil para la transformación de la realidad y de la creación de nuevas potencialidades humanas en un colectivo que vive de la artesanía, que la instalación repentina de una fábrica en una región en la cual ese tipo de sistema de producción no represente una continuidad del desarrollo de la amanualidad de los sujetos que allí viven. El desarrollo de la técnica como desarrollo del ser humano, visto por la elaboración de la amanualidad, se realiza no sólo por la introducción o acceso a ciertos equipos, sino por la relación amanual que las personas hacen de estos. Dicha relación puede en ciertas situaciones llevar a la superación de formas menos productivas por quienes trabajan, así como a su desarrollo personal y colectivo. Transformar la realidad material o simbólica debería estar siempre ligado a la posibilidad de creación de nuevas condiciones de vida, útiles y deseadas por aquellos que viven en ciertas condiciones.

Grado de amanualidad

El desarrollo de la amanualidad también es un proceso gradual. El ser humano produce su realidad a partir de la manipulación de la realidad a la que tiene acceso, en la cual está situado. La produce mediante el trabajo de la experiencia acumulada, de la cultura producida y de las finalidades deseadas, de ahí la importancia de la educación, de la libertad. Como ejemplifica el mismo filósofo: “El [ser humano] primitivo, después de haber inventado el arco y la flecha no logra, claramente, enviar ningún satélite artificial al espacio, pero consigue cazar animales que hasta entonces estaban fuera de su alcance” (Vieira Pinto, 1969, p. 532).

Existen diferentes graduaciones de manipulación de los objetos, lo que distingue una graduación de otra es el trabajo que ya fue y el que está siendo hecho. En sus palabras:

Una cosa es revolver un poco de barro, otra es tomar una vasija para beber, y otra aún es tomarla entre las manos para apreciar la belleza de sus diseños y del colorido que le fue dado por el arte cerámico. En los tres casos, imaginados como ejemplo, tenemos la misma materia, pero tres grados distintos de manipulación, representando tres modalidades de ser, en suma cuánto hay de significado particular para cada uno; y lo que determina la diferenciación entre esos tres modos es la operación del trabajador, que imprime en cada caso a la sustancia bruta original propiedades que condicionan las diferentes posibilidades de manipulación. De hecho, es el trabajo lo que eleva la realidad a otro grado de amanualidad. Y con esa elevación surgen nuevas características de objeto (Vieira Pinto, 1960 [I], p. 69).

Cada situación, en relación a la persona que actúa, establece un grado de amanualidad. Este grado es construido y transformado a través del trabajo. El trabajo es acumulado en el proceso histórico y social de transformación de los artefactos. Este lleva la relación entre la persona y la realidad a otro grado de amanualidad, a nuevas formas de comprensión de la realidad y a nuevos artefactos, así como a nuevas formas de manipulación, nuevos modos de ser, a nuevas formas de producir la propia existencia en tanto que ser. En el caso de la creación y uso de artefactos llamados digitales, podemos tener ejemplos de estos modos al utilizar/manipular/trabajar una/en una aplicación computacional: a) se puede usufructuar directamente la aplicación, como en un juego para entretenerse; b) se puede utilizar una aplicación , como editor de texto, para elaborar un texto, situación en la que la aplicación puede ser vista como una herramienta; o c) más aún, se puede trabajar con un editor de texto, para construir/programar otra aplicación, que puede incluso ser un editor de texto. En esta última situación, se pone en evidencia que en la realización de este trabajo, la amanualidad en que la persona construye (y que pretende transformar, poniendo en el mundo una nueva aplicación) es histórica y pasa por el conocimiento acumulado de la sociedad, que se encuentra materializada en sus propios saberes y en las herramientas que esta persona tiene a disposición, y por su transformación. Diferentes contextos configuran diferentes relaciones de amanualidad. Programadoras y programadores en Brasil, en Argentina o en Estados Unidos no están en las mismas condiciones de amanualidad, aún si tuvieran las mismas aplicaciones y equipos. Las personas tienen historicidades diferentes, y la amanualidad no se establece solamente en la relación directa entre artefactos y personas, sino, con toda su realidad envolvente, en totalidad.

Amanualidad en grado cero y el llamado alfabetismo digital

Del mismo modo que no existe persona o artefactos “finalizados” o “completos”, dado que están siempre “en construcción”, tampoco es posible decir que existe un grado “final” o “último” de amanualidad. No hay un grado 10/10 o 100% de amanualidad, y no existe ausencia de amanualidad. Toda persona está en una relación de amanualidad, ya que siempre hay una manipulación del mundo establecido. Como ejemplo, Vieira Pinto (2010, 1960) discute la alfabetización. El analfabetismo no es el estado inicial, natural del ser humano, ya que no tiene sentido decir que un/a niño/a en edad pre-escolar es analfabeta. El niño/a puede tornarse “analfabeta”, en virtud del particular proceso de educación que la sociedad le destina. Una persona analfabeta no tiene como esencia ser analfabeta; lo mismo en el caso de una persona letrada. El analfabeto es conducido/educado por las condiciones sociales a devenir analfabeto, no nace como tal. Alfabetizar y analfabetizar son formas de educación que la sociedad está constantemente reiterando, la mayoría de las veces y situaciones de modo diferenciado a diferentes clases sociales. Del mismo modo, el analfabetismo no posee una esencia distinta de la alfabetización ni se opone a ella. El analfabetismo es un grado de alfabetización, dado que no se trata de una cuestión binaria y sí, de una de desarrollo, de trayectoria. La alfabetización, por lo tanto, está siempre situada en un proceso socio-histórico, del mismo modo en que una persona alfabetizada en inglés es analfabeta en portugués. Una persona no puede estar “alfabetizada en grado cero” ya que ser alfabetizado va más allá de leer y escribir. Es posible que alguien no sepa partir del alfabeto para comprender palabras, pero aún así lee la realidad que la rodea, o sea manipula la realidad. Si las palabras escritas forman parte de su entorno y esta persona necesita relacionarse con las palabras para sobrevivir, aún sin acceso al alfabeto para mediar su lectura, esta persona las manipula de algún modo, por otras mediaciones. Aunque en una comunidad no sepa leer signos impresos a partir de un alfabeto, tiene una relación con este alfabeto, se vive en un mundo con palabras y se relaciona de alguna forma con el texto escrito. La persona que está en el mundo, tiene una lectura de su mundo a partir de su modo de ser y de su grado de amanualidad.

El individuo que no sabe utilizar programas de creación y edición de software, o no se sabe expresar en lenguajes de programación para la producción de software, aún sin “saber programar” también puede ser alguien que computa. Ella o él se relacionan en amanualidad con los sistemas computacionales. Al elegir instalar software y aplicaciones, refuerza, produce o transforma la computadora y aquello que computa. Manipula, consecuentemente, significaciones y codificaciones, en ciertas configuraciones materiales y simbólicas, dado que altera parte de su computadora y de la red a través de la cual se conecta a otras personas, cuando elige instalar o no instalar algún software, a medida que realiza el proyecto de sus intenciones, de sus quereres, pero también en función de sus saberes y posibilidades. La persona que recurre a la ayuda técnica para instalar o desinstalar software o aplicaciones también manipula su computadora. Aún en la adquisición de computadoras, esta persona está desarrollando su relación posible con los objetos en su entorno, buscando modificar su relación de amanualidad con la realidad. En otro ejemplo, podemos entender el “grado cero” como “grado cero de amanualidad” y pensar sobre la cuestión del alfabetismo digital. Por ejemplo, una persona que no tiene acceso directo a dispositivos digitales, puede no saber utilizarlos o incluso comprenderlos formalmente. De todas formas, los encuentra en su realidad circundante como con lo que necesita enfrentarse, nos manipula a partir de sus conocimientos y de su lectura del mundo. En el caso de un trabajador o trabajadora que tenga que utilizar un cajero automático para realizar transacciones bancarias para recibir su sueldo, si la manipulación de computadoras es vital para su supervivencia, aunque tenga dificultades con el uso del sistema computacional o con la lectura de las palabras inscriptas en las pantallas del sistema, éste aún así posee su relación de amanulidad. Aunque su manipulación sea en grado cero, como es el caso de las personas que utilizan la ayuda de amigas o amigos, parientes o empleadas o empleados de un banco (su recurso disponible para la acción) para realizar las operaciones en el cajero automático por ellas. Esta manipulación en grado cero puede ser considerada una forma poco elaborada de amanualidad, pero de todas formas es una modalidad de ser, es un modo de entablar contacto con el mundo circundante, una relación marcada por el carácter activo entre la persona y su realidad. Esta manipulación la proyecta a un modo de computar a partir de sus recursos y de su amanual. Así, el “analfabetismo digital” puede ser considerado como un grado de manipulación de la computadora, y no como ausencia. Este grado deber ser considerado, y no negado, para poder partir de él. Considerar el grado cero no significa que “no hay de qué preocuparse”, que la respuesta sea mantener un inmovilismo ya que las personas resuelven sus problemas por sí solas. Nadie es prisionero de su relación amanual con los objetos, tampoco es indiferente si una persona realiza su manipulación de los artefactos de forma directa, en grados elaborados o en grado cero. Es necesario tener en cuenta que la amanualidad se desarrolla históricamente, lo que implícitamente también significa axiológica y políticamente. El grado cero indica un modo de amanualidad donde la persona lidia con el computar de la manera en que le es posible, aún con recursos escasos, pero que está disponible para nuevos desarrollo. Es posible que se desarrolle y pueda empezar a “trabajar” las computadoras, no en el sentido de “aprender el modo correcto” de computar, sino en el sentido de su desarrollo: de crearse, con la utilización de artefactos, elaborando su amanualidad. Diferenciar una persona de la otra, una generación de otra, como letrada o iletrada digitalmente, implicaría una naturalización de su condición, y una consecuente jerarquización, lo cual, en términos de valores (axiológicos), es bastante cuestionable. La noción del grado cero de alfabetismo digital apunta y abre la perspectiva de que siempre hay posibilidad de cambio y transformación, pero no la determina. Pasar de un modo de amanualidad a otro (cambiar la relación amanual entre ser humano y mundo), de manera que la persona pueda manipular la realidad con recursos más elaborados, es desarrollarse y transformar el modo de ser. El pasaje de un modo de amanualidad a otro se da a partir de la amanualidad pre-existente que se dirige hacia un nuevo modo, y, así, el “hacer el nuevo como desglose del antiguo, [es] por lo tanto desarrollar” (Vieira Pinto, 1960 [I], p. 79).

Los grados de amanualidad tampoco pueden ser discutidos como una métrica cuantitativa. La idea de grado sirve para “medir la amanualidad” pero para indicar que no es estática y tampoco apenas una característica o propiedad del sujeto o de los objetos. La existencia de los grados de amanulidad no pretende la mera contabilización en escala, a fines de jerarquizar verticalmente las técnicas. Lo que indica es que en cada situación socio-histórica se desarrollan técnicas diversas (formas de manipulación de la realidad), que no deben ser jerarquizadas por alguna “esencia” que las defina. Sí pueden ser comparadas, si esa evaluación se realiza de modo histórico y situado a partir de las finalidades que se propone un determinado grupo social, ya que cada sociedad desarrolló, desarrolla y desarrollará ciertas técnicas, que puede ofrecer resultados fructíferos, pero también pueden resultar menos rentables, o más nocivas violentas y coercitivas. No existe quien se haya desarrollado por completo o algo que esté en un estadío final, ya que la amanualidad, la técnica y el ser humano están siempre en construcción continúa.

Consideraciones finales

Consideramos que los conceptos discutidos a lo largo de este texto tienen potencial para el debate en tecnologías digitales, a pesar de necesitar aún seguir siendo desarrollados. Lejos de “relativizar” las técnicas como si fueran idénticas, la amanualidad permite poner en evidencia algunas diferencias y tensionar diferentes modos de interactuar con los artefactos. A partir del concepto de Álvaro Vieira Pinto, creemos contribuir a una comprensión más igualitaria de la técnica, de los artefactos y del conocimiento, sin jerarquizar sujetos, manteniendo una mirada histórica y teniendo siempre en cuenta el desarrollo. El concepto de amanualidad de Vieira Pinto permite un análisis de lo artificial que no sustancializa las posibilidades de sus usos como cualidades y características intrínsecas, dado que la función y significado del artefacto no está en él mismo sino en el horizonte de su manipulación. Quienes manipulan son siempre las personas.

De este modo, se evita en cierta medida la comprensión instrumental de técnica, dado que la agencia y el trabajo no se restringe a los artefactos propiamente dichos, o inclusive a las personas que crean o que usan artefactos. La totalidad circundante es siempre más abarcadora. En las palabras de Vieira Pinto, un “objeto es siempre el producto de la mano que lo hace, dado a la mano que lo conoce” (Vieira Pinto, 1960 [I], p. 70). Este concepto de amanualidad tensiona el postulado ingenuo de que los sistemas digitales, siendo idénticos frente a dos personas diferentes, ofrecerán las mismas posibilidades de uso e interacción. Las posibilidades serán siempre diferentes por la relación única que se establece entre cada sujeto y cada artefacto. El concepto original de J. Gibson también es relacional, pero volcado a la comprensión de la percepción de organismos y formas más simples de vida. En este sentido, no se podría hablar de la affordance de un artefacto, como se hace en IHC.

La horizontalidad de análisis de las manipulaciones por la amanualidad también cuestiona el determinismo tecnológico, al no indicar una concepción de técnicas y artefactos que sean necesariamente avanzados o atrasados.El desarrollo no es determinado por la tecnología, como si esta fuera autónoma: la tecnología es obra humana y el desarrollo tecnológico es desarrollo humano. La compresión democrática de técnica de Vieira Pinto propone que cada momento histórico posee técnicas más elaboradas para determinados fines, no siendo posible comprimir todas las historicidades en una perspectiva lineal de historia ni considerar lo digital y artefactos como computadoras, como técnica “universal” o “más eficiente”. Cada sociedad se desarrolla en un proceso histórico de transformaciones en el cual, simultáneamente, colectivos modelan la tecnología que necesitan y las técnicas de momento modelan las relaciones sociales.

Referencias

Gonzatto, Rodrigo Freese y Merkle, Luiz Ernesto (Orientador) (2014), Design de Interação e a amanualidade em Álvaro Vieira Pinto. Disertación (Mestrado em Tecnologia e Sociedade) – Programa de Pós-Graduação em Tecnologia, Universidade Tecnológica Federal do Paraná. Curitiba

Gonzatto, Rodrigo Freese y Merkle, Luiz Ernesto (2013), Âncoras e amanualidade: quando um link é mais que um meio. En: Dias, S.; Pallone, S.; Barata, G.; Kanashiro, M.; Peixoto, P.; Camelo, A.; Pontin, V.; Vogt, C., II Seminário Internacional Empírika: Comunicação, Divulgação e Percepção de Ciência e Tecnologia – Anais. Labjor-Unicamp: Campinas, SP, p. 267-281.

Norman, Donald A. (1988), The Design of Everyday Things (previamente publicado como The Psychology of Everyday Things), New York, Basic Books.

Vieira Pinto, Álvaro (1960), Consciência e Realidade Nacional, Rio de Janeiro, ISEB, 2 v.

Vieira Pinto, Álvaro (1969), Ciência e Existência, Rio de Janeiro, Paz e Terra.

Vieira Pinto, Álvaro (2005), O Conceito de Tecnologia, Rio de Janeiro, Contraponto, 2 v.

Vieira Pinto, Álvaro (2010), Sete lições sobre educação de adultos, São Paulo, Cortez.

Winograd, Terry y Flores, Fernando (1987), Understanding Computers and Cognition: A New Foundation for Design, Norwood, NJ, Ablex.

Diseño de experiencias continuas12

Texto: Sebastian Vetter, Kelly Ann McKercher y Jess Howell

Traducción: Paz Marenco

El Dr. Sebastian Vetter es Diseñador de Experiencia en Optimal Experience para Pricewaterhouse Coopers en Auckland, Nueva Zelanda. Ha ayudado a fabricantes de productos y proveedores de servicio en un amplio espectro de industrias a ofrecer mejores experiencias del cliente. Su formación es en psicología organizacional y laboral y en ingeniería industrial y ergonomía.

Sebastian.Vetter@optimalexperience.com

Kelly Ann McKercher es Diseñadora de Experiencia en Optimal Experience para Pricewaterhouse Coopers. Tiene experiencia en la creación de nuevos servicios así como en la evaluación y mejora de servicios existentes en diferentes sectores que van desde salud, servicios financieros a desarrollo social. Su formación es en innovación de diseño y antropología social.

KellyAnn.McKercher@optimalexperience.com

Jess Howell es Diseñador de Experiencia en Optimal Experience para Pricewaterhouse Coopers. Tiene experiencia en descubrir los problemas del usuario a través de investigación y análisis extensivo del usuario. Ha trabajado con diversas industrias para encontrar soluciones a esos problemas utilizando procesos de diseño participativo. Su formación es en administración de organizaciones y pensamiento de diseño.

Jess.Howell@optimalexperience.com

Resumen

La industria de servicios es el sector económico más importante en el mundo occidental. La tecnología ha cambiado dramáticamente la forma en que se ofrecen y vivencian los servicios. En este artículo presentamos un abordaje para diseñar experiencias de servicio de excelencia a través de canales digitales y no digitales. El abordaje consiste en 4 pasos: la creación de un marco de servicio, la investigación de clientes/usuarios, el análisis de los puntos de contacto y el desarrollo de canales.

1. Introducción

La industria de los servicios es el sector económico más importante y de mayor crecimiento en el mundo occidental. El ascenso del sector de servicios marca el ocaso de los sectores primarios (agropecuario) y secundario (manufactura). En Nueva Zelanda, el sector de servicios representa el 69.5% del Producto Bruto Interno. Los rápidos avances en la tecnología han cambiado de forma significativa la forma en que los se ofrecen y vivencian los servicios. Por ejemplo, en mayo de 2013 aproximadamente dos millones de neo zelandeses (la mitad de la población total) usaban home banking. Esta cifra representa un incremento del 20% a lo largo de los últimos 4 años. Un cuarto de los nuevos usuarios de internet acceden a la web a través de sus celulares. No sólo el banco ha migrado a los dispositivos móviles, sino que organizaciones de diversos sectores están introduciendo oferta en ese sentido.

Muchos proveedores de servicios creen que ofrecen una propuesta de servicio superior a sus clientes invirtiendo en tecnología de última generación. Desafortunadamente, muchos de sus clientes no están de acuerdo. La inversión consciente en el diseño de experiencia es con frecuencia olvidada.

Durante los últimos 11 años, Optimal Experience ha trabajado a lo largo de Australasia con proveedores de servicios financieros, empresas de telecomunicaciones, aseguradoras, educadores, empresas de comercio minorista y gobiernos para diseñar mejores experiencias para los usuarios y empleados en canales digitales y no-digitales. Creemos que las grandes empresas no compiten por precio, servicios, productos o características. Por el contrario, compiten por experiencia. Las experiencias de primera línea provienen de feedback de usuarios generado a través del abordaje de “Diseño de Servicio”.

2. De vanguardia

El diseño de servicios es un abordaje emergente e interdisciplinario que combina métodos y herramientas de varias disciplinas como la antropología, psicología, diseño de interacción, diseño gráfico, administración de operaciones, etc. Es una nueva manera de pensar acerca del diseño y oferta de servicios que desafía continuamente la teoría centrada en el producto y no se trata de una disciplina autónoma. ¿Por qué las organizaciones necesitan nuevas formas de pensar? El problema es que muchas organizaciones creen que están vendiendo productos en lugar de ofrecer servicios. Las empresas financieras, de telecomunicaciones y aseguradoras son perfectos ejemplos de esta mentalidad. Muchas de estas organizaciones están organizadas en compartimentos estancos, cada uno de ellos enfocado en ofrecer “su” producto o eslabón en la cadena de valor. Con frecuencia diseñan con la experiencia global en mente, sin embargo tienen escaso o nulo conocimiento del recorrido del cliente a lo largo de todo el servicio. Pólizas de seguro, cuentas bancarias y servicios de comunicación se ofrecen y vivencian a través de una serie de interacciones entre el cliente y el proveedor de servicios. Esto significa que los servicios no son meramente productos. Por ejemplo, al adoptar una aseguradora es posible interactuar con la compañía vía sitio web, email, aplicación(es) móvil(es), formularios en papel, consultores de venta en terreno, consultores de venta telefónicos, agentes de seguros externos, sucursales, etc. Llamamos a estas interacciones puntos de contacto. Un punto de contacto es un momento individual de interacción en un canal particular, como puede ser una llamada telefónica o un intercambio de mail. Un cliente puede interactuar con varios puntos de contacto a través de uno o más de un canal. Cada punto de contacto individual suele estar bien diseñado, dado que existe un departamento o equipo velando por su desarrollo y mantenimiento. El desafío con el que se enfrenta la mayoría de las organizaciones es la sincronización de todos los puntos de contacto para poder ofrecer una experiencia continua. La mentalidad tradicional centrada en el producto combinada con estructuras organizacionales divididas por canales suelen ir en detrimento de la oferta de una experiencia de servicio coherente y de calidad. La división en compartimentos estanco orientados a canales tiene sentido en el contexto de la unidad de negocios, pero no tiene sentido alguno desde el punto de vista del cliente para quien toda la oferta constituye una sola experiencia.

3. Caso de estudio

En 2014 trabajamos durante varios meses con un proveedor de servicios en Nueva Zelandia rediseñando sus canales digital y no-digital para ofrecer una experiencia de cliente continua. Seguimos un proceso de cuatros pasos: creación de un marco de servicio, investigación de cliente/usuario, análisis de los puntos de contacto y desarrollo de canales.

Creación de un marco de servicio

Para obtener una visión integral de las tareas que los clientes pueden realizar y de los canales disponibles creamos un marco específico para la organización en cuestión. Como primera medida revisamos investigación y métricas preexistentes e identificamos las tareas realizadas frecuentemente por los usuarios. Luego, elaboramos una lista de los canales disponibles y resaltamos los puntos de contacto entre tareas y canales. El gráfico 1 presenta un ejemplo del marco.

CEO
Canal | Digital | Directo | Teléfono | Sucursal
Punto de Contacto | Web | Móvil | Email | Carta | Flyer | IVR | CSR | Vendedores | Producto
Conocer el nuevo producto | X | X |  |  | X |  | X | X | X
Adoptar el proveedor de servicio | X |  |  |  |  |  | X | X |
Recibir factura | X | X | X | X | X |  | X |  |
Pagar factura | X | X |  |  |  | X | X | X |
Cancelar el servicio | X |  | X |  |  |  | X | X |

Gráfico 1

El marco muestra una estructura organizacional orientada a canales, característica de muchas organizaciones. La mayor parte de las tareas que los usuarios desean realizar, podrían hacerse a través de más de un canal de acuerdo con sus preferencias. Por ejemplo, los clientes pueden adoptar el servicio online, hablando con un representante por teléfono o en una sucursal. También muestra que algunos canales son más especializados que otros. Por ejemplo el IVR (sistema de voz interactivo) se usa exclusivamente para cuestiones relativas a la factura. La web y los call centers con Representantes de Ventas al Cliente (CSRs) tienen múltiples puntos de contacto a lo largo de diferentes tareas. Este marco ofrece una visión de conjunto de las tareas, canales y puntos de contacto que definen el servicio ofrecido actualmente por la organización.

Los puntos de contacto, no necesariamente son el resultado del desarrollo estratégico de canales, sino que han sido agregados ad hoc a lo largo del tiempo derivando en los siguientes problemas:

El sistema es desordenado, y costoso en términos de administración interna debido a la falta de flujos de trabajo eficientes.

Cuando los clientes cambian de un canal a otro la experiencia es por lo general incoherente y confusa.

En esta etapa el marco de servicio es meramente descriptivo. No se puede usar para la toma de decisiones estratégicas dado que no refleja la calidad de la experiencia del usuario o los costos asociados a la oferta del servicio.

Investigación de cliente/usuario

Para poder evaluar la experiencia actual del cliente:

Llevamos cabo 15 horas de entrevistas con los stakeholders.

Llevamos a cabo 20 entrevistas de una hora con clientes actuales y potenciales.

Pasamos un día completo escuchando llamadas en el call center.

Pasamos 2 días observando y conversando con los clientes en las sucursales.

El objetivo era entender qué tareas eran realizadas por los clientes en los diferentes canales, cómo las llevaban a cabo y por sobre todo, cómo era su experiencia. Descubrimos una serie de de puntos débiles: uso frecuente de jerga; “shock de factura” (recibir una factura de valor más alto al esperado); ser derivado de un agente de call center a otro; opciones de auto-servicio online limitadas; mensajes de texto irritantes a la noche tarde, etc. Algunos de estos problemas funcionaban como disparadores para que los clientes cambiaran el canal de interacción o en algunos casos que se fueran. Un cliente con el que hablamos (y que llamaremos Susan a efectos de este artículo) recorrió cuatro canales tratando de entender la jerga utilizada en su factura. Veamos su recorrido en el gráfico 2.

1. Susan recibe una factura alta por correo:

“¿Por qué es tan alta mi factura? No entiendo la jerga que usa”.

2. Revisa el uso del servicio online utilizando su través de su celular:

“¿Qué significan estos números? ¿Están actualizados?”.

3. Llama al call center donde logra sortear el IVR para hablar con un representante:

“Quiero que una persona de carne y hueso me lo explique”.

4. Por fin paga con su tarjeta de crédito accediendo al sitio a través de su computadora de escritorio:

“¡Dios mío! ¡Eso me llevó una eternidad!”

Gráfico 2. El uso de la jerga puede ser un disparador para que los clientes salten entre canales

En este ejemplo Susan eligió, en ese momento, el canal más práctico para la interacción. Una experiencia de servicio pobre en el canal de autoservicio online la llevó a llamar al call center. Saltar de un canal a otro consume mucho tiempo, es costoso para la organización y en el caso de Susan, resultó en una experiencia pobre e incoherente del servicio.

Para poder cuantificar los insumos obtenidos mediante la investigación, llevamos a cabo una encuesta de preferencia de canal con 900 usuarios. La encuesta cubría tareas comunes que los clientes pueden llevar a cabo, tales como “pagar una factura” o “revisar uso del servicio”. Los participantes eligieron su canal preferido y “menos preferido” para cada tarea específica. En líneas generales los resultados indicaron una fuerte preferencia por los canales digitales de autoservicio. Llamar al call center o visitar una sucursal fueron los “menos preferidos” dado que implicaban un mayor esfuerzo por parte del cliente. Luego de llevar a cabo una encuesta como esta, es importante comparar lo que los clientes señalan como su preferencia con respecto al comportamiento real con cada punto de contacto.

Análisis de los puntos de contacto

Por cada punto de contacto contrastamos los siguientes criterios: feedback de la investigación de clientes/usuarios, costo por cliente a servir, porcentaje real y proyectado de clientes usando el canal (ver gráfico 3).

Gráfico 3. Criterio para cada punto de contacto.

Encontramos que a pesar de que la mayoría de los clientes sostenía que prefería el sitio web, en realidad llamaba o visitaba la tienda para poder ejecutar una tarea. ¿Por qué? Analicemos dos ejemplos de nuestro caso de estudio para comprenderlo.

Ejemplo 1. Adopción del servicio/Suscripción

Los puntos de contacto revelaron que la mayoría de los clientes deseaba adoptar el servicio usando su teléfono celular. Sin embargo, el porcentaje real de de clientes que se suscribía desde un dispositivo móvil era menos del 1%. Esto se debía a que el proceso implicaba múltiples pasos y a que el sitio era difícil de usar y no era responsive. Para incrementar las suscripciones online la empresa ha decidido invertir en el diseño de un sitio web responsive aplicando un proceso de diseño centrado el usuario (DCU) para lograrlo.

Ejemplo 2. Autoservicio

Cuando se trata de las opciones de autoservicio como administrar sus cuentas, encontramos que aunque la gente quería auto gestionarse, pocos clientes usaban de hecho las opciones disponibles en el sitio web. Por contraste el número de gente que llamaba para administrar sus cuentas era relativamente alto. El call center es un canal costoso, que insume varios dólares por llamada. La investigación demostró que la mayoría de la gente que llamaba simplemente no sabía que podía ejecutar la tarea por sí solos online o consideraba que el sitio web era difícil de usar.

Desarrollo de canales

Las organizaciones deberían guiar activamente a sus clientes hacia los canales que ofrecen la mejor experiencia de servicio con costos aceptables. Por ejemplo, si adoptar el servicio mediante un formulario físico lleva mucho tiempo al cliente y su proceso resulta costoso para el negocio, deberían priorizar los canales que satisfagan las necesidades del cliente de forma más ágil, por ejemplo, solicitudes online. Consideremos usar factores de persuasión y disuasión. Persuadir activamente a los clientes para del uso de canales digitales con la promesa de que será más ágil y fácil completar una tarea en particular. Disuadir a los clientes de usar los canales no-digitales. Recomendamos usar la matriz de desarrollo de canales (gráfico 4) como guía para el proceso de toma de decisiones acerca de qué canal es el más apropiado para una tarea específica.

Eje Y: Costo por cliente/de alto a bajo

Eje X: Calidad de la Experiencia del Usuario/de alto a bajo

Eliminar

Desprioirzar

Estimular

Monitorear

Gráfico 4. Matriz de desarrollo de canales

El uso de un canal debería ser estimulado para una tarea en particular solamente si para un determinado punto de contacto la experiencia del usuario es buena y el costo por cliente es bajo. Los canales digitales por lo general tienen bajo costo por cliente y pueden ser utilizados por varias personas de forma simultánea.

4. Conclusiones

El éxito en la creación de servicios de primera línea implica llevar nuestra forma de pensar más allá de la centrada en el producto y poner las necesidades del cliente en el centro del diseño y mejora de los servicios. La estructura interna y asignación de presupuesto de muchas organizaciones es típicamente especializada en canales y centrada en torno un único o sólo algunos eslabones de la cadena de valor. Rompa los compartimentos estancos entre los equipos de cada canal, permita presupuestos transversales a los canales y la creación de equipos trans-funcionales que trabajen juntos constantemente para mejorar la experiencia de servicio de punta a punta. Muchos proveedores de servicios están convencidos de que ofrecen una propuesta superior a sus clientes invirtiendo en la mejor y última tecnología. Lamentablemente, muchos de sus clientes no están de acuerdo. Invierta en comprender a sus clientes. Use técnicas cualitativas de investigación de campo tales como observar y entrevistar a los clientes en su contexto o en el contexto en el que vivencian su servicio, para entender realmente quiénes son, y cuáles son sus necesidades y puntos de estrés. Enriquezca sus hallazgos agregando datos cuantitativos tales como reclamos comunes y cancelaciones. Desarrolle su propio marco de servicio para tener una visión integral de las tareas más comunes, los canales disponibles y los puntos de contacto resultantes. Revise y analice todos los puntos de contacto concentrándose en las tareas que los clientes desean realizar, sus necesidades y deseos al hacerlo. Identifique las experiencias que llevan a sus clientes a saltar de un canal a otro. Desarrolle canales y guíe activamente a sus clientes hacia aquellos que ofrezcan una mejor experiencia con un costo razonable. El buen diseño de servicios no se apoya en agregar más canales a su oferta. Por el contrario, se trata de mejorar los canales existentes para articularlos de forma continua y ofrecer una experiencia coherente de primera línea. 0

Notas

12 http://tvnz.co.nz/business-news/two-million-kiwis-now-using-online-banking-5425564

Descubriendo modelos mentales: El caso de una visualización interactiva que propicia la I+D mediante el cruce entre la academia y la industria TIC

Texto: Lorena Paz y Martín Szyszlican

Lorena Paz es socióloga (UBA), máster en Cooperación Internacional (Deusto) y diplomada en Educación y Nuevas Tecnologías (FLACSO). Doctoranda. Creó el Laboratorio Viviente “AbuelosTEC”, que se enmarca en un proyecto de investigación que desarrolla en la Universidad de Flores. Co-diseñó las primeras especializaciones universitarias en Argentina sobre Diseño de Interacción, usabilidad y accesibilidad y Experiencia de Usuarios, y los talleres de Inmersión UXDI. UX Research en la Empresa.

Martín Szyszlican es experto universitario en Usabilidad y Accesibilidad Web por la Universidad Tecnológica Nacional. Es además consultor y capacitador en realización de proyectos digitales. También se desempeña como coordinador de iniciativas de tecnología cívica como Congreso Interactivo, Yo Quiero Saber y Fundación Conocimiento Abierto. Integra el equipo de investigación-acción Sinapsis.

Resumen

Este capítulo detalla la segunda fase de un proceso de Diseño Centrado en el Usuario, durante el cual se profundizó en los Modelos Mentales de los usuarios involucrados.

Es el caso de una visualización interactiva que busca incentivar la investigación y el desarrollo (I+D) logrando el cruce entre la academia y la industria en el campo de la tecnologías de la información y la comunicación (TIC). El caso pone en evidencia que comprender los modelos mentales de los usuarios y de los propios creadores del proyecto sirve para comprender la identidad de un proyecto institucional. Identidad que es tratada aquí como un criterio de usabilidad.

Al divulgar esta experiencia se puso foco en detallar el proceso en el que la investigación etnográfica logra otorgar elementos para mejorar el testeo de la interacción con la interfaz en etapa temprana.

El método “Sinapsis, La estrategia del Bricolage”: Un marco teórico sistémico

Un investigador de experiencia de usuario (UX Researcher) puede, al mismo tiempo, comprender emociones y documentar acciones, cruzar esos datos y obtener conclusiones significativas, en tanto debe saber combinar múltiples métodos, materiales empíricos, perspectivas y observaciones.

El método que implementa Sinapsis (Equipo de Investigación-acción que llevó a cabo este trabajo) está basado en la estrategia de bricolage e impregnado de un enfoque sistémico, en tanto las piezas se van insertando para darle sentido a un todo. De este modo, cuando realizamos una investigación de usuarios para medir la usabilidad de una interfaz, asumimos que se genera información cuya utilidad será múltiple porque sirve para:

Validar la aptitud de la propuesta frente al público objetivo.

Analizar la forma en la que se comunica el proyecto institucional en la web.

Mejorar la expresión de sus objetivos y su identidad para facilitar la de comprensión de su sentido por parte de los usuarios.

Validar la comprensión de la redacción de los textos de la interfaz, los rótulos de los enlaces y las formas de interacción.

Creemos que el Investigador UX como un artesano, un bricoleur debe ser lo suficientemente dúctil como para poder trabajar con datos cualitativos y cuantitativos, manejarse cómodamente en un contexto transdisciplinar, pasando del campo de la informática, a la psicología, al diseño. Por ese motivo, se hace necesario el uso de técnicas y herramientas de recolección de datos propia de la etnografía desde una perspectiva multidisciplinar, una metodología que integra lo cualitativo y lo cuantitativo.

Asumiendo esto, en este caso nos propusimos recoger en las entrevistas y en las observaciones, material para analizar y poner en cuestión aspectos claves del proyecto, como su identidad, e ir conociendo los modelos mentales de los usuarios.

Introducción al caso: Las conexiones en el mundo de la investigación y desarrollo

En mayo del 2013, el equipo de investigación-acción Sinapsis gana el concurso “Ideas/Proyectos de Investigación Plataforma MITIC”, destinado a mejorar la usabilidad, calidad de datos, aprovechamiento, eficiencia o cualquier otro aspecto vinculado a la plataforma “Mapa de la Innovación en Tecnologías de la Información y la Comunicación”, por sus siglas MITIC de la Fundación Sadosky y, a partir de ese momento, los integrantes de Sinapsis nos pusimos a trabajar para mejorar su usabilidad.

El proyecto MITIC es una aplicación web con un sistema de búsqueda que brinda una visualización de la red de conexiones existentes entre investigadores, empresarios, proyectos financiados por el estado y universidades. El objetivo de la cual es propiciar la creación de proyectos de Investigación y Desarrollo (I+D) favoreciendo la interacción mediante la web entre investigadores académicos y empresarios del área de la Tecnologías de la Información y la Comunicación (TIC) en Argentina. La intención del proyecto de unir estos dos mundos, el académico y el industrial, para propiciar procesos I+D, nos llevó a considerar la necesidad de realizar un estudio de usabilidad con los usuarios objetivo, a fin de detectar problemas de usabilidad en las zonas clave de la interfaz y validar su aptitud para lograr los objetivos institucionales.

Al analizar la intención de los creadores de MITIC y evaluar proyectos similares, el desafío se presentó claramente: tornar efectiva una plataforma que pretendía según sus creador “propiciar I+D en el ámbito TIC en Argentina” pero cuya navegación, búsqueda y visualización resultaba muy compleja. Disminuir las barreras al uso de la plataforma sería la manera en que se “unirían e interactuaran” esos dos modelos mentales.

Por lo tanto el trabajo implicaba bucear en las formas de pensar e interactuar de los usuarios del MITIC, a las que podíamos acceder a través de una investigación exploratoria con foco en obtener datos acerca de los modelos mentales de los actores en juego: los empresarios y los investigadores del “mundo TIC” en Argentina. Pero también implicaba analizar proyectos similares y comprender el mundo de la I+D en Argentina y en el mundo.

Los siguientes párrafos representan un recorrido sobre las diferentes perspectivas metodológicas usadas y algunas de las conclusiones extraídas de las mismas. Luego se detalla el proceso de trabajo, los cambios propuestos al diseño y una conclusión general.

Las preguntas de investigación y los modelos mentales:

Con respecto al público objetivo, el creador de la aplicación afirmó: “El usuario previsto es, por un lado, el empresario (o la persona de la empresa) que, ante una necesidad puntual de resolver un problema o encarar una innovación van a ir a ver al mundo científico. Y, por otro lado, el académico que busca empresas interesadas en financiar su investigación”.

Sin embargo, a lo largo de la investigación, fue quedando cada vez más claro que estos no son los únicos usuarios de la aplicación, ya que en las entrevistas se presentaron personas con un nuevo rol, al que hemos denominado “gestor de innovación y desarrollo”. Un usuario que había resultado invisible para los creadores de la aplicación.

Las siguientes preguntas de investigación fueron disparadoras:

¿Es útil una interfaz web para facilitar la creación de proyectos de I+D?

¿Es efectiva la plataforma para hallar empresarios o investigadores TIC?

¿Es efectiva la plataforma para que empresarios e investigadores TIC hallen nuevos socios para sus proyectos?

¿Cómo son los modelos mentales de los investigadores TIC?

¿Cómo son los modelos mentales de los empresarios TIC?

Para dar respuesta a estas preguntas, fuimos obteniendo información sobre los modelos mentales de los usuarios tanto de manera inducida como casual y en diferentes instancias de la investigación (antes, durante y después de las pruebas técnicas) a través de entrevistas para relevar la experiencia del usuario y como material para el co-diseño de la visualización de los patrones de búsqueda. La definición de modelo mental que nos ha resultado más adecuada para encarar este proceso de indagación es la formulada por Donald Norman, quien los describe como “los modelos que tiene la gente de sí misma, de los demás, del medio ambiente y de las cosas con las que interactúa. La gente forma modelos mentales mediante la experiencia, la formación y la instrucción. El modelo mental de un dispositivo se forma en gran parte mediante la interpretación de sus actos percibidos y de su estructura visible”.

Más preguntas de investigación: Disparos en un blanco

Más preguntas recorrieron la investigación, interpelando tanto a la interfaz como a los líderes y creadores del proyecto, a los supuestos usuarios, y también a nosotros los investigadores.

¿Qué tipo de sitio es? ¿Cuál es el contexto de uso? ¿Qué tipo de acciones permite hacer el sitio? ¿Cuál es el público objetivo? ¿Hay coherencia entre el objetivo institucional y el objetivo de la aplicación web?

Con la orientación que brindaban estas preguntas, el equipo de investigación-acción Sinapsis fue ampliando el conocimiento de la interfaz usando técnicas heurísticas, en las que un grupo de tres evaluadores con diferentes grados de experiencia en el campo usaron las guías de evaluación heurística de Hassan Montero y Nielsen, lo que nos permitió un acercamiento inicial al tipo de problemáticas de usabilidad que podrían encontrarse en el sitio.

Adicionalmente se realizaron comparaciones con otras herramientas similares, logrando un análisis del estado del arte, también llamado benchmarking, a la vez que profundizamos en el dominio específico de la aplicación.

Paralelamente existió un proceso de indagación compartida con el creador y el líder de la aplicación para evidenciar los objetivos con que la institución crea la aplicación y el público al que pretende llegar con ella, además de repasar la historia, misión y visión del proyecto. Esta instancia también nos permitió conocer sus expectativas con respecto a las posibles mejoras de la interfaz y cuáles eran los puntos que ellos consideraban críticos.

Las pruebas sobre la interfaz y las entrevistas etnográficas

Las pruebas sobre la interfaz y las entrevistas etnográficas aportarían, además de la detección de problemas de usabilidad, información para poder redefinir los objetivos institucionales con respecto a la aplicación y un profundo conocimiento del modelo mental de los usuarios, especialmente a través de la realización del protocolo think-aloud durante las pruebas. Es decir, pedirle a los usuarios que “piensen en voz alta”, que informen al entrevistador acerca de lo que piensan hacer y si lo que pasó es lo que esperaban. Este protocolo fue introducido en el campo de la usabilidad por Clayton Lewis en 1982 y desarrollado en su libro de 1993.

El análisis de las entrevistas considera algunas frases textuales y opiniones de los usuarios investigados como el soporte que da sentido a los datos cuantitativos obtenidos en las diferentes pruebas, esto permite una comprensión articulada de la usabilidad en sus dimensiones objetiva y subjetiva. La complejidad que presenta el poder mensurar la satisfacción del usuario con lo que concretamente hizo (en tanto efectividad y eficacia) visibiliza la naturaleza de la usabilidad en tanto análisis de los factores humanos en la interacción. Al respecto es recomendable tener presente el exhaustivo trabajo de Yusef Hassan Montero que ahonda sobre este asunto y que hemos tomado como modelo técnico.

En cambio, la identidad, en tanto criterio de usabilidad, es más simple y obvia de comprender y es definida como “(...) la forma en la que se presentan en la interfaz los objetivos del proyecto y los intereses de la institución que lo promueve, así como también el público objetivo al que se dirige”. Como “la identidad de un proyecto web atañe al lenguaje y redacción de los textos que presentan los objetivos (…)”, estos son más fácilmente comprendidos cuando en su sintaxis y semánticas son los adecuados para los modelos mentales de los usuarios.

Proceso de trabajo Sinapsis para MITIC

Se acordó que el trabajo sería realizado por dos integrantes de Sinapsis que dedicarían en total 20 horas semanales distribuidas de acuerdo al siguiente cronograma de trabajo:

4 semanas a la investigación inicial, conformada por evaluación heurística, relevamiento y reorganización de la arquitectura de la información y relevamiento del perfil de usuarios.

Entrevistas al líder (Project Manager) y al creador de MITIC.

Evaluación heurística sobre los criterios usabilidad que respeta la plataforma.

Redacción del Informe Heurístico (objetivos de la institución + análisis de la interfaz).

2 semanas a la elaboración de un primer informe con Plan de Desarrollo más detallado.

Investigación de usuarios/Observaciones in situ.

Redacción de informe para el desarrollo de prototipo.

1 semana al diseño de una primera versión del Prototipo

2 semanas a la realización de Pruebas de Usabilidad sobre el Prototipo.

Redacción de la guía de preguntas test.

Pruebas de usabilidad sobre el prototipo.

Redacción de un informe.

3 semanas a la realización de una iteración sobre el diseño, repitiendo el ciclo de prototipado y evaluación, incluyendo las mejoras realizadas en base a los resultados de las pruebas anteriores.

2 semanas a la elaboración de un Prototipo Final

2 semanas a la elaboración de un Informe Final

Investigación y pruebas

En total se realizaron tres ciclos de investigación de usuarios, diseño y pruebas, con la participación de un total de veintiún usuarios. Al realizar los ciclos de pruebas con usuarios fuimos desarrollando prototipos refinados, con mejoras a las funciones actuales y propuestas de nuevas funciones. Al cabo del tercer ciclo se entregó un prototipo interactivo como referencia para la implementación.

A lo largo de todo el proceso de Diseño Centrado en el Usuario (DCU) y en el contexto previo o posterior a las pruebas se realizaron entrevistas contextuales para relevar el conocimiento de la plataforma por parte de los usuarios y la percepción que tenían de la relevancia de la herramienta en relación con sus actividades profesionales, como empresario o gestor o investigador del mundo de las tecnologías de información y comunicación.

Como complemento se realizaron entrevistas con personas que aún no conocían el mapa de innovación MITIC o no la habían usado (usuarios potenciales), pero que luego de informarse con documentación de la propia Fundación Sadosky, manifestaron interés en la plataforma. Este grupo de entrevista nos permitió descubrir la necesidad de nuevas funcionalidades.

Fue durante estas entrevistas donde se evidenció que aquellos usuarios de perfil académico no estaban tan interesados en buscar financiación para sus investigadores, considerando que esto era una tarea del área de extensión universitaria de la institución a la que pertenecían. Además algunos reciben ofertas para trabajar en empresas de forma asidua, y no siempre están en condiciones de aceptar.

De la misma forma, los empresarios TIC están enfocados en la búsqueda de recursos humanos para satisfacer a sus clientes actuales. Algunos de ellos, los que son también investigadores, comprenden el valor del trabajo académico, en el que participan por sus contactos universitarios, aunque este trabajo no siempre tenga un valor de mercado.

Descripción de la interfaz y cambios realizados

Capturas de pantalla comentadas de interfaz original:

Realizando las pruebas con usuarios

El primer prototipo a testear fue la aplicación completamente desarrollada tal como existía al inicio de la participación del Equipo Sinapsis en el proyecto (Ilustración 1). Basados en un análisis heurístico inicial, las áreas sometidas a prueba en el primer prototipo de MITIC fueron:

Navegabilidad, entendida como la capacidad que tengan los usuarios de encontrar las diferentes funciones y áreas de contenido.

Ubicabilidad, entendida como la capacidad del sistema de informar al usuario dónde se encuentra y qué acciones puede llevar a cabo en cada instancia.

Contenido, entendido como los rótulos, nominaciones, temas y categorías de la plataforma MITIC, es decir, qué información existe en la plataforma y cómo es presentada al usuario.

Registro y acceso, a fin de evaluar el impacto de la complejidad de estos pasos en la adopción de la aplicación.

Funciones principales del mapa y filtrado.

Detalle de la primera ronda de pruebas con usuarios

Para realizar las pruebas convocamos a usuarios investigadores en ciencias exactas, empresarios de la industria TIC en una primera etapa, ya que no fue hasta la segunda etapa que convocamos a gestores de procesos de investigación y desarrollo.

Un total de seis personas completaron exitosamente la prueba de usuario, que consistía en una primera fase exploratoria, una serie de consignas y una entrevista final que detallaremos a continuación. Durante la fase exploratoria los usuarios eran instruidos en el uso del protocolo think-aloud, consistente en el relato oral por parte del usuario de todas sus acciones y pensamientos durante la navegación. Al comienzo de la prueba el usuario navegaba el sitio sin tareas guiadas y con una mínima intervención de los facilitadores que para reforzar el pensamiento en voz alta hacían preguntas del estilo “¿Qué pensás de esto?” o “¿Qué es lo primero que harías?”.

En una segunda instancia de navegación estructurada se les requirió hacer una búsqueda y analizar los resultados por su cantidad y calidad en relación a los objetivos de la plataforma. A los investigadores se les pidió que busquen un partner para financiar o convertir en producto su investigación, según su preferencia; a los empresarios se les solicitó que buscaran investigadores para resolver los problemas complejos en sus emprendimientos y se pidió a los gestores que busquen investigadores o empresas que pudieran ser aliados en sus actuales proyectos. A todos los usuarios se les requirió analizar los resultados por su cantidad y calidad en relación a los objetivos de la plataforma al tiempo que se relevaba uso del formulario de búsqueda y las páginas de error.

Preguntas e indicaciones realizadas a los usuarios durante las pruebas

¿Cuál es tu tema de investigación? ¿En qué proyectos o temas trabajas en la empresa? ¿Qué harías para encontrar socios o partners para tu proyecto? ¿Qué estás viendo en esta pantalla? ¿Qué más podrías hacer en esta pantalla? ¿Encontraste información que consideras útil para encontrar socios o partners para tu proyecto? ¿Por qué crees que aparecen estos elementos en este listado? ¿Piensas que en la página existe alguna información que te pueda ayudar a interpretar esto? ¿Te parece que esta es la única forma de ver los resultados? ¿Qué más podrías hacer en esta pantalla? ¿Qué te parece que estás viendo? ¿Qué crees que significa cada una de esos elementos? ¿Qué te parece que significa la diferencia de grosor en las líneas? ¿Podrías darme un ejemplo? ¿Estos resultados coinciden con tu búsqueda? ¿Esta es la misma información que estaba en la lista que acabamos de ver? ¿Qué diferencias te parece que hay entre esta información y la otra? ¿Querrías modificarla? ¿Qué te parece que es esto? ¿Puedes ver más información de alguna de estas?

Por último y tras la ejecución de las tareas del guión del test, se preguntó a los usuarios acerca de su estado emocional en relación a la prueba, y se les pidió que resumieran sus apreciaciones acerca de la aplicación web que acababan de utilizar y que expusieran sus propios consejos y dudas acerca del proyecto. También Sinapsis incorporó el co-diseño en tanto volvió a entrevistar a los primeros usuarios tester mostrándoles el prototipo y dejándolos opinar acerca del proyecto en general.

Resultados de las pruebas con usuarios

Algunas conclusiones de la primera ronda fueron:

Muy pocos usuarios descubrieron la vista de conexiones.

La mitad de los usuarios logró hallar socios potenciales.

Todos esperaban un formulario de registración.

Todos detectaron información faltante.

Ninguno descubrió el significado del grosor de las líneas en el grafo.

Mediciones de la efectividad y experiencia de usuario de la aplicación web de acuerdo a la métrica: Todos: 8/8; Casi todos: 7/8; Muchos: 6/8; Más de la mitad: 5/8; La mitad: 4/8; Pocos: 3/8; Muy pocos: 2/8; Casi ninguno: 1/8; Ninguno: 0/8.

Como consecuencia de los problemas identificados, menos de la mitad de los usuarios logró hallar socios potenciales para generar proceso de Investigación y Desarrollo (I+D), lo que evidenció la necesidad de rediseñar esa función.

Las pruebas también revelaron que los perfiles de los usuarios no son puros: un empresario podía ser al mismo tiempo un investigador. Es importante destacar aquí que el proyecto institucional, por medio de su proyecto web, busca el encuentro entre estos usuarios como si pertenecieran a dos mundos separados, sin tener en cuenta la existencia de aquellos que ya eran investigadores de I+D en empresas o empresarios que dirigían departamentos de investigación tal como pudimos descubrir a través de las pruebas.

Muchos de los usuarios entrevistados no parecían tener el perfil adecuado para usar este sitio, ya que no estaban interesados en contactar directamente con personas del otro grupo.

Algunas frases textuales:

Para comprender mejor el contexto de la interacción de los usuarios y sus modelos mentales, resulta útil citar aquí algunas frases que dijeron durante las pruebas de usabilidad y las entrevistas anteriores y posteriores:

“No es el problema de la plataforma sino del estadío de desarrollo en Argentina. El estadío en Argentina de I+D es muy embrionario”.

“El problema grave que hay en Argentina es que el requerimiento de ciencia y tecnología es muy bajo, la demanda es baja, y en general, en las pymes, no saben a quién pedirla”.

“El FONSOFT tiene una línea de crédito que no se corresponde con el tiempo de vida medio de los proyectos, tardan en otorgar el dinero más tiempo que el tiempo de vida medio de los proyectos, es decir, que en esas circunstancias un proyecto nace muerto. Se cumple así el principio de San Mateo”.

“Es un tema de diferencias culturales de idioma, de entenderse. Pero es un problema serio en todo el mundo, no sólo de Argentina: Son agendas diferentes, prioridades diferentes”.

“Sobre todo en Argentina el requerimiento de las empresas respecto de investigación y transferencia de tecnología es muy bajo, es gigante la brecha entre el que requiere y el que ofrece. Es tan grande la brecha que nadie sabe cómo transitarla”.

El modelo mental y el significado de los términos

El modelo mental del usuario es clave a la hora de lograr una búsqueda exitosa, así como la forma en la que el motor de búsqueda recupera información resulta tan importante.

Para ejemplificar, podemos encontrar en nuestras pruebas de usuario un caso muy notorio. Una consigna invitaba a los usuarios a buscar “una empresa argentina que se dedique a algoritmos”. Y podemos ver cómo, dependiendo del grupo al que pertenecen los usuarios, realizan búsquedas diferentes. Para este caso un investigador escribió: “programación dinámica”, en referencia al campo científico al que pertenece el tema. Un empresario escribió literal: “algoritmos”. Una gestora escribió “optimización”, con la consciencia de que la utilidad del trabajo en algoritmos es muchas veces la aceleración de los procesos. El buscador devolvió resultados completamente diferentes para cada una de estas búsquedas, lo que significa una barrera para el encuentro de personas con diferentes modelos mentales. Los usuarios estudiados, quienes forman parte del público objetivo de este proyecto, presentaron modelos mentales marcadamente diversos.

Un ejemplo claro de cómo funcionaron los modelos mentales como condicionantes lo tuvimos a lo largo de las entrevistas y de los test de usabilidad con los usuarios del grupo “investigadores TIC”, ya que ellos tienen una mayor comprensión de cómo se estructura una base de datos y de cómo se elabora un grafo, por lo tanto su nivel de expectativa con respecto al buscador es menor. Al comprender cómo se elabora lo que hay “detrás” de esa interfaz pueden entender qué acciones podrían ser mejores para que éste responda. Por lo que “adaptan” su búsqueda a lo que ellos consideran la viabilidad de la respuesta.

Modificaciones realizadas a la interfaz

En función de los resultados de las pruebas, y habiendo detectado una gran cantidad de problemas de usabilidad, se realizaron las siguientes propuestas de modificación en la interfaz.

Conclusiones

El hallazgo más importante de la primera iteración estuvo relacionado con el descubrimiento de un nuevo actor relevante en la I+D, el gestor de I+D, que había sido contemplado inicialmente como potencial usuario de MITIC. Por lo tanto, los usuarios relevados pertenecían a tres categorías y no a dos como sugerían los creadores: Empresarios del área de tecnologías de información y comunicación (TIC), Investigadores del área TIC y Gestores de I+D.

La relevancia del hallazgo como producto de nuestra investigación, radica en que, los Gestores de I+D serán los actores claves que propicien la I+D en el estadío de desarrollo en el que aún se encuentra Argentina en el campo de las TIC. Los gestores trabajan a diario propiciando el encuentro de estos mundos en espacios no virtuales. Sus reflexiones acerca de MITIC en particular y sobre la interacción de empresarios y universitarios para hacer I+D resultaron claves para comprender en profundidad el problema que intenta resolver MITIC y hacer una propuesta de mejora. También fue clave la actitud y predisposición del creador y líder del proyecto de comprender la necesidad de incorporar este nuevo actor, y propiciar que el equipo profundice en la labor de este usuario.

Otro punto destacable de esta investigación es la comprobación de que cada tipo de usuario tiene una estrategia diferente para nominar las cosas de acuerdo a sus objetivos. En los casos observados, los investigadores utilizaron palabras relativas a los procesos y a las áreas de investigación, mientras que los gestores piensan más en lo que puede resultar importante para las empresas o para las solicitudes de fondos estatales de investigación y desarrollo. De la misma forma, los empresarios están motivados por las necesidades del día a día de su empresa y entienden su búsqueda en términos de recursos para cumplir con sus objetivos. Por lo tanto, una correspondencia simple entre los términos de búsqueda y la información en la base de datos resulta insuficiente para la mayoría de los usuarios, exceptuando aquellos que pueden imaginar de forma acertada cómo funciona un sistema de búsqueda simple. Será necesario evaluar el uso de estrategias avanzadas de recuperación de información, como clustering y detección de términos relacionados, uso de sinónimos y abreviaciones, además de un análisis semántico del término ingresado, optimizando para el campo semántico específico. La conclusión fue contundente: no sólo “buscaban” diferentes, usaban otros términos, si no que la propia base estaba cargada sólo con un modelo mental, con la taxonomía de ACM.

Concluyendo, el caso comprueba que la comprensión y el uso apropiado de una interfaz se basa en establecer un modelo del sistema apropiado que permita a los usuarios reconocerlo y saber cómo utilizarlo. Cuanto más conocimiento previo se tenga sobre el modelo mental de los usuarios, y se lo piense como un ingrediente clave en un proceso Diseño Centrado en el Usuario, más usable y útil será el diseño de la interfaz. Y más aún, será coherente con los modelos mentales de los actores y efectivo respecto al objetivo de la institución que hay por detrás. La investigación etnográfica es una inversión que retorna rápidamente, disminuyendo la necesidad de rediseños, programación, e incluso el testeo con los usuarios equivocados.

El relato sistematizado de esta experiencia fue concebido como un aporte del mundo UX al mundo de la I+D+I. Pensando estos métodos como herramientas y puentes que posibilitan el cruce de los mundos de la académica y la empresa.

Bibliografía

Lewis, Clayton H., Mack, Robert L. (1982), “Learning to Use a Text Processing System: Evidence from ‘Thinking Aloud’ Protocols”. En: Nichols, Jean A. y Schneider, Michael L. (eds.) Proceedings of the SIGCHI conference on Human factors in computing systems, March 15-17, 1982, Gaithersburg, Maryland, United States. pp. 387-392.

Nielsen, J., Molich, R. (1990), “Heuristic evaluation of user interfaces”, Proceedings of ACM Conference on Human Factors in Computing, New York.

Norman, Donald (1990), La Psicología de los Objetos Cotidianos, Madrid, Ed. Nerea.

Nielsen, J. (1994b), “Heuristic evaluation”. En: Nielsen, J., & Mack, R.L. (Eds.), Usability Inspection Methods, New York, John Wiley & Sons.

Hassan Montero, Y. y Martín Fernández, F.J. (2003), “Guía de Evaluación Heurística de sitios web. No sólo Usabilidad”. ISSN 1886-8592. http://www.nosolousabilidad.com/articulos/heuristica.htm

Hassan Montero, Y. y Ortega Santamaría, S. (2013), “Introducción a la Interacción Persona-Computadora”. En: Pioneros y Hacedores: Fundamentos y casos de Diseño de Interacción, Buenos Aires, Ediciones Godot.

La nueva página de las charlas TED: una breve historia

Texto original: Aaron Weyenberg (http://hello.ted.com/2014/04/15/the-new-ted-talk-page-a-brief-history/)

Traducción: Sebastián Betti

Aaron Weyenberg es un profesional de formación ecléctica en informática, ingeniería y comunicación de tres universidades diferentes. Actualmente es líder de UX en TED.com, y en el pasado fue Director de Arte en ESPN.com, paquetes editoriales especiales y en el desarrollo de las primeras aplicaciones deportivas con datos en tiempo real.

La vida de una charla TED comienza cuando un orador comparte su idea en el escenario de TED, a una audiencia en vivo. A partir de ese momento, la idea se propaga a través de conversaciones y de video en línea. Si bien las charlas TED se ven mediante muchos canales (por ejemplo, YouTube, Netflix, Roku, y aplicaciones móviles nativas), podemos ofrecer una mejor experiencia en contexto desde el sitio TED.com.

Cuando uno visita TED.com, es probable que lleguemos a la página de las charlas (la página de las charlas representa un 60% de las vistas a TED.com). A menudo, esta es la página objeto de todos los tuits y mensajes de Facebook. Para muchos usuarios es también la carta de presentación a TED.com, e incluso a TED. Esta página se ve en cientos de diferentes dispositivos, en un sinnúmero de condiciones y configuraciones. Tiene que proporcionar una experiencia sólida, significativa y atractiva para un viajero en Bangkok, un contador que toma su café por la mañana en Vancouver, un estudiante peruano que aprende inglés, o un investigador en India.

Con tan amplia gama de casos de uso, el diseño tiene que ser lo más cercano a lo “correcto” como sea posible. Es por eso que pasamos meses pensando en la página de las charlas, diseñando, construyendo, deconstruyendo, iterando y probando.

Nuestras intenciones de diseño

Formamos un conjunto de objetivos al principio del proceso de diseño. Estos objetivos reflejaban tanto la dirección en que TED se movía como organización, y lo que hemos aprendido escuchando las necesidades y preferencias de la comunidad de usuarios. Entre la lista de prioridades surgieron.

Una experiencia de video mejorada. Más grande, más teatral, que responda a las condiciones variables de ancho de banda.

Eliminar la reproducción automática. Para permitirte decidir cuándo empezar a ver la charla, y por lo tanto cuando enviar audio a los parlantes de tu PC.

Guardar charlas para verlas más tarde. Una forma de marcar fácilmente las conversaciones que desea ver cuando tenga más tiempo.

Ofrecer más contenido. Presentar otras maneras de aprender más y profundizar en una idea.

Hacer algo en respuesta a una charla. Muchas charlas inspiran la acción. Queríamos ofrecer a los usuarios formas para dar el siguiente paso.

Los primeros diseños

Con nuestra brújula en una dirección estratégica general, exploramos muchas direcciones de diseño con nuestro socio HUGE. Empezamos probando lo que nos pareció que era un candidato fuerte a diseño inicial.

Nos gustó por varias razones. En primer lugar, presenta una gran cantidad de contenido, que nos pareció que agregaba contexto a la idea subyacente a la charla. En segundo lugar, economiza espacio y agrupa el contenido en partes sensibles. En tercer lugar, se desplegaba muy bien en una interfaz de usuario con pestañas en las pantallas de los teléfonos móviles.

Los usuarios de las pruebas entendieron el contenido principal y el propósito de la página: mirar una charla TED. Después de descubrir algunos problemas con sólo cinco usuarios, hicimos ajustes rápidos en el prototipo y continuamos con las sesiones. Fuimos haciendo pequeñas mejoras incrementales.

Pero las pruebas, si las hacemos con eficacia y metodologías enfocadas, son casi garantía de una experiencia sorprendente, así como de un ejercicio de humildad para los diseñadores de productos. Eso es lo que pasó. Nos sorprendió el deleite unánime expresado al ejecutar el muelle de video, una funcionalidad que sigue mostrando una pequeña versión del video mientras uno se desplaza arriba y abajo de la página en las pantallas de escritorio.

Algo que pensábamos podría molestar a los usuarios, fue adorado casi universalmente. Pero luego, un baño de humildad. Surgió un problema grave recurrente: los usuarios estaban abrumados y desorientados por el contenido a tres columnas por debajo del área de video. Una página que comenzó fuerte y con un propósito bien determinado se sumió rápidamente en el caos conforme los usuarios trataban de absorber el contenido de la página.

Iteramos, ajustamos, usamos algunos trucos de diseño y recursos visuales. Incluso cambiamos contenido, pero nuestros esfuerzos simplemente no produjeron los resultados necesarios.

Golpe de timón

A veces, cuando uno gira en torno a algo mucho tiempo sin lograr suficientes avances medibles, tiene que considerar los costos irrecuperables y explorar nuevas opciones.

Conservamos lo que sabíamos que funcionaría: el reproductor de video y sus características asociadas. Pero abandonamos el diseño de contenido a tres columnas del diseño inicial en favor de una estructura de contenidos más apilada. Los denominamos “panqueques”.

¿Por qué fuimos en esta dirección? Había algunas cosas que necesitábamos controlar mejor...

Flexibilidad del tipo de contenido y volumen

Muchas charlas TED tienen una amplia gama de contenido editorial complementario y de otro tipo que realza la absorción por parte del usuario de la idea del orador. Otras charlas pueden no tener nada de esto. Así que cualquier diseño que adoptáramos debía estructurarse para escalar físicamente hacia arriba y abajo de esta manera. Las columnas son rígidas. Pueden quitarse o añadirse “panqueques” y la página mantiene su unidad. Los panqueques también hacen más predecible la ubicación de contenido en condiciones de “diseño adaptativo”.

Flexibilidad del contenido en el tiempo

Cuando se publican las charlas TED, siguen ocurriendo cosas. Se crea más contenido tanto dentro como fuera de TED.com. El orador da entrevistas, se escriben artículos sobre la charla o el tema. El diseño reestructurado soporta mejor soporta las adiciones de contenido en el tiempo.

Control de la narrativa

Agrupar el contenido similar en pilas estratificadas nos permite controlar la narrativa de la página conforme uno la va recorriendo. Se alineaba mejor con la priorización de contenidos que describimos al principio del proyecto. Queríamos guiar la experiencia del usuario de una charla: mirar y compartir, aprender más sobre la idea, entrar en acción si la charla nos inspirada, y discutir la idea con la comunidad de TED.com. Otro modo ofrecido en este abanico fue el descubrimiento de otro contenido (tunneling).

Quizá sea más instructivo mostrar el resultado final en lugar de cada iteración (confía en mí, había un montón) del proceso. Así se ve hoy la página de las charlas.

Diseño continuo

Pensamos la página de charlas en su estado actual más como algo en desarrollo que una línea de meta. El diseño es un ejercicio continuo de escuchar y responder a la retroalimentación, a las pruebas, a los datos, y a nuestros propios instintos. Como resultado, la funcionalidad o el contenido probablemente serán modificados, añadidos, o incluso eliminados por completo. La única vara de medir que usamos en nuestras decisiones de diseño, sin embargo, es la pregunta: ¿Lo que estamos haciendo contribuye a la difusión de ideas? Si la respuesta es no o es incierta, por lo general no pasan de la fase discusión de ideas. Si la respuesta es sí, es probable que obtenga los recursos y le demos una segunda vuelta en profundidad, siguiendo el espíritu de la misión de TED.

Analizando las OLPC mediante heurísticas de usabilidad18

Texto: Ivana Harari y Paola Amadeo

Ivana Harari es especialista en Docencia Universitaria de la Universidad Nacional de La Plata (UNLP, 2012). Tesis en desarrollo del Master en Redes de Datos de la UNLP. Es además licenciada en Informática (UNLP, 1992) y docente-investigador III, en DUX, Interfaces Móviles y Accesibilidad Web. También se desempeña como Directora del Área de Accesibilidad de la Facultad de Informática de la UNLP, desde 2010. Integrante Cooperativa IACOOP, desde 2014. Profesora Adjunta por concurso en la UNLP, desde 1998 y asociada desde 2015. http://ar.linkedin.com/in/ivanaharari

Paola Amadeo es magister en Entornos Virtuales de Aprendizaje, Virtual Educa – OEI – OEA. Es además Profesor Docente Autorizado de la Universidad Nacional de La Plata, UNLP 2007. Tesis en desarrollo del Doctorado en Ciencias Informáticas. Es además licenciada en Informática (UNLP, 2001) y Docente-investigador III, en Educación a Distancia, Tecnologías Aplicadas a Business Intelligence y Accesibilidad Web. Su cuenta de twitter es @pulamadeo.

1. Introducción

El proyecto OLPC “One Laptop Per Child”19 nace en el año 2005, en el Media Lab de MIT, Laboratorio de Medios del Instituto Tecnológico de Massachussets, EEUU. Su objetivo fue desarrollar una computadora portátil de bajo costo para ser utilizada por los niños en el proceso de aprendizaje.

El equipo de desarrollo de las OLPC ha adoptado un escritorio de trabajo especialmente diseñado denominado Sugar sobre Fedora Core. Sugar es el núcleo de la interfaz del usuario de las OLPC y presenta una metáfora de escritorio original y divertido. Posee características icónicas en el diseño de los conceptos y aplicaciones e incentiva la interacción grupal.

Muchos estudios se han desarrollado sobre las OLPC y Sugar, como es el caso de la Facultad de Informática de la Universidad Nacional de La Plata, en donde el Laboratorio de Investigación en Nuevas Tecnologías Informáticas LINTI han llevado a cabo diversas evaluaciones sobre las OLPC como testeos de usabilidad a más de 100 niños de escuelas primarias 20 y en donde se han propuesto alternativas al escritorio de Sugar como la distribución local basada en Lihuen GNU/Linux.21 En este trabajo se realizará una evaluación de Sugar analizando la usabilidad de su interfaz del usuario en base a un set de heurísticas y principios básicos sobre calidad de uso.22 Se hará un recorrido general sobre las OLPC analizando dichas heurísticas y puntualizando algunos problemas de interacción detectados.

Las OLPC testeadas en esta oportunidad tienen un software 13.1 para XO 1.5 y una versión de Sugar 0.97.8.23

2. ¿Qué es una evaluación heurística?

Una evaluación heurística es un estudio llevado a cabo por profesionales expertos en la temática y problemática de Interacción Hombre Computadora (habitualmente referenciada con las siglas HCI) teniendo en cuenta principios fundamentales del buen diseño de la interfaz del usuario.24 Estos principios ponderan la interfaz que está siendo evaluada con lo que creen que será la interacción de los usuarios con distintos perfiles. Los usuarios o la comunidad en la que está dirigido el proyecto, en este caso lo niños, no participan en este tipo de evaluaciones.

La evaluación heurística fue presentada inicialmente por Nielsen y Molich en el año 199025 y cuatro años más tarde minimiza la lista a 10 principios generales y elementales.26 Estos principios han sido incluidos en numerosas listas de comprobación como la utilizada para evaluar las interfaces web de Xerox Corporation27, y se ha extendido a interfaces basadas en web, como los principios heurísiticos redactados por Keith Instone en 1998 y revalidados en el 2001, los redactados por Nielsen y Tahir28 para las páginas de inicio de un sitio Web y aún hoy están vigentes en el apartado de web usability del sitio web Nielsen Norman Group.

A continuación, se presentan los principios básicos de usabilidad considerados en este estudio, basados en los principios presentados por los distintos autores mencionados, entre otros, y la experiencia de las autoras en evaluaciones heurísticas realizadas con anterioridad.

Simplicidad y fácil utilización

Representatividad y expresividad de los conceptos impartidos en la OLPC

Flexibilidad y cuestiones de Performance

Confiabilidad y consistencia en las OLPC

El feedback en las OLPC

Cuestiones de Adaptación

La Asistencia en las OLPC

Accesibilidad

En las próximas secciones, se hará un recorrido por estas recomendaciones de usabilidad, analizando tanto ventajas como problemas de diseño encontrados.

2.1. Simplicidad y fácil utilización

Un sistema debe ser simple de utilizar y de rápido aprendizaje, más aún si la comunidad a la que está destinado es la de los niños. Los usuarios no deberían esforzarse por utilizar y comunicarse con el sistema.

Una de las características importantes de simplicidad es que la interfaz sea intuitiva y expresiva, brindando información al usuario en cada momento para incentivar la realización de acciones correctas.

En este sentido, cuando entramos por primera vez a una OLPC observamos una interfaz del usuario original y atrayente. Posee en su sector central, el símbolo de una persona y varios íconos alrededor de ella conformando una espiral, como se muestra en la Figura 1.

Figura 1. Persona y actividades en las OLPC.

Si nos detenemos en esta pantalla, podemos notar que la misma no posee ningún título ni una descripción de lo que en ella se puede hacer, información que sería útil al usuario para comenzar la interacción.

Además, las imágenes no tienen una descripción asociada, a menos que se pase el cursor del mouse por encima de ellas y, si se mantiene en ese lugar por más de unos segundos, aparecerá un menú de opciones

Hay veces, que las actividades29 se inician cliqueando en el ícono que la representa o en algunos casos, yendo a su menú y cliqueando en el nombre de la misma que aparece entre las opciones.

Esta acción no es tan intuitiva ni tampoco está informada previamente. Esto hace que se consuma un tiempo considerable en entender el ambiente. Es imprescindible leer la documentación previamente, o tener alguna persona que explique el ambiente en forma general.

Por el tamaño del ícono central XO y su ubicación destacada, es lo primero que se intenta tocar [ver Nota al pie 20]. Como mencionamos antes, al mantener el cursor del mouse encima del objeto, aparece un texto y al rato aparece un menú con opciones. En este caso, el texto corresponde al nombre del usuario y en el menú de opciones, se presentan funciones específicas al usuario como Mis Ajustes pero también, otras propias del sistema como Apagar y Reiniciar, que deberían estar en un lugar más visible. Encontrar el Apagar el sistema dentro del ícono que representa al usuario no es tan evidente.

La recomendación de que todo sistema, aplicación, actividad, estado y transacción debe contar con salidas evidentes, es un principio básico de usabilidad.30 El usuario debería poder salir de todos los contextos del sistema en forma sencilla.

El diseño de las OLPC invita a la exploración libre, donde el niño puede incursionar por varios sectores. Pero esta cualidad debe estar acompañada por una funcionalidad básica, que es la de poder salir fácilmente de los diferentes contextos en donde el usuario puede hallarse, y que esta función de salida, sea representada y ubicada de una manera coherente y distintiva.

En las OLPC, no todas las actividades cuentan con el ícono de Salir o Parar la misma. Un ejemplo de esto es el Diario.31 En la Figura 2, se muestra la imagen de la barra superior del Diario que no cuenta con la opción de Salir.

Figura 2. Barra superior del Diario.

La forma de salida en algunas actividades que no cuentan con un ícono específico, es complicada e implica varios pasos, que el niño debe realizar y memorizar, como ser:

Visualizar el marco de las OLPC, presionando el botón rectángulo del teclado.

Ir al borde superior para activar vista Hogar, presionando el ícono:

Intentar identificar la actividad a cerrar, cuando se da el caso de existir varias instancias de una actividad. En algunos casos esto implica, ingresar a cada una de ellas.

Una vez que se distinguió la actividad a cerrar, hay que volver al marco superior y presionar en el icono de la actividad.

Presionar con el botón derecho, el icono cruz, como en la Figura 3.

Figura 3. Menú contextual de una actividad abierta.

Otra de las características que hacen a la simplicidad, es proveer el lenguaje del usuario, sin usar palabras extranjeras ni técnicas. La ayuda, cuyo acceso debería estar siempre presente en todos los contextos del sistema y debería ser fácil de ubicar y entender, se encuentra representada con el término inglés Help. También en este contexto, se utiliza la palabra Home para representar el término Hogar.

Hay actividades o sectores en las OLPC donde la ayuda32 es sumamente necesaria, pero en realidad está ausente. Por ejemplo, en el Diario, donde se encuentra todo el manejo y administración de trabajos que el niño realizó en sus diferentes sesiones de interacción, el mismo no cuenta con ningún tipo de asistencia. Para poder hallarla, el niño debería realizar pasos que lo sacan totalmente del contexto en donde se encontraba. Por ejemplo, debería hacer:

Salir del Diario con el que estaba trabajando.

Ir a la ventana principal.

Buscar la actividad de ayuda referenciada como Help.

Recorrer y explorar toda la wiki para poder encontrar algún tipo de información de lo que estaba haciendo.

Salir de la ayuda.

Ir a la ventana principal.

Retomar el Diario.

2.2. Representatividad y Expresividad de los Conceptos impartidos en las OLPC

Las OLPC utilizan íconos en la mayoría de los contextos. Los íconos bien diseñados permiten reconocimiento automático del concepto que subyace detrás del símbolo. Además, simplifican la interacción pues el usuario manipula directamente las representaciones fieles de los objetos.

La representación e interacción icónica debe estar cuidadosamente diseñada, para que dichas cualidades se logren. En caso contrario, un diseño icónico inapropiado puede complicar la interacción del usuario con el sistema ya que deberá trabajar con representaciones dudosas, probar con recelo dichos íconos para poder recién comprenderlos [ver Nota al pie 23].

La representación visual utilizada en el ambiente Sugar debería aprovechar las cualidades del diseño icónico y ser lo más entendible posible como para que el niño pueda reconocer inmediatamente los conceptos impartidos. Los íconos empleados en el sistema tienen que reducir la distancia semántica entre los objetos modelados y los objetos reales, permitiendo un fácil reconocimiento de los mismos.

Hay símbolos provistos en las OLPC cuyo significado no es tan simple de entender. Por ejemplo, los íconos que se muestran en la Figura 4, que son muy utilizados en el sistema, no permiten un reconocimiento instantáneo del concepto que representan.

Figura 4. Algunos íconos de las OLPC.

La utilización de íconos como medio de representación, impone una visualización que debe ser entendida más allá de la nacionalidad, costumbres e idiomas de los usuarios. Todo niño debe entender el concepto que se transmite a través de la imagen icónica [Ver Nota al pie 23].

Hay otros casos de íconos que no son muy comprensibles a simple vista y que, mediante prueba y error se termina entendiendo la finalidad de los mismos. Por ejemplo, el ícono Estrella utilizado en las actividades visualizadas desde la Vista Lista. El ícono Estrella se visualiza en la Figura 5, al principio de la imagen.

Figura 5. Icono33 estrella.

Al situar el cursor por encima de una estrella, no aparece ningún texto explicativo sobre su funcionamiento. El niño deberá descubrir que la misma es cliqueable, generando un efecto de estrella coloreada cuando la misma fue cliqueada.

El usuario asocia entonces, que la estrella totalmente pintada significa que fue seleccionada y la estrella sin relleno denota que aún no se seleccionó. Esta interacción de seleccionar la estrella no tiene ningún otro feedback que el coloreo de la misma. En ningún momento el sistema avisa que dependiendo del estado de dicha estrella, la aplicación que se encuentra al lado de la misma, pasa a ser una actividad Favorita o no.

Además, el menú contextual respectivo para hacer o no favorita a una actividad, se encuentra asociada al ícono que representa la actividad y no al texto de dicha actividad ni siquiera a la estrella misma.

Para los conceptos de Vecindario y Grupo, no se utilizan íconos que representan estas relaciones humanas fielmente, en cambio, se utilizan combinaciones de puntos. Entender que esos puntos representan a humanos no es tan comprensible a simple vista, como se muestra en la Figura 6.

Figura 6. Icono Vecindario y Grupo.

Además, esto se hace confuso puesto que a veces el humano está representado como un punto dentro de ciertas partes del sistema, pero muchas veces está representado con el ícono de una persona o XO.

Encontrándose en las vistas de Vecindario y Grupo, también resulta costoso entender el significado de algunos íconos que representan ciertas funcionalidades. Por ejemplo, en el menú contextual de un amigo. Allí aparecen dos íconos que no son muy claros, uno para ingresarlo como amigo y otro para dejar de hacerlo (ver Figura 7). Al principio, será necesario probar estas acciones o consultar el manual para averiguarlo.

Figura 7. Iconos del menú contextual sobre un Amigo.

También, es importante que los íconos estén acompañados siempre por un texto descriptivo.34 El texto es un medio de comunicación que aún se encuentra vigente y que toma preponderancia en las recomendaciones sobre Accesibilidad [ver Nota al pie 39]. El texto debería acompañar siempre las representaciones visuales o multimediales. El empleo del texto permite que cualquier herramienta de adaptación informática para usuarios con discapacidad como lectores de pantalla, lectores de documentos, pueda ser utilizada.

En la mayoría de las veces, los íconos de las OLPC tienen texto descriptivo que aparece sólo cuando el cursor se encuentra encima del mismo, pero igualmente, se han detectado casos en donde esto no sucede, como ser en algunos íconos de las actividades de Info Slicer, Libros, Pintar, entre otros.

2.3. Flexibilidad y cuestiones de Performance

La interfaz icónica debería trabajar en dos aspectos. Primero, minimizar el gap o distancia de ejecución, o sea minimizar los costos de llevar a cabo una acción. Y segundo, acortar el gap de evaluación, que implica minimizar los costos y el esfuerzo de un usuario en interpretar el estado del sistema. Las tareas que el usuario tenga en mente deberían poder ser realizadas en forma inmediata, estableciendo una correspondencia directa entre la forma natural de llevarla a cabo, con la forma requerida por el sistema.

Es importante que el sistema permita un manejo directo, ágil y dinámico por parte de los niños, pero, en ciertas circunstancias, la realización de acciones elementales se torna pesada.

Por ejemplo, cuando el niño realiza diferentes trabajos con una misma actividad, éstos se listan en el sector superior. Los mismos se visualizan con el mismo ícono de la actividad para todas estas instancias de trabajo. Si el usuario quiere volver a retomar uno de los trabajos que quedó pendiente, por ejemplo, uno de los documentos que estaba escribiendo, debe recorrer cada ícono que represente la tarea activa de Escribir, ubicar el cursor encima, esperar un rato para que se muestre una descripción, y si esto tampoco lo identifica, deberá ingresar a cada uno de dichos íconos para hallar el documento que quería seguir editando.

Las actividades, ni los trabajos realizados en ellas, carecen de identificación propia,35 y uno debe recurrir a ciertas secuencias de acciones poco naturales, para poder reconocerlas e identificarlas. Además, cuando el número de actividades en uso aumenta, los costos para identificar cada una de ellas son muy significativos.

Lo mismo sucede para detectar cuáles de las actividades que está realizando el usuario son colaborativas y cuáles no. Esta información no se expresa en ningún momento. El usuario tiene que interactuar entre el modo Grupo y el de Hogar, y analizar cuáles actividades que él está realizando, están allí presentes. En el peor de los casos, se deberá ingresar a ellas para analizar que se está tratando de las mismas actividades.

También, si el usuario quiere saber en qué tareas se encuentra su mejor amigo. Estando en el modo Vecindario y a pesar de tener a todo el vecindario presente, encontrar o identificar a uno de ellos, es una tarea bastante ardua, pues requiere pasar el mouse por encima de cada uno y con pausada velocidad, para ver qué nombres se reflejan. Lo mismo ocurre en el panel de amigos conectados, como se muestra en la Figura 8.36

Figura 8. Panel con amigos conectados.

Otro aspecto para mejorar la performance, es el tema de las búsquedas. Es bueno que en todo momento el usuario tenga a disposición el casillero de búsqueda, ya que esto permite que el usuario pueda acceder en forma directa a la funcionalidad o documento que necesite. En la Figura 9, se muestra el casillero de búsqueda disponible en el panel superior de la vista Hogar de las OLPC.

Figura 9. Panel superior con el casillero de Búsqueda.

Para brindar un mejor aprovechamiento de la función Buscar, ésta debe ser flexible, inteligente, detectando posibles resultados según vaya coincidiendo o “matcheando” el texto tipeado. Otro elemento importante es que se transmita al usuario qué se puede buscar allí y cómo hacerlo, para evitar intenciones infructuosas.

Cuando uno desea buscar alguna aplicación que permita por ejemplo escribir una nota, uno puede utilizar el casillero Buscar. En ese casillero, uno intenta con opciones como “Escribir nota”, “Escribir documento”, “Editar documento”, “Editor de textos”, todos son intentos fallidos donde la pantalla no presenta ningún mensaje o acotación para ayudar al usuario. El Buscar no ofrece un buen feedback. Tampoco muestra nombres de actividades que coincidan con alguna palabra.

Después de varios intentos, se comprobó que la única palabra que el buscador encuentra efectivamente una actividad para editar un documento, es con la palabra “Escribir”. Tampoco permite buscar por nombre de trabajo ya realizado desde las actividades, pudiéndose realizar esto a través del Diario.

A partir de Sugar 0.104, se ofrece autocompletado de los nombres de las actividades en el cuadro de búsqueda.

Otra característica que permite lograr flexibilidad es contar con diferentes mecanismos para realizar las acciones, es decir poder interactuar con el mouse mediante manipulación directa, pero también con el teclado mediante las teclas de movimiento, de tabulación o combinaciones de teclas.

En el caso de las OLPC, los listados de actividades o en el Diario, no permiten el uso del teclado. Las teclas de movimiento para recorrer dichos listados se encuentran deshabilitadas. La única manera es el uso del scrolling. Esto se muestra en la Figura 10.

Figura 10. Listado de actividades.

Siguiendo con el análisis de la eficiencia y flexibilidad en la ejecución de las tareas, y después de varias sesiones de trabajo con el sistema, se han detectado secuencias de acciones complicadas que el niño debe realizar en pos de llevar a cabo una intención sencilla.

Es muy interesante que las OLPC hayan creado un diseño innovador para el manejo de archivos. Se reemplaza el sistema de archivos tradicional, por el contar con una lista de objetos guardados donde los mismos son trabajos asociados a actividades. En estos casos, también se indica cuándo fueron creados o modificados.

Pero el manejo de dichos objetos no es tan simple, por ejemplo el enviarlos a un pendrive o al imprimirlos. Todo apunta a que estas acciones están disponibles con el menú contextual de los mismos, pero no es así. En el caso de querer guardar un trabajo en un pendrive, involucra demasiados pasos que no están informados previamente, como ser:

Guardar previamente el trabajo en el Diario desde la actividad en donde se encuentre.

Irse de la actividad para acceder al Diario.

Ir al Diario a buscar el trabajo.

Montar el pendrive y asegurarse que el dispositivo esté montado. Esto se hace observando visualmente que un ícono que represente al pendrive se encuentre en la parte inferior del Diario.

Cliquear puntualmente en el nombre del trabajo y arrastrarlo al ícono del pendrive que se encuentra en la parte inferior del Diario.

Las OLPC muestran un pequeño ícono del documento encima del dispositivo USB. El mismo casi es imperceptible si el cursor se encuentra encima. Cuando dicho ícono desaparece, la transferencia culminó, pero no hay ningún mensaje aclaratorio de cierre de dicha acción.

Esta secuencia de acciones es complicada, porque existen ciertos factores como falta de información textual, exigencia de una buena precisión y excelente dominio del mouse, cambios de contexto, interacción únicamente a través de manipulación de íconos, que en definitiva hacen imposible llevar a cabo las intenciones que el usuario tenga en mente en forma sencilla y eficiente.

El manejo del Diario fue mejorado ampliamente en la versión 0.100 de Sugar, con la implementación de operaciones sobre múltiples elementos.

2.4. Confiabilidad y Consistencia en las OLPC

En un diseño icónico hay que prestar especial atención respecto a la consistencia. Como la forma de comunicación de un concepto es a través de la imagen, la misma no puede ser ambigua, ni confusa y debe permanecer consistente a lo largo de todo el sistema.

La ambigüedad sucede cuando dos o más conceptos son representados visualmente en forma similar y casi idéntica, o puede ocurrir cuando un mismo concepto es visualizado con dos imágenes diferentes.

En el caso del ícono estrella de la Vista Lista de Actividades, la misma representa el significado de Favoritos, en cambio hay varias actividades que la utilizan para el concepto de Crear. A su vez, este concepto de crear un objeto también se encuentra representado por varias imágenes diferentes a lo largo de las distintas actividades disponibles.

Para evitar esta confusión, se reemplazó en las versiones subsiguientes la estrella por la chispa como metáfora de creación.

Hay muchos íconos que se utilizan en las OLPC que son mayoritariamente combinaciones de figuras geométricas. Un cuadrado blanco dentro de un círculo negro, un círculo negro sobre un círculo blanco o un cuadrado gris dentro de un círculo blanco, son figuras similares que dicen muy poco de la funcionalidad que pueden representar. Esto puede confundir al usuario y deberá esforzarse para recordar sus significados y además, analizando el contexto donde se encuentran.

Por ejemplo, la imagen de un cuadrado negro dentro de hexágono blanco es usada para salir de una actividad pero también tiene otro significado en otro contexto, como ser en el editor, que es utilizado para parar la voz del lector de textos.

También el concepto Parar tiene diferentes imágenes que lo representan, a veces se utiliza el ícono y en otras aplicaciones se encuentra el ícono .

Con respecto a la Ayuda, ésta debería estar siempre presente, tener un ícono único y un lugar ya preestablecido dentro de las actividades.

En la Figura 11, se muestra la ayuda a la izquierda como en la actividad Etoys, otras veces a la derecha como en la actividad Tortuga, y otras directamente no se encuentra, como en la actividad Memoria.

Figura 11. Inconsistencia en la ayuda entre varias aplicaciones.

En las imágenes anteriores, también podemos observar a simple vista ciertas inconsistencias como ser, que en algunas actividades falta el ícono representativo de las mismas, que es importante porque constituye un menú con funciones internas cuando el mismo es cliqueado. En la misma Figura 11, se puede observar que la actividad Tortuga tiene su ícono representativo mientras que las demás no.

También en la Figura 11, se muestran algunas actividades que presentan menús textuales como es el caso de la actividad Memoria, pero en las otras actividades, los menús son icónicos.

En las versiones sucesivas de las OLPC, se trabajó mucho para hacer más consistentes las barras de herramientas.

La consistencia hay que analizarla en todos los contextos del sistema, y es abarcativa a todos los elementos de la interfaz. No sólo los íconos que representan estados, objetos y actividades deben ser consistentes sino también qué sentido se da al color, a los tamaños, a los espacios y sectores de la pantalla. Todo debe estar pensado con una lógica determinada, manteniendo homogeneidad a lo largo de todo el sistema.

Por ejemplo, el Guardar como PDF lo podemos encontrar en la barra superior de algunas actividades pero en otras, allí no se encuentra. Se debe recorrer el menú superior y hallarlo internamente dentro de una de sus opciones desplegables.

En la actividad Etoys, en la de Distancia, Obras o Palabras, también presentan ciertos íconos en la barra superior como ser los íconos Descripción o Privado, que en otras actividades se encuentran en el menú interno del ícono que representa la actividad.

De igual manera hay otras características no consistentes, como ser:

El manejo de guardar o abrir un trabajo no está estandarizado en el contexto de las OLPC.

Hay sectores donde encontramos íconos con menús asociados y teclas asignadas, pero otros íconos con apariencia similar, no tienen ni menús contextuales ni combinación de teclas asociadas.

Hay actividades que contienen íconos de maximizar la actividad a pantalla completa y otros no, donde se debe acudir al teclado para lograrlo.

Se presentan también casos donde hay mucha similitud en el diseño visual de dos conceptos muy diferentes, como ser el de búsqueda y el del título de la actividad. Tienen apariencias muy similares, están ubicados en el mismo sector, cuando en realidad el sentido de los mismos es muy diferente.

En la Figura 12, se observa el casillero de título de la actividad y el casillero de búsqueda.

Figura 12. Casilleros similares con funciones distintas.

Siguiendo con el mismo ejemplo anterior, se puede mencionar que el casillero de título de la actividad se utiliza para referenciar el trabajo que se está haciendo con ella. Esto no es tan intuitivo y cuesta pensar que para nombrar un trabajo se deba editar el título de la actividad que se está utilizando [Ver Nota al pie 20].

Además, hay búsquedas que son casilleros de edición con el título Buscar a su izquierda mientras que otras no tienen ese texto de acompañamiento.

Actualmente todos los casilleros de búsquedas tienen un ícono con una lupa.

El ícono representado con un ojo en varias actividades despliega un menú con opciones para realizar zoom, o sea agrandar o achicar la pantalla como en el caso de Escribir, mientras que en otras tareas se encuentra el mismo ícono pero con otras funciones internas, como en el caso de la actividad Tortuga.

El ícono que representa el concepto de Descripción se encuentra en diversos lugares según el contexto que el usuario se encuentre. A veces está en la barra superior, como es el caso de la actividad Charlar, pero otras veces se encuentra recién al cliquear en el ícono que representa la actividad, como es el caso de la actividad Mapas mentales. Esto se muestra en la siguiente figura (Figura 13):

Figura 13. Icono Descripción sobre la barra y en otros casos dentro del ícono de la actividad.

También, se observan casos donde las mismas funciones presentes en dos actividades distintas, se visualizan y se manejan completamente distintas. En la Figura 14, se observa claramente las diferencias de íconos entre las actividades de Abiword y del Paint para idénticas funciones. En la Figura 14 a) se visualiza la inconsistencia en los íconos de abrir y guardar en ambas actividades y en la Figura 14 b), en los íconos de deshacer y rehacer. En la Figura 14 c), se observa en cambio, las diferencias en el uso y visualización del disco de almacenamiento.

Figura 14. Inconsistencias en el uso y visualización entre el Abiword y el Paint frente a las mismas funciones.

Los problemas de inconsistencia que se mencionan en este informe traen como consecuencia que la confianza que el usuario tenga del producto pueda disminuirse, convirtiendo su forma de interacción en un trabajo de prueba y error.

Cuando el usuario trabaja con representaciones difíciles de distinguir y de comprender, o que visualmente son muy parecidas pero cumplen funciones muy distintas, se encuentra en una situación de total inseguridad e insatisfacción y lo lleva a cometer errores de interpretación.

2.5. El Feedback en las OLPC

El feedback en una interfaz del usuario, representa al diálogo unidireccional que va desde el sistema al usuario. Es información comunicacional que el usuario percibe desde el sistema. Con él, se puede reflejar claramente sobre la pantalla cómo es el estado del software frente a la interacción e intervención del usuario [Ver Nota al pie 23].

El feedback es una técnica indispensable que permite transmitir al usuario las reacciones del sistema frente a sus acciones. El feedback está presente en los mensajes de aclaración, de asistencia, de confirmación, de progreso en los procesos que están en curso, de cierre indicando si una transacción fue culminada correcta o erróneamente, generando en estos casos un mensaje de error. El mal diseño del feedback puede conducir al usuario a realizar acciones erróneas que son difíciles de solucionar [Ver Nota al pie 26].

En el caso del feedback asociado al manejo de Favoritos que presenta las OLPC, es confuso. Si el usuario elige Borrar Favorito, el sistema muestra un mensaje preguntando si quiere borrar la actividad en forma permanente. En principio, el querer borrar un favorito no implica querer borrar la aplicación entera, provocando una desinstalación del software, como sucede en este caso.

Además, ante la pregunta de “Si quiere borrar…” denota una respuesta por Sí o por No. En el caso particular que estamos mencionando, las respuestas presentadas son Guardar y Borrar. Encima el Guardar tiene un ícono al lado de cruz, y el Borrar con el ícono al lado de tilde, como si fuera una opción divertida, cuando en realidad desinstala la actividad en cuestión.

Se nota la falta de feedback también en casos más simples como el de poner un nombre a un trabajo realizado en una actividad. No hay ningún mensaje que así lo explique, está el casillero de edición con el nombre de la actividad pero sin ningún título asociado o texto descriptivo. Es necesario consultar al manual para comprender el sentido de los objetos presentes en la pantalla.

Tampoco se nota la presencia de feedback cuando uno guarda un objeto, publica, lo guarda en distintos formatos o después de quitar un usuario. El usuario no cuenta con información si estas acciones fueron realizadas correctamente o no. Algunas aplicaciones, como la de Etoys, al salir te pregunta si quieres abandonar el proyecto pidiendo confirmación, pero en otras actividades esto no sucede.

Además, en las OLPC no se observa comúnmente la utilización de feedback para prevención de errores. Hay situaciones donde los íconos de actividades están habilitados y no tiene sentido utilizarlos. Por ejemplo, es el caso del Chat, que se encuentra habilitado y te permite utilizarlo siendo uno, el único usuario en la red.

Otro caso que también está relacionado con el feedback, es que en ciertas circunstancias al operar las OLPC se puede detectar la presencia de íconos iguales. Ante esto, el sistema debería mostrar sobre la pantalla una manera de identificarlos sin necesidad de poner el foco en cada uno de ellos. Por ejemplo, en los entornos de Vecindario o de Grupos, se muestran muchos íconos XO, algunos con colores muy similares donde el sistema no presenta ante el usuario ninguna aclaración, apodo, o nombre para poder identificar a la persona que representa, a simple vista.

Lo mismo sucede cuando se realizan trabajos distintos con una misma actividad y estos permanecen activos. En este caso se visualizan todos en la barra superior, representados con un mismo y único ícono, el de la actividad, como se muestra en la Figura 15.

Figura 15. Iconos de la actividad Escribir.

También se puede observar íconos idénticos y sin ninguna distinción entre ellos en el portapapeles cuando se copia elementos desde una misma actividad. En las versiones sucesivas, se mejoró la visualización del portapeles mostrando su contenido.

Por último, se puede decir que se nota la ausencia de feedback en situaciones donde sería importante su utilización. Por ejemplo, un usuario puede apagar el sistema y no te avisa que las actividades que estaban abiertas se cerrarán y que quedarán registradas en el Diario.

2.6. Cuestiones de Adaptación

La comunidad de personas a las que están dirigidas las OLPC es muy amplia. Las mismas pueden ser utilizadas por niños con diferentes niveles de formación, experiencia, nacionalidad, cultura, idioma y costumbre. También surgen los roles del padre, maestro, directivo que también deberían ser contemplados como posibles usuarios finales.

La diversidad de las características que presentan los posibles usuarios del sistema, hace a la necesidad de proveer mecanismos de adaptación que reconozcan distintos perfiles de usuarios.

Funciones de personalización del sistema, de configuración tanto de aspectos visuales como de contenido e interacción, identificación de roles, adaptación de elementos de la interfaz según hábitos o patrones detectados en las sesiones, constituyen las características esenciales de un sistema con signos de adaptación.

Las OLPC no proveen características de adaptación. Esto hace que un usuario novato no tenga asistencia alguna, ni guías de recorrido ni sugerencias, mientras que para los niños que ya estén expertos en el uso, no permiten modificar cosas de lugar, generar macros, agilizar el diálogo icónico ni personalización.

2.7. La Asistencia en las OLPC

Todo sistema de interacción para uso humano debe contar con mecanismos de ayudas y asistencia. Puede proveerse una ayuda general de todo el sistema como sucede en las OLPC a través de la actividad Help, pero también es necesario contar con asistencia en todos los ámbitos o contextos en donde el usuario se encuentre.

Las actividades deben tener una funcionalidad de ayuda, las transacciones, las secuencias de interacción complejas requeridas a veces por el sistema, los recursos que se proveen o los objetos que se perciben, deben estar acompañados también por mensajes explicativos que guíen y conduzcan al usuario a la realización de interacciones correctas [Ver Nota al pie 23].

No todas las actividades que funcionan sobre las OLPC cuentan con ayuda, y en algunos casos, la misma se encuentra en inglés como es el caso de la actividad eToys (Figura 16).

Figura 16. Actividad de eToys con ayuda en inglés.

Estas cuestiones de inconsistencia y de uso de lenguaje técnico y foráneo dificultan notablemente la interacción, causando más incertidumbre que asistencia.

2.8. Accesibilidad

La accesibilidad es una condición necesaria para permitir que personas con diferencias sociales, culturales, físicas o técnicas puedan acceder a un servicio, información o producto sin que medien exclusiones de ningún tipo.

La accesibilidad en un sistema de software es una característica que se manifiesta principalmente al proveer diferentes medios para poder acceder a la información, a las funciones o para desarrollar una actividad. Brindar alternativas de acceso por teclado o por mouse, disponer de ayudas técnicas como teclados virtuales, magnificadores o lectores de pantalla o permitir el uso de las mismas, también brindar diferentes mecanismos para mostrar la información tanto mediante imágenes, video, texto o sonido, son características que hacen a un sistema accesible.

Que el sistema funcione totalmente con el teclado habilita muchos escenarios de interacción en el que un usuario con discapacidad pueda encontrarse. Permite que el usuario pueda operar el sistema mediantes teclados especiales, teclados braille, de una sola mano, en el caso de personas con problemas motrices. Las personas invidentes también trabajan con la PC utilizando sólo el teclado pues es la única manera que tienen para recorrer las pantallas.

El que funcione completamente sólo con el mouse, permite que personas que utilizan pulsadores, sistemas de barrido o mouse controlados por la cabeza, por el pie o mentón, puedan utilizar el sistema sin quedar excluidos del mismo.37

Analizando la accesibilidad de las OLPC, podemos puntualizar los siguientes comentarios:

Hay sectores de la OLPC en que no funciona el teclado. Las teclas de arriba, abajo, tabulador, están inutilizadas. En algunos contextos estamos observando una lista de elementos como en la vista de lista de actividades.

Hay actividades como el de Tam Tam, que permite recorrer los instrumentos con el teclado, pero el resto de las secciones de dicha actividad, el teclado está deshabilitado como se observa en la Figura 17.

Hay actividades que presentan la función Decir, pero sirve para leer oralmente un texto seleccionado. Esto para una persona invidente es muy difícil de utilizar, en primera instancia porque se complica seleccionar texto cuando uno no puede visualizar la pantalla. Lo importante es disponer de un lector o permitir su uso en todos los sectores del sistema, no solamente para leer el texto escrito y seleccionado previamente.

No provee funciones de accesibilidad para darle sonido a las teclas, configuración de velocidad de teclas repetidas, existencia de teclado virtual, entre otras cuestiones.

Figura 17. Actividad de Tam Tam no accesible completamente con el teclado.

Cuestiones de usabilidad como la consistencia y simplicidad también benefician notablemente al usuario que presenta alguna discapacidad. Que las actividades estén estructuradas de la misma manera, con un diseño coherente, con sectores bien definidos, ayuda sobremanera la interacción con el sistema.

3. Conclusiones

El proyecto OLPC intenta introducir un cambio radical en la manera de plantear las actividades a los alumnos, tanto las que se deban realizar en clase como en el hogar. A través de un escritorio de trabajo visual, atrayente e innovador provisto por la interfaz del usuario de Sugar, se trata de capturar a los niños e incentivarlos a la realización de actividades que lo ayuden a su formación. Esto permite que los niños se “apropien” de las computadoras y puedan acercar la tecnología también a sus hogares.

Este artículo intenta analizar las OLPC desde la perspectiva de la interacción hombre-computadora mediante el desarrollo de una evaluación heurística de usabilidad.

Se realiza un abordaje sobre las recomendaciones básicas de usabilidad y realiza un recorrido por el sistema analizando su aplicación y cumplimiento, mostrando aspectos a mejorar.

Garantizar usabilidad en sistemas de uso masivo es imprescindible para asegurar el mejor aprovechamiento posible de las potencialidades que ofrecen las OLPC, permitiendo que los usuarios puedan desenvolverse con el sistema en forma simple, contenida y eficiente, haciendo que la experiencia sea gratificante.

Realizar evaluaciones de usabilidad mediante tanto métodos de inspección como los de indagación son esenciales para garantizar la calidad de uso del software interactivo que se va a poner en producción, y deben incorporarse en las prácticas habituales de la Ingenería de Software, dentro de un marco metodológico apropiado.

4. Glosario de términos

Interfaz del Usuario: Es la componente del sistema interactivo encargada de proveer y solventar la comunicación bidireccional entre el usuario y el sistema. Es el medio que permite a una persona comunicarse con una máquina. Está compuesta por los puntos de contacto entre un usuario y el equipo.

Ícono: Es un símbolo, una imagen que tiene sentido o significado subyacente. Constituye un par conformado por la parte semántica o lógica que denota su significado y la parte física representada por la imagen del mismo. Presenta un diseño representativo y significativo al objeto, función o estado del sistema al que alude.

Sistema operativo: Un sistema operativo es el software encargado de administrar todos los recursos de hardware del sistema. Ejerce el control y coordina el uso del hardware entre diferentes programas de aplicación y los diferentes usuarios. Ofrece un ambiente en el cual el usuario puede ejecutar programas y utilizar los recursos, abstrayéndose de los detalles y complejidades del hardware.

Sugar: Es la interfaz gráfica de usuario desarrollada para el proyecto de las OLPC. Es el núcleo que soporta el diálogo humano-computador amigable y simple, y la interacción grupal.

Feedback: Es el diálogo unidireccional que va del sistema interactivo hacia el usuario. Es la respuesta del sistema frente a las acciones del usuario. Estas respuestas pueden ser visuales o textuales y expresan el estado final del sistema ante eventos realizados.

Notas

18 El trabajo de comentar este artículo tuvo como meta contribuir a la comprensión total de cómo se realiza un proceso heurístico, yendo al encuentro entre especialistas, usuarios y desarrolladores. Nos parece apropiado aportar desde el punto de vista crítico, cuestionando la labor y los métodos científicos, para enriquecernos y mejorar los métodos de inspección. El proceso heurístico genera obligados encuentros multidisciplinares (de investigación-acción) que de ser efectivos y permanentes podrían llevar a la mejora de interfaces y sistemas operativos. En este punto, es loable aclarar la predisposición de las autoras que aceptaron ser interpeladas, así nos queda por agradecerles su humildad, generosidad y paciencia.

19 OPCL es el proyecto, no el software. Se tiende a llamar OPCL a las laptos, aunque el nombre es XO, siendo éste un análisis de accesibilidad/usabilidad del software. Hay que contemplar que Sugar es el nombre del software y el hardware es de las XO.

20 Díaz, F. Javier; Banchoff, Claudia; Harari, Viviana y Harari, Ivana. “OLPC en Argentina: evaluación de usabilidad frente a alumnos de nivel primario”. Publicado en el IX Workshop de Investigadores en Ciencias de la Computación, WICC IX, Universidad Nacional de la Patagonia. Págs. 753-759.

21 La versión testeada de Sugar no tenía la traducción completa por ser una versión en desarrollo. Hoy Sugar está traducido al castellano íntegramente (http://translate.sugarlabs.org/). Sugar sigue un ciclo de desarrollo de seis meses, siendo las versiones estables los números pares, y las versiones impares son de desarrollo. Sugar 0.97.8 fue una versión intermedia en preparación a 0.98, luego vinieron 0.100, 0.102, 0.104, 0.106 y ahora estamos trabajando en 0.107 que será distribuida a los usuarios como 0.108. La discusión del diseño es abierta, proponiéndose “Features”, mediante un proceso preestabecido. Las features implementadas en cada release, http://wiki.sugarlabs.org/go/0.100/Feature_List.

22 Díaz, F. Javier; Harari, Ivana y Amadeo, Paola (2013), “Guía de Recomendaciones para Diseño de Software Centrado en el Usuario”. Edulp, Editorial de la Universidad Nacional de La Plata.

23 Este artículo ha sido actualizado y comentado por Gonzalo Odiard y supervisado por Lorena Paz en septiembre 2015. Ambos son miembros de Sugar Labs Argentina. Gonzalo Odiard es Desarrollador de software freelance (https://ar.linkedin.com/in/gonzaloodiard). Lorena Paz es Investigadora Independiente (https://ar.linkedin.com/in/lorenapaz).

Los comentarios apuntaron a:

Hacer especial hincapié en que la base teórica de la plataforma es la pedagogía constructivista que ocasiona que algunas consideraciones (criterios de usabilidad) no cobren sentido. Sugar y el hardware de las XO (OLPC) han sido diseñados considerando al niño como centro y se propicia que sea él quien se auto guíe en el descubrimiento-aprendizaje, por lo que hay más de una forma de interactuar. Aquí los maestros son facilitadores, la idea madre es que no se les da contenido sino herramientas, propiciando que ello sean creadores.

Proveer información acerca de la labor que realiza la comunidad Sugar en el intercambio permanente con docentes y especialistas con el objetivo de mejorar/adaptar la interfaz. Aportar a la apropiación y el uso de esta plataforma educativa de trabajo colaborativo hecha bajo la filosofía del software libre, el trabajo colaborativo ad honorem.

Cabe reconocer que la accesibilidad es una de las cuentas pendientes en Sugar, pero que sin embargo se están realizando grandes avances y trabajos específicos con niños que presentan algún tipo de discapacidad. Sin embargo, constantes modificaciones y el trabajo en conjunto con ingenieros de electrónica ha permito trabajar con Sugar en escuelas especiales, como lo es el proyecto en Uruguay que lidera Andrés Aguirre.

Muchos de los puntos aquí nombrados sólo son relevantes en términos pedagógicos para comprender un proceso heurístico y de testeo, ya que algunos puntos de las versiones nuevas no fueron analizados. Dentro de nuestro plan de trabajo en 2017 se encuentra el realizar un nuevo estudio de accesibilidad/usabilidad con la última versión de Sugar mediante un trabajo de etnografía áulica en colaboración con los desarrolladores, diseñadores y traductores de Sugar Labs.

En última instancia este trabajo que hemos realizado al momento de compilar el Pioneros y Hacedores II, tiene como meta el contribuir a la comprensión total de cómo se realiza un proceso heurístico, yendo al encuentro entre especialistas, usuarios y desarrolladores. Nos parece apropiado aportar con humildad y generosidad desde el punto de vista crítico, cuestionando la labor y los métodos científicos, para enriquecernos y mejorar los métodos de inspección. El proceso heurístico genera obligados encuentros multidisciplinares (de investigación-acción) que de ser efectivos y permanentes podrían llevar a la mejora de interfaces y sistemas operativos.

24 Nielsen, J., Mack, R. (1994), Usability Inspection Methods, John Wiley and Sons.

25 Nielsen, J., Molich R. (1990), “Heuristic evaluation of User Interfaces”. En Proceedings of ACM CHI, ACM Press.

26 Nielsen J (1995), “Alert Box, 10 Usability Heuristics for User Interface Design”.

27 Usability Techniques. Heuristic Evaluation Activities.

28 Nielsen, J. y Tahir, M., (2001), “La evaluación Hueristica”. En: La interacción persona-ordenador, Universitat de Lleida.

29 Las actividades se pueden iniciar de dos formas. En la home, por defecto, inician continuando el último trabajo que se haya hecho. El menú muestra los últimos trabajos creados y una opción para crear un nuevo trabajo. Desde el “Diario” se puede reiniciar cualquier trabajo realizado anteriormente haciendo click en el icono de la entrada que se seleccione. La vista de lista se considera una vista de administración de actividades, donde se pueden seleccionar las favoritas o desinstalarlas. Un problema que hemos detectado es que por ser similar al Diario, algunos usuarios desinstalaban actividades pensando que borraban un trabajo en particular. Para evitar ese problema, ahora se solicita una confirmación, y es posible configurar actividades que no pueden ser desinstaladas. En Sugar se trata de que el programa usado (en otros ámbitos llamados aplicaciones) sean transparentes al usuario. Se usan verbos (Escribir, Pintar, etc.). Que el chico piense "Voy a escribir un texto". Ver "Actividades, no aplicaciones":

https://help.sugarlabs.org/es/sugar_ui.html#for-parents-and-teachers

Esto tiene sus propias limitaciones, por ejemplo no todo se puede describir fácilmente con verbos.

30 Tatcher, Jim (2006), Web Accesibility: Web standards and regulatory compliance, Berkeley, Friends of ED.

31 Gonzalo Odiard: “Al Diario no se ha diseñado una opción salir porque la idea es que está corriendo todo el tiempo, como las vistas Hogar, Amigos o Vecindario. Otras actividades que no cuentan con un botón Salir estándar son Scratch e Etoys. Ambos son proyectos separados con sus propios procedimientos y no accedieron a modificar su interfaz. Con respecto a otras actividades, en el año 2011 se inició un proceso de unificación de íconos para hacer más uniforme el uso”. http://wiki.sugarlabs.org/go/Design_Team/Toolbar_Catalog

32 Esto fue mejorado ampliamente en la versión 0.102 de Sugar, donde se implementó una ayuda contextual. Presionando alt+shift+h en cualquier pantalla o actividad se abre una ventana con ayuda relativa al contexto (http://wiki.sugarlabs.org/go/Features/Activity_Help). En la versión 0.106, se agregó Help Social, se muestra además de la ayuda, acceso a un foro relacionado con el tema. Hoy en el menú de la actividad (en el marco) se muestra una opción para entrar a la ayuda, y se muestra el Shortcut.

33 Aquí se presenta una gran dificultad: el diseñar iconos que sean entendidos en diferentes culturas.

34 No incluir textos con los íconos fue una decisión de diseño en Sugar, por dos motivos: apuntar a los niños aún antes de que dominen la lectoescritura, y la internacionalización.

35 Cada instancia de la actividad tiene un título. Aunque tiene uno por defecto, es una buena práctica ponerle un nombre relevante. No es algo que el sistema obligue a hacer, sin embargo. En versiones recientes de Sugar, se agregó un campo Descripción, con el objetivo de estimular la reflexión acerca de lo aprendido.

36 Gonzalo Odiard: “Se puede buscar por nombre (de actividad o de amigo) en todas las vistas para ubicarlos”.

37 Shneiderman, Ben y Plaisant, Catherine (2005), “Usability of Interactive Systems for Designing the User Interface”, University of Maryland, Addison Wesley.

Diseño centrado en los usuarios: El caso Kokori

Texto: Mariela Szwarcberg Bracchitta y Eduardo Mercovic

Mariela Szwarcberg Bracchitta es licenciada en Ciencias Biológicas (Facultad de Cs. Exactas y Naturales, UBA). Además, es asesora y coordinadora de ciencias naturales en escuelas públicas y privadas desde el 2003, nivel primario e inicial, y Facilitadora en talleres para docentes en el Ministerio de Educación (Nación y CABA, Argentina). Se desempeña también como docente universitaria UBA desde 1993 y como Jefa de Trabajos Prácticos de la Cátedra de Fisiología Vegetal, Facultad de Agronomía, UBA. Es cofundadora y responsable de la consistencia biológica y la Guía Didáctica en Kokori, Proyecto Fondef, Chile (2011-2008); partícipe del desarrollo del videojuego Ciclania sobre Cambio Global (2013); investigadora asociada en Tekit (Centro de Investigación y desarrollo de herramientas educativas, Universidad Santo Tomás de Chile, 2015-2012) y Lof (Empresa Social de Ciencia y Tecnología, 2015); y miembro del Comité Editorial de la Revista de Ciencias para chicos y docentes Chicos, Edit. Ciencia Hoy (2016).

Eduardo Mercovich es casi licenciado en Biología. Fundador de GaiaSur y Consultor/diseñador en Experiencia del Usuario desde 1994. Responsable de diseño de interacción y usabilidad de Kokori (2011-2008). Co-fundador de http://MamaGrande.org desde 2011. Investigador asociado del Centro Tekit en TICs y Educación, Universidad Santo Tomás de Chile (2015-2012) y Lof, Empresa Social de Ciencia y Tecnología (2015). Jefe de trabajos prácticos y co-diseñador de las Especializaciones en Diseño de Interacción con estándares de accesibilidad y usabilidad: http://accesibleyusable.com/, de la Universidad Tecnológica Nacional, Argentina. Miembro Fundador del Movimiento de Diseño Inclusivo http://www.disenoinclusivo.org.ar/. Asesoramiento de empresas y organismos no/gubernamentales y creación del departamento de usabilidad y de diseño de experiencia de usuarios de Mercado Libre. Relevamiento sobre Investigación Científica para el gobierno de Chile (2016-2015).

1. Síntesis

Kokori es un conjunto de herramientas TIC para enseñar biología celular que incluye

Un videojuego 3D gratuito, con siete misiones cortas donde el jugador debe salvar unas células en problemas comandando diferentes tipos de nano-robots (nanobots), evadiendo lisosomas, eliminando virus y bacterias, reparando estructuras rotas.

Una Guía Didáctica con material para docentes de primaria y secundaria. Propuestas lúdico-pedagógicas, teoría, evaluaciones y secuencias didácticas sugeridas para insertar las diferentes misiones en el desarrollo de las clases.

Un “Navegador celular” para facilitar a los docentes y estudiantes un paseo por el interior de una célula eucariota animal. Demostrativo, sin estrés, pensado para docentes que no quieren jugar al videojuego, sin necesidad de evadir ni sortear enemigos como en el juego.

Dos historietas cortas que tienen como héroes a los estudiantes. En una se relata una historia de ficción sobre el origen de los nanobots y la investigación científica y la otra vincula el videojuego con asuntos cotidianos, el nivel micro (celular) con lo macro (tabaquismo).

Kokori surge por la preocupación de docentes universitarios acerca del nivel de conocimiento con el que los estudiantes llegan a la universidad. Fue creado para colaborar en mejorar el nivel de aprendizaje de un tema abstracto como la célula, que se enseña en primaria y secundaria y apunta específicamente a niños y niñas de secundaria de 13 a 16 años. Fue desarrollado para distribuir masivamente en instituciones educativas, con requerimientos bajos de hardware, que se pudiera jugar sin conectividad y fue diseñado muy cerca de sus usuarios: docentes y alumnos.

Kokori ha sido descargado libremente por miles, ha sido avalado con premios en concursos educativos y de ciencia, ha sido instalado por y usado por docentes en muchos países y una productora independiente produjo una miniserie para televisión. En este artículo, queremos compartir nuestra experiencia desarrollando este proyecto, con especial énfasis en las pruebas de usabilidad e impacto pedagógico con docentes/estudiantes/jugadores. Para mayor información, descarga gratuita del juego, Guía docente, Navegador, Historietas y versión breve en línea: http://kokori.cl

2. Por qué Kokori

Desde el primer año de la carrera de Biología se ve claramente que en biología celular, como en tantas otras áreas del saber humano, forma y función están íntimamente relacionadas.

A partir de ese momento, la idea de crear un videojuego para explorar ese espacio al que no podíamos llegar con nuestros sentidos, por ser demasiado pequeño en el espacio y demasiado rápido en el tiempo, fue una constante.

En el 2008, Virginia Garretón, amiga y en ese momento directora de la carrera de Biotecnología en la Universidad de Santo Tomás en Chile, nos cuenta de las severas falencias en conceptos básicos de biología celular con que sus estudiantes entraban en carrera. Más de 20 años de docencia universitaria en la Universidad de Buenos Aires, además del trabajo mano a mano con docentes de otros niveles educativos, nos corroboraban el mismo panorama en la Argentina. Mucha evidencia da cuenta de lo complejo que es enseñar y aprender en ciencias naturales. Ese año se abría un concurso estatal para financiar herramientas que usen TICs para fomentar la educación y Virginia nos estaba invitando a presentarnos.

El escenario era ideal. Con un variopinto equipo de la Universidad de Santo Tomás, todos preocupados por el nivel de conocimientos con el que llegan a la universidad. Ingenieros, biólogos, gente de sociales, filosofía, químicos y otros, armamos y presentamos el proyecto casi como un juego. Y ganamos.

El objetivo estaba planteado: para mejorar el nivel con el que llegan a la universidad había que trabajar desde el secundario y, por qué no, desde primaria también.

El juego era el elemento central, pero al mismo tiempo la rigurosidad científica era fundamental.

¿Cómo satisfacer lo que a primera vista parecían requerimientos casi contrapuestos?

Apostamos a la simplificación, sin caer en errores conceptuales, pero había que averiguar y cumplir con nuestros usuarios. Investigamos quiénes serían los usuarios de nuestro juego: los estudiantes y docentes. Cómo era la situación actual en la enseñanza de este tema, por qué, qué querían/necesitaban y debían cambiar, con qué contaban. Y en cuanto a los estudiantes, era importante averiguar a qué jugaban, qué les interesaba, etc.

Lo diseñamos, lo probamos, lo construimos, lo ajustamos, lo aplicamos y lo volvimos a ajustar un poco más. Confirmamos que los docentes son indispensables para llegar a los estudiantes, que el aprendizaje no es simple por buena que sea la herramienta de enseñanza. Hicimos talleres con docentes en diferentes regiones de Chile y aprendimos mucho. Kokori significa “juguemos juntos” en Rapa Nui, la lengua de la Isla de Pascua. Y eso hicimos también desarrollando el juego, y eso hacen los chicos que lo juegan. Y eso que decidimos hacer y aprender, queremos compartirlo acá con todos.

3. Diseño y desarrollo

3.1. El Equipo del proyecto

En el equipo nuclear de Kokori participamos una variedad de profesionales: dos trabajadoras sociales, un ingeniero en biotecnología, dos bioquímicas, un profesor de filosofía y 2 biólogos. Junto con nosotros, una multitud de otros profesionales (especialistas en comunicación, diseño visual, programadores, etc.) fueron parte del desarrollo.

Esta diversidad tiene su costo dada la complejidad que agrega en la comunicación e interacción diaria, y más entre dos culturas y múltiples áreas de saber. Sin embargo, la riqueza y las ventajas que aportan superan ampliamente las dificultades.

Y es notable que más allá del resultado del juego y su impacto, al hacer la evaluación del proyecto todos coincidimos en que el equipo que habíamos formado era una de los logros más importantes, por lejos. Tanto es así, que decidimos seguir explorando juntos otras posibilidades de la intersección entre juegos, aprendizaje e impacto social, y luego desarrollando otro juego más (¡sobre Cambio Climático, Global y Educación Ambiental!).

Pero algo fue crucial: el aporte de los usuarios. Docentes y estudiantes fueron clave en el exitoso resultado de este proyecto.

3.2. Requerimientos para el videojuego

Al comienzo, y aún abiertos a que algunos de estos requerimientos podían cambiar, definimos que el videojuego:

Debía funcionar en hardware antiguo (baja exigencia de potencia).

Debía ser igualitario entre géneros (o sea, que todos lo jueguen por igual, por ejemplo no seguir el camino usual de combates que tienden a seguir más los niños que las niñas).

Debía ser un juego de verdad (o sea, tiene que tener sentido per se y ser divertido, no podía ser un ejercicio escolar disfrazado de juego porque los chicos no lo juegan.38

Debía poder ser integrado a las actividades del aula (Chile tiene salas de computadoras en casi todas las escuelas) lo cual le impone un requerimiento de tiempo breve a cada segmento o misión, y al mismo tiempo podrían querer jugarlo en sus casas o ser mandado como tarea para el hogar.

Esta lista era adecuada pero parecía demasiado ambiciosa. Además teníamos otra lista de requerimientos académico-conceptuales (tratados más adelante) bastante complejos también. Sin embargo, estábamos convencidos de que no sólo eran características necesarias para el éxito del proyecto, sino que finalmente sería más fácil resolverlos todos juntos que por separado.

3.3. Usuarios

Para lograr los objetivos planteados, era necesario tener en cuenta a los 2 grupos de usuarios del proyecto: docentes y estudiantes.

Trabajamos con ambos grupos desde el inicio, pero ajustando la interacción a las posibilidades, usos y características de cada uno:

Con los docentes integramos un panel de expertos para estar seguros de que el videojuego rasca, pero rasca donde pica.

Con los estudiantes probamos el juego: ¿se entiende, pueden jugarlo, es interesante, es divertido, es igualitario en términos de género, qué entienden?

Si bien tanto los docentes como los estudiantes podían jugar, nuestro objetivo era que lo utilicen los estudiantes, no excluyendo así a los docentes. Pensando entonces en las características de los chicos/as, su edad, familiaridad con la actividad y lenguaje de interacción, decidimos usar un lenguaje visual y narrativo cercano a ellos: el cómic.

3.4. Actividades con docente

Al comenzar el proyecto hicimos un llamado a docentes interesados en el proyecto. Respondieron docentes de colegios públicos, privados y subsidiados y luego de unas charlas quedó conformado el “Panel de Expertos”. Se recabó información acerca de qué puntos del Programa de Estudio y las clases de biología celular suelen ser los más difíciles de enseñar y aprender, o áridos, o suelen ser los menos comprendidos históricamente por los alumnos. Definimos que abordaríamos los temas del Primer año de Nivel Medio de Chile, por ser introductorio, amplio y muy concordante con la enseñanza de la célula en otros países. Evaluamos herramientas de uso hasta el momento y su efecto. Cruzamos los temas complejos con aquellos en que creíamos que un videojuego puede ayudar más. Multiplicando ambos índices, dificultad y aporte del juego, y con un aporte desde nuestro criterio integrado por diferentes miradas, definimos los temas, contenidos y conceptos fundamentales que el juego iba a tratar:

Organelas y estructuras subcelulares (núcleo, lisosomas, retículo, membranas).

Metabolismo energético (glucosa, ATP).

Sistema de endomembranas, endo/exocitosis.

Compuestos básicos y macromoléculas de las estructuras celulares (lípidos, proteínas, azúcares, ácidos nucleicos).

Mecanismos de defensa y degradación (lisosomas).

Tamaños relativos entre estructuras.

Léxico específico.

Simultaneidad de procesos dentro de la célula.

El panel de expertos fue convocado regularmente a lo largo del proyecto crucial para informar lo que íbamos definiendo y haciendo y validar que estábamos alineados con las posibilidades y necesidades de los docentes y el uso en el aula.

3.5. Prototipos y pruebas con estudiantes

Desde el inicio, queríamos probar lo más tempranamente posible las ideas que íbamos acordando. Por ello, trabajamos con pruebas de usabilidad (o sea, observaciones de usuarios reales con tareas reales y realistas) desde los prototipos tempranos y las repetimos frecuentemente a lo largo del desarrollo, ajustando el guión del test para ser coherente con el avance del juego.

Una de las pruebas fundamentales, estaba relacionada con el uso de 2 ó 3 dimensiones. Debatimos mucho si un juego 3D era necesario para que los estudiantes comprendan la relación entre forma y función. El desarrollo de un juego en 3D podría ayudar a los objetivos del juego, pero complicaría notablemente el desarrollo y aumenta tanto el costo como los requerimientos de hardware para jugarlo adecuadamente (ver Bibliografía).

Finalmente, por ser una función nuclear del juego, poder “visualizar” y no volver a repetir el modelo de célula tipo “huevo frito” en el pizarrón, decidimos que sí era necesario. Pero a fin de que no disminuyera la accesibilidad, queríamos simplificar la navegación 3D.

Como hay evidencias de que un 3D real marea a muchos jugadores tanto como otros que nunca llegan a moverse bien, probamos con una versión simplificada: un espacio tridimensional pero de movimiento restringido a 2,5 D. En nuestro caso, esto se traduce a un movimiento orbital alrededor de la célula, manteniendo la mirada siempre hacia el núcleo, y con capacidad de hacer zoom hacia dentro o hacia afuera de la célula.

Esta navegación “orbital” era fundamental para la comprensión de la forma tridimensional de los espacios intracelulares.

Para probar si era usable y comprensible para los Usuarios, hicimos un prototipo muy liviano y definimos unas pruebas de usabilidad con estudiantes.

3.6 Informe del test de usabilidad con Estudiantes, 1er prototipo

3.6.1. Síntesis

En el marco del proyecto Kokori, desarrollo de un (video) juego para facilitar el aprendizaje de la biología celular, y habiendo definido hasta un nivel operativo mínimo y suficiente las características del juego, necesitábamos validar la utilidad y usabilidad de la propuesta, como objetivos principales.

Para ello, desarrollamos un prototipo con las características básicas del espacio intracelular y su navegación y lo probamos con una muestra representativa de usuarios, alumnos de Nivel Medio con experiencia previa en juegos y manejo de la computadora.

Los resultados de esta prueba de usabilidad nos sugirieron que:

El mecanismo de navegación definido (navegación orbital) es útil (permite moverse y cumplir las tareas) y usable (los usuarios entienden cómo hacerlo y lo hacen efectivamente).

La experiencia de moverse en un entorno tridimensional (3D) semi inmersivo mejora la percepción de la estructura celular, aunque sea desde unas interfaces bidimensionales (monitor, mouse y teclado) y pudiendo realizarlo en sólo 12 minutos aproximadamente.

La relación de trabajo en parejas de alumnos o tríos, parece ser la óptima, propiciando el trabajo colaborativo, que enriquece. No así el trabajo individual, ni en grupos todos juntos.

Hay posibilidades de mejorar aún más el resultado pedagógico con algunos cambios al prototipo como por ejemplo: destacar la membrana celular que se nota menos de lo deseable, agregar la posibilidad de observar hacia otro ángulo o “mover la cabeza” dentro de la célula y mejorar el algoritmo que posiciona las etiquetas de las organelas.

3.6.2. Objetivos del test

Objetivos generales:

Verificar si el mecanismo de navegación diseñado es útil y usable.

Observar el impacto que genera esta experiencia inmersiva en la concepción que los usuarios tienen de la célula.

Objetivos específicos:

En mayor detalle, queremos determinar para el grupo de usuarios definidos:

Si el mecanismo propuesto para la navegación dentro de la célula les permite hacer lo que les solicitamos y si pueden hacerlo solos y/o requieren alguna ayuda, y en ese caso qué tipo de ayuda.

El nivel de destreza “navegacional” al que se llega en los primeros 10 a 20 minutos de uso del prototipo, que es el tiempo breve estimado como de una sesión en la escuela, y si el nivel alcanzado es suficiente para moverse con soltura en el entorno tridimensional para poder usar sus recursos cognitivos en las tareas (misiones) propuestas.

La diferencia –o transformación– del concepto de célula y estructura general de la célula previa y posterior al uso del prototipo. En caso de no existir concepto previo (caso de los niños más pequeños), el resultado de la exposición al prototipo.

La memorización, comprensión e impacto cognitivo general de la experiencia.

La apreciación del prototipo en su estado actual y de la experiencia como un todo.

No es parte de este experimento medir ningún aspecto del proceso de instalación, ni comprensión de la propuesta del juego y/o su atractivo para los posibles usuarios ya que están diseñados pero no desarrollados.

3.6.3. El prototipo del videojuego Kokori

El prototipo probado tiene una representación muy simple de una célula y sus principales organelas, con la membrana semitransparente, que permite un movimiento orbital (alrededor) con el mouse (ratón), y un zoom con la ruedita.

Figura 1: Captura de pantalla de la vista intracelular. Nótese el Centro de Comando (abajo a la derecha) y la falta de contraste que dificultó su visualización a algunos usuarios.

Figura 2: Captura de pantalla de la vista extracelular, localizándose inmediatamente fuera de la membrana plasmática. Nótese la mayor opacidad que en la Figura 1 producida por observar el interior a través de la membrana celular, cuya textura se aprecia levemente. Cuando el usuario sobrevuela la imagen del Retículo Endoplasmático Liso (o cualquier otra), como la estructura se visualiza detrás de la membrana, la etiqueta dice “membrana plasmática”.

Figura 3: Captura de pantalla de la vista de la célula completa desde su exterior. Ahora la membrana se aprecia mejor, pero los usuarios no suelen llegar a este nivel de zoom espontáneamente con las tareas de este test.

Al seleccionar un objeto accionable, aparecen las acciones posibles en botones. En este prototipo, sólo se accionan los nanobots con el botón de “Mover” y el Centro de Comando con el botón “Crear Nanobot”.

Figura 4: Captura de pantalla de la vista del Centro de Comando (fijado a la cara interior de la membrana) con un nanobot recién creado.

El juego está proyectado con varias misiones a cumplir. Sin embargo, para esta prueba piloto, el prototipo de juego no tenía ninguna misión, sólo familiarizarse con el entorno celular. Dentro, el núcleo celular, organelos, el Centro de Comando (que en la ficción del juego permite la comunicación, la gestión de nanobots y el intercambio de elementos con el exterior celular) y los nanobots.

3.6.4. Descripción general del test

El test se llevó a cabo en 3 etapas, repitiendo en cada una el mismo protocolo (ver apéndice de guión y protocolo completo del test):

5 usuarios lo hicieron individualmente, en serie.

4 usuarios lo hicieron en 2 parejas, en serie.

9 usuarios lo hicieron de a parejas, simultáneamente (en grupo).

En todos los casos, el protocolo fue el mismo:

Bienvenida y entrevista pre test (incluyendo información personal, costumbres relacionadas con juegos y computadoras, y dibujo de una célula si tuvo clases de biología celular).

Realización de las tareas propuestas con el primer prototipo de Kokori.

Entrevista post test, incluyendo una evaluación subjetiva de la experiencia y nuevamente, dibujo de una célula.

Se tomaron registros en audio y video y se midieron resultados cuantitativos (tiempos y éxitos por tarea) y cualitativos (expresiones y emergentes actitudinales, dibujos de la célula pre y post experiencia, etc.).

En todos los casos estuvieron presentes:

1 facilitador.

2 observadoras calificadas.

Otros observadores, todos del equipo del proyecto Kokori.

Figura 5: Sesión de la prueba con usuarios en varias parejas trabajando simultáneamente.

Se homogeneizó el discurso hacia los usuarios y las instrucciones fueron similares en todas las sesiones.

Como en los 3 primeros usuarios se observó cierto tiempo hasta encontrar el uso del ratón para lograr el movimiento deseado, a partir del cuarto, los usuarios recibieron como única instrucción o ayuda un gráfico relacionado con el uso del ratón para moverse.

Estas instrucciones eliminaron los primeros 30 a 60 segundos de exploración necesarios hasta encontrar cómo rotar, alejar y acercarse en la célula.

3.6.5. Resultados y Discusión

Las tareas se crearon para refutar o validar las hipótesis básicas:

Acerca del mecanismo de navegación propuesto (les requería moverse dentro del entorno celular).

De impacto cognitivo de la experiencia (les implicaba estar varios minutos haciendo cosas dentro de la célula, sin poner su atención en recordar las estructuras).

Tarea
Explicación para el usuario
Criterio de éxito (1=éxito < éxito parcial < 0=fracaso)
Promedio de éxitos

Identificación de foráneos
Hay objetos que no pertenecen a este espacio. Búscalos, por favor. Tómate todo el tiempo que desees.

Total: 1 o 2 nanobots, 2 carritos rojos y base de comando.

Parcial: 1/3 o 2/2 según los tipos diferentes tipos vistos.

No identifica objetos externos al entorno celular.

0.97

Ver grupos y conexiones
¿Cuántas cosas verdes hay? ¿Cuántas cafés? ¿Cuántas azules grisáceas?

Total: 1 café, 5 verdes, 7 azul.

Parcial: 1 café y ± 1 marrón o azul.

Fracaso: mas de 1 café o ± 1 marrón o azul.

0.75

Mover nanobot
Hay 2 objetos marcados con flechas. Trata de moverlos a la otra punta.

Total: logra seleccionar 1 nanobot y moverlo hacia el otro lado de la célula.

Fracaso: no logra mover ningún nanobot.

1,00

Seguir
Por favor, trata de que un robot siga a uno de los objetos móviles rojos.

Total: lograr que un robot siga a un bicho rojo.

Parcial: lo acerca aunque no lo siga.

0.75

Crear nanobot
Hay una manera de crear más robots. Por favor, crea por lo menos 1 nanobot.

Total: crea por lo menos 1 nanobot.

Fracaso: no puede crear ningún nanobot.

0.75

-Éxito:

Aunque el porcentaje de éxito es alto en general (85% del total de las tareas), no está distribuido homogéneamente. Hay tareas más difíciles que otras aunque ninguna de estas dificultades es relevante al juego o al aprendizaje:

La tarea de contar se enfrentó con un problema conceptual que es si el retículo endoplasmático (RE) es 1 o varios, ya que se visualizan sacos interconectados.

No se vio inmediatamente cómo crear nuevos nanobots.

No hubo ningún problema en diferenciar las estructuras propias celulares de aquellas introducidas por el juego, ni tampoco en mover los nanobots.

El porcentaje de éxito es diferente a lo largo de los tipos de interacción.

Los usuarios que trabajaron en grupo de más de dos integrantes tienen un éxito apenas mayor que los que estuvieron en parejas, y a su vez éstas tienen mayor éxito que los usuarios individuales.

Éste fenómeno se conoce como co-descubrimiento, y refleja la situación usual en la escuela y en la casa cuando hay juego con amigos (situación frecuente según datos preliminares de una muestra de estudiantes de primer año de la UST). No hay co-descubrimiento posible cuando el usuario juega individualmente, sea en casa o en la escuela. Muchas corrientes educativas propician el trabajo colaborativo como potenciador del aprendizaje.

-Tiempos:

El tiempo grupal es mucho mayor que los de los usuarios en pareja e individuales, porque incluye además de la espera a los más lentos (en este experimento con ambiente controlado) todo el intercambio general entre los grupos y mayor actividad social que, aunque no aumenta el nivel de éxito de las tareas, enriquece los lazos entre pares y probablemente la comprensión de los fenómenos estudiados.

-Estructura celular:

A los usuarios que habían visto biología celular en la escuela se les preguntó acerca del tema que habían visto, para qué servía y/o con qué otros temas estaban relacionados y se les solicitó que dibujen cómo recordaban a una célula.

Los que recordaban algo del tema se expresaron muy vagamente en forma verbal (en parte por las dificultades del uso del lenguaje oral para un tema que les resulta lejano), pudiendo sin embargo usar esbozos gráficos para aproximarse a lo visto.

Luego de las tareas se les solicitó nuevamente que dibujen una célula, con resultados notablemente diferentes. Si bien estos resultados pueden estar vinculados con lo reciente de la experiencia, las expresiones (tanto gráficas como orales) de los usuarios muestran que hay un fuerte aporte diferencial relacionado con la inmersión, interacción y visualización propuesta.39

Dibujos de los usuarios individuales:

Dibujos de los usuarios grupales

(Nótese en varios de estos esbozos la falta de membrana celular)

-Membrana celular:

Como se observa en los dibujos, 6 de 22 no incluyen la membrana celular. Creemos que esto se debe en parte porque se muestra demasiado transparente en nuestro prototipo. Cuando el usuario se mueve hacia el entorno extracelular “atraviesa” la membrana, pero como esta es muy transparente no sólo no se ve, sino que crea una sensación de “falso tag” asociado ya que todas las organelas parecen tener la misma etiqueta (un usuario identificó el REL como “membrana celular”).

Además, el Centro de Comando (CdC) tiene poco contraste contra la membrana y cuesta encontrarlo.

Un alumno dibujó el CdC en su modelo de célula: nos muestra que el rol docente es indispensable, definiendo los elementos de fantasía y los del modelo celular.

-El juego y sus mecanismos:

Manipulación de objetos:

Para mover un objeto, todos intentaron primero arrastrarlo.

Luego de un tiempo (entre 10 y 60 segundos aproximadamente), encontraron el botón lateral derecho de “Mover”.

-Propuestas de juego hechas por los usuarios

Nos interesaba saber acerca de las expectativas o fantasías de los usuarios respecto del juego. Para ello, y habiendo aclarado que este prototipo aún no tenía juego sino sólo movimiento, se les preguntó qué querrían que tuviera el juego.

Las opiniones vertidas sugerían:

Que la célula esté en peligro y que los jugadores la salvaran.

Que uno pueda crear sus propias cosas dentro del juego.

Que sea para niños y niñas.

Afortunadamente, las propuestas de los usuarios concuerdan con las previamente pensadas por el equipo Kokori. Nuestras observaciones coinciden con la bibliografía en que los niños tienden a gustar más de la acción, mientras que las niñas más de la historia y los personajes.

Estamos teniendo en cuenta estas variaciones para hacer el juego atractivo y disfrutable para ambos sexos.

3.6.6. Discusión y conclusiones

-Utilidad y usabilidad del primer prototipo Kokori

El modelo de utilidad y usabilidad integra cuatro aspectos o puntos de vista de un sistema. Este experimento nos permite ver el (un) estado inicial del videojuego Kokori:

Facilidad de uso y aprendizaje + rendimiento: los usuarios pudieron completar con éxito (0.85) casi todas las tareas en un plazo de entre 10 y 30 minutos aproximadamente sin ayuda, excepto un gráfico para acelerar la navegación intracelular.

Apreciación: los usuarios disfrutaron del juego y la experiencia, mostrando interés por repetirla.

Utilidad: los usuarios mostraron, a través de sus dibujos y sus expresiones verbales (ver citas en Impacto de la experiencia en el concepto de la célula y dibujos en estructura celular) una diferencia notable entre su concepción de la célula pre y post experiencia. Luego de las tareas, la célula tenía mucha más precisión en sus componentes, distribución y conformación espacial (aún no probamos procesos).

-Mecanismos del juego

Aunque el mecanismo de navegación fue suficiente como para cumplir con las tareas, varios usuarios tuvieron que hacer maniobras complejas simplemente para poder fijar la vista en los nanobots cuando algún organelo les dificultaba la visión directa. Creemos, por lo tanto, que falta un mecanismo para poder mirar a los lados (el movimiento análogo a “mover la cabeza”). También creemos deseable alguna manera de hacer más suaves y/o precisos los movimientos orbitales de navegación.

Los botones del marco inferior izquierdo sólo fueron vistos (y usados) por 1 de los 5 usuarios individuales, 2 de las 2 parejas, y todos los usuarios grupales. Debemos rediseñar la interfaz en este punto, aunque el co-descubrimiento haya permitido solucionar el desafío.

-Impacto de la experiencia en el concepto de la célula

Como se observa tanto en los dibujos post test como en los comentarios, la experiencia de moverse dentro de una célula (simulada) y el hecho de llevar a cabo tareas dentro de ese entorno impactó de manera importante en los usuarios. Este impacto se nota no sólo en los dibujos, sino además son los comentarios y actitudes, tanto explícitas como corporales, de los usuarios que habían visto biología celular, que destacaron la diferencia de comprensión entre los gráficos y lo visto en clase, comparados con el prototipo del juego, algunos comentarios:

“Lo puedo ver, ¡ver realmente!”.

“Se entiende al toque”.

“Se ven más cosas”.

“Acá [por el juego], cuando quería ver algo mejor, me acercaba”.

“En la escuela lo vi con puros esquemas que eran desordenados, aquí lo vi más completo y más ordenado”.

“En la escuela nos enseñan cómo se compone, pero no cómo es realmente”.

“Es más divertido, más interesante”.

-Mejoras al prototipo

A partir de las observaciones de este experimento, surgen múltiples posibilidades de ajustes/mejoras al prototipo:

Agregar el “movimiento de cabeza”.

Aumentar el contraste del Centro de Comando para facilitar su ubicación.

Hacer las formas menos regulares, tanto de la célula como las organelas.

Aumentar la opacidad de la membrana celular y quizás mostrar algún esfuerzo para atravesarla para hacerla más notable.

Desde lo biológico, distribuir mejor las organelas, hacer el citoesqueleto más realista, etc.

-Trabajo en el aula

Un resultado interesante es el que relaciona tiempo y éxito en las tareas y asociación entre alumnos. Aunque es un hecho conocido por los docentes a partir de su práctica, es interesante constatar que la relación óptima (entre las probadas en este experimento) es la del trabajo en pareja. Esto no descarta otras posibilidades, como el trabajo en tríos, pero claramente separa el trabajo individual del grupal completo.

Sería interesante medir si hay una mejora usando un trabajo de a 2 ó 3 alumnos en el aula, con una discusión grupal posterior, tema que analizaremos con el panel de docentes expertos del proyecto.

3.6.7. Apéndices

Guión completo del test

-Preparación:

Armado de la mesa con el/los computadores y el prototipo funcionando

Armado y conexión del proyector (para grabar y observar la pantalla del usuario sin interferir), cámara de video y espacio para los observadores.

Grabación del video, que se hizo de 2 maneras diferentes:

Con una cámara de video sobre un trípode, filmando sobre el hombro del participante (especialmente en la versión grupal del test).

con una webcam que captaba la cara del participante y el fondo (a su espalda) donde proyectábamos lo que se veía en el monitor (lo que hacía el participante).

-Bienvenida:

Al entrar cada usuario (individualmente, en pareja o en grupos), presentábamos a los participantes, al facilitador y a los observadores. Preguntamos si sabe lo que se hará, y luego se lo explicábamos en detalle.

-Entrevista pre test:

Información personal:

Nombre y apellido:

Edad:

Curso al que pasaste:

Uso de Internet:

¿Cuánto hace que usás Internet?

¿Desde dónde usás Internet?

¿Qué sitios o servicios usás regularmente?

¿Usás alguna red social? Facebook, Myspace, Twitter, Reddit, Digg, otras.

¿Tenés Internet en tu teléfono? ¿Alguno de tus amigos?

Gustos y preferencias generales:

¿A qué jugás, con quién, cuánto tiempo? (juegos en general, videojuegos en particular).

Qué han visto de Biología celular en la escuela:

¿Viste Biología celular en la escuela?

Si vieron algo de Biología celular, ¿te contaron para qué sirve?

Por favor, dibujá lo que sea que recuerdes de una célula.

Observaciones generales durante el test:

¿Necesitó ayuda para navegar? ¿Cuál?

¿Usó los cambios de puntos de vista de abajo a la izquierda?

¿Rota?

¿Hace zoom?

Si se da por vencido/a, ¿cuánto tiempo tarda en hacerlo?

-Entrevista post test:

¿Tenés alguna pregunta?

Contanos por favor si hubo algo notable, una sorpresa, algo que no te haya gustado, que fuera difícil, feo, lo que sea.

¿Y algo que te haya gustado, lindo, o que haya sido fácil?

Dibujá por favor lo que recuerdes de lo que viste ahí.

¿Recordás los nombres de algunas de las cosas que viste? Si recordás qué parte era, indicanos.

¿Hay alguna diferencia entre esto que viste y la idea de la célula que tenías antes?

¿Qué te gustaría que pasara en esto como un juego?

Preguntas abiertas a las/os observadoras/es, si tienen alguna.

¿Tenés alguna pregunta antes de terminar?

¿Te interesaría participar en otras pruebas del juego en el futuro?

-Matriz de Usuarios, tareas, tiempos, éxitos y fracasos:

Los usuarios fueron representantes del público objetivo del proyecto, en una muestra cualitativamente representativa:

Niños y niñas de escuela media de 13 a 16 años aproximadamente,

Con cierto manejo mínimo necesario de interacción con una computadora (uso de ratón y teclado, coordinación viso-motriz).

Con una cierta –mínima– exposición previa a videojuegos (no queremos que éste sea su primer juego y medir usabilidad y/o aprendizaje de juegos en general, sino el impacto de Kokori en particular).

| Acerca de los Usuarios |  |  |  | Acerca de las tareas |  |  |  |  |
|  |  |  |  |  |  |  | (1=éxito < éxito parcial < 0=fracaso) |
| Usr. | Test | Edad | Sexo | Curso | Colegio | ¿Vió BC? | Tiempo mm:ss | T1 | T2 | T3 | T4 | T5 | Tavg
1 | individual | 14 | m | 1ero m | E | Si | 09:15 | 1 | 0,75 | 1 | 1 | - | 0,94
2 | individual | 14 | m | 1ero m | E | Si | 12:05 | 1 | 1 | 1 | 0 | - | 0,75
3 | individual | 12 | m | 7mo b | P | Si | 09:16 | 1 | 0,75 | 1 | 1 | - | 0,94
4 | individual | 13 | m | 1ero m | E | Si | 08:50 | 1 | 0,5 | 1 | 0 | - | 0,63
5 | individual | 13 | m | 8vo b | P | Si | 13:10 | 0,75 | 0,75 | 1 | 1 | 0 | 0,70
6 | dupla 1 | 13 | f | 8vo b | P | No | 14:00 | 1 | 0,75 | 1 | 1 | 1 | 0,95
7 | dupla 1 | 13 | f | 8vo b | P | No | . | . | . | . . . .
8 | dupla 2 | 12 | f | 7 b | P | No | 11:00 | 1 | 0,75 | 1 | 1 | 1 | 0,95
9 | dupla 2 | 11 | f | 7 b | P | No | . | . | . | . . . .
10 | grupal | 13 | f | 1ero m | E | Si | 32:00 | 1 | 0,75 | 1 | 1 | 1 | 0,95
11 | grupal | 14 | f | 1ero m | E | Si | . | . | . | . . . .
12 | grupal | 13 | f | 1ero m | E | Si | . | . | . | . . . .
13 | grupal | 14 | f | 1ero m | E | Si | . | . | . | . . . .
14 | grupal | 16 | m | 3ero m | PE | Si | . | . | . | . . . .
15 | grupal | 16 | m | 3ero m | PE | Si | . | . | . | . . . .
16 | grupal | 14 | f | 1ero m | E | Si | . | . | . | . . . .
17 | grupal | 13 | f | 1ero m | E | Si | . | . | . | . . . .
18 | grupal | 14 | f | 1ero m | E | Si | . | . | . | . . . .

3.7. El Desarrollo del videojuego

El desarrollo de un videojuego (tanto la parte artística de historia, visual y sonido, como la programación) está aún más cerca del arte que de la ciencia.

Por lo tanto, para el desarrollo del videojuego hicimos una licitación abierta en la cual aclaramos las necesidades y características del proceso de desarrollo (ya que la forma final precisa no la conocíamos al comenzar con la licitación).

La licitación siguió el proceso típico de publicación, período de preguntas (que fueron reenviadas a todos los participantes junto con las respuestas), presentación de propuestas, evaluación, finalistas, comparación final y anuncio del ganador. Finalmente, la empresa ACETeam se ganó el desarrollo del juego e hizo un gran trabajo no sólo en lo técnico, sino con aportes importantes a los aspectos lúdicos, como la adición de un “malo” necesario, el desarrollo del arte, etc.

Por supuesto, en el mundo no todo son rosas. Temas que nos quedaron pendientes para Kokori fueron:

Que el juego fuera multiplataforma, o sea, que funcione en Windows, Mac y Linux. Finalmente, aunque la versión completa es sólo para Windows, logramos al menos hacer una versión web, más liviana, del inicio del juego. Tenemos también reportes de que en Linux funciona bajo el emulador Wine.

Hacer el juego más accesible. Dada la naturaleza de Kokori, la gente con muy baja o nula visión no puede utilizarlo. Si bien es lógico dado el estado actual de la tecnología, queremos analizar cómo hacer para que todas las personas, más allá de sus capacidades físicas y mentales, puedan jugarlo.

3.8 Transferencia: ¿un caso especial?

Una vez que el videojuego estuvo listo nos enfrentamos al desafío de hacerlo llegar a sus usuarios: docentes y estudiantes en la sala de clases.

El asunto no era menor: hay un montón de buenas ideas desarrolladas que quedan durmiendo en cajones de expertos. Además, la intención del equipo era aportar en la reducción de las brechas de calidad en la enseñanza, que tanto en Chile como América Latina son un problema de desigualdad social importante.

Y es que si bien las tecnologías de la información y comunicación abren grandes posibilidades en estos términos, si no son acompañadas por estrategias de transferencia que se enfoquen a generar condiciones para la apropiación de los contextos educativos más vulnerables, pueden terminar ampliando las brechas en vez de reducirlas.

Así, construimos una estrategia de transferencia directa en los municipios identificados como de mayor vulnerabilidad social, poniendo a Kokori al servicio de aquellas escuelas donde obtener resultados satisfactorios es más difícil dadas las desventajas iniciales con que se enfrenta el desafío de aprender: altos niveles de pobreza, multifuncionalidad de los docentes, baja escolaridad de los padres, entre otras características.

Apostamos a acompañar a los docentes a conocer Kokori. Ofrecérselo como una herramienta desarrollada con ellos desde el inicio, que un grupo de científicos ponía a su disposición. Nos sentamos con ellos y juntos tratamos de resolver cómo romper las limitaciones que muchos no nativos digitales tenemos con los videojuegos y otras TICs, que es a nuestro juicio una de las principales barreras para la apropiación. Desarrollamos el Navegador específicamente pensando en ellos para que, si no quieren, no jueguen. Que les pueden pedir a los estudiantes de tarea hacer las misiones del videojuego y ellos leer la descripción de cada misión de la Guía para el docente o mirando los tutoriales de YouTube.

Les presentamos la Guía Didáctica para el Docente, diseñada respondiendo a sus requerimientos para el uso pedagógico del videojuego, instrucciones de instalación, juego, evaluaciones, background teórico, ejercicios y descripción de misiones y sus componentes y actividades sugeridas. Deja a disposición propuestas de uso, para que hagan de ella lo que estimen más adecuado para la realidad de sus salas de clases. Lo dejamos disponible en la web entero y en fascículos según el tema y la misión, para facilitar la lectura y la descarga según interés. Y lo imprimimos en papel, que es el formato que más nos acomoda a algunos docentes que más que digitales, somos analógicos y seguimos enamorados del papel para algunas actividades.

Con los estudiantes jugamos en la sala de clases, motivando a través del juego su interés por la ciencia. Compartimos stickers, reglas, comics y en algunos cursos, el presidente de curso se hizo cargo de administrar una copia del videojuego para que cada niño y niña que tuviera computador en casa pudiera instalarlo.

Así, visitamos en Chile las 25 comunas que identificamos como de mayor complejidad social según Índice de Desarrollo Humano.

Por otra parte ofrecimos hacer llegar a todo el departamento de educación que quisiera el material, en la medida que manifestara su interés de recibirlo y explicitara como lo distribuiría: más de 70 municipios aceptaron la invitación.

Como nuestro equipo de investigadores es internacional, pudimos generar actividades de transferencia también en Panamá, Argentina y Colombia, entre otros.

En Panamá se implementó una estrategia social de transferencia similar a la chilena, a través del financiamiento de CENACYT, mientras que en Argentina se participó en seminarios de difusión y se instaló el videojuego en las netbooks a través del Plan Conectar Igualdad.

Un aliado de la transferencia fueron las redes sociales y medios de comunicación de prensa escrita y televisión, que tomaron a Kokori como un evento en sí mismo, y lo desarrollaron con sus propias dinámicas (por ejemplo, cuando vimos que los niños y niñas compartían sus puntos en Facebook, integramos ésa función directamente en el juego).

Al generar este proceso de transferencia y tomarnos en serio esto de que las TICs reduzcan las desigualdades, nacen nuevos desafíos para Kokori. Particularmente para Chile, fortalecer el conocimiento de los docentes en biología celular, apoyar el desarrollo de estrategias de uso pedagógico del videojuego, romper la idea instalada de que en la sala de clases hay uno que sabe y otro que no sabe, abrirse a la generación de un aprendizaje colaborativo donde el juego promueve aprendizajes significativos para los niños y niñas.

4. El paquete de herramientas TIC Kokori

Hoy en día, Kokori es un conjunto integrado, maduro y probado de herramientas para el aprendizaje de biología celular por niñas y niños de 13 a 16 años y sus docentes:

Un videojuego 3D gratuito + un navegador celular (descargables desde http://www.kokori.cl/descargalo-aqui/).

Una guía didáctica para el docente (descargable desde http://www.kokori.cl/guia-docente/).

Otros productos como la historieta (disponible en el sitio web de Kokori), una serie televisiva (accesible en http://www.tvn.cl/programas/nanoaventuras/).

4.1 Futuro/s posible/s y actualidad

La experiencia de desarrollar Kokori fue conmovedora, de mucho aprendizaje y con resultados que fueron más allá de lo esperado.

Como valiosa evaluación externa siempre contamos con nuestros amigos y colegas de trabajo, tanto desde lo pedagógico como desde lo académico. Ese aval y reconocimiento también lo obtuvimos con la cantidad de gente que sigue descargando el juego, los docentes que nos siguen y al ganar varios concursos y premios, con jurado experto en ciencia y educación. Y los docentes nos siguen pidiendo que los acompañemos en talleres y cursos. Suponemos que sigue vigente porque a pesar de los avances de la ciencia y la docencia, fue hecho con rigor, con respeto y escuchando de las necesidades de los usuarios, y eso no cambia tanto con el tiempo.

Pero la historia sigue, como mencionamos antes, y uno de los valores más importantes que todos destacamos fue el capital humano: el (súper) equipo formado. La diversidad y riqueza aportada y un resultado que fue más que la suma de las partes, nos dejó con ganas de hacer más. Nos unimos en un par de emprendimientos como el Instituto Tekit y la Empresa Social Lof, para divertirnos juntos en nuevos desafíos.

¿Y si desarrollamos otro videojuego? Al año siguiente de terminar Kokori, nos presentamos a otro concurso de fondos estatales chilenos con otro desafío. Había en el tintero ideas y pedidos varios: genética, inmunología, química, física, medicina anatómica... Decidimos volver a abordar un desafío interesante, actual, urgente. Saltamos de los fenómenos micropequeños e hiperveloces a los gigantes y muy lentos: cambio global. Nos propusimos hacer un videojuego para niñas y niños de primaria sobre educación ambiental y fenómenos que incluyen cambio climático, energía, producción, consumo, industria, uso del agua y el suelo, bienes naturales, su cuidado, la biodiversidad, los ciclos, la contaminación, etc. Para concientizar y repensar hábitos relacionados con el impacto humano en el planeta Tierra, nuestra casa.

Y ¿saben qué? ¡Nos dieron nuevamente el subsidio! Lo ganamos.

Pero esa es otra historia, que les contaremos en otra oportunidad.

Si les interesa, visiten http://ciclania.org/.

5. Agradecimientos

Al equipo de Kokori, sin el cual nada de esto hubiera sido posible: Maricela, Javiera, Mauricio y el Pape, Romina, Ignacio, Frank, Dulce y nuestra directora (pero mucho más importante, amiga) Virginia.

A nuestras familias e hijos, que se pusieron la camiseta y nos aguantaron semejante aventura con las consecuentes ausencias cruzando la cordillera. Sin ustedes nada de esto hubiera valido la pena.

Notas

38 Para validar esto, sólo es necesario observar a qué eligen jugar cuando se los deja libres para ello.

39 Donde no hay dibujo pre experimento es debido a que los usuarios no habían tenido biología celular en la escuela aún o no recordaban una célula como para dibujarla.

6. Bibliografía

Koivisto, Elina M.I. y Suomela, Riku (2007), “Using Prototypes in Early Pervasive Game Development”, Sandbox Symposium 2007, San Diego, CA, August 04-05.

Fullerton, Tracy; Chen, Jenova; Santiago, Kellee; Nelson, Erik; Diamante, Vincent; y Meyers, Aaron (2006), “That Cloud Game: Dreaming (and Doing) Innovative Game Design”; Sandbox Symposium 2006, Boston, Massachusetts, July 29–30.

La Bounta, Henry (Moderator), Gingold, Chaim; Townsend, Jeremy; Gray, Kyle; Buchanan, John; y Caballero, Vander (Panelists) (2007), “Rapid Prototyping: visualizing new ideas (panel)”; Sandbox Symposium 2007, San Diego, CA, August 04-05.

Kroeker, Kirk L. (2009), “Medical Nanobots: Researchers working in medical nanorobotics are creating technologies that could lead to novel health-care applications, such as new ways of accessing areas of the human body that would otherwise be unreachable without invasive surgery”, Communications of the ACM, septiembre 2009, vol. 52, no. 9.

Grammenos, Dimitris; Savidis, Anthony; y Stephanidis, Constantine (2009), “Designing Universally Accessible Games”, ACM Comput. Entertain. 7, 1, Article 8 (February 2009).

Turner, J. (2006), “Destination Space: Experiential Spatiality and Stories”, Cyber Games '06 Proceedings of the 2006 international conference on Game research and development, págs. 87-94.

Nnadi, Ogechi; Fischer, Ute; Boyce, Michael; y Nitsche, Michael (2008), “Effect of Dynamic Camera Control on Spatial Reasoning in 3D Spaces”, Sandbox Symposium 2008, Los Angeles, California, August 9–10.

Oulasvirta, Antti; Estlander, Sara; y Nurminen, Antti (2009), “Embodied interaction with a 3D versus 2D mobile map”, Personal and Ubiquitous Computing, May 2009, Volume 13, Issue 4, pp 303-320.

Elmqvist, Niklas; Tudoreanu, M. Eduard; y Tsigas, Philippas (2008), “Evaluating Motion Constraints for 3D Wayfinding in Immersive and Desktop Virtual Environments”, CHI 2008, April 5–10, 2008, Florence, Italy.

Cockburn, Andy y McKenzie, Bruce (2002), “Evaluating the effectiveness of spatial memory in 2D and 3D physical and virtual environments”, CHI 2002, April 20-25, 2002, Minneapolis, Minnesota, USA.

Mathews, Moffat; Challa, Madan; Chu, Cheng-Tse; Jian, Gu; Seichter, Hartmut; y Grasset, Raphael (2007), “Evaluation of Spatial Abilities through Tabletop AR”; CHINZ '07 Proceedings of the 8th ACM SIGCHI New Zealand chapter's international conference on Computer-human interaction: design centered HCI, págs. 17-24.

Prensky, Marc (2003), “Digital Game-Based Learning”; ACM Computers in Entertainment, Vol. 1, No. 1, October 2003, Book 02.

Cockburn, Andy; Kristensson, Per Ola; Alexander, Jason; y Zhai, Shumin (2007), “Hard Lessons: Effort-Inducing Interfaces Benefit Spatial Learning”;; CHI 2007, April 28–May 3, 2007, San Jose, California, USA.

Fullerton, Tracy (2008), “Playcentric Design”, Interactions, march-april 2008.

Roussou, Maria (2004), “Learning by Doing and Learning Through Play: An Exploration of Interactivity in Virtual Environments for Children”; ACM Computers in Entertainment, Volume 2, Number 1, January 2004, Article 1.

Lewis, J.P., McGuire, Morgan; y Fox, Pamela (2007), “Mapping the mental space of game genres”, Sandbox Symposium 2007, San Diego, CA, August 04-05.

Claypool, Mark y Claypool, Kajal (2009), “Perspectives, Frame Rates and Resolutions: It’s all in the Game”, ICFDG 2009 April 26-30, 2009, Orlando, FL, USA.

Cockburn, Andy (2004), “Revisiting 2D vs. 3D Implications on Spatial Memory”, 5th Australasian User Interface Conference (AUIC2004), Dunedin. Conferences in Research and Practice in Information Technology, Vol. 28.

Ziemek, Tina R. (2006), “Two-D or not Two-D: Gender Implications of Visual Cognition in Electronic Games”, I3D 2006, Redwood City, California, 14–17 March 2006.