No importa si eres un consultor IT, un analista de negocio o un diseñador web. “Dibujar” lo que tienes en la cabeza antes de lanzarte a redactar, a programar o a diseñar puede resultarte de gran ayuda. No hace falta que utilices lápiz y papel, claro. Hay otras maneras. Te sugerimos que aproveches los diferentes recursos de diagramación para abordar el proyecto con una visión más amplia y certera. Estos recursos te permitirán:

1. Asegurarte de que el planteamiento de partida tiene bases sólidas.
2. Te darán la oportunidad de “discutir” el proyecto hasta conocer mejor la visión de tu cliente.

Al fin y al cabo, es en ese estadio inicial cuando más sencillo y menos traumático resulta introducir cambios.

Te proponemos las siguientes herramientas:

Diagramas de flujo: Son esquemas que representan la estructura y el flujo de navegación de un sitio web o de una aplicación. Algo así como un “plano” en el que se muestran las conexiones y la interacción entre las diferentes partes de un sistema. El aspecto de los elementos es lo de menos mientras pueda comprenderse el flujo. Esta visión esquemática y de conjunto te permitirá sacar a la luz bastantes nudos y contradicciones que hasta el momento habían pasado inadvertidos.

Wireframe o “maqueta”. Un wireframe es una representación esquemática de una página web. No muestra elementos gráficos, porque lo importante es establecer el contenido y el comportamiento de las diferentes páginas.

El wireframe puede ser más o menos detallado: se considera de baja fidelidad cuando se limita a representar aspectos generales, y de alta fidelidad cuando alcanza un gran nivel de detalle, por ejemplo, en el caso de una maqueta dinámica que permite, incluso, interactuar al usuario.

Tanto lo diagramas de flujo como las maquetas nos proporcionan una excelente oportunidad para “discutir” el proyecto con el resto del equipo y, por supuesto, con el cliente antes de empezar a programar y diseñar, de forma que los malentendidos y los cambios y modificaciones no resulten demoledores. En ambos casos, el aspecto de los diagramas es absolutamente secundario. De hecho, introducir elementos de diseño en esta fase suele consistir un grave error: el cliente enseguida centrará la discusión en las formas y colores, dejando de lado otros temas fundamentales.

Wireframe vs prototipo. Ojo. Un wireframe no debe confundirse con un prototipo. Hay una diferencia fundamental entre ambos: los prototipos se construyen para funcionar -aunque no cuenten con una funcionalidad completa- mientras que los wireframes o maquetas tienen como principal objetivo representar el sistema, y no tanto actuar. Como ya hemos comentado, podríamos realizar un wireframe de baja fidelidad con lápiz y papel, y sería perfectamente válido siempre que resulte comprensible.

EL PUNTO DE VISTA DEL USUARIO: OTRAS HERRAMIENTAS INTERESANTES

Especificaciones. Las especificaciones constituyen un sistema muy extendido para documentar, comunicar y conseguir un acuerdo con el cliente sobre el diseño de la aplicación. El problema es que, en el mundo del desarrollo web -convertido muchas veces en una carrera enloquecida- el exceso de documentación y una recogida de requisitos excesivamente reglada pueden eternizar el desarrollo de un proyecto. Y lo que nosotros buscamos es un desarrollo ágil. Por eso, dentro de la metodología ágil SCRUM han surgido herramientas alternativas a las especificaciones tradicionales. Una de las más consolidadas son las historias de usuario.

User stories/Historias de usuario. Una historia de usuario es una forma de recoger los requisitos de un proyecto en tan sólo un par de frases. Esas frases se anotan en una pequeña cartulina o tarjeta para garantizar que los requisitos no crecen hasta hacerse inabarcables, y se formulan en un lenguaje corriente, para que tanto el equipo como el cliente pueda entenderlas a la perfección. El objetivo es capturar de forma rápida y efectiva los requisitos reales del cliente, sin perderse en montañas de documentación y procesos formales. De esta forma, en un entorno de cambio constante, los cambios pueden ser absorbidos sin que el proyecto se desplome.

Las historias de usuario se llaman así precisamente porque recogen el punto de vista del usuario. En su blog, Kelly Waters nos propone el siguiente sistema: Una historia de usuario debe centrarse en el QUIÉN, el QUÉ, y el POR QUÉ, no en el CÓMO. Por ejemplo, en un sitio web de empleo, dos de las historias de usuario serían:

• Como persona en busca de trabajo, quiero buscar un empleo para progresar profesionalmente.
• Como seleccionador de personal, quiero publicar una oferta de trabajo para encontrar a un nuevo miembro del equipo.

La estructura sería:
Como [rol de usuario], quiero [objetivo], de forma que pueda [motivación]

La importancia de la última parte -la que corresponde al POR QUÉ- no está tan acreditada, pero también es cierto que conocer la motivación del usuario puede darnos buenas pistas sobre sus necesidades.

Card sorting. Esta técnica de tarjetas resulta útil cuando se quiere construir una estructura de contenidos basándose en el punto de vista del usuario. Consiste en observar y analizar la forma en que los usuarios agrupan y asocian unas tarjetas etiquetadas con diferentes temas. Siguiendo el comportamiento y el orden de los usuarios se puede organizar la información del sitio web. Hay dos tipos de card sorting:

• Abierto. Los usuarios pueden agrupar las diferentes categorías temáticas con total libertad, haciendo tantos grupos como crean necesario.
• Cerrado. Se establece un número limitado de conjuntos, de forma que el usuario debe ubicar cada tema en uno de esos grupos. Por ejemplo, se establecen desde el principio los grupos “qué hacemos” “quiénes somos” “cómo lo hacemos” y el usuario debe incluir cada tema en una de esas 3 categorías.

Esta entrada fue publicada el Wednesday, 26 de March de 2008 a las 8:14 y está clasificada bajo: General, PYMEs, Ágil. Puede hacer un seguimiento de los comentarios de esta entrada gracias al feed RSS 2.0. Puede dejar un comentario, o enviar un trackback desde su sitio.