U.

UX Fighters, el club de los luchadores

image

Este fin de semana he tenido la suerte de ir a la primera edición del evento UX Fighters en Madrid y os digo desde ya que me vuelvo encantada. Da gustó ver cómo desde 2012 los eventos claramente marcados con temática sobres Experiencia de Usuario han ido surgiendo. Por supuesto, antes de 2012 ya existían otros meetings de profesionales que han acabado reencontrandose en esta disciplina, pero es genial contar con gente que se anima a organizarlos y nos ‘obliga’ a relacionarnos más.

He de decir que ha sido una gozada poder charlar de nuevo con gente de muchísimo talento (entre ponentes y asistentes) con los que he podido coincidir. Como siempre, estos eventos te ayudan a remover las inquietudes, a inspirarte y a motivarte para poner en marcha algún cambio transformador. Debo felicitar a los organizadores por tener el coraje de meterse en este “fregao” y habernos hecho partícipes.

Dicho esto, y teniendo en cuenta que Madrid como capital tiene mucha suerte de poder aglutinar a tanta comunidad, debemos seguir haciendo el esfuerzo por generar oportunidades en otras provincias. Mirándome el ombligo pongo mi vista en el sur, en Málaga, donde la infraestructura lo permite pero el glamour nos lo roba malamente la imagen de ‘ciudad de vacaciones’. Sí, esto es un tiro directo a los organizadores del UXSpain para que se animen a ponerlo marcha aquí mientras otros miramos para otro lado sin intentar nada de nada. Y no es que no quiera viajar, todo lo contrario, me encanta el caracter ‘de provincias’ de este evento, es simplemente que me postulo por la mejor ciudad de la península (habiéndose celebrado ya en Granada, por supuesto).

Bueno, no me enrollo, estas son las cositas que más me han llamado la atención durante el evento UX Fighters, quizá algunas de ellas las compartáis conmigo, a saber:

  • Me encanta el nombre del evento, la imagen, la narrativa, aunque personalmente creo que sobraron tanto chiste sobre ir a pelear al Matadero, jur jur.
  • El lugar fue perfecto, siendo Madrid creo que han elegido bien, las sillas ikeísticas un poco incómodas y poco espacio para glotonear y charlar al mismo tiempo pero no hay duda que el entorno molaba, además tenía una zona de running perfecta ^^
  • Después del lío inicial con las acreditaciones, todo fue sobre ruedas, no faltaba comida, el grandísimo maestro de ceremonias nos introdujo a los ponentes conviertiéndose en uno más gracias a sus reveladoras batallas personales que dieron gusto oír.
  • La batalla empezó con Chris Grant al que sólo recuerdo por repetir fucking product owner en el UXSpain pero que nos contó un poco más sobre los clientes/usuarios. Difícil de distinguir en el caso Tuenti. Confieso que a mí Tuenti como Treinti(añera) que soy no me moló nada cuando me registré, cuando Coca Cola me felicitó mi cumpleaños y Movistar me pedía mis datos muy personales para aseguarse de que era humana, pero oye, yo no era la usuaria y a Chris no puedo culparle.
  • Gema Muñoz nos dejó a todo/as alucinados con su pasión y energía en el escenario hablándonos de analítica y métricas de cero a cien. La más dispuesta a compartir, nos dejó esta joyita para el recuerdo y la memoria

