El documento describe los procesos de diseño, prototipado y construcción de productos. Explica que el diseño comienza con la creación de un modelo conceptual y continúa con el diseño físico detallado a través de iteraciones de prueba con usuarios. También cubre técnicas como el storyboarding, prototipado en papel, wireframing y el uso del método "Mago de Oz" para simular interacciones y obtener retroalimentación temprana de usuarios.

1. Diseño, prototipo y
construcción

2. Diseño
 Diseño conceptual. Desarrollo de un modelo
conceptual que captura lo que un producto hará y su
comportamiento.
 Diseño físico. Se enfoca al los detalles del diseño tales
como pantalla, menús, íconos y gráficos.
 Surge de un proceso iterativo de rediseño con la evaluación de
usuarios.

3.  Modelo conceptual orientado a producto.
 Su estructura se basa en los productos y herramientas que los
usuarios crean, modifican y mantienen.
 Ej: Ofimática.
 Modelo conceptual orientado a proceso.
 Su estructura se basa en la lista de pasos de proceso que
conforman la base de una aplicación.
 Ej: SW para controlar una planta química, un paquete
administrativo o contable, etc.

4. Circunstancias de diseño
 Cuando se empieza desde cero.
 Cuando se modifica un producto existente.
 Agregar características adicionales.

5. Perspectivas para el desarrollo
de un modelo
 1. Modo de interacción.
 Depende de las actividades del usuario, dónde y cómo hace su
tarea / usara un desarrollo.
 2. ¿Se puede usar alguna metáfora en la interfaz?
 Si es posible, aprovechar metáforas del dominio del que el
usuario esté familiarizado.
 3. ¿Qué paradigma de interacción se usará?
 De escritorio / móvil / Web.
 Cómputo ubicuo.
 Cómputo pervasivo.
 Wearable computing.
 Otros.

6. Perspectivas para el desarrollo
de un modelo contextual
 1. Modo de interacción.
 Depende de las actividades del usuario, dónde y cómo hace su
tarea / usara un desarrollo.
 2. ¿Se puede usar alguna metáfora en la interfaz?
 Si es posible, aprovechar metáforas del dominio del que el
usuario esté familiarizado.
 3. ¿Qué paradigma de interacción se usará?
 De escritorio / móvil / Web.
 Cómputo ubicuo.
 Cómputo pervasivo.
 Wearable computing.
 Otros.
Son decisiones tentativas,
que pueden cambiar.

7.  Actividad: De los ejemplos vistos del CHI, ¿qué tipo de
paradigma siguen?
 ¿Qué funciones realizará el producto?
 ¿Cómo se relacionan las funciones entre sí?
 ¿Una después de otra? ¿en paralelo?
 ¿Qué información necesita estar disponible?
 ¿Qué información se requiere para una tarea?

8. Reglas de oro para el diseño
de interfaces de Shneiderman
 1. Consistencia.
 2. Permitir atajos.
 3. Ofrecer retroalimentación.
 ¿Error 404? ¿y eso es?
 4. Indicar cuando una acción se completa.
 Notificar: impresión completa

9. Reglas de oro para el diseño
de interfaces de Shneiderman
 5. Ofrecer prevención de errores y un manejo de errores
simple.
 Que la interfaz prevenga errores.
 Aunque las equivocaciones pueden suceder, el sistema debe
permitir retomar o corregir la situación.
 6. Permitir acciones reversibles.
 7. Que el usuario se sienta en control.
 8. Reducir la carga de memoria.

10. Diagrama de afinidad / Pared
de afinidad
 Organiza notas capturadas durante la sesión de
recopilación de datos.
 Las notas son agrupadas juntas ya sea que se
relacionen entre sí de alguna manera.
 Los grupos no son predefinidos, sino que se forman de
acuerdo a los datos.
 Se pone una nota y luego el equipo busca otras notas
que estén relacionadas d alguna manera.

11. Prototipado

12. Tipos de prototipado según
funciones a considerar
 Prototipado horizontal.
 Enfocado a proporcionar un conjunto amplio de funciones, con
poco detalle.
 Prototipado vertical.
 Proporciona mucho detalle para pocas funciones.

13.  Ej: Prototipo de un modelo conceptual orientado a
proceso.

14. Problemas de los prototipos de alta
fidelidad con respecto a los de baja
 Consumen más tiempo en realizarse.
 Los usuarios que los prueban tienden a comentar
