Trampa nº 2: Historias de usuario falsas

Cuando nos tragamos por primera vez el manual del diseño centrado en el usuario, solíamos entusiasmarnos con nuestros personajes.

Aquí hay uno, Henry tiene toda una trama paralela sobre su divorcio, y cómo ha afectado a su relación con sus nietos. Es muy fácil de entender. Creo que estábamos trabajando a través de nuestro parche púrpura aquí. Empezamos con personajes mucho más delgados, de bolsillo, tenían signos de estrella, pero no se podía realmente averiguar su motivación en golpear el botón de salida.

De todos modos, últimamente somos mucho más funcionales. Es mucho más probable que los nombres de los personajes sean del tipo "Comprador de entradas individuales". Se llamen como se llamen, no es probable que aparezcan en historias de usuario como esta:

[historia] "Como mecenas quiero comprometerme con contenidos ricos sobre proyectos educativos para sentirme más implicado".

Me temo que eso es una historia de usuario falsa. Son las historias que acabamos escribiendo cuando intentamos que los usuarios encajen en las motivaciones de nuestra organización. Básicamente estás comenzando con esos requisitos departamentales de ida y vuelta, y tratando de ponerlos en formato de historia de usuario. Ves esa parte al final de la historia de usuario. ¿La parte de "Así que puedo"? Esa parte es la más importante de una historia de usuario porque se supone que establece el beneficio para el usuario, y por lo tanto la razón por la que querrían esta función. Cuando se tiene una larga lista de requisitos generados internamente esto se vuelve molesto bastante rápido. ¿Quiénes son estas personas? ¿Qué quieren? Es un estorbo...

Así que terminas con historias de usuario falsas, y debido a que la gente en la cara del carbón la entrega de las características:

1. No sabe cómo desarrollar la función (porque las historias de usuario no se lo dicen realmente).
2. No sé para qué sirve la función (porque la historia es falsa)

Enhorabuena, te la has jugado.

Lo que hay que hacer:

• Podrías ser más realista, preguntando a los usuarios reales para qué quieren utilizar tu sitio web. Si preguntas a personas reales, puede que empiecen a hablarte de cosas que creen que podrían querer, en lugar de cosas que necesitan, así que aún mejor, podrías observar a usuarios reales utilizando una herramienta como HotJar o Full Story, o realizar una prueba de usuario real centrada en tareas.
  
  
• Recomiendo echar un vistazo al framework Jobs To Be Done . Jobs To be Done es bastante interesante. No está diseñado como un reemplazo de Historias de Usuario, pero tiene algunas cosas que decir acerca de Personas. Se supone que un usuario tiene un trabajo que hacer, y considera cómo su producto facilitará ese trabajo. Si pensamos en el trabajo de asistir a un espectáculo, y luego considerar todas las cosas que nuestro usuario tiene que hacer con el fin de hacer ese trabajo, nos dará pistas sobre las principales tareas de nuestro sitio web debe facilitar, desde la investigación de los espectáculos y los tiempos, a introducir sus datos de tarjeta de crédito, para obtener indicaciones para llegar al lugar. El por qué está integrado en la tarea a realizar, el cómo es cosa tuya. Puede que te resulte útil ver tu producto desde esa perspectiva, en paralelo a tus historias de usuario. Al fin y al cabo, cuando piensas en las tareas que tienes que hacer, no importa mucho si eres un Libra divorciado o no.

Trampa nº 10 Construcción de un monumento
Trampa nº 9 Cobertura 100% digital
Trampa nº 8 Divide y vencerás
Trampa nº 7 Diseñar para el smartphone de su CEO
Trampa nº 6 Falsos profetas
Trampa nº 5 Fetichismo por los post-it
Trampa nº 4 Construir en lugar de comprar
Trampa #3 Comprar no Bodging
Trampa nº 2 Historias de usuario falsas
Trampa nº 1 A contracorriente