En un proyecto web grande hay una fase en la que se discute mucho y todavía no funciona nada. Desde fuera se lee como lentitud. Vista desde dentro, es el tramo en el que cambiar de opinión cuesta minutos.
En nuestra herramienta de gestión de proyectos hay una tarea con un título poco glamuroso: «Wireframes de secciones interiores», los esquemas en cajas grises de cada pantalla antes de diseñarla. Pertenece a la plataforma de comercio electrónico de una gran institución, un proyecto que combina catálogo de productos, tienda online, registro de clientes profesionales, validación de documentación, facturación e integraciones con el ERP, otras plataformas corporativas y la herramienta de email.
Esa tarea acumuló 174 comentarios a lo largo de un buen número de semanas: 85 nuestros y 89 del cliente, una conversación a partes casi iguales. En los años que lleva el proyecto solo la superan dos tareas: la de plantillas de contenido, que fue su continuación natural, y la de migración de contenidos.
Este artículo cuenta qué se decidió en ese hilo y qué trabajo lo rodea. Por confidencialidad no identificamos al cliente ni mostramos sus entregables; las cifras proceden de la herramienta de gestión del proyecto.
La fase que más se recorta
La arquitectura de la información es la disciplina que decide qué contenidos tiene una web, cómo se agrupan, cómo se llaman, cómo se llega a ellos y qué puede hacer cada usuario en cada pantalla. Junto con la UX (la experiencia de usuario) y la UI (la interfaz visual), forma la fase en la que un proyecto se conceptualiza antes de construirse.
Es también la fase que más se tiende a recortar. «Ya tenemos claro lo que queremos», «hagamos algo parecido a la web de X», «los wireframes los vamos ajustando sobre la marcha». Se entiende: es la parte del proyecto en la que todavía no se ve nada funcionando. En proyectos grandes, recortarla sale caro.
Lo que había antes del primer wireframe
Cuando ese hilo empezó, llevábamos tiempo conceptualizando el proyecto con el cliente. Ningún wireframe se dibuja en blanco.
Cuatro piezas de trabajo previas
La conceptualización es un proyecto dentro del proyecto, con entregables propios que el cliente revisa y valida.
Un cuestionario inicial y cuatro reuniones de grupos de trabajo con los distintos equipos implicados, porque cada uno usa la web de una manera distinta y necesita cosas distintas.
Un árbol y un plan de contenidos, versionados y revisados por el cliente varias veces, apoyados en un benchmarking de plataformas de referencia.
Cinco sesiones de definición: cómo se crea un producto y sus variantes, cómo se registra y se verifica un cliente, cómo compra (un producto, varios o un paquete), cómo se gestiona la parte económica y de marketing, y con qué sistemas se integra todo.
Precios y descuentos, campos de registro y atributos de cada tipo de producto, rellenados con el cliente.
Sin todo eso, el wireframe habría sido un ejercicio de estética. Con todo eso, era la primera vez que el cliente veía su negocio convertido en pantallas.
Qué se decidió en esos 174 comentarios
Seis decisiones que se tomaron en el hilo
En el hilo casi no hay comentarios del tipo «este botón, un poco más a la izquierda». Lo que hay son decisiones de negocio y de producto, tomadas cuando cambiarlas costaba minutos.
El cliente tenía muchos tipos de producto y quería distinguirlos. Nuestra recomendación era la habitual en los grandes comercios electrónicos: pocas plantillas, para que el usuario aprenda una sola forma de consultar y comprar. El debate fue largo y muy bueno. Terminó en un punto intermedio: menos plantillas, pero respetando la jerarquía entre tipos de producto que para el cliente era estratégica.
Preparamos pantallas adicionales para que el cliente probara el registro con usuarios reales. Resultado: hubo que cambiar el orden de los grupos de campos del formulario. En un prototipo eso es arrastrar unas cajas. Con el sitio ya publicado implica tocar formularios, validaciones y correos.
¿Puede un usuario cambiar su email? ¿Y su tipo de perfil? ¿Qué pasa cuando alguien borra su cuenta? Son preguntas que en Drupal tienen implicaciones serias. Las respondimos con el wireframe delante, antes de prometer nada, y el cliente decidió conociendo el coste de cada opción.
El autocompletado de direcciones y ciertas ventanas modales se pasaron conscientemente a una segunda fase, con una solución provisional acordada. Saber dejar cosas fuera también es diseñar, y es lo que permite llegar a una fecha de lanzamiento.
Para decidir cómo mostrar las variantes de cada producto, el cliente analizó cuántas suele tener activas a la vez. El componente se diseñó para ese caso y no para el ejemplo bonito.
Hasta el texto del menú se discutió: ¿el nombre del catálogo o «Explora»? En arquitectura de la información, cómo se llaman las cosas determina si el usuario las encuentra.
Un hilo así solo se sostiene si la conversación es abierta y nadie tiene miedo de llevar la contraria, ni el cliente ni nosotros.
Un comentario en un wireframe cuesta unos minutos. El mismo cambio en un sitio en producción cuesta días de desarrollo, pruebas y despliegue, y a veces una migración de datos. La fase de UX es el único momento del proyecto en el que equivocarse sale barato.
La fase de UX es el único momento del proyecto en el que equivocarse sale barato.
Del wireframe al funcional
Un wireframe validado todavía no es un proyecto listo para desarrollar. Lo acordado en ese hilo se trasladó a tres documentos funcionales: módulos, navegación y plantillas, y procesos. Describen qué hace cada componente, qué muestra según el tipo de producto y el tipo de usuario, y cómo se encadena cada flujo. Pasaron por varias rondas de comentarios hasta su versión definitiva, en paralelo a la propuesta gráfica y a una guía de estilo web que fija la interfaz.
Ese conjunto permite que el equipo de desarrollo trabaje sin adivinar y que, años después, cualquiera pueda saber por qué una pantalla funciona como funciona.
Por qué pesa más cuanto mayor es el proyecto
En una web corporativa pequeña, un error de arquitectura se arregla con una tarde de trabajo. En una plataforma con tienda, registro, facturación, integraciones y varios tipos de usuario, cada pantalla mal resuelta se multiplica: afecta a formularios, permisos, correos transaccionales, informes del panel de gestión y procesos internos del cliente.
Si tuviéramos que elegir dónde se gana o se pierde un proyecto así, diríamos que en los primeros meses. Por eso defendemos esta fase cuando llega la tentación de recortarla.
Qué comprobar antes de pasar a desarrollo
Si tienes por delante un proyecto de este tamaño, con nosotros o con otro equipo, estas preguntas te dirán si la fase de definición ha hecho su trabajo.
Cinco preguntas sobre la fase de definición
Valen para cualquier equipo y cualquier plataforma.
¿Dirección, marketing, gestión y tecnología han visto lo mismo y han decidido sobre lo mismo antes de gastar presupuesto en código?
¿Las limitaciones técnicas, los casos raros y los requisitos que «se daban por supuestos» han aparecido ya en una reunión, o van a aparecer en la fase de pruebas?
¿Cada decisión se ha contrastado con cómo navega y compra la gente, con referentes del sector y, cuando hace falta, con un test real?
¿El desarrollo se va a estimar sobre un funcional cerrado? Sin él, las estimaciones son deseos.
Cuando el proyecto crezca en fases posteriores, ¿la arquitectura está pensada para absorberlo?
Aquellos 174 comentarios dicen que el cliente y nosotros nos tomamos en serio el proyecto antes de escribir una sola línea de código. Cuando llegó el desarrollo, ya sabíamos qué había que construir.