R.

Recordatorios

Hay gente que tiene la habilidad de no hacerte sentir parte de un equipo cuando lo que tienes que decir no les agrada. Muchas veces decir que algo está mal hecho, mal ejecutado o no funciona forma parte de nuestra responsabilidad si es que estamos convencidos de ello. Muchas veces no queda más remedio que decirlo buscando la mejor de las maneras: valorar el trabajo, explicar los razonamientos y hablar con educación (¡británica a ser posible!). Muchas otras veces, cuando no quieren escucharte el único recurso que queda es compartir los riesgos a los que queda expuesta una solución y seguir adelante. Pero siempre siempre se debe ser honesto con lo que único cree, de otra manera, las reuniones de equipo se convertirían siempre en meras luchas de poder de las que además no sacaríamos nada positivo. Y eso es lo que he aprendido hoy, una vez más. 

K.

Kim Goodwin – Using Scenarios to Design Intuitive Experiences

Kim Goodwin – Using Scenarios to Design Intuitive Experiences

¿.

¿Qué hay detrás de tu estrategia de experiencia de usuario?

image

Hoy me gustaría compartir qué tipo de información trato de comunicar cuando escribo la Estrategia de Experiencia de Usuario (UX Strategy) de un nuevo producto o proyecto que queremos empezar a desarrollar.

Generalmente esta UX Strategy se enmarca dentro de la estrategia general del proyecto por lo que cosas como la justificación del caso de negocio o tecnológica la recogen otros expertos en profundidad (ventajas de empresa grande, ande o no ande…).

Bueno allá va, por mi parte como Design Lead, intento establecer algunos conceptos básicos para que puedan entenderse los pasos tácticos y técnicos para desarrollar el diseño con éxito. No es casualidad que muchas de las cosas que aquí mencionen se asocien con las primeras fases de Investigación y Requerimientos de un proceso de desarrollo puesto que la idea es descubrir el problema de diseño.

Relación entre los usuarios y los clientes

No en todas las soluciones existe una relación clara entre una buena experiencia de usuario y un beneficio directo sobre los clientes que compran el software, principalmente porque las razones por las que se adquiere software a veces están más ligadas a cuestiones estrategicas empresariales o políticas más que por razones de usabilidad o utilidad.
Sin embargo, esto no quiere decir que se imposible hacer algo bien hecho, por lo que es importante que establezcamos los beneficios que tendrá sobre el negocio y sus clientes el hecho de que los usuarios obtengan algún beneficio.
Por ejemplo, ahorrar a un médico papeleo significa que podrá dedicar más tiempo atendiendo a sus pacientes, que la calidad del servicio sanitario sea mejor y más eficiente, etc. etc.

Personas, escenarios y contexto de uso

No sólo como input beneficioso para el equipo de diseño y desarrollo sino para ayudar a comprender el ámbito de los proyectos a nivel de management y como puente entre el problema y la solución, considero importante describir el problema y lanzar las primeras ideas de una posible solución. Las personas nos ayudarán a conectar también con los Actores de los Casos de Uso y los escenarios con las User Stories de desarrollo, guardando siempre la perspectiva que nos interesa: la del usuario.

Key performance indicators

Aunque no todo en software son webs, los KPIs pueden definirse de muchas maneras, un libro del que tiro mucho es el de Measuring User Experience. De él busco definir la mejor forma de medir el éxito de un buen diseño alineado con los objetivos de los proyectos ya que no todos son iguales. Algunos necesitan rediseñar, otros lanzar nuevas ideas al mercado, otros iterar sobre algo hecho, etc.

Finalmente incluyo una sección bastante más extensa para establecer el marco de la estrategia de diseño específica que incluye Form Factors, dispositivos, conectividad, accesibilidad, referencia a guías de estilo y supuestos de la tecnología.

Conclusión

