03 Arquitectura de información

03.01 ¿Qué es arquitectura de información?

Si la idea de crear “estructuras” en “información” es un concepto completamente foráneo para ti, esta liga puede ayudarte: Entendiendo Arquitectura de Información

Arquitectura de información (AI) puede ser muy simple en un proyecto pequeño e increíblemente compleja en proyectos más grandes. AI es invisible, para trabajar con ella necesitamos dibujar un mapa de sitio. Aquí un ejemplo:

Este ejemplo muestra un sitio con 6 páginas. Una página de inicio, dos secciones en el menú principal y 3 sub secciones. Las líneas indican qué páginas están conectadas por navegación (menús y botones).

Nota: Un millón de usuarios no equivalen a un millón de páginas de perfil. Tienes una página de perfil que despliega la información de cualquier usuario.

Cuando las páginas se organizan de esta manera, como un árbol genealógico, se llama “diagrama de jerarquía” o “diagrama de árbol”. La mayoría de sitios y apps se organizan de esta manera (aunque no es la única).

No hay reglas para dibujar mapas de sitio, pero si algunas sugerencias generales:

• No porque sea simple quiere decir que hace sentido
• Mantenlo limpio y usable
• Dibujamos de arriba hacia abajo, no de izquierda a derecha
• No hagas un documento “bonito”. Es un documento técnico, no un desfile de modas.

Largo o ancho. No ambos.

Generalmente tu mapa será “ancho” (flat) que incluye más secciones en el menú y menos contenidos dentro o tu mapa será “largo” (deep), con menos menús pero más contenidos dentro de cada uno.

Nota como las estructuras ilustradas son la misma cantidad de páginas pero acomodadas de diferente manera.

Sitios con muchos productos, como el sitio de Wal-Mart, generalmente tienen una arquitectura “larga” o los menús serían absurdos. Páginas como YouTube que solo lidia con videos generalmente son más “anchos”. Si tu sitio es largo y ancho, eso es malo. Necesitas simplificar tus objetivos o diseñar una buena búsqueda como una funcionalidad base.

Mito: A veces la gente dice que todo tiene que estar “a 3 clics de distancia”. Eso probablemente es porque aprendieron de UX en los 90’s y no han aprendido nada nuevo desde entonces. Enfócate en el usuario, asegúrate que sepan dónde están y a dónde pueden ir, todo el tiempo. Si tu navegación es fácil de entender, el número de clics es irrelevante.

03.02 Historias de Usuario y Tipos de Arquitectura de Información

Una “historia de usuario” (flujo de navegación) describe un flujo posible que un usuario podría tomar en tu sitio o aplicación. Debe ser breve, pero completo. Necesitas muchas historias (o flujos) para describir tu diseño completo.

Un flujo para Google.com puede verse así:

• El usuario llega a la página principal de búsqueda.
• El usuario puede hacer cualquier búsqueda y enviarla con su teclado o mouse.
• La siguiente página muestra la lista de resultados, con los más relevantes hasta arriba.
• El usuario puede hacer clic para ir al sitio que desee, o puede navegar más páginas de resultados hasta encontrar algo que considere útil.

Obviamente este flujo está simplificado, pero esa es la idea.

Nada en la historia dice específicamente como resolver algo con diseño, solo que es posible. El propósito de la historia es describir flujos, secuencias de opciones, no la interfaz final.

Si el flujo es simple y efectivo, estás haciendo un buen trabajo (hasta ahora)

Los jefes a veces piensan que las historias de los usuarios son una manera de solicitar UX a un diseñador, pero eso es absolutamente equivocado ¿Por qué? Porque una historia es básicamente una lista de funciones y eso tiene un efecto dramático en el diseño de la solución final. El diseñador de UX escribe las historias para comunicárselas a su equipo, no al revés. Es cómo decirle a Bob Ross qué colores utilizar.

Entonces, ahora que sabes escribir historias, necesitamos volver a la Arquitectura de Información. La estructura en tu página determina el número de pasos en la historia del usuario. Y para estructurar tus páginas necesitas escoger algún tipo de arquitectura con cual trabajar (o varias, pero mantengamos esto simple).

Tipos de arquitecturas incluyen:

• Categorías
• Tareas
• Búsqueda
• Tiempo
• Gente

Va la descripción de cada una:

Categorías:

Cuando piensas en una tienda como H&M seguramente te imaginas su menú como una lista de categorías (hombres, mujeres, niños, ofertas, etc.). Tipos de contenido. Cuando haces clic en cada categoría esperas ver contenido que aplique a esa categoría.

Este es el tipo de Arquitectura de Información más común. Sin embargo, en industrias como banca o químicos o juguetes para adultos (me han contado) las categorías pueden ser más complejas, entonces tus usuarios pueden no tener una idea clara de que esperar ver dentro de cada categoría. Si quieres comprar un juguete sexual ¿Esperas encontrarlo en la categoría de “opera con baterías” o “brilla en la oscuridad”? La vida es difícil a veces.

Tareas:

Otra manera de organizar tu aplicación o sitio es según los objetivos que el usuario quiere cumplir. Si eres un banco, seguramente una estructura como “Ahorra, Préstamos, Inversiones, Ayuda, Abrir una cuenta” puede hacer un menú más simple. Si el usuario sabe lo que quiere, esta es una excelente manera de estructurar el diseño. Pero ten cuidado, los usuarios no siempre saben lo suficiente como para escoger su propia aventura.

Piénsalo, un sitio estructurado en categorías y otro en tareas pueden ser muy diferentes. Es una decisión importante.

Búsqueda:

Si tu sitio es muy complejo, o si está lleno de contenido generado por usuarios, una arquitectura basada en búsqueda puede ser útil, cómo en YouTube. Si YouTube tuviera categorías sería muy difícil de usar y costaría mucho trabajo mantener esas categorías correctamente.

Tiempo:

Si estás comenzando en UX, esto puede sonar un poco raro. Puedes diseñar una Arquitectura de Información que cambie con el tiempo. La versión más sencilla es tu correo, en dónde los mensajes llegan en el orden en el que se envían, ese es un diseño “basado en tiempo”. En un sitio con páginas de “Popular ahora” o “Contenido nuevo” como Reddit o tu Feed de Noticias en Facebook también son ejemplos de diseño basado en tiempo.

Gente:

Facebook (o cualquier otra Red Social) usa una arquitectura basada en gente. Todas las páginas están diseñadas alrededor de a quién le pertenece la información y las relaciones entre ellas. Cuando estás en el perfil de un usuario, Facebook te muestra fotos, amigos, lugares o contenido relacionado a esa persona.

03.03 ¿Qué es un wireframe?

Un Wireframe es documento técnico. Lineas, cajas, etiquetas, tal vez un par de colores. Eso es todo.

Los wireframes se comparan frecuentemente con “planos” porque cumplen el mismo propósito.

Un plano le dice a los constructores cómo ejecutar el plan del arquitecto. No les dice qué color de tapiz colocar o qué tipo de muebles comprar. Los planos son documentos serios, no son sugerencias o “una idea” o un “diagrama rápido”.

Todos tus garabatos durante juntas de trabajo son útiles, pero no son wireframes, son ideas para wireframes que harás después.

Un wireframe puede que tome una hora en hacerse, pero puede tomar semanas o meses en planearse. Es importante que tus colegas y clientes entiendan eso. So un diseñador de interfaz (UI) no puede usar tu “wireframe” entonces no es un “wireframe”, es un dibujo. Sigue trabajando.