Antes de construir un sitio web, dibújalo

Posteado March 29, 2008 a 9:22 am por ansueta

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 programar o a diseñar un sitio web puede resultarte de gran ayuda. No hace falta que utilices lápiz y papel, claro. Hay otras maneras. Te sugerimos que aproveches las diferentes herramientas y 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 exponer y “discutir” el proyecto hasta conocer mejor la visión de tu cliente.

Recuerda que es en ese estadio inicial cuando más sencillo y menos traumático resulta introducir cambios.

Herramientas

Axure y Visio se han consolidado como aplicaciones estándar. Con ellas podrás dar forma a tus ideas de manera rápida y más o menos sencilla, según el nivel de complejidad que necesites. También existen otras alternativas en el mercado, como Smartdraw o Jumpchart.

Pero antes de que empieces a utilizar las herramientas es aconsejable que conozcas algunos conceptos fundamentales. A continuación te mostramos algunos de los recursos de diagramación más destacados:

Mapas mentales

Partiendo de un concepto o idea clave, los mapas mentales nos permiten crear una red de ideas, palabras, tareas y otros elementos asociados. Son muy útiles para visualizar, estructurar y clasificar ideas, y han sido utilizados durante años por educadores, ingenieros y psicólogos para solucionar problemas, en sesiones de brainstorming, para escribir y para tomar decisiones. Los mapas de ideas también pueden ayudarnos a tomar notas, a generar nuevas ideas a través de asociaciones, a recordar las cosas y a repasar la información de manera rápida.

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.

Wireframes o “maquetas”

Un wireframe es una representación esquemática de una página web. No muestra elementos gráficos definitivos, 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: OTROS RECURSOS 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 en la mayor parte de los casos 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]

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 “quiénes somos, “qué hacemos” y “dónde estamos”, y el usuario debe incluir cada tema en una de esas 3 categorías.

Publicado en: Aplicaciones Web, General