aspectos superficiales.
 Los desarrolladores no quieren cambiar algo que les
tomó horas.
 Un pequeño bug en el prototipo y puede detener la
evaluación.

15. Proceso del prototipado
 Conforme avanza el desarrollo del diseño, la calidad del
prototipo aumenta.
 Se requieren herramientas que reflejen dónde se
encuentra uno en el proceso del diseño.
 Al inicio, no cosas de alta definición que consuman mucho
tiempo.
 Comienzo con storyboards,
 Proporcionan un sentido de las tareas y los escenarios que se
van a soportar.

16.  Luego prototipos de papel.
 Mock-ups digitales.
 (En el dominio Web) HTML estático.
 Partes dinámicas (bases de datos y partes
desarrolladas).

17.  Error común:
Centrarse en la interfaz de usuario antes de centrarse en
las tareas para las que va a servir la interfaz.

18. Storyboard

19. Storyboard
 Se enfoca en las tareas.
 En unos cuantos paneles se presenta para lo que una
interfaz puede ayudar a una persona a lograr.
 Comunican flujo.
 Como en una tira cómica, muestra lo que sucede en
puntos clave.
 No se trata de dibujos bonitos, sino de comunicar ideas.
¡¡¡Deben ilustrar una meta!!!!

20. Partes a mostrar en un
storyboard
 Un escenario.
 Actores involucrados (Persona).
 Ambiente
 Tarea a ser efectuada.

21.  Secuencia.
 ¡Pero no de la interfaz! (no sobre cómo son los botones).
 ¿Qué pasos están involucrados?
 ¿Qué lleva a alguien a usar la interfaz?
 ¿Qué tarea es ilustrada?
 Satisfacción.
 ¿Qué motiva al usuario a usar el sistema?
 ¿Qué permite lograr al usuario?
 ¿Qué necesidad cubre el sistema?

22. Beneficios de usar storyboard
 Enfoque holístico.
 Enfatiza como una interfaz ayuda a cumplir una tarea.
 Evita centrarse a una interfaz particular.
 Aún no especifica botones, capas, etc.
 Ayuda a que todos los stakeholders compartan los
mismos conceptos respecto a la meta.
 Comparten un mismo trasfondo.

23.  No gastar mucho tiempo en storyboards.
¡No se trata de dibujos bonitos!

24.  Actividad: realiza un storyboard para ilustrar cómo llenar
el tanque de gasolina.

25.  Plantilla para storyboard en PowerPoint:
http://blog.elearningart.com/rapid-storyboarding-and-a-free-template/

26. Prototipado en papel

27. Prototipado de papel
 Al tener una breve idea de para lo que la interfaz va a
servir:
 Comenzar a pensar en cómo se va a implementar.
 ¿Qué se le va a presentar al usuario y con qué va a interactuar?
(look and feel).
 ¿Cómo sería la interfaz de usuario?

29.  Bosquejo de la interfaz de usuario, pero no en
computadora.
 En computadora, tomaría tiempo, uno tiende a ser exacto y darle
detalles.
 Herramientas: Papel, post-its, marcadores, pluma, etc.
 Es un bosquejo rápido.

30.  Videos:

31. Consejos al usar prototipos de
papel
 Manejar componentes reutilizables (botones, etc.).
 Si algo es difícil de simular (indicar de progreso, botón
derecho del mouse, hiperenlaces), permite que el
usuario pregunte si está disponible y verbalmente
describirle la interacción.
 Útil usar una maqueta o pegar "las pantallas" sobre un
dispositivo.

32.  Se pueden usar capturas de pantalla, dibujos, todo lo
que ayude a realizarlo rápido.
 Si se manejan capas, se pueden usar transparencias.
 Para ayudar a la persona que pruebe el prototipo,
explicarle la parte conceptual del bosquejo en papel.

33. Ventajas del prototipo en
papel
 Permite probar varios prototipos simultáneos.
 Se puede involucrar distintos stakeholders.
 Identifica si los usuarios se traban, se confunden o consideran
que algo es extraño.
 Identifica sus sugerencias. /en otro papel, que indiquen qué
modificaciones harían.
 Al terminar el prototipado de papel, se puede pasar a un
bosquejo digital.

34. Diseño de menús
 Nombres claros, cortos y no ambiguos.
 Usar agrupaciones lógicas.