En conclusión, la UX Strategy busca identificar y alinear objetivos y valores para establecer una visión común a través del entendimiento de las necesidades de los usuarios, el cliente y el negocio. Por lo tanto, es importante proporcionar toda esa información que, aún siendo susceptible de evolucionar durante el desarrollo, genera los primeros descubrimientos de cuáles son nuestras oportunidades para afrontarlo con éxito.

Como siempre, os dejo algunos enlaces relacionados de interés:

P.

Personas: manteniendo el diseño centrado en el usuario

Últimamente estoy trabajando en al definición e investigación de Personas para el proyecto en el que trabajo, de ahí mis dos últimos posts (libros y UXser Stories), y debo confesar que no me está resultando un trabajo nada fácil.

Por una parte me encuentro con muchos escépticos (sobre UX en general, y Personas en concreto), que vienen a ser principalmente los responsables de conocer las necesidades de sus usuarios y, sin embargo, los primeros que no quieren saber nada de ellos. Este tipo de ir-responsables lo resume todo en 1) Dame una plantilla y 2) ¿No habrá nada por ahí que podamos copiar?

Por otra parte me encuentro con las barreras para acceder a los Subject Matter Experts (expertos de dominio), ex-usuarios contratados para aportar su conocimiento experto en el ámbito funcional. Los usuarios una vez contratados pierden cierto potencial para el testing en mi opinión, pero son más que imprescindibles para hacer escuchar la voz de los usuarios durante el desarrollo. Y es que este es el propósito de una Persona: ser el usuario cuando no hay usuarios cerca. Sin embargo, los expertos de dominio están generalmente para legislaciones, validaciones, hacer casos de uso (si saben lo que es) y traducir software.

Sin embargo es cierto que a veces insistir tanto en una buena práctica de diseño trae su recompensa. Ver, por ejemplo, que sin definición de los target users no se puede justificar un Business Cases o que algunos compañeros que sí confían en el valor de las Personas (léase con doble sentido), son los mejores describiendo lo que necesitan los usuarios hasta el punto de emocionarte al leer ciertas historias es reconfortante..

¿Qué debe tener una buena descripción de una persona? Pues como soy muy fan de leer libros para formarme e informarme os comparto otro recurso muy aprovechable y lleno de ideas sobre como integrarlas en el desarrollo del producto:

image

The Persona Lifecycle (en Amazon)

D.

Dos libros imprescindibles sobre Personas

Seguramente hayas oído hablar alguna vez del uso de Personas como técnica de investigación de necesidades de usuario.

En el caso de que quieras aprender algo útil más allá de los cientos de artículos que sólo buscan posicionarse a favor o en contra, te recomiendo que leas los siguientes libros:

Alan Cooper es dios, la religión es cosa tuya 😉

E.

Experiencia de Usuario para Desarrolladores

Si alguno de vosotros se ha preguntado como desarrollador qué debe saber o conocer sobre el diseño de Experiencia de Usuario, qué es el Diseño de Interacción o el Diseño Visual y qué tiene que ver todo esto con el proceso de desarrollo, le recomiendo este vídeo y los siguientes enlaces:

Espero que os resulten útiles.

H.

Historias de Usuario

As a designer, I want to read meaningful user stories that talks about real people with real expectations and goals to achieve when using your software.

¿Por qué tus user stories no me dicen nada? Debo confensar que no soy una gran apasionada de Scrum. Generalmente mi desagrado no viene por los principios del desarrollo ágil y su manifesto, sino por quienes lo practican y evangelizan sin querer o saber integrar actividades de diseño en un desarrollo ágil.

¿Tan difícil resulta? Veamos…

En la metodología de Diseño Centrado en el Usuario uno de los principios fundamentales es entender las necesidades de los usuarios y diseñar los productos para satisfacer dichas necesidades o incluso ‘adelantarse’ a ellas. Todo gira en torno a los usuarios, tanto el análisis como el diseño y la evaluación del producto, convirtiéndose en protagonistas dentro de todo el elenco de actores.

