Ricardo Devis

Una Visión Panorámica

¡Acrónimos, Disciplinas y Círculos!

Según Dan Saffer, el Diseño de Interacción cae enteramente en el área del Diseño de la Experiencia del Usuario (UX), pero también tiene intersecciones con la Arquitectura de la Información (IA), la Ingeniería de Interfaces de Usuario (UIE), Factores Humanos (HT), Ingeniería de Usabilidad (UE), Diseño Gráfico (CD), Diseño Industrial (ID!) e Interacción Hombre-Máquina (HCI): O sea, se trata de un área multidisciplinar que, precisamente por esta característica, necesita de criterios claros que permitan establecer con nitidez sus lindes. De alguna forma, se trata de un “best of breed” .

Problemas, Trampas y NegociosUna Lengua Franca

Buena parte del esfuerzo en la abstracción informática se ha dado en tratar de superar el gap entre los modelos reales (el dominio del problema) y los modelos software (el dominio de la solución… software) …sin llegar a conseguirlo (de forma reglada)

▪ “Once upon a time there was a problem… and a software designer and… oh, well, just there were two problems” [Plinio Smith]

Así que –mayormente– los intentos de especificación de requisitos han derivado hacia el camino legal. Se trata de asegurarse que la solución software implantada es

inatacable (o difícilmente impugnable), desde el punto de vista jurídico, una vez que el cliente ha firmado una lista de requisitos funcionales (¿funcionales?)

Se dan, por tanto, diversas trampas que hay que evitar.

Los ProTecs acostumbran a comenzar sus proyectos con una fase de descubrimiento de requisitos (usualmente funcionales), que se plasman en documentos que suelen forzar a firmar a las empresas, para así determinar de forma monetariamente clara el alcance de sus trabajos Se trata de que el presupuesto se ajuste a la tarificación de tales

requisitos. Pero no es posible para la empresa valorar la completitud

de tales requisitos, sino sólo (y a veces ni siquiera eso) su corrección [explicar, explicar]. Es decir: el documento de requisitos es una condición interna

del proceso de implantación, propia del ProTec, que éste probablemente deba redactar▪ …pero no constituye hito alguno para la empresa, que, en cualquier

caso, sólo podrá corregir en él errores obvios, pero no validarlo.

Sin que se suela renunciar a los requisitos atómicos funcionales (que a menudo vienen acompañados de números de referencia, como las piezas de recambio), los ProTecs sustancian el “análisis” en la descripción de las secuencias de trabajo (a modo de “procesos”) que encuentran en el entorno de la empresa.

Pero de nuevo se da un importante gap: el detalle de tales procesos sólo tendría sentido si el nuevo sistema fuera exactamente igual que el anterior (o que la situación sin sistema informático alguno) …pues no son los procesos lo que hay que trasladar al

dominio de la solución, sino su esencia, los objetivos que los animan. Y esto no son requisitos ni secuencias, claro.

Los auto-denominados “Métodos Ágiles” (que yo diría “Métodos Frágiles”) fuerzan a la empresa/cliente a redactar los “escenarios de negocio” en los que basar las especificaciones de desarrollo software para construir los sistemas que les den soporte.

Se trata, sin más, de otro medio de control del límite de gastos y esfuerzos por parte de los ProTecs, pues… La capacidad analítica de las empresas no se evalúa antes

del trabajo

Los requisitos surgen, de tales escenarios, de forma quasi-mágica (pues las listas resultantes se basan en la experiencia y capacidades de su lector informático ).

El reto reside en que se dé “algo”, escrito o codificado en un lenguaje que sea inteligible, a la vez, para la empresas y para el ProTec …y que, por tanto, por derivación y

factorización, debería redactar el ProTec.▪ …y sobre lo que, además, se pueda establecer una

correspondencia con lo que se advenga después (diseño, software, interfaces, etc.)

