Estamos más obsesionados con aparentar ser buenos que a veces nos olvidamos simplemente de intentar ser mejores. Pensándolo tiene cierto sentido, nuestra identidad moral y nuestra reputación son un valor que queremos preservar porque lo que piensan los demás de nosotros nos importa. El problema surge cuando preferimos proyectar una imagen artifical sobre lo buenos… Continue reading
Post Category → People
Post-humanismo y diseño
No todos podemos sostener, con un alto grado de seguridad, que hemos sido siempre humanos. – Rosi Braidotti “Lo Posthumano” El concepto de humano, nacido en la Ilustración, nos da cierta tranquilidad. Ser humano es lo natural en nosotros, es nuestra característica fundamental como especie, nuestra identidad. Sin embargo, en el contexto de las sociedades… Continue reading
Modelar la investigación de usuario con Patrones de Comportamiento
Cuando hablamos de Diseño Centrado en el Usuario siempre nos planteamos un proceso de investigación de usuarios desde donde descubrir sus características, sus circunstancias, sus expectativas y sus objetivos. Sin embargo, una vez que recogemos toda esta información debemos ser capaces de ‘traducirla’ de modo que nos permita tomar decisiones en base a ella en… Continue reading
Diseño persuasivo, diseño alienante
Habrás escuchado una y mil veces que el diseño de interacción tiene que ser persuasivo, convincente, emocionante, tiene que motivar e influir en nuestra decisiones a la hora de interactuar con un producto o servicio. It’s about understanding the emotions that influence people’s behavior and decision-making, and then acting on that information to design compelling… Continue reading
Mujeres, la tecnología no tiene edad
Con el ruido de fondo de la lavadora, te mando mis respuestas que son más bien preguntas. Soy una persona con suerte o al menos cuando la escucho me hace sentirlo. La semana pasada mencionaba lo inspirador que me resultó escuchar a Emma Watson. Esta vez he ido a buscar la inspiración un poco más… Continue reading
La lucha feminista no se para
La escucho y no lo puedo evitar, me emociona. Sus palabras se dijeron para encender la mecha de uno de los movimientos feministas más relevantes del siglo XXI: HeForShe, iniciado en su papel de embajadora de las Naciones Unidas. Emma Watson es una mujer privilegiada que ha hecho con su poder algo necesario: activismo político…. Continue reading
Qué se aprende en un meetup
Los encuentros de tecnología que se organizan a través de la web Meetup en la ciudad de Málaga han crecido como la espuma en los últimos dos años. Yes We Tech, Databeers, Scala, Frontend, Digital Marketing e incluso comunidades con más recorrido como GDG se han pasado a esta plataforma para anunciar sus eventos. Cada semana… Continue reading
Las preguntas correctas en feminismo
A la Real Academia de Ingeniería, Como mujer, ingeniera y feminista debo reconocer el enorme valor e importancia que considero tiene su recientemente impulsado proyecto ‘Mujer e Ingeniería’ que promocionan a través de este vídeo. Para mí es emocionante ver este tipo de proyectos ya que suponen admitir la situación de anormalidad que sufrimos en… Continue reading
Innovar buscando la perfección
Como mucha gente sabe hace más de 60 años el atleta estadounidense Dick Fosbury revolucionó la técnica de salto de altura haciendo algo que nunca antes nadie había hecho: pasar por encima del listón de espaldas.
Esta idea original le hizo ganar unos juegos olímpicos estableciendo un nuevo récord mundial en los 2m 24cm. Él sabía que, a pesar de no ser el atleta mejor dotado de su generación y de las mofas de sus compañeros de instituto, su técnica innovadora le podía llevar al éxito.
Fosbury, quien no se sentía cómodo afrontando el listón de frente y no terminaba de adaptarse a las técnicas clásicas, tuvo no sólo que crear una nueva idea transgesora sino que pasó meses y meses poniéndola en práctica y mejorándola totalmente en solitario hasta que pudo demostrarle al mundo, en una competición de máximo nivel, que efectivamente había mejorado todas las marcas.
Mientras Fosbury practicaba sólo, los más cercanos a él sabían de sus intenciones de probar suerte en el campeonato que le dio su primer oro. Hoy en día nadie duda de que la suya es la mejor técnica de salto de altura para competición. Lo curioso es que las técnicas anteriores tales como rodillo ventral aún se usan aún durante los entrenamientos para entender la mecánica del cuerpo y la clave más importante del salto: la necesidad de levantar la cadera.
Para el atleta, su triunfo no venía por ganar muchos oros en los subsiguientes campeonatos, seguramente porque sabía, entre otras cosas, que su físico no era el más talentoso y que pronto otros atletas más potentes le copiarían su nueva técnica. Sin embargo sabía que su objetivo primordial era el de conseguir el mejor salto posible.
Toda esta suma de cosas, toda esta historia que parece desconexa me ha hecho siempre reflexionar sobre la necesidades personales de innovación y especialización.
En el caso de este gran saltador de altura innovar le llevó a sentar un precedente, a ser el mejor (por un tiempo) pero sobre todo a demostrar que no era necesario afrontar la barrera como todo el mundo solía hacerlo para superarla de forma más óptima.
Por otra parte cuando por fin la asumió como una idea posible fue cuando decidió llevarla a la perfección buscando el máximo rendimiento, optimizando el giro de su cuerpo, el arco de su espalda, el levantamiento de los brazos y todo aquel gesto que contribuía a la superación del listón.
La necesidad de una alternativa a causa de una limitación propia disparó la idea creativa. La práctica resultó necesaria para convertir su idea en innovadora. Y de ésta se sentó una base para el desarrollo de una nueva técnica.
Albert Einstein dijo
La creatividad nace de la angustia, como el día nace de la noche oscura… En tiempos de crisis la creatividad, supera el conocimiento.
Ésto es algo que bien sabe Fosbury y que a modo de tópico escuchamos mucho aunque no queramos oírlo. La crisis personales, que no tienen por qué ser la económicas, ponen a prueba el tipo de ser innovador que somos.
Mi pregunta es ¿estamos dispuestos a reconocernos como tales o queremos seguir dejando que todas las barreras nos parezcan inalcanzables?
Y si encontramos una idea mejor ¿tenemos miedo a no ser los más talentosos para sacarle el máximo rendimiento? ¿A caso importa esto para innovar?
Nota final: otro pequeño gran detalle que contribuyó a este atrevimiento fue el de colocar un colchón tras el listón en lugar de un montón de arena. Lo que demostraba que era valiente, pero no un loco, lo último que un atleta busca es una lesión que le aparte de su objetivo. Hagan ustedes la sobrelectura del simil.
¿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)