En este contexto, Scrum debe ser la metodología de trabajo que guía el desarrollo, asegurando con sus principios y técnicas que se entrega a los clientes un software de calidad de forma ágil y que cumple sus expectativas.

El gap empieza a notarse en el momento en el que las principales user stories, los epics, que deberían describir una funcionalidad de valor para un producto, es decir, para un usuario, terminan convirtiéndose en frases vacías que no dicen nada o más bien dicen obviedades.

Estos son algunos ejemplos que considero insignificantes.

As a user, I want to get access to the item details easily.

As a clinician, I want to get access to the patient details easily.

Pues bien, primer problema es la ausencia de actor protagonista. Tanto la palabra user, como cualquier rol asociado a un usuario, no tienen por qué ser siempre la mejor forma de referirse a quién es el usuario que necesita dicha funcionalidad.

De hecho, las funcionalidades tienden a ser características del producto que se usarán dependiendo de la actividad, y la actividad no depende sólo de un rol sino también de un objetivo, por lo tanto, es más que probable que la necesidad ‘get access to the patient details’ formará parte (o no) de las activitidades para alcanzar algún otro objetivo más importante y relevante para el usuario.

La forma que sugiero de resolver este conflicto es incluyendo el uso de Personas para protagonizar las user stories, entendiéndolas desde un punto de vista de objetivos y patrones de comportamiento. Si asociamos objetivos a nuestros usuarios arquetipos y les dotamos de personalidad podremos referirnos a ellos de la siguiente manera:

As Stepehen King, I want…

As Peter Pan, I want…

As Morgan Freeman, I want…

Segundo problema: el valor de la user story es inexistente. Muchas veces me he encontrado user stories del siguiente tipo:

As a clinician, I want to get access to the patient details easily so I have a good overview of the patient health record.

¿En serio? Una cosa es que a los usuarios, en este caso médicos o enfermeras, les cueste expresar por qué necesitan ver los datos de un paciente, pero no quiere decir que no persigan un objetivo. Este objetivo lo da muchas veces el escenario y el contexto. Mi propuesta es enganchar aquí con los Escenarios de uso para describir qué es lo que el usuario realmente persigue con sus necesidades.

As Dr. Smith, I want to get access to the patient details easily so I can … diagnose a patient.

As Dr. Smith, I want to get access to the patient details easily so I can … schedule a follow-up appointment.

As Dr. Smith, I want to get access to the patient details easily so I can … check blood tests results.

Es importante que la user story siga pareciendo una historia real dentro de un contexto real, ya que incluso a este nivel, ningún desarrollador podrá escribir una línea de código sin hablar antes con el Product Owner, sin embargo, sí podrá entender e imaginar el alcance de la funcionalidad que tiene que implementar. ¿Cómo debería desarrollarse la user story para que el acceso a un paciente sea suficientemente efectivo como para saber diagnosticarlo, reservar una cita o comprobar los tests de usuarios?

Entra en juego también que el objetivo (so I can…) puede determinar el tipo de información que el Dr. Smith querrá ver para decidir o no acceder a los detalles del paciente.

El tercer problema que encuentro es el complemento de modo (condiciones de satisfacción).

As a clinician, I want to get access to the patient details easily.

Estoy segura que a estas alturas la Usabilidad forma parte de los requerimientos no funcionalidades de tu producto desde hace mucho tiempo y que no hace falta redefinirla en cada user story. Hacer algo easily no significa nada nuevo ni nada específico. Si lo que queremos es enfatizar cómo sería acceder a los datos de un paciente por el Dr. Smith de forma sencilla ¿por qué no lo escribimos tal cuál debe ser?

As Dr. Smith, I want to get access to the patient details easily so I can schedule a follow-up appointment.

Aquí podríamos incluir los condicionantes (Acceptance criteria) o bien usar una forma diferente de escribir que ayude a su validación (Acceptance stories).

As Dr. Smith, I want to get access to the patient details so I can schedule a follow-up appointment while I’m waiting for the next scheduled patient.

