Prototipos y

diseño iterativo
Marco Antonio Contreras Arévalo #1630529
Abraham Israel Rodriguez Torres #1652599
Erick Arnulfo
  Una parte crucial de hacer una buena interfaz de usuario es hacer
prototipos tempranos del usuario interfaz y probarlos para la
Prototipos y usabilidad.
 Esto se llama diseño iterativo y mostramos cómo funcionó en un
diseño caso específico: un sistema hotelero con altos requisitos de
iterativo usabilidad.
 Finalmente, observamos varias formas de prototipos y sus pros y
contras.

Dado que los desarrolladores tienen problemas para crear la
interfaz de usuario, ¿no podrían pedirle a algunos especialistas en
usabilidad que lo diseñaran, o al menos mirar el diseño del
desarrollador y ayudarlos a mejorarlo?
 Esto probablemente sería mejor, pero recuerde que incluso los
especialistas en usabilidad son malos para predecir los problemas
de usabilidad al principio del desarrollo (la primera ley de
usabilidad).
  ¿Cuál es la solución? Tenemos que atacar el problema básico que
los desarrolladores no tienen conocer a los usuarios y sus tareas, y
que los problemas de usabilidad no se pueden predecir.
Enfoque  El mejor enfoque en la práctica común consiste de tres técnicas
centrales:
clásico: diseño  1 Permita que los desarrolladores estudien a los usuarios y sus
iterativo tareas como parte del análisis (análisis de tareas).
 2 Haga un prototipo temprano en la fase de diseño. Revísalo con
usuarios expertos.
 3 Usabilidad prueba el prototipo con usuarios típicos. Corrija el
prototipo para eliminar problemas de usabilidad, prueba de nuevo
y así sucesivamente hasta que el resultado sea satisfactorio. Esto
es diseño iterativo - no desarrollo iterativo
Tercera ley de  Mientras más esfuerzos hayan dedicado los desarrolladores a
hacer un prototipo, menos dispuestos estarán a reemplazarlo.
usabilidad
  Sin embargo, el diseño iterativo clásico tiene algunos puntos
débiles:
 1 No hay una forma sistemática de diseñar las pantallas. ¿Cuántas
pantallas se necesitan? ¿Qué deberían contener? En el enfoque
Puntos débiles clásico, es de prueba y error.
 2 No hay una forma sistemática de corregir los problemas de
usabilidad una vez que se detectan.
 3 Es difícil encontrar usuarios de prueba con el perfil correcto.
Historia del  El autor, con el apoyo de diferentes colegas, se propone
desarrollar dicho sistema. En el resto del libro mostraré varias
desarrollo instantáneas de este proceso. Los pasos principales son estos:
Fase de  Estudié hoteles mientras viajé a muchos países en todo el mundo
mundo. No miré los sistemas de TI actuales que usaban, pero
análisis. escuché los comentarios en su sistema.
  ventanas virtuales. Junto con Morten Borup Harning, desarrollé un
plan para pantallas que mostrarían los datos necesarios para todas
las tareas del usuario.
 Hicimos un Borrador de papel y lápiz sin importar qué botones y
Primer diseño: menús necesarios y qué pantallas de búsqueda eran necesarias.
(En realidad, esto no fue solo prueba y error, pero es parte del
método de diseño sistemático. Las pantallas fueron lo que
llamamos ventanas virtuales.)
Primer  Más tarde, agregué las cosas faltantes a las pantallas y tiene un
prototipo de papel y lápiz (una maqueta dibujada a mano).
prototipo y  Esto se basó en mi intuición y hecho bajo presión de tiempo, como
pruebas de sucede a menudo en proyectos de TI. I usabilidad probado el
prototipo con tres usuarios típicos. Esto reveló mucha usabilidad
usabilidad. problemas, como veremos en la siguiente sección.
  La lección que aprendí de estas pruebas de usabilidad fue que lo
Diseño haría pagar para hacer un diseño más sistemático. Continuando en
una forma de prueba y error parecía poco realista.
sistemático  Así que seguí el resto del método de ventana virtual.
  El resultado del proceso de diseño sistemático fue bastante fácil de
transformar en un prototipo. En este punto, decidí usar Microsoft
Acceso, porque estaba ampliamente disponible. (Previamente había
imaginado usando Visual Basic o C ++).
 Hice un prototipo más avanzado: una maqueta basada en
herramientas.
Próximo  Las pantallas eran 'Dibujado' por medio de acceso e impreso en papel.
 Los datos fueron agregados a lápiz estas impresiones.
prototipo y  Las pruebas de usabilidad mostraron que muchos de los problemas
pruebas de anteriores tenían ahora desapareció, no tanto porque las pantallas
eran más parecidas a Access, sino por las primeras pruebas de
usabilidad y el proceso de diseño sistemático. Sin embargo, algunos
usabilidad de los problemas persistieron y no desaparecieron después de varios
cambios de diseño.
 Estos problemas no fueron muy serios, y con una hora de
