¿Cómo abordas la arquitectura de información de un producto con muchas funcionalidades?

Basa la estructura en cómo agrupan las cosas los usuarios, no en cómo está organizada la empresa. Inventaría lo que existe, después haz card sorting o tree testing para encontrar el modelo mental de los usuarios, y valida con pruebas de primer clic sobre etiquetas reales. Prefiere etiquetas claras a etiquetas ingeniosas, mantén la navegación poco profunda donde puedas, y ofrece una ruta de transición cuando cambies una estructura que la gente ya conoce.

Empiezo con un inventario, que es tedioso y siempre revela algo. En un producto B2B encontramos cuarenta y un destinos en una navegación que se presentaba como si tuviera nueve, porque durante años se habían ido metiendo funcionalidades dentro de ajustes. Después voy a buscar el modelo de los usuarios en vez de imponer el mío. Un card sort abierto con quince personas me dice qué va junto y, más útil todavía, qué palabras usan. A los equipos les encanta el vocabulario interno y los usuarios no lo tienen. Después construyo un árbol y lo pruebo antes de diseñar una sola pantalla. El tree testing es la investigación de más valor y menos coste que existe: sin visuales, solo si sabes encontrar dónde irías para hacer esto. Si una tarea se encuentra en menos del 60% de los casos, la estructura está mal y ningún diseño visual la va a rescatar. La parte que se infravalora es la transición. Si reorganizas un producto que la gente usa a diario les has roto la memoria muscular, así que planifico redirecciones, una explicación corta dentro del producto, y una búsqueda que siga entendiendo los nombres antiguos.