//platform.twitter.com/widgets.js

  • Los chicos de Redbility se atrevieron a contar sus cagadas, ¡que no fueron pocas!, pero demostraron que a pesar ellas se puede evolucionar si se aprende y ahí los tienen con una empresa de esas de las que te encantaría formar parte.
  • José Martull me gustó especialmente por lo inusual que es para mí pensar en los usuarios como clientes a los que debemos querer atender. En mi ensoñación personal, mis clientes son mis jefes, compañeros de equipo, equipos de producto, etc. a los que ofrezco mi expertise (si estoy lúcida). Y debo decir que me ayudó mucho a reubicar ideas para mejorar mi relación personal con “el cliente”.
  • Ignacio Riesco habló sobre ecommerce, siendo muy taxativo en algunos principios básicos sobre el diseño de comercios electrónicos y otras veces intenso en sus puntos de vista. ¡Ahí empezó la verdadera batalla!
  • Orse Olsen habló sobre agilismo y algunas claves de procesos de diseño. Una de esas personas a las que te encantaría tener como manager, jefe y referente.
  • Borja Delgado puso el acento en un tema que me encanta: los pequeños grandes detalles. Este excelente comunicador siempre sabe simplificar y transmitir ideas para nada evidentes al resto de uxers mortales. Un crack aunque sobra decirlo.
  • Juan Leal compartió su filosofía de copy sobre Soysuper, un proyecto simpático y muy útil que hay que seguir de cerca.
  • El segundo día empezó cañero con Frederic Alluin, un francés de 2 metros que nos dio caña con las nuevas interfaces que se avecinan. Compartió su experiencia con las Google Glass (una mierda innecesaria), las Oculus Rift (una pasada, pero marean!) y muchas más. Vamos, que tengo una necesidad mortal de comprarme un smartwatch como mínimo y trastearlo.
  • De Pere Rosales sólo me sale una cosa: es muy grande. No es sólo por lo que inspira, o por su entusiasmo, sino porque sabe hacerte cómplice y eso no lo consiguen todos. Siempre un placer escucharle y charlar con él.
  • Jerónimo Mazzarrasa es un cuentista en el mejor sentido de la palabra, y nos contó muchos cuentos dentro de uno: el de cómo lo que hacemos ahora construye el futuro que se nos viene. Brutal.
  • Sergio Leyva me sorprendió con una confesión y es que aún recuerda el trauma del primer UXSpain. Sergio ha hecho muchas, muchas cosas buenas y nos demostró que no hay nada mejor que dejar que tu trabajo hablé por ti. Es un tio con mucho talento, sin duda, aunque él solito se mete en unos berenjenales difíciles de salir sin que le caiga alguna réplica.
  • Al pobre Jorge Márquez le tocó la mala suerte de ser el último, con el retraso del evento, pasadas las dos y con la cognición de los guerreros por los suelos.
  • Las mesas redondas me dejaron sabores agridulces, gente que aporta más o menos a la conversación y algunos a los que me habría encantado escuchar en solitario en una ponencia más larga. Es un formato difícil donde la opinión no generaba debate aunque sí revelaba alguna postura incómoda. 

Como podéis ver en general el evento mereció la pena, pero que no se pudiera celebrar el hackatón fue una pena (a los que una vez fuimos frikis nos sigue gustando el modelo party).

Pero lo mejor de todo es que me permitió tomarle de nuevo el pulso a la profesión, a la oferta académica y al contacto con los profesionales.

Sigo sin tener claro si algún día me dará por marcharme a Madrid para vivir todo ese ambiente ‘a diario’, pero sí que me encantaría poder tener a un/a mentor/a tan crack como lo/as que allí expusieron sus ponencias. A veces se necesitan referentes para poder crecer más rápido y dejar de darse de leches con tonterías por falta de experiencia. Mientras tanto, compartiré lo aprendido siempre que me sea posible aunque me las tenga que apañar con mi intuición e Internet 🙂

Nos vemos en la próxima edición y con suerte antes en algún UXSpain (sí, esto también es un tiro directo a sus organizadores).

Saludos

P.

Pencil

Herramienta de prototipado de código abierto multiplataforma

Si la austeridad también ha llegado a su ciudad, como el camión del tapicero, quizá guste de conocer esta interesante herramienta de prototipado de baja fidelidad totalmente gratuita y disponible para Linux, Windows y Mac.

Pencil no es nada nuevo ni bohemio ni cool, de hecho la última release es de Septiembre de 2013 y no da la impresión de que el proyecto siga vivo, pero no podemos negar que como herramienta es bastante útil si quieres empezar a trastear con el diseño de pantallas desde ya, además es gratis, es libre y el resto depende de tu imaginación (como siempre). 

Pencil Project nació en 2008 y se distribuye bajo términos de licencia GPL version 2, y es una herramienta muy sencilla que permite hacer cosas tan básicas como:

  • Dibujar diagramas
  • Sketchear GUIs basadas en componentes predefinidos
  • Relacionar documentos de un proyecto mediante enlaces de contenido
  • Exportar los documentos como imágenes o un documento HTML (aunque éste sea bastante precario)
  • Definir tus propia librería de componentes (muy útil para equipos de diseño)

Sobre éste último punto he publicado un pequeño artículor en el que explico cómo hacerlo.  Aquí os dejo el enlace por si os pica la curiosidad: Cómo crear una librería de recursos con Pencil.

C.

Cómo crear una librería de recursos con Pencil

