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.

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:

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)

New Year Resolutions

I started blogging in 2004, since then, I’ve changed my nickname, hosting, domain, blog skin, and language several times. Maybe too many times.

Como no podía ser de otra manera, vuelvo a hacerlo por algunas razones.

Necesito escribir y expresarme más y mejor en castellano. Puede parecer absurdo, pero después de leer, hablar y cruzar mails en inglés todo el día en mi trabajo necesito poder expresarme con más comodidad en mi lengua materna.

Eso no quiere decir que ya haya superado todas mis barreras con el inglés sino más bien lo contrario, este blog lo empecé a escribir en inglés con ese propósito y aún me queda mucho por mejorar y corregir. Por ahora prefiero hacerlo en otros ámbitos a parte del profesional y recuperar este espacio para otros escritos, quizá con un poco más de éxito.

No me importa reconocer que después de haber publicado durante todo este tiempo algunas entradas que llevaban tras de sí muchas horas de trabajo el resultado no es el esperado. Pero lo cierto es que tampoco espero una gran repercusión en este sentido, más bien compartir un poco de mi trabajo, de lo que se puede y no es obviamente confidencial.

No me gustaría extenderme en esta publicación más de la cuenta así que aquí dejo mi pequeña lista de propósitos para año nuevo respecto a mi presencial online:

  1. Focalizarme al máximo en el proyecto que más me está motivando desde hace meses: elcine.de. Del que espero sacar una versión beta antes de mediados de 2014.
  2. Escribir mejor y con más frecuencia en este blog. En castellano 😉
  3. Reactivar http://designersforinteraction.com/ esta vez sí, en (casi) perfecto inglés a ser posible.
  4. Animar a la otra pata de UXSALAD para que elcine.de y otros proyectos puedan publicarse durante este año 2014.

¡Muchas gracias y Feliz Año!

One design to rule them all?

image

Today I wanted to get some clarity about a way to efficiently approach the UX design when targetting multiple mobile devices. You know, to deserve my holidays.

During my research, I’ve needed to take apart aspects like the Interaction design and get focused only on the very basic initial challenge: the app structure and navigation. I’ve also centred the research within the smartphone scope by considering only Android, iOS7 and Windows Phone 8.

These are some early ideas I’d like to investigate further:

  • The commonalities and diferences between the in-built functionalities like Search, Notifications, Multitasking, Back vs Up navigation and in-app navigation.
  • A compliance layout, app structure and navigation which naturally fits into the different platforms according to their guidelines.
  • A translation (if exists) between the different navigation patterns (flat, hierarchical, etc.) and the recommended UI controls (Tabs, Toolbars, Segmented control, etc.)

So I’ll continue digging into the guidelines and trying some design to validate (or not) the hypothesis “One” design to rule them all might be difficult but not impossible, it is, actually, needed.

Cheers

 

2013 – Catch up

Disclaimer: This is a personal note.

Last March, 2013 I felt the need of a professional change. Somehow I knew that it didn’t necessary mean that I had to leave my current job, although that was actually the first and most immediate plan that came to my mind.

It has been a time of self-searching, the lesson learnt is that I shouldn’t stop now because changes are being happening since that moment.

First, my partner and I decided to move forward and create our own space of creativity. Now it’s just a brand but it’s also a declaration of intentions: we as professional should have our own identity, whether it looks like a brand or it’s just our personal name and twitter account. Fortunately or not, User Experience is a discipline that co-living within an online community and we should be there.

Alongside uxsalad, I started working in the creation of a digital product called elcine.de – sorry, I know there’s nothing visible yet. Encouraged by my passion for films and willingness of enjoying every sort of different movies, I’ve been researching, reading, and ideating to get a better understanding of my target users and create the version Zero of elcine.de: an online platform to live the movies throughout the people who love&hate the movies.

It may sound like yet another social website, but the intend is not that. I want to be the first Spanish platform that contributes to the film culture by bringing the movies back to the people, to us – ok then, it may sound like yet another movie website… fair enough, I’ll work for making a difference, that’s all I can promise now.

Finally, I have to add that, yes, I’m still working 40 hours a week for a company which is providing me other types of challenges and allows me to worry only of enjoying whatever I do both inside and outside it. And No, I’m not keen on the discussion “to start up you have to leave behind everything”. Of course, I wish I had more time, interestingly, is this few time what’s keeping me focused.

Hopefully I can share more about elcine.de in the following weeks, since the first design iteration and a small proof of concept have gave me interesting outcomes.

Cheers.

How to Create an Enterprise UI Toolkit | UX Magazine

How to Create an Enterprise UI Toolkit | UX Magazine