Podríamos ya barruntar que tal lengua franca, por necesidad, habrá de ser el lenguaje natural. Pero… ¿se trata de una forma de especificar los

requisitos?▪ No. Los requisitos no sirven. Veamos por qué.

Abandono (posicional) de los RequisitosAbrazo (entusiasta) de los Objetivos

¿Cómo se determina la funcionalidad necesaria en una aplicación o paquete software? ¿Mediante el análisis funcional? ¡Ja, ja, ja, ja! ¿Por medio de conjuros? ¿En razón de la experiencia de… ¿los analistas??

Caso de Estudio Logitech lanza su primer escáner USB Filosofía: soluciones combinadas Hardware (Hw) +

Software (Sw) Precio bajo y calidad alta

¿Qué funciones añadir al Sw del escáner? Esto es: ¿cómo determinar que debería ofrecerse?

▪ Y “todo” no es una respuesta buena: de hecho NO es una respuesta

¿Qué criterios son los habituales? Según el Gestor

▪ Toda aquella funcionalidad que se nos ocurra.

Según los Programadores▪ Toda aquella que sepamos hacer.

Según el Jefe de Proyecto▪ Toda aquélla que se haya firmado y no se salga del presupuesto

▪ Y si no cuesta esfuerzo y/o dinero… opina como los programadores.

En resumen… Se ponen/ofrecen/habilitan muchas funciones (todas las

posibles) y entre ellas estará la que necesite el usuario.▪ Se suple la carencia de estrategia con fuerza bruta

Problema: Exhibir demasiada funcionalidad es tan malo como

ofrecer/habilitar/enseñar/poner poca. Y encima… lo que se haga de más no es gratis. Requiere mayor esfuerzo de desarrollo

El software es más complejo de utilizar▪ ¿Por dónde empiezo? ¿Y la formación? ¿Y…?

La funcionalidad útil se ve afectada por la innecesaria▪ ¿Cuál es el criterio para poner un chat en un sitio Web?

▪ Un buen plato no es mejor por tener más ingredientes

Los impactos de cada nueva funcionalidad en las ya existentes son cada vez más difíciles de calibrar y manejar.

!Un momento, un momento! ¡Eso no pasa en los desarrollo software a medida!

En los “proyectos software personalizados” se da una interfaz entre analistas, diseñadores y programadores. Los requisitos/funciones/tareas que debe reflejar y acometer el

programa se establecen en la fase de análisis. ¡Todo arreglado! ¿O no?

Problema de la lista de requisitos como interfaz: Falta información vital para el proceso de desarrollo

▪ RF3672: los usuarios tendrán que hacer (sic) login [!???!]▪ RF6728: el código de cada artículo será único [!???????]▪ RF8372: el cliente debe obtener una factura si la pide [!!??]

Cuando al diseñador/programador le llega una tal lista de funcionalidades… Frecuentemente piensa que… “Esta funcionalidad puede

hacerse (sic) de varias maneras”▪ ¿Cuál será la adecuada? ¿La que más proyección tenga?▪ ¿(Se) Necesitará más flexibilidad?

Así que el programador/diseñador se encuentra sin criterios objetivos… para realizar su trabajo.

Fabricar una Máquina que cumpla con los Siguientes Requisitos:

1. Que tenga un motor de combustión interna

2. Cuatro ruedas3. Un sistema de

transmisión del motor a las ruedas

4. Todo ello en un chasis de metal

5. Que tenga un volante

¿Qué se perdió en la lista de Requisitos?

1. La potencia necesaria del motor

2. El tamaño de las ruedas

3. La velocidad mínima

4. El número de pasajeros (??)

5. Las posibles adiciones

¡Falta el objetivode la máquina!

¡Objetivos!

Objetivo: Cortar el césped de forma rápida y cómoda.

Y ahora, con este objetivo en mente, todos los requisitos (que ahora se entienden de otra manera) hallan su contexto operativo, su entorno correcto y los límites de sus rangos, valores y calibraciones.

