Prototipos de papel para análisis de requisitos y usabilidad ágiles
05.01.2008
Cuando el cliente no termina de tener claros algunos puntos o cuando la usabilidad es un valor clave del sistema, el prototipado en papel es una excelente técnica de trabajo; y como estos son factores habituales en los proyectos ágiles, es muy útil disponer en el inventario de recursos esta forma de prototipado ligero para echar mano de ella cuando se necesite.
¿En qué consiste?
Una imagen vale más que mil palabras:
Para el propietario del producto, y para las reuniones con el equipo, este tipo de recortables informales dan información de detalle muy valiosa. Para realizar pruebas de usabilidad con grupos de pruebas es aconsejable emplear plantillas impresas con mejor factura y de diseño más próximo a la realidad, como se ve en este vídeo que presenta un caso real de pruebas de usabilidad realizadas con prototipos de papel en el el laboratorio de Corel para analizar en un sistema para el desarrollo de sitios web, las ventajas e inconvenientes de uso con los usuarios de un planteamiento tipo "wizard" y de uno tipo "plantilla", así como los posibles problemas que puede producir la terminología; y tener esta información antes de programar una sola línea.
Algunos consejos:
Cuando se usa la técnica para determinar con el equipo los requisitos finales, resulta muy cómodo con una cámara digital adjuntar las imágenes a las historias de usuario, o al wiki o sistema de documentación que se emplee.
Si se emplea en pruebas de usabilidad con plantillas impresas de diseño más elaborado, la plantilla base puede estar impresa en un acetato blanco, a modo de pizarra de soporte, y aplicar sobre el dorso de los recortables empleados un poco de pegamento en spray. El uso de una camara web para grabar las reacciones y comentarios de los usuarios pemite analizar los resultados con más detalle y tratarlos en el equipo.
Coste mínimo! ... escrito por Rommel Anatoli Quintanilla Cruz,
January 05, 2008
Gracias por hacer conocer la existencia de esta idea!! ... por más simple que es .. seguro que nos ahorra tiempo en hacer líneas de codigo antes de saber la reacción del usuario frente al software ... .. felicitaciones por el blog ...
La técnica sin duda es excelente para reducir o acotar al máximo las confusiones que puedan existir en las especificaciones funcionales. Pero estamos en el 2008, creo que ya existen varias herramientas como para evitar mostrar papelitos al cliente.
Salu2
Informar de comentario inadecuado
voto negativo
voto positivo
Votes: +0
Pero a veces lo simple es mejor escrito por Juan,
January 06, 2008
Algunas veces la herramienta más sencilla es la más adecuada, y sin embargo por dar empaque se crean complicaciones innecesarias, llegando a ser el peso del entorno y las herramientas más una zancadilla que una ayuda.
Para trabajar en equipo (que no tanto en grupo de trabajo) de forma ágil y en un número reducido puede ser más recomendable una pizarra con post-it's y comunicación verbal directa, que una intranet de comunicación colaborativa.
Ahora tienes toda la razón, para trabajar en equipo puede estar bien, pero para enseñar a clientes en salas de reuniones, quizá un pelín cutre la modalidad de líneas torcidas con rotulador.
Un saludo.
Informar de comentario inadecuado
voto negativo
voto positivo
Votes: +0
No sé, no sé escrito por JRubira,
January 06, 2008
Uff. No sé. No sé. Para desarrollo agil ... con el tiempo que tardo en escribirlo en papel, se hace lo mismo diseñandolo directamente en la aplicación (aunque solo sean las ventanas sin funcionar), y así no trabajas dos veces. Por otra parte, el mayor problema no está en que campos llevará la aplicación, (añadir y quitar campos puede ser relativamente facil si la arquitectura es simple) sino en como se aplican las formulas que hay por debajo (dtos, comisiones, lo que lleva iva y lo que no, o lo que sea) Si es una arquitectura compleja donde intervienen muchas personas en el desarrollo es mejor hacer un analisis donde si pueden llevan las ventanas pero de una manera más legible. :- Bueno, para gustos los colores.
Les tiro algunas ventajas que tiene el prototipo en papel sobre el realizado en la computadora: - Es mas rápido y economico de realizar - Se puede modificar adelante del cliente - Cualquier persona que sepa escribir sabe realizar un prototipo, sin necesidad de conocer una determinada herramienta. - Evita falsas espectativas al cliente cuando ve las pantallas en la computadora, pensando que ya tenemos el sistema listo. - Muchas veces el cliente cuando ve un prototipo en la computadora piensa que ya está listo y no opina sobre las modificaciones que abria que hacerle... cosa que en papel fomenta la participación del cliente.
Informar de comentario inadecuado
voto negativo
voto positivo
Votes: +0
Papel o electrónico, pero que sea prototipo escrito por Jorge Uriarte,
January 09, 2008
El primer enfoque puede resultar demasiado 'abstracto' para requisitos, algún cliente me ha dicho despues de una reunión de prototipado en pizarra que 'como el trabajo lo han hecho ellos, no me pagan esas horas' (!)
Personalmente creo (a diferencia del comentario de JRubira), que el prototipo cuesta muy poco (mucho menos que las pantallas, no importa el lenguaje), y que con la herramienta adecuada, sirve para varios propósitos: - Efectivamente, cierra los requisitos del cliente (y sirve al cliente para descubrir lo que 'no quiere' porque se pueden hacer demos muy facilmente) - Sirve de referencia para el desarrollo. - Anticipa problemas de usabilidad (e incluso funcionales)
Pero es muy importante que el usuario no crea que el prototipo es un entregable final por varios motivos: - Pensará que el desarrollo está más avanzado de lo que está. No importa cuánto insistas, si ve una ventana con todos los colorines, pensará que 'ya está casi' aunque no haya ni una linea de código para soportarla. - Lleva mucho tiempo completar un prototipo, aunque sea sólo estéticamente. No lo intentes, quédate en un wireframe. - Puedes atraparte en una estética que resulte en problemas funcionales más tarde, y te obligará a renegociar.