entrenamiento, incluso principiantes los usuarios podrían operar el
sistema. Sin embargo, la ambición era que los novatos los usuarios
deberían poder averiguar por sí mismos, al menos sobre tareas
básicas. Debería olvidar este objetivo?
  En este momento, me sentí completamente frustrado por estos
estúpidos y persistentes problemas de usabilidad. Los problemas
relacionados con la pantalla importante donde la recepcionista
buscaba invitados.
 En un último intento, decidí probar una búsqueda en vivo donde el
resultado de la búsqueda cambiaba cada vez que la recepcionista
Prototipo ingresaba a un solo personaje, por ejemplo, en el nombre del
invitado. Sin embargo, no puedes probar esto con una maqueta de
funcional papel.
 Necesita un sistema con alguna funcionalidad real. Así que tuve
que desarrollar uno, pero primero tuve que aprender cómo
realmente funcionaba Access. Aunque es bastante fácil crear
pantallas simples con Access, es extremadamente difícil averiguar
acerca de la funcionalidad avanzada, como una búsqueda en vivo.
  La documentación es muy oscura y los libros de texto existentes
son demasiado básicos o demasiado avanzados. Aprender cómo
funciona realmente Access llevó meses de arduo trabajo.
 Muchos expertos de Access me ayudaron en el camino, pero no
pudieron decirme de inmediato cómo hacer que la interfaz de
usuario funcione según lo previsto.

Prototipo  Cuando desarrollaron aplicaciones de acceso, las basaron en lo

que era fácil de hacer, no en las observaciones de usabilidad. Sin
funcional embargo, resultó que las soluciones técnicas eran muy simples,
una vez que entendía cómo funcionaban las cosas.
 El resultado valió la pena.
 La búsqueda en vivo y algunos otros trucos hicieron que el sistema
sea intuitivamente comprensible.
 Fue genial ver la sonrisa en el rostro del usuario de la prueba
cuando el sistema respondió de inmediato y descubrieron cómo
funcionaba.
  Algunas personas concluyen a partir de esto que afirmo que las
búsquedas en vivo son la panacea. ¡Todo mal! La lección es que
algunos problemas de usabilidad no se pueden eliminar con
prototipos de papel y lápiz.
La leccion.  Necesitas un prototipo parcialmente funcional.
 Aunque una búsqueda en vivo resolvió algunos problemas de
usabilidad difíciles en este caso, no significa que otros casos
también necesiten búsquedas en vivo.
  Ahora no había ninguna duda sobre cómo debería funcionar la
El sistema final interfaz de usuario, y el resto de la programación fue bastante
fácil.
  Para responder a esta pregunta, tenemos que mirar el propósito
de los prototipos se usan para:
¿Qué versión  ¥ Pruebas de usabilidad (encontrar los problemas de usabilidad)
de prototipos  ¥ Cambiar el diseño - a menudo radicalmente
es la mejor?  ¥ Definir qué programar
 ¥ Discutir soluciones con usuarios
  pantallas para copiar. El usuario completará los datos en una pantalla en blanco. El equipo de
prueba lo hará
 precompletar a otros con datos correspondientes a las situaciones esperadas.
 También podemos necesitar listas desplegables, mensajes de error, etc. Aquí hay una lista de lo
que necesitamos
 para una maqueta completa:
 a) Pantallas vacías para copiar.
Contenido de  b) Pantallas rellenas con datos realistas (copias).
 c) Pantallas que el usuario puede completar (copias).
una maqueta  d) Menús que pueden mencionarse.
 e) Enumera ese menú desplegable cuando el usuario hace clic en un cuadro combinado.
 f) Cuadros de diálogo, por ejemplo, uno que pregunta si enviar una confirmación de reserva por
carta, fax o correo electrónico.
 g) Mensajes de error, por ejemplo, uno que dice que no puede reservar una habitación cuando
no tiene seleccionado el invitado para reservar.
 h) Ayuda de textos de varios tipos, por ejemplo, ayuda emergente (consejos de control).
 cuando el usuario deja que el mouse "descanse" sobre un botón.
 i) Algunas notas para que el facilitador le recuerde cuáles son las funciones no obvias y los
puntos de menú se supone que deben hacer.
  Veamos primero los beneficios de una alta usabilidad:
Beneficios de  Aprendizaje más rápido. Cuando el sistema es fácil de aprender,
la usabilidad los usuarios pasan mucho menos tiempo aprender a usar el
sistema, y no tienen que tomar cursos caros.
 Todo esto significan ahorro en los costos.
Un trabajo
 Cuando el sistema es eficiente para el uso diario, las personas
diario más trabajan más rápido y El dinero se guarda más.
rápido.
  Cuando los usuarios no cometen errores, no pierden su propio
