Blog

(D/I) Los escenarios

Para que se entienda que son los escenarios, voy a recurrir a una analogía muy socorrida para explicarlos:

(D/I) Los escenarios 1Pensad en vuestra casa, en ella, cada una de las habitaciones (o zonas), se destina a cumplir un objetivo particular, a lo sumo dos (o tres…). Cada habitación cuenta con muebles, utensilios y los elementos necesarios, ordenados de una forma coherente y accesible, para realizar las tareas que os permitan alcanzar objetivos particulares asociados a esa habitación. Así por ejemplo, la cocina es para cocinar, el comedor es para comer o el despacho es para trabajar. Ocasionalmente podemos realizar las tareas que habitualmente se realizan en una habitación en otra, así podemos comer en la cocina, dormir en el salón (o en el despacho), o lavar la ropa en el baño. Si estas tareas se realizan en forma permanente y continuada en una habitación distinta que la original, veremos como la nueva habitación anfitriona se transforma para albergar los utensilios, herramientas y elementos necesarios para desarrollar la nueva tarea. Así, si por ejemplo el comedor lo usamos para trabajar, el ordenador, los elementos de escritorio, los documentos de referncia y demás elementos pasarán a la corta, o a la larga, a formar parte de ese decorado.

En definitiva, nos movemos por nuestra casa en la medida en que nos proponemos nuevos objetivos prácticos, pero no es sensato -ni cómodo- tener que cambiar de habitación para desarrollar las tareas necesarias para un sólo objetivo práctico. Imaginaros, teniendo que sacar los alimentos del congelador en el garaje, mezclar esos alimentos en el comedor y cocinarlos en la cocina para luego acabar lavando los utensilios en el lavavajillas situado al lado del pilón, junto a las lavadora y la secadora, desplazándose de un lugar a otro para preparar nuestra comida.

Pues bien, en una aplicación los escenarios son lo que para una casa son las habitaciones. Las áreas con utilidades que deben contar con todas las herramientas para que uno de los personajes alcance uno de sus objetivos prácticos.

Para definir escenarios, y relacionar estos con los personajes y sus objetivos prácticos, existe una base lógica de correspondencia, pero es necesario probar, abrir la mente, proponer ideas antes de alcanzar un conjunto de escenarios adecuado. Definir los escenarios no es una tarea mecánica, sino una tarea de diseño y por lo tanto requiere al mismo tiempo técnica y creatividad.

Los escenarios son el modelo de representación, que luego llenaremos de botones, menús y todo tipo de artefactos del Framework que decidamos usar. Definir correctamente los escenarios pensando en el/los personaje/s y sus objetivos prácticos, nos asegurará que la interfaz estará adaptada a su modelo mental, y no al modelo de implementación.

(D/I) Los escenarios 2

Tipos de escenarios

Es necesario saber que existen diferentes tipos de escenarios para posteriormente poder priorizar su importancia.

1. Escenarios de uso diario

  • Los personajes desarrollan la mayoría aplastante de su tareas.
  • Por aplicación suelen ser uno o dos, a lo sumo tres.
  • Los usuarios aprenden rápidamente trucos para dominarlos y los recordarán en la siguiente “visita” debido a su uso frecuente.
  • Puede ser que una aplicación, debido a su objetivo, no tenga escenarios de uso diario.
  • Los defectos y deficiencias en la interacción de este tipo de escenarios generan un experiencia de usuario dañina.
  • Deben reflejar el modelo mental
  • Es muy importante dedicar mimo y tiempo a diseñar este tipo de escenarios pues en ellos los usuarios se sentiran satisfechos o infelices con las consecuencias que ello conlleva a nivel de éxito de la aplicación.

EJ: Cuando se usa Word, pasamos el 99% del tiempo delante de la pantalla de edición (escenario 1). Puede que utilicemos a veces la función de combinar correspondencia (escenario 2), o la de crear nuevos estilos (escenario 3), pero hagamos lo que hagamos el escenario de uso diario de Word será el de la pantalla de edición (escenario 1).

