Inicio arrow Artículos - apuntes arrow Prototipos de papel para análisis de requisitos y usabilidad ágiles Make Text BiggerMake Text SmallerReset Text Size
Prototipos de papel para análisis de requisitos y usabilidad ágiles E-mail
05.01.2008

barquitoCuando 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.

Más información:

Comentarios (7)Add Comment
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 ... smilies/grin.gif .. felicitaciones por el blog ... smilies/wink.gif
Informar de comentario inadecuado
voto negativo
voto positivo
Votes: +0
Prototipos
escrito por Carlos Astudillo, January 06, 2008
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. smilies/tongue.gif

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.
Informar de comentario inadecuado
voto negativo
voto positivo
Votes: +0
Ventajas
escrito por Diego, January 07, 2008
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.

Hice una pequeña recopilación de herramientas hace unos meses, yo uso el stencil Visio de guuui.com, pero podéis verla aquí:
http://blog.omelas.net/2006/07...yping.html
Informar de comentario inadecuado
voto negativo
voto positivo
Votes: +0
¿Prototipo o Maqueta?
escrito por Lin Fan, February 22, 2008
Porqué le llaman prototipo a algo que no funciona.

¿Te imaginas el prototipo de un auto y que no ande?

Mientras que de la maqueta, si me lo imagino.

¡Usemos los términos propiadamente!
Informar de comentario inadecuado
voto negativo
voto positivo
Votes: +0

Escribir comentario
quote
bold
italicize
underline
strike
url
image
quote
quote
smile
wink
laugh
grin
angry
sad
shocked
cool
tongue
kiss
cry
reducir | aumentar

busy
 
< Anterior   Siguiente >

En Navegapolis
En Internet

ScrumManager

Advertisement

Área de descargas

Artículos relacionados