Comentarios de Experiencias de Usuarios

En la exploración de conocimiento en la red sobre este tema me han hecho llegar un curso del MIT, que consta de 14 semanas y varias lecturas al respecto. Por aqui dejo algunas de las frases que han golpeado un poco mi paradigma, unas que apoyan algunas ideas y otras que van en contra de algunas creencias.

1. Una ventana con excelencia artística no tiene nada que ver con una buena experiencia de usuarios
2. Una aplicación que cumpla con las reglas de ser gráfica, manejable con el ratón, sin uso de comandos complicados, con previsualización de lo que se va a crear y con WYSIWYG (What you see is what you get) podría incluso no ser nada usable.
3. Los mensajes de ayuda amplios, extensos y explicativos no son usables, proporcionan una mala experiencia de usuarios y crean confusión (por qué un párrafo tan largo explicativo de una funcionalidad que debe ser simple?)
4. Existen elementos que son vistos, se conoce su uso y están disponibles fácilmente, sin embargo son ignorados. Es el mismo principio de halar una puerta que tiene un cartel grande que dice "EMPUJE", y solamente cuando vemos que no podemos halar la puerta es que vemos que está hecha para ser "empujada".
5. Las páginas que plantean acceso aleatorio están bien para usuarios nuevos, pero si no se agrega una forma de "recordar" o algún acceso directo para usuarios frecuentes o expertos, se convierte rápidamente en una página no usable ya que plantea recorrer todos los items aunque sepas cual estás buscando.
6. La experiencia de usuarios no es algo para dejar en lo ultimo como un paquete de instalación de arte o un patch final, es parte del proceso de desarrollo
7. Como se manejan los submenús en cada sistema operativo puede ser un problema y puede ser la razón para no usar esta opción, o para usarlos de determinadas maneras. Por ejemplo GTK implementa submenús que cambian inmediatamente así que un mínimo movimiento del ratón dentro de otra área de menú y enseguida cambia (hacer un file -> quit debe ser un dolor de cabeza), Windows lo hace con un temporizador de medio segundo mas o menos y mac traza una zona triangular que permite movimientos en diagonal.
8. La experiencia de usuario afecta y a veces define la percepción del sistema, así los sistemas usables se venden más y los no usables se abandonan
9. La percepción es a veces... superficial
10. Los usuarios de negocio normalmente no son los usuarios finales del sistema
11. Los usuarios a veces se culpan por las malas experiencias de usuarios haciendo los reportes de incidencias respecto a esto mucho más difíciles de capturar
    
12. Los usuarios son solo usuarios no podemos forzarlos a ser diseñadores es fácil decir: "Bueno si tienen problemas con la interfaz pues pueden personalizarla y listo!", es errado por dos razones 1.- La mayoría de los usuarios no personalizan sino que usan el por defecto y 2.- la personalización puede hacer que la experiencia de usuarios sea aún peor de lo que ya es. La personalización no puede tratarse como una bala de plata.
13. Dimensiones de usabilidad: Learnability, Efficiency, Memorability, Errors, Satisfaction.
14. Usuarios nuevos necesitan Learnability, usuarios poco frecuentes necesitan Memorability y expertos necesitan Efficiency. Pero no podemos asumir que tendremos un único tipo de usuarios en nuestra aplicación.
15. La experiencia de usuario no existe aislada y puede no ser una de las propiedades más importantes del sistema, sin embargo debe estar en el top de las propiedades requeridas y el sistema puede fallar si no se le toma en cuenta.
16. La buena experiencia de usuarios no se logra a la primera, se debe hacer un grupo de iteraciones en Diseñar/Evaluar/Implementar para poder obtenerla, es algo dinámico

Como dije algunas de estas premisas están en contra de alguno que otro aprendizaje... a medida que conozco más del tema estoy cuestionando incluso el hecho de que la experiencia de usuarios se le puede asociar a solo un rol, en vez de que sea parte del proceso y en donde estemos involucrados todos los roles en diferentes grados.

Debería el Analista de negocio también ser un Experto en alguna temática del negocio

La versión en inglés de esta pregunta forma parte de uno de los más populares debates del grupo IIBA en LinkedIn y los muchos comentarios al respecto dicen que si debería ser así, más todos exponen una razón distinta.
En lo personal el analista de negocios debe hablar varios lenguajes que requieren distintos niveles de abstracción respecto al tema, es decir, si el negocio es bancario el analista debe hablar en terminos bancarios al nivel del cliente que es un nivel de abstracción alto, mientras que debe hablar con el equipo de desarrollo en términos de herramientas bancarias y en términos técnicos que son un nivel de abstracción bajo, con una granularidad fina para transmitir más eficientemente el mensaje.
Estas combinaciones de niveles de abstracción van a desencadenar que el analista de negocios se convierta o que deseablemente sea experto en banca, o por lo menos sea un muy conocedor al respecto.
No solamente se refiere a lo que el cliente conoce y maneja, sino también respecto al mercado, las tendencias, las actualizaciones, innovaciones y avances sobre el tema del negocio para poder proponer soluciones coherentes a los problemas planteados por el cliente.
Por esto es que en mi opinión no es un nice-to-have ni una opción sino que es una necesidad el hecho de que el analista sea un experto en el tema del negocio.