2. Escenarios de uso periódico

  • Los personajes logran aquí objetivos concretos de manera esporádica.
  • Suele responder a un objetivo de un tipo de usuario determinado.
  • Es posible que una aplicación sólo tenga escenarios de tipo periódico. Por ejemplo un programa de copias de seguridad o un antivirus.
  • Su uso esporádico hace que los usuarios accedan a estos escenarios como si fuera la primera vez y se olvidan de los “trucos” que aprendieron la vez pasada.
  • El foco en este tipo de escenarios es realizar la tarea lo más rápido posible.
  • Deben reflejar el modelo mental

EJ: En Word, un escenario de uso periódico sería la función combinar correspondencia. Para la mayoría de los usuarios no es una funcionalidad que se utiliza más de una vez al mes.

3. Escenario de uso necesario

    • Estan hechas para satisfacer las necesidades de la aplicación.
    • Los sistemas de archivos y las pantallas de configuración son los máximos exponentes de este tipo de escenarios.
    • Los personajes no logran objetivos prácticos en este tipo de escenarios.
    • Son de uso muy esporádico.
    • Reflejan el modelo de implementación, exponiendo al personaje al sistema de archivos, las características del equipo y a otros detalles técnicos totalmente ajenos a los objetivos reales de estos.
    • Hay dos reglas básicas respecto a estos escenarios:

1. Tratar de eliminarlos.

          Tomar decisiones valientes por los usuarios. Programando para averiguar la información que necesita en vez de preguntarla. Incluyendo valores por defecto adecuados. Si no es posible esto:

2. Versión light.

        El software debe funcionar razonablemente bien sin necesidad de pasar por ningún escenario de uso necesario. Colocando unos valores por defecto que permita trabajar con la aplicación en una primera instancia y si es preciso poder modificar alguna configuración más adelante.

EJ: Los usuarios no suelen cambiar las pantallas por defecto que traen sus navegadores web. No es que no sepan como cambiarlo, es que no saben que se puede hacer. Para hacerlo usarían la pantalla de configuración, cosa que siendo sinceros la mayoría nunca ha usado, sólo los «frikis» por la tecnología.

4. Escenarios de caso límite

    • Los personajes se los encuentran en situaciones límite (el disco está lleno, el documento de un nombre tienen 1024 caracteres!, el modem no encuentra línea.
    • Son situaciones de borde, en las cuales la aplicación trata de rebasar la frontera de las capacidades y hay que tomar una decisión al respecto.
    • Desde el punto de vista de los usuario estas situaciones tienen una importancia mínima mientras se cumplas estos dos requisitos:

Primero.

          Conserven el trabajo realizado hasta el momento.

Segundo.

        Den la oportunidad de llamar a un técnico que resuelva el problema.

EJ: El personaje Antonio compró un PC con Windows XP que utiliza en su oficina hace ya tres años y jamás tuvo el menor cuidado del espacio en disco. Cuando el procesador de texto dio el mensaje de error de “disco lleno”, salvó el documento, cerró el editor, vació definitivamente la papelera de reciclaje y volvió a abrir el editor y a trabajar en el documento, como si nada hubiera pasado. Para ese personaje la situación límite fue intrascendente, ignora que quien programó el editor hizo maravillas para que cuando él apretara el botón guardar, el documento se guardara íntegro como todos los días, a pesar de que no había en el disco espacio suficiente para ello.

Agrupación y dedicación

Debemos agrupar los escenarios por tipo y como guía priorizar dedicando:

  • 75% del tiempo a los escenarios de tipo diario
  • 20% del tiempo para los de tipo periódico
  • 5% del tiempo para los de uso necesario
  • 0% del tiempo para los de caso límite.

No debemos confundir estos porcentajes de dedicación, con los porcentajes necesarios para la programación. Puede darse el caso que para implementar un escenario de tipo diario se consuma un 10% de tiempo de toda la fase de implementación, uno de uso periódico 20% o uno de uso necesario 30% y uno de límite 40%. Son dos fases distintas, una cosa es «desarrollar» la interacción y otra programar para que esa interacción se haga realidad.

En le próximo, y último post sobre el método de «Diseño de la interacción”, me pararé a hablar de técnicas prácticas para aplicar este método.

Hasta el próximo post!.

Dejar un comentario