Planteamiento de Problemas

Pasar por todos los puntos trazando cuatro líneas rectas… sin levantar el lápiz del papel.

Problema de Límites

Los límites son, usualmente, sólo auto-limitaciones.

Extensión de Problemas

Pasar por todos los puntos (sin levantar el lápiz del papel) trazando…

1. Una sola línea recta

2. Una sola línea recta… ¡por un solo punto!

Resolución General de Problemas: “The overly strict limits are a block in the mind of the solver […]. A

solution is sensitive to the proper isolation of the problem. In general the more general de problem can be stated the more room is available for conceptualization”

James L. Adams [Conceptual BlockBusting] Los objetivos, como criterios clave, son la forma de

plantear los problemas que permite un mayor rango de soluciones …y no un mayor rango de opciones [explicar].

▪ Requisito (malo): exigencia de identificación de usuarios▪ Objetivo (razonable): evitar la desaparición de información▪ Implementación (plausible): que nada se borre [versionamiento]

▪ Si se evita el requisito y se hace caso al objetivo, la implementación se centra en el problema en sí, y no en una de sus funcionalidades posibles (opción de “login”).

¡ID! ¡Sorpresa!

En definitiva…

1. Es difícil determinar la funcionalidad que debe ser construida y exhibida en una aplicación.

2. Es tan malo pasarse como quedarse corto.

3. Los requisitos no son suficientes.

tachán,

tachán,tachán,tachán

El Diseño de Interacción

(ID: Interaction Design)

Modelado mediante Personas, Objetivos y EscenariosUn Ejemplo Práctico

Al final… ¡Tiene que haber un programa! Por tanto obtener una codificación es un objetivo

¿Qué se necesita, entonces, en las fases de desarrollo? Un planteamiento del problema que permita soluciones efectivas

▪ Las [Personas + Objetivos] son ese planteamiento

El analista tiene que descubrir, pues… Quién es el usuario y cuáles son sus necesidades fundamentales

Y… ¿Entonces…?

No se trata de renunciar a los requisitos formales, sino de superar el “gap mágico” que se da entre estos y la solución final, pues es cierto que parece darse una suerte de milagro entre lo que se requiere y lo que se obtiene.

Las herramientas para obtener resultados que puedan ser trazados son: personas, objetivos y escenarios. Veámoslas.

Personas

Objetivos

Escenarios

Persona

“Una persona es la descripción precisa de un usuario y de lo que quiere lograr” [Alan Cooper]

Modelo

“Esquema teórico de un sistema o de una realidad que se elabora para facilitar su comprensión y el estudio de su comportamiento” [DRAE]

Ejemplo

v = e / t [Algún griego]

En informática ya se utilizan modelos Pero... ¿por qué no modelar también los usuarios?

▪ Si es el objetivo de todo sistema ¿cómo no estudiarlo y comprenderlo?

Los modelos se utilizan para estudiar, en un determinado contexto (en razón del que se construye el modelo) el objeto que constituye la base del modelado [¡Uf, cuánto repetir la raíz “modelo”!, ¿eh?] Así, por ejemplo, un CrashTest Dummy es un modelo de

una persona en el contexto de un accidente (de automoción), que permite estudiar su evolución y reacciones en tal contexto.

¿Qué me tiene que decir un modelo de una Persona?

Problemas a resolver para y por el analista: ¿A quién entrevista el analista cuando el usuario no está

accesible?▪ Paquetes Software o Sitios Web

Aunque pueda entrevistar al usuario… ▪ ¿Qué la va a responder éste cuando se le pregunte si quiere la

funcionalidad X? Ventajas de un modelo del usuario Sustituye al usuario cuando NO se le puede preguntar qué

necesita Sustituye al usuario cuando se le puede preguntar qué

necesita▪ Ojo, que el usuario sigue siendo imprescindible…

¿Qué debe tener el modelo? Nombre

