Simplificar las capturas de pantalla en documentación

En el estudio Cómo leen la web los usuarios (Nielsen Norman Group, 1997) se concluye: "[los usuarios] no leen la web. La gente rara vez lee páginas web palabra por palabra; por el contrario, escanean la página seleccionando palabras y oraciones individuales.” La documentación se ha adaptado progresivamente a esta realidad, con formatos de página mejor estructurados y un uso minimalista del lenguaje que apoya el flujo de lectura del usuario. Resulta llamativo que, en este proceso, el tratamiento de las capturas de pantalla apenas haya cambiado.

Qué nos enseña una aplicación de mapas

¿Qué vemos cuando abrimos Google Maps en nuestro teléfono móvil? Por defecto, la pantalla muestra una vista simplificada de nuestro entorno (imagen izquierda). Esta vista es una descripción esquemática (no real) del terreno, donde resulta fácil identificar los puntos de interés. Por el contrario, en la vista aérea del mapa (imagen derecha), se ofrece una imagen fiel del entorno, con abundantes elementos visuales, pero donde puede ser difícil determinar las áreas de interés (comercios, transporte público, monumentos, etc.) o la importancia relativa de unos elementos frente a otros.

Los mapas que utilizamos habitualmente resultan útiles en la medida en que ofrecen una visión simplificada del entorno. La vista aérea de un mapa puede ser interesante para hacernos una idea más precisa de la naturaleza del terreno, pero es poco eficaz cuando nuestro propósito es desplazarnos a un punto concreto del mapa.

El uso que hacemos hoy de las capturas de pantalla en la documentación técnica se asemeja mucho a la vista aérea de un mapa. Mostramos la interfaz de usuario (el terreno) en toda su complejidad y detalle. Y en muchos casos, la densidad de información de estas imágenes nos obliga a destacar elementos (ver figura) para centrar la atención en el punto de interés -reconociendo así la dificultad de “encontrar nuestro camino” en la imagen. El problema no es la captura de pantalla en sí misma, el problema es que su interpretación rompe el flujo de búsqueda de información del que habla Nielsen Norman Group en su estudio.


El coste de capturar pantallas

Incluso con los inconvenientes de interpretar estas imágenes, no hay duda de que añadir una captura de pantalla en la descripción de una tarea mejora su comprensión. El conocido refrán “una imagen vale más que mil palabras” se convierte casi en axioma en redacción técnica. Si la interfaz del software es poco intuitiva o usa métodos no convencionales para resolver una tarea, incorporar capturas de pantalla al texto resulta muchas veces imprescindible.

Este hecho contrasta con la escasez de ilustraciones y capturas de pantalla con la que muchos fabricantes de software acompañan los textos de ayuda. ¿Por qué esta contradición? La explicación es sencilla: la generación de estas capturas de pantalla supone un incremento importante del tiempo de desarrollo. Esto es especialmente visible cuando la documentación se publica en diferentes idiomas, y aunque existen soluciones que permiten automatizar (parcialmente) esta tarea, las variaciones dentro de un mismo programa y entre diferentes idiomas pueden hacer muy compleja la automatización. ¿Cómo podemos, entonces, proporcionar a la usuaria el soporte visual necesario, sin romper su flujo de búsqueda de información y sin incrementar el tiempo de desarrollo?


Ilustrar, no capturar

Si accedemos a la documentación del Centro de Aprendizaje de Google Suite podemos observar algo aparentemente anecdótico: las capturas de pantalla han sido sustituidas por ilustraciones simplificadas de la interfaz:

Estas ilustraciones solo muestran aquella parte de la interfaz que afecta a la tarea que se describe, el resto de elementos se minimizan o se obvian intencionadamente. Este hecho podría parecer puramente estético, pero tiendo a pensar que existen razones prácticas que llevan a Google a utilizar este método:
  • Reduccir los costes de producción
  • Mejorar la consulta de información

La reducción de costes solo puede entenderse cuando la documentación tiene que traducirse a varios idiomas y cuando el software se actualiza con relativa rapidez. Ambas condiciones se cumplen hoy en el caso de muchos productos de software -y se cumplen sin duda para los productos de Google tomados como ejemplo.

La mejora en la consulta de información existe porque la usuaria dispone solo de la información visual necesaria para realizar su tarea. Todos los elementos accesorios de la interfaz se eliminan o simplifican. Así, por ejemplo, los menús incluyen solo el texto que corresponde con las opciones descritas en la tarea. La lectura de estas imágenes es más sencilla, y soporta en mejor medida el flujo de búsqueda de información. En comparación con una captura de pantalla, las ilustraciones se asemejan a mapas simplificados del terreno en los que se ha eliminado todos los detalles superfluos.


Algunas estimaciones (no basadas en datos reales)

Hasta aquí todo parecen ventajas, ¿pero no supone también la generación de ilustraciones una tarea con un elevado coste? Es indudable. Sin entrar en el proceso detallado de traducción de estas ilustraciones (que requeriría una expliación mucho más extensa), la ventaja de utilizar ilustraciones reside en que solo necesitan hacerse una vez, y es relativamente sencillo traducirlas a múltiples idiomas. Por el contrario, las capturas de pantalla han de ser tomadas cada vez para cada idioma.

A continuación arrojo algunas estimaciones (no basadas en ningún dato real). Al trabajar en la primera versión de un manual que contiene múltiples capturas, se dan las siguientes circunstancias:
  • El tiempo o esfuerzo necesario para tomar las capturas de pantalla es bajo con pocas traducciones, pero aumenta de manera lineal al aumentar el número de traducciones.
  • El tiempo o esfuerzo necesario para crear las ilustraciones es alto inicialmente, pero se ve compensado con un menor esfuerzo en la traducción.
La situación de esta primera versión se puede ilustrar de la siguiente forma:
Existe un número de idiomas (punto C en la imagen), a partir del cual el coste de tomar capturas de pantalla es mayor que el coste de traducir las ilustraciones de forma automática. ¿Qué ocurre cuando el software se actualiza en una nueva versión? Cualquier actualización que afecta a la interfaz de usuario (nuevos menús, cambio en el esquema de colores, etc.) nos obliga al laborioso proceso de obtener de nuevo las capturas de pantalla. Las ilustraciones, precisamente por su sencillez, pueden ser adaptadas de forma mucho más rápida. En este caso tendríamos la siguiente situación:
El coste para tomar las capturas de pantalla se mantiene invariable, pero el coste inicial para generar las ilustraciones es ahora mucho menor que en la primera versión del software. El punto C a partir del cual resulta más eficiente usar ilustraciones se consigue ahora con un número más bajo de idiomas.

Si el fabricante de software dispone además de varios productos con una interfaz similar, las ilustraciones pueden ser reutilizadas en otros productos, multiplicando así el beneficio de usar ilustraciones en lugar de capturas de pantalla. En la siguiente imagen podemos ver un ejemplo de este caso, donde se utiliza la misma ilustración para definir una tarea en dos productos distintos:

Pero si solo tenemos en cuenta el factor tiempo/esfuerzo, estamos dejando de lado el argumento más importante para nuestra usuaria: estas ilustraciones simplificadas, al reducir el número de detalles visuales, soportan el proceso de búsqueda de información de manera más eficaz que las capturas de pantalla. Si el formato y texto del documento técnico han cambiado progresivamente hacia un enfoque más minimalista, quizá sea también el momento de aplicar este mismo enfoque a las capturas de pantalla.