Menos errores tiempo, y no pierden tiempo para el soporte de TI o colegas
expertos que tienen que resolver el problema errores.
Menos  Cuando el sistema es fácil de usar, los usuarios llaman mucho
menos a la línea directa.
demanda de  La línea directa es costosa y necesita personal altamente
línea directa. calificado.
Mejor  Cuando los usuarios les gusta el sistema, se sienten motivados.
motivación y  Esto los hace funcionar mejor y más rápido, también en áreas que
no se relacionan directamente con el sistema.
menos estrés.
  Cuando el sistema es motivador y fácil de aprender, podemos
atraer más usuarios.
 Esto es particularmente importante cuando el sistema es opcional:
Más usuarios los usuarios pueden elige descuidar el sistema.
 La mayoría de los servicios web son opcionales y atraer usuarios es
una preocupación clave.
  a) What is the difference between traditional systems development,
iterative?
 El diseño tradicional se enfoca mas al diseño logico o funcional del
software y el iterativo se enfoca mas en la usabilidad y la participacion
de un diseñador o el usuario final en las "iteraciones" de el desarrollo
del software
 b) How many design iterations are usually needed?Eso depende de
cada proyecto, pero usualmente se usan dos iteracciones en el
modelo Iterativo clásico
Test Yourself  c) What are the main problems with the classical iterative design?El
modelo iterativo puede generar un incremento en el tiempo para
completar el proyecto, por otra parte las iteracciones no son una
herramienta de diseño si no una herramienta para encontrar
problemas o sus soluciones
 d) Did the first law of usability work in the hotel case?No, porque
generaban mas problemas inexistentes
 e) What went wrong in the horror story?La interfaz era muy funcional
pero el aspecto de usabilidad no se tomo en cuenta y el sistema era
muy completo pero dificil de usar
 f) How much should we add to the ordinary development costs to make the system user-
friendly?
 Aprendizaje más rápido. Cuando el sistema es fácil de aprender, los usuarios pasan mucho
menos tiempo aprender a usar el sistema, y no tienen que tomar cursos caros. Todo esto
significa ahorro en los costos. Un trabajo diario más rápido. Cuando el sistema es eficiente para
el uso diario, las personas trabajan más rápido.
 g) Mention the four basic kinds of user interface prototypes.
 Dibujado a mano maqueta. El diseñador dibuja las pantallas a mano usando papel y lápiz.
Durante las pruebas de usabilidad, cambia las pantallas (o abre y cierra las ventanas) El
diseñador 'responde' en nombre de la computadora escribiendo los resultados en la pantalla.
(Este fue el primer prototipo de sistema hotelero).
 Maqueta dibujada por la herramienta. El diseñador dibuja las pantallas en la computadora
usando el misma herramienta que se usará en el producto final.
 Prototipo funcional Es similar a un prototipo de pantalla, pero muchos de los botones, puntos
de menú, etc., realmente hacen algo. Pueden, por ejemplo, abrir y cerrar Windows, actualice
datos en pantallas relacionadas y saque datos de una base de datos real.
 Prototipo de pantalla. Las pantallas se muestran en la pantalla de la computadora real, pero
tienen poca funcionalidad. Normalmente, el usuario puede ingresar datos en algunos de los
campos, pero cuando presiona un botón o selecciona un punto de menú, nada sucede por sí
mismo.
 h) What is the accelerator effect?
 Realizar maquetas de las pantallas más importantes, las que se usan la mayor parte del tiempo
o en situaciones críticas Usabilidad Pruébelas cuidadosamente y revíselas hasta que sean
fáciles de usar. ¥ Ahora diseña el resto de las pantallas y crea prototipos de ellas. Parece menos
Es crítico si estos prototipos son maquetas o más o menos funcionales prototipos.
 i) What should a complete mock-up contain?
 También podemos necesitar listas desplegables, mensajes de error, etc. Aquí
hay una lista de lo que necesitamos para una maqueta completa:
 a) Pantallas vacías para copiar.
 b) Pantallas rellenas con datos realistas (copias).
 c) Pantallas que el usuario puede completar (copias).
 d) Menús que pueden mencionarse. e) Enumera ese menú desplegable
cuando el usuario hace clic en un cuadro combinado.
 f) Cuadros de diálogo, por ejemplo, uno que pregunta si enviar una
confirmación de reserva por carta, fax o correo electrónico.
 g) Mensajes de error, por ejemplo, uno que dice que no puede reservar una
habitación cuando no tiene seleccionado el invitado para reservar.
 h) Ayuda de textos de varios tipos, por ejemplo, ayuda emergente (consejos
de control). cuando el usuario deja que el mouse "descanse" sobre un botón
 . i) Algunas notas para que el facilitador le recuerde cuáles son las funciones
no obvias y los puntos de menú se supone que deben hacer.