En respuesta a este asunto, desde mi experiencia, y cuando teníamos un
proyecto de verdadera magnitud, antes de preparar una propuesta comercial se
preparaban dos o tres diseños (bocetos de diseño) y organización de los
posibles contenidos, haciendo especial hincapié al cliente de que éstos eran
una mera ilustración, algo para que él (que normalmente no tenía ni idea y no
se preocupaba ni siquiera de leer la propuesta) supiera por dónde iban los
tiros.
Una vez que esta propuesta estaba aprobada (con todas las áreas definidas en
cuanto a contenido) comenzaba el trabajo "duro".
Como arquitecto de información, definía en un documento TODAS las
especificaciones y casos de uso de todas las áreas. Desde las partes que
componían el menú y sus relaciones, hasta la definición de los sistemas de
búsqueda, cómo quería que fueran los CMS, qué pasaba cuando se mostraba un
resultado, cuando se daba de alta un usuario, etc. En este documento se
explicaba con pelos y señales toda la estructuración del site, un documento
tremendamente válido tanto para diseñadores como programadores y proveedores de
contenidos.
A partir de ese documento, comenzaba el diseño "visual" de la arquitectura de
información con cualquier programa en el que todo quedara lo suficientemente
claro (se desarrollaban cuatro o cinco plantillas ya que el resto mantendrían
el diseño estructural habitual).
Evidentemente, todos estos "diseños estructurales de arquitectura de
información" no salían de la nada y no se empezaba a trabajar directamente en
un powerpoint, en un openoffice draw o en un visio sino que TODO quedaba
cuadrado en papel, con el fin de que, poco a poco y "en sucio" se fuera
perfilando tal arquitectura.
Soy de los que, una vez tengamos el visto bueno de la "línea de diseño que
hay que seguir", es partidario de presentar en las reuniones de seguimiento con
el cliente, documentos físicos bien estructurados con su correspondiente
arquitectura de información (es más elegante y las modificaicones que el
cliente aporte se pueden ir anotando y planteando posteriormente su viabilidad
o no).
Todo este proceso no es de un día para otro (ese es el caballo de batalla que
he tenido)... porque tanto el cliente como nuestros jefes piensan que el
proceso es:
-> aprobación de propuesta -> realización de web y se olvidan que, entre esas
dos acciones existe tooooooooda una retahíla de documentos, casos de usos,
diseños de arquitectura de información, consultoría, etc.
Message: 1
Date: Tue, 9 May 2006 09:01:49 -0700 (PDT)
From: Enric Naval
Subject: Re: [cadius] Prototipación en papel
To: Lista de Cadius
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=iso-8859-1
hola, este es un mensaje algo viejo, pero como nadie lo ha contestado y
yo llevo retraso de leer mensajes.....
yo sólo he empleado prototipos de papel a la hora de que el cliente me
explicase directamente cómo hacer una determinada página. Esto es para
entrevistas directas donde el cliente no tiene clara la interfaz o yo
no entiendo la explicación.
Normalmente, a media entrevista, cojo una hoja en blanco y un boli que
previamente he preparado y empiezo a dibujar un boceto muy básico sobre
dónde quedarian los elementos. Mientras dibujo, voy diciendo, al pulsar
AQUI, pasa X, y al pulsar alli, pasa Y. También divido la hoja en
varias pantallas, y dibujo flechas del boton de una pantalla a la
pantalla de destino.
En ese proyecto, hay tres responsables, y responden de maneras
diferentes, pero lo más normal es que una vez hcho el diseño básico, me
pidan el papel y se dibujen ellos mismos la interfaz al otro lado de la
misma hoja o hagan las correcciones adecuadas.
Yo voy pidiendo alaraciones mientras dibujan, y permito que me vayan
corrigiendo lo que entiendo mal. Hay que decir que el proceso me ayuda
tanto a entender yo mejor lo que el cliente quiere como a que el
cliente entienda lo que el mismo quiere. Tambien dibujo bocetos sobre
lo que NO se puede hacer (como cierto botón no cabe en la pantalla, o
es demasiado visible).
Si el diseño se ha hecho sobre las tareas que ha de hacer el usuario,
no suelo encontrar la necesidad de montar un prototipo de papel más
currado y hacer pruebas, sino que paso directamente a implementar la
página. Una vez hecha, pueden necesitarse cambios, pero la estructura
básica suele ser correcta.
Por cierto, una ventaja de que el dibujo lo hayan hecho ellos mismos es
que después esa hoja se puede tomar como parte de los requerimientos.
Si el usuario se queja, se le puede señalar la hoja que ellos mismos
dibujaron, e incluso pedirle que la modifique o dibujar una nueva
versión a partir de la vieja, rectificando los problemas encontrados.
Otra posibilidad, cuando el prototipo nunca va a pasar por la fase de
papel:
Cuando el diseño me llega bien "desde arriba", o bien desde una persona
que asume que su diseño será el diseño definitivo sin ningún cambio ni
negociación, me suele llegar un diseño hecho por software, bien una
página HTML o un dibujo del diseño final.
A veces los requerimientos son tan claros que me dan el HTML ya hecho y
solo hace falta implementar el código que mueve las cosas por debajo.
Aún así siempre quedan partes sin especificar, y allí puedes hacer
propuestas y usar papel.
Bueno, esta es mi experiencia más o menos. En resumen: los prototipos
de papel se utilizan para diseños que se van a negociar, porque el
papel es un entorno donde es fácil colaborar. Si el diseño te llega ya
hecho en software, entonces no hay prototipo de papel que valga porque
ese diseño es exactamente como lo quieren :)
---------------------------------
LLama Gratis a cualquier PC del Mundo.
Llamadas a fijos y móviles desde 1 céntimo por minuto.
http://es.voice.yahoo.com
_______________________________________________
altas, bajas y modificaciones:
http://www.cadius.org/lista/opciones.html
