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

Gracias!!

@diegofer79

diego.fernandez@mulesoft.com