Diseño de Interacción - El primer Paso Necesario (Ricardo Devis)
Upcoming SlideShare
Loading in...5
×
 

Diseño de Interacción - El primer Paso Necesario (Ricardo Devis)

on

  • 516 views

El Diseño de Interacción (IxD) se ha convertido, lenta e imperiosamente, en el mejor conjunto de técnicas para definir el comportamiento de un sistema digital frente a los comportamientos ...

El Diseño de Interacción (IxD) se ha convertido, lenta e imperiosamente, en el mejor conjunto de técnicas para definir el comportamiento de un sistema digital frente a los comportamientos segmentados de sus usuarios (personae). He aquí una breve y sencilla introducción al ánimo y métodos del IxD.

Statistics

Views

Total Views
516
Views on SlideShare
514
Embed Views
2

Actions

Likes
4
Downloads
10
Comments
0

2 Embeds 2

http://www.linkedin.com 1
https://twitter.com 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Diseño de Interacción - El primer Paso Necesario (Ricardo Devis) Diseño de Interacción - El primer Paso Necesario (Ricardo Devis) Presentation Transcript

  • Ricardo Devis
  • Una Visión Panorámica
  • ¡Acrónimos, Disciplina s 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 Negocios Una 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 quasimá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 Requisitos Abrazo (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. 2. 3. 4. 5. Que tenga un motor de combustión interna Cuatro ruedas Un sistema de transmisión del motor a las ruedas Todo ello en un chasis de metal Que tenga un volante
  • ¿Qué se perdió en la lista de Requisitos? 1. 2. 3. 4. 5. La potencia necesaria del motor El tamaño de las ruedas La velocidad mínima El número de pasajeros (??) Las posibles adiciones ¡Falta el objetivo de 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 autolimitaciones.
  • Extensión de Problemas Pasar por todos los puntos (sin levantar el lápiz del papel) trazando… 1. 2. Una sola línea recta 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. 2. 3. Es difícil determinar la funcionalidad que debe ser construida y exhibida en una aplicación. Es tan malo pasarse como quedarse corto. 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 Escenarios Un 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  Nombre  María Excel ▪ El identificador único de la “persona”, que nos permite referirnos a ella de forma inequívoca 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.  Descripción  Objetivos (motivación y razón)  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”  ¿Cómo se crean los escenarios? [Alan Cooper]  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 CARLOS ESTUDIANTE 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.   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, Usabilidad Diseñ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 Escribir Guiones Storyboards Casting … Producción Rodar Actores se emocionan Gritar “corten” Repetir toma … Personas y Diseño Objetivos (componentes) Escenarios Programar requisitos Paper Prototyping Especificaciones Post-Producción Montaje Banda Sonora Promoción … 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   Paper Prototyping  Invocaciones, Notificacion es  Entidades y Relaciones  Diagrama de clases  Diagramas de secuencia  De Interacción con el Sistema ▪ Textual ▪ Prototipos [en papel] de las pantallas  De Interacción entre  ▪ Requisitos para otros lotes Manuales del usuario  Extraídos, en buena Subsistemas ▪ Diagramas de Secuencia de Invocaciones y Notificaciones Especificación de Subsistemas medida, de los escenarios   Guías de Administración del Sistema Guías de Instalación
  • Reflexión Ponente/Asistentes Debate Final
  •             Requisitos Análisis Objetivos Personas Escenarios Interacción Ejemplos Aplicaciones Prototipos Funciones Entregables Libros