▪ El identificador único de la “persona”, que nos permite referirnos a ella de forma inequívoca

Descripción Objetivos (motivación y

razón)

Nombre María Excel

Descripción María trabaja de secretaria en

el Departamento de Expediciones. Ha estudiado algo de Office y es administrativa. No usa Internet pero es capaz de hacer hojas de cálculo complejas con fórmulas y gráficos en cuestión de minutos.

Objetivos Mantener informado a su

superior sobre desviaciones en el volumen de los envíos

¿De donde se extrae la información de una Persona? Entrevistas con usuarios (se avisó) Estudio de sistemas existentes Procedimientos, etc.

La idea es recabar toda la información que se pueda y con ello formar el modelo de los usuarios Una vez hecho esto se extrae/deduce el resto de la

información a partir del modelo▪ Es el matiz diferencial con un análisis clásico

¿Hasta donde describir una Persona?

Hasta que permita la empatía

▪ Empatía: "Identificación mental y afectiva de un sujeto con el estado de ánimo de otro" [DRAE, otra vez]

ID es el Método Stanislavsky del Diseño

Y… ¿dónde ensaya? (esto, es ¿dónde se utilizan las personas?

▪ En las Reuniones de Diseño

Reuniones de Diseño [Antes]: Diseñador 1: ¿Y si el usuario quiere imprimir esto? Diseñador 2: No creo que quiera imprimir eso Diseñador 1: Pero a lo mejor alguien quiere imprimirlo Diseñador 2: Yo creo que no.

▪ [Repetir esta discusión en cada reunión hasta el final del proyecto] Reuniones de Diseño [con Personas]: Diseñador 1: ¿Y si el usuario quiere imprimir esto? Diseñador 2: El usuario se llama María y a María eso no le sirve para

nada. Lo haría con el Excel. Diseñador 1: Pero a lo mejor le sirve a otro usuario Diseñador 2: Pero estamos diseñando para María.

▪ [Fin de la discusión y a tomar unas cervezas] La Persona es un ente al que se invoca para atajar los “¿Y si…?”

El Usuario Elástico

Otro objetivo de las personas es evitar el problema del “usuario elástico”

El software se escribe, en vez de para personas, para este legendario usuario elástico… que no existe!!

Debería ser el software el que se adaptara a las necesidades del usuario

Normalmente es al usuario al que se le estira para que encaje en la funcionalidad

Personas

Objetivos

Escenarios

La parte fundamental del modelo de un usuario (Persona) son los objetivos Los objetivos son los que motivan a las personas “a

hacer las cosas”▪ Por ellos se sabe qué cosas harán y cuáles no

Los objetivos son las motivaciones para que las personas desarrollen requisitos Por tanto la única forma de saber qué requisitos se

necesitarán implementar es averiguar sus objetivos ¿Cómo se sabe si un diseño es un buen diseño? ¿Cómo comenzar entonces un desarrollo sin

considerar personas y sus objetivos?

¿Cómo saber si hemos encontrado un requisito o un objetivo? Un objetivo es una condición final

▪ Un requisito es un medio para conseguir un objetivo▪ Objetivo: viajar a Vitoria

▪ Requisitos: comprar un coche, lavarlo, echar gasolina, echar aceite, pagar seguro.

Los objetivos permanecen, los requisitos cambian▪ Los requisitos tienen que ser planteados (y re-planteados) en

función de la tecnología disponible

▪ Si se tiene una lista de requisitos uno se suele limitar a optimizarlos en vez de replantearlos

Objetivos Finales Representan las expectativas de una Persona a la hora de

interactuar con un producto▪ Encontrar el mejor precio▪ Generar las facturas▪ Dar la situación de la empresa

Objetivos Personales Son objetivos que tiene toda Persona. Por tanto a veces no es

necesario explicitarlos (por generales), pero mi consejo es que sí se detallen expresamente (pues en ciertos entornos, como por ejemplo las redes sociales, son determinantes)▪ No sentirse estúpido▪ No cometer errores▪ Divertirse (o al menos no aburrirse).

Durante la fase de análisis se extraen los objetivos finales Deben ser cumplidos para

que el usuario vea al producto como algo útil▪ Pero deben cumplirse

obligatoriamente también los objetivos personales para que el producto tenga éxito

La esencia del ID es plantear una interacción que cumpla los objetivos finales sin violar los objetivos personales

Personas

Objetivos

Escenarios

Finalmente hay que llegar a concretar la funcionalidad que tendrá cada sistema. Los requisitos no desaparecen; se entregan igualmente… pero

en un diferente contexto: el de los objetivos Los escenarios son la herramienta para averiguar las

requisitos necesarios para cumplir con los objetivos de las personas “Un escenario es una descripción concisa de una Persona usando

una aplicación para cumplir uno o más de sus objetivos” [Alan Cooper]

¿Cómo se crean los escenarios? Poniéndose en el papel de una Persona se coge uno de sus

objetivos y se busca la forma más directa de conseguirlo▪ Debe interpretarse el papel intentado pensar cómo él y teniendo en

cuenta sus habilidades, capacidades y posibilidades.

Un escenario es a la vez generador de requisitos y filtro para desestimarlos

No tiene sentido un requisito que no venga de un escenario

No tiene sentido un escenario que no sea la forma más sencilla de lograr un objetivo

Norma Fundamental para la Obtención de Escenarios

“No presuponer ningún sistema ni herramienta”

Tipos de escenarios Diarios

▪ Son los más importantes ya que son los se realizan con mayor frecuencia

Necesarios▪ Son el resto de las acciones que deben ser realizadas para

cumplir los objetivos (mantenimiento, medidas correctivas, etc.)

En función de ello habrá que implementar la solución más… Eficaz Sencilla

Veamos un ejemplo de ID Logitech lanza su primer escáner USB

La filosofía de esta compañía es lanzar soluciones combinadas Hardware + Software

Gama media/alta con muy buen precio ¿Qué funciones añadir al Software del escáner? Lo primero que hay que hacer es…

▪ …Quitar toda funcionalidad▪ No hay personas ni objetivos así que no tiene sentido plantear

alternativas de diseño que no se pueden validar

Comenzar identificando personas…

VÍCTOR WEBITO

Es un chico de 25 años que ha montado una pequeña empresa en su casa para crear sitios Web.

Sus conocimientos técnicos son los justos para construir sitios Web pequeños. No es un artista gráfico pero utiliza imágenes para formar la estética de sus sitios Web. El escáner le permite obtener imágenes de calidad media, algo suficiente para la Web.

CARLOS ESTUDIANTE

Universitario de 20 años que necesita escribir frecuentemente trabajos o informes que debe presentar en clase .

Sus conocimientos son los básicos que le permiten usar el Word (o similar) para escribir las prácticas, sin demasiadas florituras. Utiliza el escáner para mejorar sus trabajos con imágenes de libros o fotografías.

INOCENCIO GRÁFICO

Profesional free-lance que comienza en el negocio de diseño gráfico (un novato, en definitiva).

No puede hacer una gran inversión por lo que nuestro escáner le servirá durante el inicio de su carrera.

EXPERTO DELAMUERTE

Un diseñador gráfico profesional queda rechazado como Persona

Ni Víctor ni Carlos (programador y universitario) están interesados en manipular imágenes Su objetivo no es escanear imágenes con calidad

profesional y, por tanto…▪ No quieren tratar con resoluciones y demás pamplinas de

configuración del escáner▪ Quieren encontrar sus imágenes rápidamente y colocarlas en los

documentos destino Inocencio si que quiere… Controlar los aspectos del escaneado

▪ Conoce las resoluciones y la representación del color

Manipular la imagen de forma avanzada▪ Filtros, máscaras, manipular colores, etc.

▪ Sin embargo… por ello precisamente no va a utilizar nuestro software.

En cuanto a la resolución del escaneado

Victor y Carlos no saben lo que es eso

▪ Sería mejor no enfrentarles con esa decisión

Inocencio sabe manejar las resoluciones

▪ Pero... ¿con qué objetivo?

En definitiva los objetivos (comunes) son:

Poder cambiar el tamaño de la imagen

Insertarla en otro programa

Sin herramientas

Acceso directo a los programas

No pregunta dónde guardar

la imagen

Objetivos cumplidos Eliminar completamente la configuración del escaner Evitar tener que colocar y buscar las imágenes por el

sistema de ficheros El programa está orientado a insertar las imágenes en

otros programas Resultado En las evaluaciones fue calificado como el software

más práctico de escaneado Fue el producto de Logitech que menos llamadas de

soporte recibió Fue en el que menos se invirtió en desarrollo

Casos de Uso, UsabilidadDiseño Gráfico, Producción Cinematográfica

Generalmente se utilizan los casos de uso para documentar la funcionalidad ya establecida del sistema Cuando se diseña un caso de uso habitualmente se hace con la

segmentación funcional en mente El interior que pasa a ser el origen de todo en vez de una

consecuencia▪ Va hacia atrás

Podría utilizarse en el mismo sentido que el ID Pero los actores tienen poca entidad y dependen de la visión

funcional que se tenga del sistema▪ Altas, bajas, modificaciones...

Las últimas propuestas en construcción de Casos de Uso proponen una tendencia hacia el ID.

La usabilidad es un complemento del diseño de interacción, pero no es suficiente sin éste Los tests de usabilidad con usuarios pueden mostrar

la eficacia de un usuario para realizar requisitos propuestas▪ Pero no sirven para demostrar si esas requisitos son las que

realmente cumplen los objetivos

La usabilidad es “no hacer perder tiempo al usuario” El ID es no hacer perder tiempo a los desarrolladores y

al cliente.

El Diseño de Interfaces sigue estando al final del ciclo de vida La estética es cuestión de gusto

▪ La estética atrae al usuario; el ID lo captura El problema del diseño de interfaces es que

asume que hay Personas por un lado y código por otro. Su misión es que se comuniquen

El objetivo del Diseño de Interacción no es diseñar pantallas. Pero se sirve de ellas para calibrar la consecución de

los objetivos

Preproducción Producción Post-Producción

Escribir Guiones

Storyboards

Casting

…

Rodar

Actores se

emocionan

Gritar “corten”

Repetir toma

…

Montaje

Banda Sonora

Promoción

…

Personas y

Objetivos

Escenarios

requisitos

Paper

Prototyping

Especificaciones

Diseño

(componentes)

Programar

Cierre

Documentación

Pruebas

Formación

Mantenimiento

…

¿Dónde están los pasos para obtener Personas?

¿Cómo se obtienen entonces las Personas? ¿Qué supone pasar al ID? Si al final depende de las personas ¿Por qué

usar el ID? Porque el esfuerzo de análisis es similar pero se

obtiene un resultado más fácil de validar, simplificar y comunicar a desarrollo▪ Documentación que aporte valor

Catálogo de Personas y Objetivos

Descripción de Escenarios De Interacción con el

Sistema▪ Textual▪ Prototipos [en papel] de las

pantallas

De Interacción entre Subsistemas ▪ Diagramas de Secuencia de

Invocaciones y Notificaciones▪ Requisitos para otros lotes

Especificación de Subsistemas Paper Prototyping Invocaciones, Notificacion

es Entidades y Relaciones Diagrama de clases Diagramas de secuencia

Manuales del usuario Extraídos, en buena

medida, de los escenarios Guías de Administración

del Sistema Guías de Instalación

Reflexión Ponente/AsistentesDebate Final

Requisitos Análisis Objetivos Personas Escenarios Interacción Ejemplos Aplicaciones Prototipos Funciones Entregables Libros