Presentación realizada dentro del marco del diplomado de Diseño de Interacción y Physical Computing 2013 de la UDD.
Contempla una revisión general de conceptos, una mirada a las metodologías Waterfall y Agile, una revisión de los principales entregables del UCD, una compilación de Principios de interacción y una introducción a las etapas de prototipado y testing
The Spotify model is a people-driven, autonomous approach for scaling agile that emphasizes the importance of culture and network. It has helped Spotify and other organizations increase innovation and productivity by focusing on autonomy, communication, accountability, and quality.
============== Follow us ==============
Website: http://xpdays.org
Linked In: https://www.linkedin.com/company/xpdays
Facebook: https://www.facebook.com/xpdaysorg
Twitter: https://twitter.com/xpdaysorg
#agile #spotify #xpdays #agilearena
Gestión de Stakeholders: Plan de gestión de las comunicaciones ASESORIAACADEMP
Estrategias de un líder para gestionar proyectos ¿Cómo afectan los interesados la ejecución de un proyecto? ¿Cómo gestionar los recursos para el éxito de un proyecto? El éxito en las comunicaciones de un proyecto ¿Como salir de un cuello de botella para lograr el éxito en un proyecto?.
The Spotify model is a people-driven, autonomous approach for scaling agile that emphasizes the importance of culture and network. It has helped Spotify and other organizations increase innovation and productivity by focusing on autonomy, communication, accountability, and quality.
============== Follow us ==============
Website: http://xpdays.org
Linked In: https://www.linkedin.com/company/xpdays
Facebook: https://www.facebook.com/xpdaysorg
Twitter: https://twitter.com/xpdaysorg
#agile #spotify #xpdays #agilearena
Gestión de Stakeholders: Plan de gestión de las comunicaciones ASESORIAACADEMP
Estrategias de un líder para gestionar proyectos ¿Cómo afectan los interesados la ejecución de un proyecto? ¿Cómo gestionar los recursos para el éxito de un proyecto? El éxito en las comunicaciones de un proyecto ¿Como salir de un cuello de botella para lograr el éxito en un proyecto?.
Lean UX: Getting out of the deliverables businessJeff Gothelf
This is an expanded presentation detailing how to focus on leaner user experience design methods and reducing the amount of deliverables in your work. It advocates focusing on the actual experience being created and not the deliverable itself as the end state of a project by reducing waste and choosing the right tool at the right time at the right depth. See also bit.ly/LeanUX
Jonathan Rasmusson, en su libro Agile Samurai, propone una forma empática e integrada de poder iniciar un proyecto de forma óptima. Esto es muy importante para trazar el mapa de ruta de hacia donde se dirigirá el proyecto, dependencias, riesgos, equipo de trabajo, y otros temas.
En esta presentación explico la esencia de este Agile Inception Deck.
Monoliths, Migrations, and MicroservicesRandy Shoup
This talk describes several common challenges of software systems at scale:
* How to break up a monolithic application or a monolithic database into microservices.
* How to approach shared data, joins, and transactions in a microservices ecosystem
Introduction to Agile Estimation & PlanningAmaad Qureshi
Presented by Natasha Hill & Amaad Qureshi
In this session, we will be covering the techniques of estimating Epics, Features and User Stories on an Agile project and then of creating iteration and release plans from these artefacts.
Agenda
1. Why traditional estimation approaches fail
2. What makes a good Agile Estimating and Planning approach.
3. Story points vs. Ideal Days
4. Estimating product backlog items with Planning Poker
5. Iteration planning - looking ahead and estimating no more than a few week ahead.
6. Release planning - creating a longer term plan, typically looking ahead, 3-6 months
7. Q&A
Lean Inception: how to align people and build the right productPaulo Caroli
Lean inception is the effective combination of Design Thinking and Lean StartUp to decide the Minimum Viable Product (MVP). It is a collaborative workshop that will help a group of people — typically an agile team, a squad, or a product team -- understand, align and plan the building of the lean product.
Learn to use the user story backlog as a way to describe user’s experience with your product.
Section 1: Importance of Product Owners Roll.
Identifying Scrum’s Product Owners roll.
Diagrammatic representation of PO Activities.
Diagrammatic representation of Product Feature Development tracks.
Section 2: User stories & Product Backlog Management.
Agile User Stories overview .
Acceptance Criteria.
Backlog Management.
Section 3: Project Scope, Product Backlog and Story Mapping.
User Story Mapping Steps.
Story Mapping example with valuable releases.
Benefits of User Story Mapping.
10,000 microservices are generated each month using JHipster!
During this in-depth session by the two JHipster lead developers, we’ll detail:
How to develop and deploy microservices easily
Scalability and failover of microservices
The JHipster Registry for scaling, configuring and monitoring microservices
Common architecture patterns and pitfalls
The first step in creating a useful plan is the ability to estimate reliably. In this session we will discuss how to do this. We will look at various approaches to estimating including unit-less points and ideal time. The class will present four specific techniques for deriving reliable estimates, including how to use the popular Planning Poker® technique and other techniques that dramatically improve a project's chances of on-time completion.
Lean UX: Getting out of the deliverables businessJeff Gothelf
This is an expanded presentation detailing how to focus on leaner user experience design methods and reducing the amount of deliverables in your work. It advocates focusing on the actual experience being created and not the deliverable itself as the end state of a project by reducing waste and choosing the right tool at the right time at the right depth. See also bit.ly/LeanUX
Jonathan Rasmusson, en su libro Agile Samurai, propone una forma empática e integrada de poder iniciar un proyecto de forma óptima. Esto es muy importante para trazar el mapa de ruta de hacia donde se dirigirá el proyecto, dependencias, riesgos, equipo de trabajo, y otros temas.
En esta presentación explico la esencia de este Agile Inception Deck.
Monoliths, Migrations, and MicroservicesRandy Shoup
This talk describes several common challenges of software systems at scale:
* How to break up a monolithic application or a monolithic database into microservices.
* How to approach shared data, joins, and transactions in a microservices ecosystem
Introduction to Agile Estimation & PlanningAmaad Qureshi
Presented by Natasha Hill & Amaad Qureshi
In this session, we will be covering the techniques of estimating Epics, Features and User Stories on an Agile project and then of creating iteration and release plans from these artefacts.
Agenda
1. Why traditional estimation approaches fail
2. What makes a good Agile Estimating and Planning approach.
3. Story points vs. Ideal Days
4. Estimating product backlog items with Planning Poker
5. Iteration planning - looking ahead and estimating no more than a few week ahead.
6. Release planning - creating a longer term plan, typically looking ahead, 3-6 months
7. Q&A
Lean Inception: how to align people and build the right productPaulo Caroli
Lean inception is the effective combination of Design Thinking and Lean StartUp to decide the Minimum Viable Product (MVP). It is a collaborative workshop that will help a group of people — typically an agile team, a squad, or a product team -- understand, align and plan the building of the lean product.
Learn to use the user story backlog as a way to describe user’s experience with your product.
Section 1: Importance of Product Owners Roll.
Identifying Scrum’s Product Owners roll.
Diagrammatic representation of PO Activities.
Diagrammatic representation of Product Feature Development tracks.
Section 2: User stories & Product Backlog Management.
Agile User Stories overview .
Acceptance Criteria.
Backlog Management.
Section 3: Project Scope, Product Backlog and Story Mapping.
User Story Mapping Steps.
Story Mapping example with valuable releases.
Benefits of User Story Mapping.
10,000 microservices are generated each month using JHipster!
During this in-depth session by the two JHipster lead developers, we’ll detail:
How to develop and deploy microservices easily
Scalability and failover of microservices
The JHipster Registry for scaling, configuring and monitoring microservices
Common architecture patterns and pitfalls
The first step in creating a useful plan is the ability to estimate reliably. In this session we will discuss how to do this. We will look at various approaches to estimating including unit-less points and ideal time. The class will present four specific techniques for deriving reliable estimates, including how to use the popular Planning Poker® technique and other techniques that dramatically improve a project's chances of on-time completion.
La interacción desde la relación que establecemos con las interfaces y pantallas de los múltiples dispositivos que nos rodean
Presentación de la charla efectuada el 26 de noviembre de 2014 para el seminario de diseño de interacción de la Universidad del Desarrollo
Una revisión de los conceptos y ejemplos de temáticas como la convergencia cultural, las múltiples pantallas, el storytelling transmedial y el gamification.
Presentación para el diplomado de Producción de Cine y Televisión de la Universidad del Desarrollo
Presentación de la clase de introducción al Gamification para la línea de comunicación digital del Magíster en Comunicación Integral de la Universidad del Desarrollo (UDD)
Presentación realizada dentro del marco del congreso ISA15 (Interaction SouthAmerica) realizado en la Ciudad de Córdoba Argentina.
Trata sobre algunas recomendaciones para realizar testeos rápidos de bajo costo (guerrilla) especialmente enfocado en Startups que no acostumbran a realizar validaciones con usuarios.
Se propone también una matriz de testeo sistemático que otorga algunas propuestas de testeo en distintas etapas del proceso de prototipado.
Effective communication is everyone’s job—whether you are trying to sell in a concept or convince a client. Visual Thinking can help us take in complex information and synthesize it into something meaningful. In an increasingly fragmented and cluttered world, simple imagery, metaphors and mindmaps can get people to understand the abstract and make your ideas tangible. Find out why why thinking visually may be one of the most sought after abilities of the 21st century.
Presentación introductoria a la metodología de diseño centrado en el usuario para el diseño de aplicaciones móviles. Curso a cargo del profesor Juan Paulo Madriaza - Uniacc - 2011
Presentación de la primera jornada del Workshop Digital donde se abaracaron las temáticas del diseño centrado en el usuario y sus metodologías, experiencia de usuario, y diseño responsive.
El Ux es una disciplina dentro del marketing Digital que se encarga de ayudarnos en la clasificación, priorización y organización de contenidos y activos digitales basados en el conocimiento e interpretación de uso por parte de nuestros clientes o publico objetivo. Tambien dependiendo de: Estrategia del Negocio, Diseño, Tecnología y contenidos. Es relevante conocer sus must y sus guidelines para usarlos a favor en la construcción de este tipo de activos para organizaciones.
UX Nights Culiacán Vol. V Prototipando Experiencias de Usuario
21 de Junio de 2016, Culiacán, Sinaloa
Prototipando Experiencias de Usuario
Carlos Duarte
Mobile design 02 Recomendaciones para el diseño de aplicaciones móvilesJuan Paulo Madriaza
Presentación introductoria de recomendaciones y buenas prácticas a tener en cuenta en el diseño de aplicaciones móviles. Curso a cargo del profesor Juan Paulo Madriaza - Uniacc - 2011
Presentación sobre cómo las estrategias de socialmedia pueden contribuir a la comunicación de las pequeñas y medianas empresas.
Esta presentación fue usada como parte de la presentación realizada por el autor en el encuentro ancional de escuelas de diseño realizado en Temuco durante el mes de octubre del 2010
Esta charla tiene como origen un paper de investigacion realizado por el autor para su magister en comunicación de la Universidad del Desarrollo
IMÁGENES SUBLIMINALES EN LAS PUBLICACIONES DE LOS TESTIGOS DE JEHOVÁClaude LaCombe
Recuerdo perfectamente la primera vez que oí hablar de las imágenes subliminales de los Testigos de Jehová. Fue en los primeros años del foro de religión “Yahoo respuestas” (que, por cierto, desapareció definitivamente el 30 de junio de 2021). El tema del debate era el “arte religioso”. Todos compartíamos nuestros puntos de vista sobre cuadros como “La Mona Lisa” o el arte apocalíptico de los adventistas, cuando repentinamente uno de los participantes dijo que en las publicaciones de los Testigos de Jehová se ocultaban imágenes subliminales demoniacas.
Lo que pasó después se halla plasmado en la presente obra.
Documento sobre las diferentes fuentes que han servido para transmitir la cultura griega, y que supone la primera parte del tema 4 de "Descubriendo nuestras raíces clásicas", optativa de bachillerato en la Comunitat Valenciana.
Ponencia en I SEMINARIO SOBRE LA APLICABILIDAD DE LA INTELIGENCIA ARTIFICIAL EN LA EDUCACIÓN SUPERIOR UNIVERSITARIA. 3 de junio de 2024. Facultad de Estudios Sociales y Trabajo, Universidad de Málaga.
4. Objetivos de este módulo
• Resumen de la primera etapa
• Teórica, pero enfocada en el hacer
• Entregar metodologías aplicables ahora
• Llevar ideas hacia el primer prototipo
• Diseñar centrado en el usuario
• Diferenciar approaches metodológicos
• Identificar principios fundamentales en el hacer
interacción
• Explorar las formas de testear prototipos
25. UCD Waterfall v/s Agile
Waterfall Agile
Más lineal Más iterativo
Más documentación Más prototipos funcionales
Más reflexivo Más impulsivo
Raíces en la administración Raíces en el desarrollo
Feedback en etapas determinadas Feedback constante
Va por el producto final Va por una mejora progresiva
Resistente al cambio Abierto al cambio constante
Se avanza sobre seguro Se avanza sobre la incertidumbre
Se negocia con el cliente Se colabora con el cliente
Funciona como el cliente Funciona como los desarrolladores
Intervalos según entregable Intervalos temporales definidos
Investigación profunda Escasa investigación
Ideal para proyectos con clientes Ideal para proyectos personales
Basado en la visión Basado en la improvisación y mejora progresiva
Mas de conocimiento Mas de experimentación
Métodos
27. Design the box
¿Qué es?
Es una caja que simula que tu idea
viene adentro (aunque nunca venga
dentro de una caja)
¿Para qué sirve?
Para aterrizar ideas, para llegar a
acuerdos en el equipo, para
dimensionar el proyecto, para
definir áreas de investigación
¿Cuándo realizarlo?
Al principio del proyecto
Contenidos:
• Nombre de la idea
• Gráfica (concepto)
• Un tagline
• 3 o 4 “promesas” destacadas en una
lista (portada)
• Una descripción detallada (atrás)
• Requerimientos técnicos
Entregables
28. Content Strategy
Canvas
¿Qué es?
Es un board que se llena según
los recuadros descritos
¿Para qué sirve?
Para sistematizar los
antecedentes y definiciones
preliminares de diseño
¿Cuándo realizarlo?
Al principio del proyecto
Contenido:
• Gancho de la idea
• Forma
• Acción esperada
• Métricas
• Canales
• Detonador de uso
• Persona (usuario)
• Recursos involucrados
• Resultados esperados
Entregables
29. Personas
¿Qué es?
Es una ficha con descriptores de
los usuarios arquetípicos de mi
idea
¿Para qué sirve?
Para entender a los usuarios, sus
intereses, motivaciones,
contextos de uso,
preocupaciones, etc.
¿Cuándo realizarlo?
Al principio del proyecto
¿Cómo se hace?
• Se definen arquetipos de usuarios
• Se hacen entrevistas con los
involucrados
• Se crean fichas por cada usuario
mencionando sus características como
si estuviéramos definiendo a una
persona real
Entregables
30. Storyboarding
¿Qué es?
Es una historia dibujada de
formas de uso de la idea
¿Para qué sirve?
Para focalizarse en lo central de la
idea, para revisar la lógica de la
idea, para comunicar el concepto
de manera fácil
¿Cuándo realizarlo?
Cuando se tienen las primeras
ideas, usuarios y contextos de
uso
¿Cómo se hace?
• Se definen las tareas y usuarios a
dibujar
• Se establece el guión
• Se dibuja la historia
• Se evalúa su resultado
Entregables
31. Benchmarks
¿Qué es?
Es una sistematización de las
mejores ideas de otros proyectos
existentes
¿Para qué sirve?
Para no inventar la rueda, para no
cometer los mismos errores de
otros, para diferenciarme de mi
competencia
¿Cuándo realizarlo?
Al momento de empezar un
proyecto que ya está relativamente
definido en su contexto
¿Cómo se hace?
• Se definen los referentes a analizar
• Se analizan rescatando lo bueno y lo malo
• Se establecen conclusiones haciendo énfasis
en las ideas que me sirven
Entregables
32. Capacidades del
sistema
¿Qué es?
Es un listado detallado de todas
las posibles funcionalidades que
puede tener nuestra idea
¿Para qué sirve?
Para definir y jerarquizar las
funcionalidades de nuestro
proyecto
¿Cuándo realizarlo?
Al momento de tener la idea
clara, los usuarios estudiados y
los referentes analizados
¿Cómo se hace?
• Se crea una tabla con todas las posibles
funcionalidades del sistema
• Se asignan niveles de importancia y
complejidad a cada funcionalidad
• Se definen las funcionalidades que van
finalmente en la solución
Entregables
33. Card Sorting
¿Qué es?
Es una dinámica de organización
de contenidos
¿Para qué sirve?
Para obtener información
respecto de cuál es la manera
más lógica de agrupar contenido
¿Cuándo realizarlo?
Al momento de tener los
contenidos delineados y/o
definidos
¿Cómo se hace?
• Se invita a varios grupos de usuarios a
una sesión de trabajo
• Se le entregan postits (definidos o en
blanco) con los contenidos del proyecto
• Se les pide que organicen los postits en
secciones (ya definidas o por crearse)
• Se realiza un reporte de los resultados
Entregables
34. Site Maps
¿Qué es?
Es un diagrama de ordenamiento
de secciones y sus contenidos
¿Para qué sirve?
Para visualizar las distintas
pantallas de la solución y sus
relaciones
¿Cuándo realizarlo?
Al momento de tener definidos
los contenidos
¿Cómo se hace?
• Se recopilan los contenidos que deben
formar parte del proyecto
• Se establecen cuáles serán las páginas
que formarán parte del proyecto
• Se establecen secciones donde se
encontrará cada página
• Se definen relaciones jerárquicas entre
cada pantalla
• Se crea un diagrama que lo especifique
Entregables
35. Task Flows
¿Qué es?
Es un diagrama de ordenamiento
de procesos y tareas
¿Para qué sirve?
Para visualizar la manera en que
las distintas tareas son realizadas
(paso a paso) y encontrar posibles
errores de lógica
¿Cuándo realizarlo?
Al momento de tener definidas
las capacidades del sistema
¿Cómo se hace?
• Se definen las tareas a visualizar
• Se establecen los pasos necesarios para
realizar una tarea
• Se buscan los puntos de bifurcación y se
establecen rutas alternativas
• Se crea un diagrama que explica las
distintas posibilidades de interacción
http://www.jjg.net/ia/visvocab/spanish.html
Entregables
36. Ideal Task Flows
¿Qué es?
Es un diagrama que muestra la
interacción ideal de un usuario
con el proyecto
¿Para qué sirve?
Para que al momento de diseñar
el proyecto podamos priorizar
evidentemente el flujo ideal
¿Cuándo realizarlo?
Al momento de tener definidas
las capacidades del sistema
¿Cómo se hace?
• Se definen las tareas más relevantes
• Se determina la ruta o los pasos ideales
con los que un usuario debería
relacionarse con el sistema
• Se determinan los puntos clave
• Se visualizan en una serie de diagramas
simples
Entregables
37. Sketching
¿Qué es?
Es un proceso de bocetaje de las
principales ideas del proyecto (no
sólo pantallas)
¿Para qué sirve?
Para sistematizar y visualizar las
ideas y sus posibles soluciones
¿Cuándo realizarlo?
Al momento de tener definidas
las capacidades del sistema
(*mapa de navegación)
¿Cómo se hace?
• Se definen las ideas a bocetear
• Se establecen las variables que
conforman cada idea
• Se realizan múltiples iteraciones hasta
encontrar las mejores soluciones
• Se realizan anotaciones que permitan
argumentar, detallar o invalidar una
idea
Entregables
38. Wireframes
¿Qué es?
Es una serie de imágenes que
muestran el layout, sin gráfica, de
las principales pantallas
¿Para qué sirve?
Para especificar el diseño de layout
de cada página y comprobar su
funcionalidad (usabilidad)
¿Cuándo realizarlo?
Al momento de concluir conforme el
proceso de sketching
¿Cómo se hace?
• Se determinan las pantallas que forman
parte de la médula del proyecto (plantillas a
prototipar)
• Se crean las pantallas utilizando un software
de wireframing (Axure, Omnigraffle)
• Se validan los resultados con usuarios
• Se realizan iteraciones hasta estar
convencido de la solución
Entregables
39. Wireflows
¿Qué es?
Es una serie de wireframes
posicionados en una única gran
pizarra
¿Para qué sirve?
Para ejemplificar las relaciones entre
una pantalla y la otra con tal de
validar la lógica de estas en su
contexto
¿Cuándo realizarlo?
Paralelamente al proceso de
wireframing
¿Cómo se hace?
• Se posicionan los wireframes sobre una
superficie que permita de un vistazo ver el
«big picture»
• Se trazan conectores entre las pantallas que
están relacionadas
• Se realizan comentarios escritos sobre la
pizarra para que faciliten el entendimiento
del documento
Entregables
40. Prototipado
interactivo
¿Qué es?
Es una serie de wireframes o
sketches que están vinculados entre
si (eventualmente tienen
funcionalidades básicas también)
¿Para qué sirve?
Para testear con usuarios
determinados flujos de tareas
¿Cuándo realizarlo?
Cuando se tienen listos los
wireframes o sketches asociados a
un flujo de tarea
¿Cómo se hace?
• Se determina la tarea a testear
• Se realizan los wireframes o sketches que
forman parte de la tarea
• Se les agrega funcionalidad
• Se ejecuta el proceso de testeo
• Se realizan cambios según los resultados
obtenidos
POP app
Entregables
41. Diseño visual
¿Qué es?
Es una serie de imágenes que
representan el diseño final de la
propuesta
¿Para qué sirve?
Para evaluar su diseño, como
insumo final para el desarrollo
¿Cuándo realizarlo?
Cuando se tienen definidos los
wireframes de las plantillas
¿Cómo se hace?
• Se determinan las pantallas a diseñar
• Se le agregan a los wireframes decisiones de
color, tipografía, imagen, textura, etc.
• Se evalúa su funcionamiento (interactive
prototype)
• Se realizan mejoras según los resultados
Entregables
42. …Y luego qué?
Mejoras constantes
Ciclos de iteración
Supervisión colaborativa de desarrollo
Control de calidad
Prototipos funcionales
User testings
Evaluación de KPIs
etc…
Entregables
48. Interaction
Principles
Protege el trabajo del
usuario
Asegúrate de que el usuario
nunca pierda su trabajo como
resultado de un error suyo, los
problemas de internet u otro tipo
de problemas inevitables, como
un apagón.
50. Interaction
Principles
Consistencia
Frente al mismo estímulo, la
misma decisión.
Es tan importante ser
visualmente inconsistente con los
objetos que se comportan de
forma distinta, como ser
consistente con los que se
comportan de igual manera.
Evita la uniformidad. Haz que los
objetos que se comportan
distinto parezcan distintos.
La consistencia más
importante es aquella que
espera el usuario. La única
manera de comprobar las
expectativas del usuario es hacer
pruebas con ellos.
51. Interaction
Principles
Carga cognitiva
El usuario no debe ser obligado a
retener información crítica para el
funcionamiento del sistema.
Deja que el sistema haga todo el
trabajo que le sea posible con tal
de que el usuario se enfoque en
las tareas en las que su
participación es crítica.
52. Interaction
Principles
Functional Minimalism
Todo debe ser tan simple como
sea posible, pero no más simple
que eso.
Evita funcionalidades superfluas.
Separa tareas complejas en
minitareas.
Limita las funcionalidades en pro
de la experiencia.
53. Interaction
Principles
Engagement (Flow)
El engagement aumenta cuando
un usuario siente que la tarea
que ejecuta es lo suficientemente
demandante como para que sea
entretenida, y no es tan difícil
como para que llegue a ser
frustrante.
FLOW- Mihaly Csikszentmihalyi
54. Interaction
Principles
Functional Layering
Según la ley de Pareto (80 -20) el
20% de las funcionalidades son
usadas el 80% de las veces.
Debemos hacer que las
funcionalidades más recurrentes
sean más fáciles de encontrar.
Debemos entregar herramientas
a los usuarios más
experimentados para que
ejecuten las tareas de manera
más rápida (aunque sea un tanto
menos lógica).
55. Interaction
Principles
Control, confianza y
explorabilidad
Si el usuario se siente en control
de lo que sucede en la interacción
eventualmente presentará
confianza en el funcionamiento
de esta por lo que se sentirá en
condiciones de explorarla de
manera más abierta.
56. Interaction
Principles
Prevención, detección y
recuperación de errores
Prevenir errores:
• Deshabilita funciones que no son
útiles
• Usa los patrones de interacción
correctos para permitir el ingreso
de data por parte del usuario
• Entrega instrucciones claras y
precisas
Detectar errores:
• Entrega feedback al usuario en el
caso que se presuma que pueda
estar cometiendo un error
Recuperación de errores
• Si el error ya fue cometido siempre
dale al usuario maneras de
deshacerlo
• Si una acción es crítica y no puede
ser deshecha indícalo antes de su
ejecución
59. Interaction
Principles
Feedback
Comunica el clic de los botones
mediante un feedback visual en
los primeros 50 milisegundos.
Muestra un indicador animado
para cualquier acción que dure
entre 1/2 y 2 segundos.
Si dura más de 2 seg. comunica el
tamaño y el progreso con un
barra de estado.
Indica con pitidos e indicaciones
visuales muy claras cuando el
usuario puede volver al trabajo
con el sistema.
60. Interaction
Principles
Visibility
Los controladores debes ser
fáciles de ubicar y usar.
Debe ser obvio y evidente el
resultado de la operación de un
controlador.
Un sistema con buena visibilidad
permite al usuario transformar
fácilmente objetivos en acciones.
64. ¿Y qué es el
prototipado?
¿Y un prototipo?
Prototipado
65. Prototipo
Modelo experimental construido mediante
múltiples iteraciones rápidas con usuarios.
Contar con prototipos físicos durante el
proceso de diseño permite un alineamiento
mayor y un diseño más eficiente.
Prototipado
70. Formas de clasificación
Baja / Media / Alta fidelidad
Baja fidelidad Media fidelidad Alta fidelidad
Muy precario, con sólo algunas
decisiones medulares tomadas,
sin interacciones
Con decisiones mas elaboradas,
pero aún incompleto. Con
interacciones simuladas
Con la totalidad de las decisiones
tomadas, cercano a ser
transformado en el producto. Con
interacciones reales
Sketches, paper prototypes Interactive Wireframes Interactive visual design,
Interactive prototypes
http://www.medien.ifi.lmu.de/lehre/ws0708/mmi1/e4.pdf
Prototipado
71. Formas de clasificación
Según etapa productiva
Basic Advanced Manufacturing Virtual
Construido con objetos
caseros
Sin preocupación por la
estética
Debe servir para probar
su factibilidad
Mejor construido (con la
ayuda de profesionales)
Se ve y funciona como el
producto
Es la versión master del
producto, desde la cual
se ejecuta la fabricación
en masa
Es una representación
digital del producto con
el detalle suficiente para
ser construído
http://www.edisonnation.com/forums/prototyping/topics/the-different-types-of-prototyping
Prototipado
72. Formas de clasificación
Según etapa de diseño
Sketches /
Storyboards
Paper
prototyping
Horizontal Vertical Wizard of OZ
Historias de uso y
dibujos de las
principales
interacciones
Sketches que
pueden ser
probados por
usuarios
(recorridos
testeables)
Se ve el global de
la idea, aún no
están disponibles
la funcionalidades
en detalle
Se presenta una
funcionalidad
completa para
testear (no está
disponible todo,
solo la
funcionalidad a
testear)
Las partes
complejas del
sistema están
simuladas
(mediante un
humano
entregando
respuestas, no un
sistema)
http://www.medien.ifi.lmu.de/lehre/ws0708/mmi1/e4.pdf
Prototipado
73. Formas de clasificación
Según su uso
Shared
communication
Working
Through a
Design
Selling Your Idea
Internally
Usability Testing Gauging
Technical
Feasibility and
Value
Lo suficiente para
que el equipo
pueda conversar y
evolucionar sobre
sus ideas.
Reemplaza la
conversación
Para trabajar sobre
la misma idea,
para pensar y
depurar
Para vender la idea
a los que no están
trabajando en el
proyecto
Para probar
nuestra idea con
usuarios
Para evaluar su
factibilidad técnica
y los costos de
producción final
Rosenfeld- Prototyping
Prototipado
84. El primer prototipo va a ser malo
Trata de terminar tu primer prototipo en un día
Vas a cambiar el problema
No te encariñes con tu prototipo
Prototipado
Otros
85. ¿Cómo son los buenos
prototipos?
Digo, como pa´saber
Prototipado
98. ¿Y qué es el Testing?
Es probar con usuarios, pero…
¿Para qué sirve?
Testing
99. Testing
• Para sacarnos el balde de la cabeza
• Para definir cambios cuando aún se puede
• Para darnos cuenta de lo que sobra
• Para detectar jerarquías erróneas
• Para obtener retroalimentación
• Para obtener motivación
• Para mejorar
Utilidades
102. Visibilidad del estado
del sistema
El sistema debe informar a los usuarios del
estado del sistema, dando una
retroalimentación apropiada en un tiempo
razonable
Heurísticas
01
103. Utilizar el lenguaje de
los usuarios
El sistema debe utilizar el lenguaje de los
usuarios, con palabras o frases que le sean
conocidas, en lugar de los términos que se
utilizan en el sistema.
Heurísticas
02
104. Control y libertad para el
usuario
El sistema no debe hacer sentir al usuario
que actúa sin su consentimiento.
Heurísticas
03
106. Prevención de errores
Mejor que un sistema con buenos
mensajes de error, es uno donde los
usuarios raramente cometen uno.
Heurísticas
05
107. Minimizar la carga
cognitiva
El usuario no debería tener que recordar
algo para poder continuar, ese algo debería
estar accesible fácilmente.
Heurísticas
06
108. Flexibilidad y eficiencia
de uso
El sistema debería proveer aceleradores
para los usuarios más experimentados.
Heurísticas
07
109. Diseño estético
y minimalista
Cada contenido o elemento innecesario
compite por la atención del usuario y
disminuye el potencial de entendimiento.
Heurísticas
08
110. Ayudar a los usuarios a
reconocer, diagnosticar y
recuperarse de los errores
Los errores deben ser expresados en lenguaje
cotidiano (sin códigos), indicar precisamente el
problema y proponer una solución.
Heurísticas
09
111. Ayuda y documentación
Si bien es mejor que la ayuda no sea
necesaria, en caso de necesitarla debe ser
accesible, contextual y precisa.
Heurísticas
10
112. ¿Cómo se hace bien?
10 Recomendaciones
User -Testing
User Testing
118. Si se puede, testea con
usuarios reales
Si no se puede, con cualquiera que no esté
en el equipo de diseño.
06
User -Testing
119. Testea y re-testea para
comparar
Hazlo con usuarios diferentes.
07
User -Testing
120. No puedes ayudar al tester
Nada de frío-frío, caliente-caliente.
08
User -Testing
121. La culpa NUNCA es
del tester
Evita que sienta que está rindiendo
examen.
09
User -Testing
122. Entrevista al final para
complementar
Puedes hacer un cuestionario para
complementar tus hallazgos.
10
User -Testing
123. ¿Qué estás pensando?
Describe los pasos que te han llevado hasta acá
¿Qué piensas que ocurrirá ahora?
¿Es esto lo que esperabas que pasara?
¿Eso fue confuso?
¿Te importaría repetir eso?
?
User -Testing
128. Más información
Prototyping
Todd Zaki Warfel
Measuring The User
Experience
Thomas Tullis
William Albert
UX Book
Rex Hartson, Pardha Pyla
http://www.uxd.cl/