35.  Card sorting.
 Resumen:
http://www.interaction-design.org/encyclopedia/card_sorting.html.
 Recursos:
 SynCaps, http://www.syntagm.co.uk/design/cardsortdl.shtml
 xSort http://www.xsortapp.com/ (OSX, gratuito).
 UXSort https://sites.google.com/a/uxsort.com/uxsort/ (Win, gratuito).

36. Wireframing

37.  Jumpchart
 https://www.jumpchart.com/
 Plan gratuito: 2 usuarios, un proyecto y 10 páginas.
 iPlotz
 http://iplotz.com/
 Plan gratuito: 1 proyecto con 5 páginas.
 InVision App
 http://www.invisionapp.com/
 Plan gratuito: 1 proyecto

38.  iPhoneMockup
 http://iphonemockup.lkmc.ch/
 Gratuito. Sólo una pantalla, vía Web.
 framebox
 http://framebox.org/
 Gratuito.
 MockFlow
 http://mockflow.com/
 Plan gratuito: 1 proyecto, 4 páginas.

39.  Pencil Project
 http://pencil.evolus.vn/
 Open-source. Cliente de escritorio. Permite enlazado de páginas.
 Cacoo
 https://cacoo.com
 Plan gratuito, solo exporta a png.
 WireFrame
 https://wireframe.cc/
 Demo 7 días. Gratuito, salva URL.

40.  JustinMind
 http:// www.justinmind.com/
 Gratuito (aunque características especiales de pago).
 PowerPoint.
 PDF dinámico.

41. Falseando la
interacción…

42.  Se requiere recibir retroalimentación lo más pronto
posible.
 Para recibir retroalimentación, se requiere algo que
funcione.
 Pruebas rápidas con usuarios sobre prototipos.

43. Mago de Oz

44. Prototipado Mago de Oz
 Simula el comportamiento de la máquina con
operadores humanos.
 Una aplicación interactiva sin (mucho o nada de) código.
 La parte visible de la interfaz (front-end).
 Un mago (remotamente) controla la interfaz.
 Usado cuando es más rápido, barato, sencillo que hacer la
interfaz real.
 Interfaces de reconocimiento, personalización basada en el usuario.

45. Retroalimentación en Mago de
Oz
 Sobre alta definición:
 Los usuarios piensan que es más real.
 Mechanical Turk.
 Consume mucho tiempo.
 Los usuarios tienden a criticar menos con este tipo de interfaces.
 Sobre baja definición:
 Recomendación para usar el mago de Oz.
 Los usuarios sienten que pueden brindar retroalimentación.

46. Consideración para preparar
un prototipo por Mago de Oz
 Mapea escenarios y el flujo de la aplicación.
 Considerar ¿qué debería suceder en respuesta al
comportamiento del usuario?
 Es más sencillo construir un prototipo-Oz para un conjunto
limitado de funcionalidades.
 Conjuntar "esqueletos" de la interfaz.
 Es lo que el usuario final va a ver.

47.  Identificar dónde y cómo el mago tendrá intervenciones.
 Al seleccionar la siguiente pantalla, al introducir texto, al
reconocer habla, etc.
 Recordar que luego el mago será reemplazado por una
computadora.
 Ensayar el papel del mago con un colega.
 ¿Qué instrucciones se le dirán a la persona?
 Ayuda a identificar fallos antes de llevar la prueba con usuarios
reales.

48. Realizando un prototipo
manejado por Mago de Oz
 Practicarlo primero con compañeros.
 Tras alcanzar confianza, reclutar usuarios.
 Un lugar cómodo para ellos (si es posible).
 Dos roles: facilitador y el mago.
 Facilitador: Proporciona tareas y toma notas.
 Mago: Opera la interfaz.

49.  La retroalimentación puede ser:
 Pensar en voz alta. Hablar libremente mientras se realizan las
tareas.
 Retrospectiva. Para cuando hablar libremente es un distractor.
 Incluso se puede mostrar un video de la sesión y luego preguntarle:
Cuando te trabaste aquí, ¿cuál fue el problema?

50.  Evaluación heurística.
 Categorías de problemas o heurísticas sobre las que se le pide
al usuario que ponga atención.
 Agradecer al usuario (revelar al mago, si es necesario).
 Agradecer a las personas.
 Una muestra de aprecio.