Si ya conocéis Pencil y os preguntáis cómo podríais definir vuestra propia librería de componentes para crear GUI en este tutorial hacemos un repaso de los pasos a seguir.

Hay dos formas de conseguir nuestra propia librería

  1. Haciéndolo bien
  2. Haciéndolo rápido

Como para hacerlo bien ya existe una buena documentación en la web de la herramienta vamos a explicar cómo puede hacerse de forma rápida (y no tan flexible) para que resulte práctico crear conceptos visuales y compartirlos con diferentes equipos.

image

Una forma fácil de empezar

Usando la librería ‘Common shapes’ podemos empezar a dibujar elementos básicos basados en formas geométricas.

  1. Una vez que tengamos todos los elementos, los seleccionamos juntos y agrupamos (CTRL+G). Ahora se comportarán como una única forma.
  2. Sobre el nuevo componente clicamos en botón derecho “Add to my collections…”.
  3. Como este es el primer componente tendremos que crear una nueva colección a la cual añadirlo. 
  4. Si ahora comprobáis en la pestaña ‘My Stuff’ veréis que ya está creada vuestra nueva colección. 

Una característica que encuentro bastante útil es la ‘Sizing policy’ que tiene cada elemento (accesible via menú contextual). Esta política permite definir el comportamiento del elemento cuando está agrupado en un componente al que se le modifica el tamaño. Gracias a esto podrás decidir si quieres que cambie o no de tamaño o se mantenga alineado a un lado o a otro.

¿Y si quiero hacerlo bien?

Qué necesitas tener

  • Un editor de texto (para ver/editar XML)
  • Un editor de SVG (las formas están definidas como vectores)
  • Un editor de bitmpas (por si necesitas meter algún icono o imagen)

Qué necesitas saber

Una estructura típica para crear una colección tiene este aspecto

... [dir] CollectionName
      |
      |___[dir] icons       #optional
      |     |
      |     |___shape1.png
      |
      |___ Definition.xml     

y en el documento Definition.xml deberás definirlo de esta forma

<Shapes xmlns="http://www.evolus.vn/Namespace/Pencil"
        xmlns:p="http://www.evolus.vn/Namespace/Pencil"
        xmlns:svg="http://www.w3.org/2000/svg"
        xmlns:xlink="http://www.w3.org/1999/xlink"

        id="your_collection_id"
        displayName="Display name of your collection"
        description="More description about this collection"
        author="Names of the authors"
        url="Optional URL to its web page">
        
        <!-- Your shapes go here -->
        
</Shapes>

Iremos añadiendo los diferentes componentes usando las etiquetas <Shape></Shape> y dentro de ellos podremos definir Propiedades (color, dimensión, etc.), Comportamientos y Acciones además de su Aspecto (mediante el SVG).

Para ver lo que estamos haciendo, puedes cargar tu colección desde Tools » Developer Tools » Load Developer Stencil Directory… seleccionando el archivo Definition.xml (usa F5 una vez cargado para refrescar).

Cuando termines, mételo todo en un archivo ZIP asegurándote que el Definition.xml está en la carpeta raíz.

No te olvides que si quieres depurar errores puedes abrir la consola de errores desde Tools » Developer Tools » Show Error Console

A partir de aquí te recomiendo que consultes el Tutorial en el que viene explicado cada detalle sobre cómo montar la colección con directivas XML.

T.

The Role of Iterative Usability Evaluation in Agile Development: A Case Study :: UXmatters

The Role of Iterative Usability Evaluation in Agile Development: A Case Study :: UXmatters

I.

Interaction Design with Indigo Studio and GifCam

Interaction Design with Indigo Studio and GifCam.

Indigo first release was free forever, although it’s not available for download any longer. I’m one of the few who still have a Lite license and can take advantage of this powerful prototyping tool built in Silverlight.

Indigo has helped me to demonstrate design, simulate behaviour and communicate specifications with the development team and also with end users.

GifCam is just a cool resource that helps me to share microinteractions implemented with a prototyping tool.

And this ‘Hello World’ example is nothing but one of the design interactions in motion I’ve been working this morning 🙂

U.

Un año de proyectos

Uno de los objetivos que teníamos cuando hace un año pusimos en marcha esta firma era el de dar soporte a todo esos proyectos que siempre hemos querido iniciar y nunca encuentran el tiempo, el dinero o el coraje suficiente para salir adelante.

