Cómo prototipar rápido y barato
¿Qué debe conseguir el testing para considerar un prototipo de baja fidelidad?
Para que un paper prototyping sea considerado un prototipo de baja fidelidad debe hacer que el testing consiga:
- Obtener feedback de los usuarios: es mejor que te reporte un error alguien que sabe que está probando una versión beta, que alguien que está probando una versión final, que incluso quizás haya pagado por ella. Además, los usuarios pueden hacer entrar nuevas ideas al producto. Quizás estás incluyendo algo que pensabas que gustaría y al final resulta todo lo contrario o quizás alguien te dice algo en lo que no habías caído.
- Ahorrar tiempo: aunque parezca contradictorio, para ganar tiempo. Debe ser rápido.
- Permitir detectar errores: debe permitir saber qué es lo que está mal para poder arreglarlo, lo que permite ganar tiempo.
A su vez, el paper prototyping debe hacer que el usuario que está probando el artefacto, entienda cómo funciona. Sin embargo, no todo el mundo tiene una gran imaginación que es lo que hace falta para hacerse una idea de lo que muestran unos prototipos en papel, por lo que el feeedback que nos devuelvan no será el más adecuado. Hay usuarios que requieren un mayor nivel de fidelidad del prototipo, por lo que, si debe hacerse un prototipo más elaborado, el paper prototyping dejará de ser un prototipo de baja fidelidad
Hay quien afirma que el hecho de que hay usuarios que se comportan de forma distinta delante de paper prototyping, no tiene ninguna ninguna base.
Los prototipos de papel son tan efectivos como los prototipos de alta fidelidad para detectar muchos tipos de problemas de usabilidad.
Otro aspecto que nos permite considerar un paper prototyping como un prototipo de baja fidelidad es el hecho de que se utilice en las primeras iteraciones del proceso de diseño para ayudar a elaborar y explorar una primera idea de lo que se quiere desarrollar y obtener un feedback rápido, ya que obliga a estar en contacto directo con los usuarios con los que realizaremos los posteriores test. La creación de prototipos de papel se trata pues de diseño iterativo -creando cosas que puedes probar rápidamente y luego descartar o mejorar-.
Pero solo porque está en papel, no significa que sea un prototipo de baja fidelidad.
Características para ser un prototipo de baja fidelidad
Las características del paper prototyping que lo convierten en un buen prototipo de baja fidelidad son:
- Es un boceto, una visualización rápida y sencilla de una idea. El mérito artístico de su boceto es irrelevante. El propósito del prototipado en papel es evaluar la idea detrás de la interfaz de usuario, no el boceto en sí. Los prototipos de papel son literalmente ‘artless’. No se puede negar que los prototipos de papel carecen de belleza, pero esto es diferente a decir que el prototipo de papel no es profesional. Este enfoque de «ordenado y bonito» puede ser uno de los mayores obstáculos para hacer que el paper prototyping sea un prototipo de baja fidelidad
- No incluye las funcionalidades del producto, por lo que no nos permitirá obtener el feedback de las mismas
- Sólo sirve para ayudar a encontrar los principales problemas, sin entrar en los puntos de fricción en la experiencia de usuario, como el rechazo instantáneo u otro tipo de reacciones viscerales del mismo. Esto precisaría prototipos de muy alta fidelidad
- No permite muchas iteraciones ni obtener reacciones intuitivas por parte del usuario, por lo que solo obtendremos el feedback de lo que ve el usuario
- Permite realzar cambios sobre el propio prototipo rápidamente, ya sea borrando el lápiz o modificando la estructura.
- Es barato porque cuesta menos tiempo de diseñar y es más fácil desecharlo, si no es válido
- Tiene una curva de aprendizaje menor, ya que colocar patrones sobre una estructura o dibujarlos sobre papel se aprende en poco tiempo.
- No hace falta documentarlo
¿Qué debe hacer para ser considerado un prototipo de baja fidelidad?
En resumen, para que un paper prototyping sea considerado un prototipo de baja fidelidad, debe:
- Dar lugar a un testing efectivo
- No tratar la experiencia de usuario
- Hacer que el usuario lo entienda
- Usarse en fases tempranas
- Ser sencillo
- No contener funcionalidades
- Permitir realizar cambios rápidamente
- Tener una curva de aprendizaje menor
- No ser necesario documentarlo
- Ser un bocento
- No tener un enfoque ordenado y bonito
- Ser diseño iterativo
- No permitir muchas iteraciones