El esquema que mucha gente tiene en la cabeza a la hora hacer el prototipo para un proceso es casi siempre el mismo: para que el usuario haga tal o cual cosa es necesario que complete estas tres pantallas A, B y C.
El equipo de diseño se lanza a realizar esas tres pantallas y el equipo de programación después programa esas tres pantallas. ¡Hey Presto! Voilà ya está hecho.
Las previsiones de tiempo y esfuerzo se calculan pensando que, al fin y al cabo, son sólo 3 pantallas.
Pero este tipo de planteamientos son ingenuos y superficiales. La complejidad de una web y la gran variedad de comportamientos del usuario hace que, en cada pantalla, sea fácil que se produzcan dos o más acciones de usuario fuera del camino habitual.
Ejemplos típicos son cuando el usuario está rellenando un formulario e introduce campos erróneos o incoherentes, intenta hacer una acción para la que no está autorizado, quiere hacer cambios a información ya introducida, quiere hacer una acción para la que necesita estar registrado, repite una acción que ya ha realizado, pincha el botón de atrás, etc.
Este tipo de acciones, absolutamente normales y habituales en cualquier proceso, sorprendentemente no se suelen tener en cuenta en el proceso de diseño y se solucionan sólo a posteriori, con ventanas emergentes dando alertas o, peor, con errores de página o los odiosos mensajes de "la página ha caducado". Rara vez he visto una presentación de prototipos web dónde se muestre, junto con el proceso habitual, las pantallas de los caminos inesperados.
Hay que ser conscientes que diseñar el camino habitual del proceso es sólo una parte del trabajo. La parte fácil, bonita, esperada, vistosa. Pero diseñar un proceso robusto y sólido requiere 5 veces más esfuerzo y es más complicado y difícil.
Si para el más simple de los procesos, digamos 3 pantallas, consideras que puede haber dos errores en cada paso, y para cada error das una pantalla de solución del error, de repente no tienes que diseñar y programar 3 pantallas, sino 15.
El trabajo de diseño no está realizado cuando se presentan las 3 pantallas del proceso. Eso es sólo la punta del iceberg. El trabajo profesional es cuando se muestra el proceso completo diseñado, de comienzo a fin, incluyendo los errores y sus soluciones.
En el fondo es cambiar la mentalidad con la que miras la página.
Es curioso como cuando haces pruebas con el equipo de programación la actitud es:
"¿a ver si esto funciona?"
Pero la actitud correcta con la que se debe mirar la página, antes de subirla es:
"¿a ver donde falla esto, a ver qué pasa si pincho en cada enlace, a ver cómo puedo hacer que esta página falle?"
Vaya, me ha encantado. Pienso igual y es raro, incluso "a estas alturas", encontrarse con trabajos (prototipos, maquetas, desarrollos) que incluyan todos los caminos.
Gracias por dejarlo tan bien escrito :)
Publicado por: alberto romero | martes, agosto 15, 2006 en 19:18
Al final, lo que provoca no contemplar los caminos alternativos es que se produzcan varias iteraciones sobre una misma pantalla, con la consiguiente pérdida de tiempo, o que tomemos decisiones los programadores (que somos los que nos enfrentamos a esta falta de previsión) cuando en realidad no nos corresponde a nosotros (no por no hacerlo, sino que hay otros perfiles mejor preparados y que lo harán mejor).
En fin, como siempre supongo que es cuestión de llegar a un equilibrio entre lo fidedignos que han de llegar a ser los prototipos y que no se puede perder mucho tiempo en ellos y que hay que dárselos enseguida a los diseñadores.
Publicado por: Fernando | martes, agosto 15, 2006 en 22:20
Sentido común al diseñar y al programar, recordar las experiencias anteriores (y si no hay pues preguntar por ellas) y sobre todo hablar, hablar y hablar.
Los compartimentos estancos eran lo que iba a salvar al Titanic del hundimiento y ahí anda.
Publicado por: marcos | miércoles, agosto 16, 2006 en 00:30
Esa es la diferencia de tener solo "programadores" y no analistas o Analistas/Programadores, o alguien con experiencia en desarrollo de software. Los programadores "descubren" el iceberg con la experiencia (con la pErdida de tiempo que implica), los analistas/programadores conocen el tamaño de antemano o lo advierten a la distancia.
Aunque en desarrollo web (y mas en estos tiempos) la velocidad de desarrollo es muy importante, no hay que olvidar que casi todo esta estudiado en ingeniería de software: no es necesario re-descubrir los problemas. Y, creo, es posible combinar la velocidad/rapidez de desarrollo con un software escalable y funcional.
Este es mi primer comentario en tu blog. Aprovecho para felicitarte. Es muy interesante.
Publicado por: Juan | miércoles, agosto 16, 2006 en 12:41
Los errores se ven como algo necesario pero no importante, aunque sean tan importantes como las pantallas principales.
En el esquema mental de mucha gente se da poca importancia a los errores, les parece que los errores hacen que una interfaz parezca complicada o que está mal programada. Se prefiere ver que todo está bonito (bonito como lo entiende cada uno), que todo funciona (que no haya errores ni los previstos ni los no previstos).
Hay veces que para una correcta gestión de los errores se debe modificar la pantalla principal. Esto hace que los errores sean tan importantes como las pantallas de las que provienen, además de que su corrección asegura una correcta experiencia del usuario.
Ahora se está tomando conciencia de que es importante una buena experiencia por parte del usuario, hasta ahora se entendía que un diseño gráfico atractivo y unos controles efectistas era casi suficiente. Aún así los errores o los supuestos rocambolescos se ven como algo secundario, cuando es algo de primer orden.
Publicado por: Boca Dorada | miércoles, agosto 16, 2006 en 13:19
Estupendo post: poco que añadir, tan sólo recomendar el libro "Defensive Design for the Web" si alguien está interesado en leer sobre este tema. Es un libro muy ligero y muy barato (el formato es pelín cutre) en el que he encontrado algunas ideas muy útiles.
Publicado por: Raúl | viernes, agosto 18, 2006 en 17:35
Hola, Jesús
Desgraciadamente la filosofía predominante en el desarrollo de software actualmente es el "cheap & dirty".
Aunque la ingeniería del software no es aún demasiado madura sí que hay mucho conocimiento acumulado y útil, aunque se utiliza poco.
Una técnica muy interesante para plantear la funcionalidad y tratarla junto a los usuarios y cliente son los casos de uso. En donde además de definir un caso de uso se defininen también variaciones al escenario o camino principal y posibles excepciones que puedan aparecer.
http://en.wikipedia.org/wiki/Use_case
(mucho más completa que la versión española)
idealista.com me ha sido muy útil infinidad de veces, gracias!
Publicado por: José Cortés | viernes, febrero 02, 2007 en 19:14