Post on 06-Apr-2017
http://uxtalk.surge.sh/
¿Qué es lo que hace esta UI?
… tenes 3 minutos para averiguarlo
MuleSoft Guest mulesoft123
¡Bienvenidos! Vamos a empezar con un pequeño juego.Tienen 3 minutos para averiguar que hace la interfaz disponible en esta URL.(…)¿Lo averiguaron? ¿Qué hace? Develemos el misterio: http://uxtalk.surge.sh/usable.html
??
Este proceso de descubrimiento -exagerado en el ejercicio- es lo que ocurre cuando uno se enfrenta a una nueva interfaz de usuario.El usuario se enfrenta a una “caja negra”, y debe que guiarse para descubrir que es lo que pasa.
Visibilidad
La “visibilidad" es decir que es lo que el sistema nos comunica visualmente nos da un primer indicio.
Visibilidad
Feedback
El segundo indicio esta en la reacción a una acción. Es decir que pasa al interactuar con el sistema. En el ejemplo que hicimos el botón de “Start" no es inmediato, tarda un poco más de 1segundo. Normalmente un segundo es el limite máximo para percibir el feedback de nuestra acción. Si presiono un botón y no pasa nada en menos de un segundo, entonces me da la impresión que algo no anda bien.
Visibilidad
Feedback
Tolerancia a equivocaciones
Pero con la visibilidad y el feedback no son suficientes. Para aprender a usar el sistema tenemos que poder equivocarnos.Si al tocar un botón puede explotar todo, entonces tenemos que poder arrepentirnos.Estas tres reglas: visibilidad, feedback, y tolerancia a equivocaciones. Son fáciles de recordar y constituyen las bases de la famosas heurísticas de usabilidad.
http://bit.ly/nielsenheuristics
Seguramente escucharon hablar de las heurísticas de usabilidad de Nielsen. Y si no se las presento.Jakob Nielsen uno de los pioneros en usabilidad web, creo una lista de cosas básicas que uno tiene que validar en la usabilidad de un sistema.
Pero al quedarnos solamente con las heurísticas, y ver la UI en términos de implementación. Nos estamos olvidando de lo más importante…
Y esto es que nosotros no somos los usuarios.Es otra persona la que va a usar el sistema.Si es una obviedad, pero una obviedad que es muy fácil de olvidar.Incluso si uno desarrolla herramientas para desarrolladores.Durante el desarrollo adquirimos mucho contexto que nos ayuda a entender la herramienta. Conocemos el lenguaje restringido que usa nuestro grupo. Tenemos una idea de que hacen otras personas en la empresa. Por lo tanto corremos con una ventaja que el usuario final no tiene.
Reconocer que no somos los usuarios. Trabajar en la visibilidad, feedback, y tolerancia a equivocaciones, son las cosas de base que suelo explicar en las capacitaciones internas en MuleSoft….
Después de estas capacitaciones internas, me queda la sensación que la excitación durante el curso, se contrasta con la realidad…
En la realidad del día a día, enfrentamos issues mal especificados, tiempos de entrega cortos…
… tareas lista para QA, con omisiones de usabilidad terribles.
Y uno se pregunta ¿Cómo llego esta funcionalidad hasta este punto? ¿Cómo es que nadie se dio cuenta del problema?
A mouse’s tale - Benjamin Renner
Cambiar ese día a día no es fácil, es como enfrentar un monstruo.
Cómo es posible que empresas como… Apple
Amazon…
Google…Provean experiencias de usuario tan pulidas?¿Es solo una cuestión de recursos?¿O hay algo más? ¿Es una cuestión cultural y organizativa?¿Cómo podemos hacer para proveer una buena experiencia?
Experiencia
Usabilidad
La usabilidad es solo una parte de la experiencia. Una parte importante por cierto, pero cuando vemos estos productos de Apple, Amazon, o Google hay otros factores que forman parte del diseño de la experiencia de usuario.
Para explicar estos factores adicionales, voy a recurrir a Donald Norman.Norman es un psicólogo cognitivo muy conocido por sus estudios sobre el diseño y usabilidad. De hecho si escucharon nombrar las heurísticas de Nielsen, probablemente hayan leído algo sobre Norman (él es socio de la consultora de usabilidad de Nielsen… NormanNielsen)
Visceral
Reflexivo
Conductual
Norman identifica la experiencia de las personas con respecto a un objeto en tres aspectos distintos:
Visceral: es el nivel más primitivo. Es lo que percibimos cuando vemos el producto, nuestra reacción “intuitiva”.Conductual: es como percibimos el producto a través de como interactuamos con él.Reflexivo: es lo que el producto dice sobre nosotros mismos.
Veamos estos aspectos con ejemplos…
Supongamos que un amigo les envía un link a un articulo sobre desarrollo de software.Cuando abren el link ven esta pagina. Horrible! Luce como un sitio de los 90s, es difícil de leer.Ahora otro amigo nos envía otro link…
¿Cuál de estas dos paginas les inspira más calidad de contenido?La primer impresión del sitio nos predispone a la experiencia.La primer pagina que mostré es la Wiki creada por Ward Cunningham, que es el “inventor" de las wikis, y el padre de Extreme Programming, y Test Driven Development. En esa wiki de aspecto horrible solían responder a preguntas un montón de personalidades del desarrollo de software, en especial de quienes terminaron creando muchas de las practicas de diseño que usamos hoy.Esta segunda pagina… bueno no sé quien la escribió realmente, solo tome un ejemplo de Medium, un sitio que se caracteriza por tener un muy buen uso de la tipografía e imágenes para mostrar artículos.La cuestión es… que lo visual importa. Lo primero que vemos genera una reacción visceral que condiciona nuestra respuesta. Si un sistema luce des prolijo, nuestra experiencia se ve afectada.(cuando explique la historia de la primer pagina, recurrí a un aspecto reflexivo: la pagina “fea" tiene un valor histórico extra -ser la primer wiki)
Visibilidad
Feedback
Tolerancia a equivocaciones
En el aspecto conductual, además de las cuestiones que mencione al principio de la charla…
es importante tener en cuenta que la forma en que comunicamos las cosas afecta a como estas se relacionan con el usuario.No hace falta poner una cartel de “tire/empuje" para indicar como abrir una puerta. Mediante la forma, podemos dar información sobre como interactuar con el sistema. Recurriendo nuevamente a Donald Norman, esta relación entre la persona y el objeto es llamada affordance.En los sistemas digitales ocurre lo mismo: el lenguaje visual nos da un indicio de como podemos interactuar con el sistema, sin que tengamos que decir una palabra.La diferencia principal, es que en los sistemas digitales esta información es principalmente visual y cultural. Por ejemplo sabemos que podemos interactuar con un botón por su formato gráfico y la asociación cultural que le damos.
Este lenguaje visual que nos da información, varía con el tiempo.Por ejemplo si somos usuarios de iOS, sabemos al ver esta pantalla que cosas son interactivas y cuales no lo son.Esto no es “natural”, si no que lo aprendimos. Nos acostumbramos a asociar “señales" (signifiers), como estilo y posición con “esto es un componente con el que puedo interactuar”.
Visibilidad
Feedback
Tolerancia a equivocaciones
Consistencia y estándares
Por lo tanto a las cuestiones de comportamiento que ya sabíamos debemos agregar una más:"Consistencia y estándares” Ser consistentes con la plataforma en la que estamos trabajando, ayuda a que el usuario descubra como interactuar con el sistema. Incluso en aplicaciones Web, si uno desea salirse de la norma, hay que hacerlo con cuidado.
Visceral
Conductual
Reflexivo
¿Y el aspecto “Reflexivo”?El aspecto reflexivo es que es lo que el sistema refleja de nuestra imagen, y nuestros valores.Veámoslo con un ejemplo concreto…
A la izquierda tenemos GitHub, a la derecha BitBucket.Ambos sistemas hacen lo mismo: proveen acceso a repositorios de Git, permiten crear pull requests, manejar comentarios, etc.Pero hay una diferencia de personalidad importante entre ambos.Mientras que BitBucket se orienta a un mercado más empresarial, con integración a las herramientas de Attlassian, GitHub se orienta a resaltar las “personalidades" del open source.
Las paginas de perfil, funcionalidad como “Followers”, y “Starts" crean una suerte de reputación en la comunidad. Eso actúa directamente en el aspecto reflexivo de como los usuarios perciben el sistema.Las decisiones sobre el publico al cual apunta un producto están dentro de la esfera de los Product Managers ¿Hay algo que podamos hacer desde el rol de QA al respecto?Si, veamos un ejemplo…
Antes de su lavado de cara, MailChimp se caracterizo por su lenguaje informal y humorístico.Este lenguaje no fue creado adrede, fue planificado.(el diseñador encargado de crear este lenguaje se llama Aaron Walter, y escribió un libro al respecto llamado Design For Emotion)
Internamente en la compañía crearon una guía de como tenia que ser esta personalidad. Por ejemplo es una muy mala idea mantener un tono humorístico cuando hay un error…
Ooops! Perdimos el trabajo que hiciste en los últimos 30min
Sin embargo eso no quita que el sistema no pueda tener un tono humorístico en otras situaciones.Todo depende de la personalidad que le queríamos dar.Si la personalidad del sistema se refleja en nuestros usuarios, entonces tiene un impacto positivo en la experiencia.Desde el rol de QA, podemos usar esta estrategia de definir la personalidad del sistema para motivar una discusión interna sobre la personalidad del producto.
cosas que puedo hacer para:
Generar conciencia sobre alguno de los aspectos de la experiencia: visceral, conductual, reflexivo.
3
(break)Describir 3 cosas que puedo hacer para:Generar conciencia sobre alguno de los 3 aspectos de la experiencia: visceral, comportamiento, reflexivo.
Evaluaciones Expertas
- Evaluaciones Heurísticas
- Recorrido Cognitivo
Evaluaciones Expertas- Evaluación Heurística- Recorrido Cognitiva
File --> New --> API Policy Project
The user enters the project name
(XML/YAML name will be fill by default)
The new project dialog shows a list of examples to
get started
Studio shows a graphical editor for the XML, and a "properties" editor for the
YAML
Phase 1: MVP
Backlog
Right click on project -> Run As --> API Policy
Maybe in Phase 1
Run policy dialog: the user fills additional policy properties & selects an API project to run
Studio start Mule and shows the console log
Idea: We can give the option to
debug the flow from the API
console
Studio shows an improved API Console that makes testing the API easier
The user logs into the API Platform, navigates to the CP screen and uploads the XML/YAML
The user logs into the API Platform, navigates to the CP screen and uploads the XML/YAML
Studio shows a dialog to upload/replace a Custom Policy
Studio shows the XML/YAML text editors
Studio also shows the API Console to test the API with the custom policy
MiroslavMule Solution Provider
VeeraMule Developer
ChristianJava Developer, New to
Mule
Happy
Sad
Happy
Sad
Happy
Sad
Expects from Studio the "extra" tools to deal with
specifics of policies
Expects to have more control over what is deployed to Mule
Expects debugger support. He is able to
deploy and test to a local Gateway, this makes it
easier but doesn't solves the debug issues
He prefers to use Postman. The API
Console is too limited
He was expecting a solution for automated
deployments
First time with Custom Policies, doesn't know if
all the Mule XML tags are available here. Also what
is this YAML file?
Needs to have an API to try the policy. There is an easy/faster way to have
it?What are the configuration
properties?
Possible discoverability issue: There are many
options in the New sub-menu
File --> New --> Mule Project
The New Project dialog shows options to create
from example, or to create an API Policy
This will address the "discoverability" issue.
But I'm not sure how the benefit balances against
other issues (ie differences within the Mule Project types)
What about Maven support?
What is the project structure?
I need to configure this every time? Studio will remember my
configuration? Can I save this configuration into a
file, and use it on an automated process?
Is this cionfiguration file Studio/Eclipse specific?
The run dialog shows the option to save the
configuration properties into a .properties file
The user sets some breakpoints using the
graphical UI
Debug As --> API Policy
I need to configure this every time? Studio will remember my
configuration?I need an example Policy
project to get started
Possible discoverability issue: The Run As right menu is not well known from someone comming
from IntelliJ or .Net
First time running a Mule app. There are many log lines to look at. Doesn't
knows if the API/Policy is running or not
Studio displays feedback indicated if the policy has been
moved to the "failedPolicies" folder
Not too much experience with API Console. Can I use it to test the API and
the policy?
Can I upload the policy to API Platform?
Can I update an existing policy?
Runtime is missing!!
Idea: show a list of selected sample
projects
Checkbox to create a dummy
API!
Add the host port address to the API
Console
Auto-completion & validation
Ejemplo de un recorrido cognitivo, plasmado en documento de “user journey”.
File --> New --> API Policy Project
The user enters the project name
(XML/YAML name will be fill by default)
The new project dialog shows a list of examples to
get started
Studio shows a graphical editor for the XML, and a "properties" editor for the
YAML
Phase 1: MVP
Backlog
Right click on project -> Run As --> API Policy
Maybe in Phase 1
Run policy dialog: the user fills additional policy properties & selects an API project to run
Studio start Mule and shows the console log
Idea: We can give the option to
debug the flow from the API
console
Studio shows an improved API Console that makes testing the API easier
The user logs into the API Platform, navigates to the CP screen and uploads the XML/YAML
The user logs into the API Platform, navigates to the CP screen and uploads the XML/YAML
Studio shows a dialog to upload/replace a Custom Policy
Studio shows the XML/YAML text editors
Studio also shows the API Console to test the API with the custom policy
MiroslavMule Solution Provider
VeeraMule Developer
ChristianJava Developer, New to
Mule
Happy
Sad
Happy
Sad
Happy
Sad
Expects from Studio the "extra" tools to deal with
specifics of policies
Expects to have more control over what is deployed to Mule
Expects debugger support. He is able to
deploy and test to a local Gateway, this makes it
easier but doesn't solves the debug issues
He prefers to use Postman. The API
Console is too limited
He was expecting a solution for automated
deployments
First time with Custom Policies, doesn't know if
all the Mule XML tags are available here. Also what
is this YAML file?
Needs to have an API to try the policy. There is an easy/faster way to have
it?What are the configuration
properties?
Possible discoverability issue: There are many
options in the New sub-menu
File --> New --> Mule Project
The New Project dialog shows options to create
from example, or to create an API Policy
This will address the "discoverability" issue.
But I'm not sure how the benefit balances against
other issues (ie differences within the Mule Project types)
What about Maven support?
What is the project structure?
I need to configure this every time? Studio will remember my
configuration? Can I save this configuration into a
file, and use it on an automated process?
Is this cionfiguration file Studio/Eclipse specific?
The run dialog shows the option to save the
configuration properties into a .properties file
The user sets some breakpoints using the
graphical UI
Debug As --> API Policy
I need to configure this every time? Studio will remember my
configuration?I need an example Policy
project to get started
Possible discoverability issue: The Run As right menu is not well known from someone comming
from IntelliJ or .Net
First time running a Mule app. There are many log lines to look at. Doesn't
knows if the API/Policy is running or not
Studio displays feedback indicated if the policy has been
moved to the "failedPolicies" folder
Not too much experience with API Console. Can I use it to test the API and
the policy?
Can I upload the policy to API Platform?
Can I update an existing policy?
Runtime is missing!!
Idea: show a list of selected sample
projects
Checkbox to create a dummy
API!
Add the host port address to the API
Console
Auto-completion & validation
El uso de “caricaturas" para las personas es intencional.Representan “ad-hoc” personas. La información utilizada para empatizar con la gente, esta basada en entrevistas. Sin embargo la investigación no fue lo suficientemente exhaustiva, y lo por lo tanto esta basada en muchas hipótesis. Y por eso las llamo “ad-hoc personas”.
Crear un "user journey" lleva tiempo. Una forma ágil de hacerlo es utilizar “user story maps”.Esto puede hacerse en conjunto con los miembros del equipo.
Test de usabilidad
Evaluativo Causal
Cualitativo Cuantitativo Task Script
Algo con que interactuar
Moderador
Observador
Contar con un “user journey” es de gran ayuda al momento de diseñar tests de usabilidad.
A mouse’s tale - Benjamin Renner
Resumen:- Reconocer que no somos los usuarios- Generar conciencia:
- Evaluaciones “expertas” (sesiones de critica)- Utilizar escenarios: user story map
- Métricas mediante encuestas, NPS- Tests de usabilidad- Iterar