Aunque estoy complicando la historia intencionadamente, el ejemplo empieza reflejar ciertos factores algo más esclarecedores de lo que significa ‘fácil’ para el Dr. Smith, que espera darle la cita a su paciente entre visita y visita, lo que significará con mucha probabilidad que el tiempo será muy reducido, que tras cerrar el encuentro con ese paciente espera poder llegar su historial, consultar su agenda y reservarle una cita a su paciente.

Sé que también que desde el punto de vista del desarrollador sería más fácil ser más explícito, es decir, si sabemos bien que esos son los condicionantes, ¿por qué no lo escribimos tal cual?

Aquí insistiría en que, primero, sigue siendo necesario hablar con el Product Owner, y segundo, ¿de verdad lo sabíamos desde el principio?

Sé que estoy liando mucho este artículo con preguntas y que da para mucho más, pero querría cerrar esta pequeña deserción con el último de los problemas o, más bien, la última de mis sugerencias.

Si no crees que estos ejemplos tengan ningún sentido, quizá deberías plantearte volver a usar Casos de Uso.

U.

Usando WorkFlowy para anotar mis ‘quehaceres’

WorkFlowy es una herramienta muy básica que te permite crear en un documento listas de elementos. Algo tan sencillo no podría sino estar llevado a cabo de forma fácil para el usuario:

  • Se puede instalar como extensión de Chrome
  • Sólo se necesitas comenzar a escribir para usarla
  • Con pocos atajos de teclado se hace un uso muy eficiente

Después de haber probado otras herramientas en principio mejor preparadas para gestionar mini-projectos personales o equipos pequeños como Asana, encuentro WorkFlowy mucho más ligero y mejor adaptado a la forma diaria de funcionamiento tanto de trabajo como personal.

Con esta herramienta podremos:

  • Crear litas de tareas pendientes
  • Anotar todas esas tareas que se han completado,
  • Añadir pequeñas notas
  • Reordenar las listas
  • Navegar por los elementos de la lista para tener una vista más centrada en una sola tarea
  • Añadir #tags para organizar libremente los elementos
  • Asignar tareas a @usuarios
  • Trabajar en modo offline
  • Marcar páginas como forma adicional de organizar el documento

Resulta especialmente interesante que estas herramientas no surjan con un enfoque Mobile First ni desde el punto de vista de su diseño ni de la forma de desarrollar el producto. El hecho de que sea una aplicación web extremadamente ligera y eficiente rompe con cualquier prejuicio sobre estas tecnologías al tiempo que nos recuerda que cada producto debe desarrollarse en el contexto tecnológico en el que resulte más eficaz para los usuarios.

Otros posts relacionados:

E.

El Cine De…

Comienzo una nueva fase de desarrollo con elcine.de. Hasta ahora estas han sido las etapas por las que ha pasado el proyecto:

  • Ideación
  • Observación de necesidades y oportunidades
  • Análisis de otras plataformas similares
  • Sketching
  • Desarrollo de una prueba de concepto sobre Drupal 7
  • Análisis de características del producto
  • Diseño – primera propuesta

En esta nueva fase volveré a la preparación de la instalación base de Drupal y al desarrollo de features incluyendo la maquetación CSS final dividida en los siguientes bloques

  1. Base de datos filmográfica
  2. Gestión de listas y colecciones
  3. Interacciones de usuario (usuario-contenido y usuario-usuario)
  4. Relación usuario-servicio (registro, login, mailing, seguimiento, baja, etc.)
  5. Perfiles de usuario
  6. Vista de película (Ficha)
  7. Vista de película en grupo (Listados, Colecciones, Perfiles, etc.)
  8. Página de inicio
  9. Buscador y navegador de catálogo
  10. Contenidos vivos (Recomendaciones, Novedades, Actividad, Personas)
  11. Páginas de la plataforma (Condiciones, Privacidad, Ayuda)