51. Ventajas de usar Mago de Oz
 Se puede usar durante todo el proceso de desarrollo (no
solo al inicio).
 Rápido, barato e iterativo.
 Permite crear múltiples variaciones.
 Se le dan al mago distintas instrucciones (no hay código que
cambiar).

52.  Identifica bugs y problemas con el diseño presentado.
 Pone al usuario en el centro del desarrollo.
 Los diseñadores aprenden al tener que interpretar al
mago.
 Permite visualizar aplicaciones que sean un reto a
construir.

53. Desventajas del Mago de Oz
 La simulación puede suponer mal el uso de alguna
tecnología.
 Puede simular tecnología que no existe o que nunca
existirá.
 Los magos requieren entrenamiento y pueden ser
inconsistentes.

54.  Puede ser cansado ser el mago.
 Algunas características y limitaciones son difíciles o
imposibles de simular correctamente.
 Puede ser inapropiado en algunos lugares (en la casa).

55.  Videos de prototipos de papel:
 10 ejemplos efectivos en video de prototipado en papel.
http://speckyboy.com/2010/06/24/10-effective-video-examples-of-paper-
prototyping/

56. Prototipado en video

57.  Que las distintas decisiones que se hagan se combinen
para dar soporte a las actividades de los usuarios.
 Elementos de la interfaz, funcionalidad, diseño visual.
 Problema: desviarse con detalles de implementación.
 Solución: prototipo en video que muestre lo que sería
usar el sistema.

58. Beneficios de prototipo en
video
 Rápido y barato.
 Sirve como herramienta de comunicación
 Pone un trasfondo común. Muestra el contexto de uso.
 Auto explicativo
 Puede servir como especificación para los
desarrolladores.
 Cualquier interfaz que logre la meta (mostrada) es una buena
interfaz.

59.  Enlaza el diseño de la interfaz con las tareas.
 Orienta y ayuda a dar prioridad sobre las elecciones de una
interfaz.
 Asegura que se tiene una interfaz completa.
 ¿Se tienen todos los elementos que alguien necesitaría para
completar la tarea que tiene que hacer?
 Asegura que no hay extras que no usen las personas para
completar sus metas.

60.  Se puede usar el prototipado en video durante todo el
ciclo del diseño.
 Al comienzo, como una ayuda a la lluvia de ideas.
 Al usar un prototipo en papel y luego ponerlo dentro de
un video.
**Videos

61. ¿Qué se muestra en un video?
 Semejante a un storyboard, se muestra toda la tarea.
 Motivación y éxito en la tarea.
 Se muestran tomas y ayuda narrativa.
 Presenta las tareas relevantes que permite el sistema.
 Permite figurar cuál es el mínimo que el sistema debe permitir.
 Si no está en el video, no es necesario incluirlo en las primeras
vueltas del proceso.

62. Pasos para un prototipado en
video
 Comenzar con un resumen (o con el storyboard).
 Planear las tomas, identificar qué se va a mostrar en el
video y cómo las tareas o actividades mostradas logran
la intención.
 Se vale improvisar.

63.  Equipo a usar:
 Una cámara (de celular, de lap, etc.).
 Participantes (los mismos integrantes del equipo - ayuda a
fortalecer la empatía hacia los usuarios).
 Un lugar realista.
 Enfocarse más en el mensaje que en la filmación.

64. Otras consideraciones
 Se puede usar audio o pantallas con títulos.
 La interfaz puede ser papel, maquetas, código o incluso
ser invisible.
 Puede mostrar tanto el éxito o la falla (de la interfaz a
desarrollar o de otras).
 Editar lo menos posible (editar consume tiempo).

65. Comparando
múltiples alternativas

66.  Al probar múltiples (cantidad) vs. Probar una de
«calidad»

67.  Fijación funcional:

68.  Fijación funcional:

69.  Prototipado serial vs. Prototipado paralelo
Prototipo
Retroalimentación
Prototipo
Retroalimentación
Prototipo
Prototipo Prototipo
Retroalimentación Retroalimentación
Prototipo

71.  ¿Por qué da mejores resultados un
acercamiento paralelo?
 Separación del Ego del artefacto.
 Motiva la comparación.
 Compartición de características.
 Mejor consenso.
 Ayuda al entendimiento entre los
integrantes del equipo.
 Proporcionan vocabulario.