Éste ha sido, en sí mismo, el primero de los retos, nuestro Proyecto Cero.

Como balance de un año me gustaría reflexionar sobre los resultados, los cuales creo que han sido más positivos que negativos.

Los principios nunca son fáciles, pero contamos con el empuje de mucha gente, entre los que destacaría a Braulio y su esfuerzo por crear la comunidad de Training Bubbles a través de la cual ofrecimos algunos vídeos rápidos sobre técnicas prácticas de Diseño y Experiencia de Usuario.

Healthy Design Services muestra muchas de nuestras aspiraciones y resumen los principios en los que nos gustaría comunicar nuestros proyectos. Un diseño saludable es representado por soluciones óptimas, balanceadas, perdurables con una estrategia sólida que pone atención en el detalle, que confía en los beneficios a largo plazo sostenido por pequeños logros a corto. Un diseño como servicio al igual que un producto como servicio para ser usado y utilizado bien, fácilmente, sin aditivos y sobre todo lleno de utilidades.

No ignoramos otro de los matices sobre nuestra identidad en esta ocasión relacionado con el background de esta pareja de dos en UXSALAD: ambos provenimos de la industria de software sanitario la cual nos ha dado una visión muy particular de lo que supone el diseño de interacción persona-ordenador con propósitos de servicio humanitario, es decir, cuya base fundamental reside en el tratatimiento de información y servicios que gestionan datos sensibles y vitales para la sociedad más que como oferta de entretenimiento, productividad o cultura general.

Con esta filosofía nos hemos mantenido estos doce meses, en los que entre otros, hemos dado comienzo al desarrollo de una plataforma social de cine que pasará a su fase beta a partir de mediados de 2014.

Aunque tampoco podemos ignorar los fallos (aún es pronto para hablar de fracasos). Es obvio que UXSALAD es un estudio de diseño al que no le dedicamos el 100% de nuestro tiempo, la principal razón es que necesitamos un flujo de ingresos estable para vivir. Una de las cosas que no quisiéramos que pasara es pervertir el buenhacer por culpa de la necesidad, si bien es cierto que la necesidad agudiza el ingenio y aprieta las tuercas para no relajarse demasiado, la prioridad es disfrutar del tiempo que dedicamos a nuestros proyectos y darles la atención que requieren. Fracasaremos el día en el que lleguemos tarde con alguna de nuestras ideas al mercado o a la audencia, sin embargo, trabajamos para ganarle tiempo a esta empresa (en el sentido menos mercantil del término).

¿.

¿Por qué tus user stories no me dicen nada?

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.

(via carmelhassan)

S.

So what’s a good solution?

As a doctor working in an Emergency Department and seeing patients (sic: people) with largely preventable conditions/diseases alot of the time, I really like the idea of personalised medicine and involving patients and empowering them to take control of their healthcare. Brushing teeth is an excellent example that I wouldn’t have thought of before. However, I would echo some of the previous comments on the dangers/naivety of providing some of this info. Lab results are only relevant when married to the clinical information (i.e. the pateint’s history, symptoms, past history and examination findings). This information is far more important and lab tests should only then be done to confirm or rule out your findings from the clinical info. Therefore providing patient information printouts based on the lab results alone is foolish and dangerous.

Also the speaker makes a good point that fear does not work in health education/promotion. I think that giving a patient a printout saying that you have 15% (or whatever) chance of getting prostate cancer/breast cancer/arthritis/whatever is probably one of the most fear-inducing things you can do to a patient. Especially considering it is almost impossible to generate that kind of accurate prediction of any condition based on a blood test or even group of blood tests.

The speaker also says that they have used colour (as if to say “Duh why hasn’t this been done before”). The dept I work in has been told by hospital management to stop ordering more paper as the hospital acn’t afford it. We have had to totally rationalise the amt we are printing and handing out. I know this happens alot of places in the public health system. So we have barely enough paper to put in printers let alone colour printers and the cartridges to keep them running. he may be aiming his comments at the lab companies that make all that money but I feel his talk doesn’t take into account the practicalities that exist in an ED / other healthcare settings

John Cronin (Posted 3 years ago) on Thomas Goetz’s TEDMED talk titled: It’s time to redesign medical data.

I found this comment as a perfect example of the real challenge on Information Design in Healthcare still Today.

We have to think and design for real practice with its context, its users, its information quality. Colour sometimes is a luxury and ranges, percentages and reference values could mislead instead of giving support.