En un projecte web gran hi ha una fase en què es discuteix molt i encara no funciona res. Des de fora es llegeix com a lentitud. Vista des de dins, és el tram en què canviar d’opinió costa minuts.
A la nostra eina de gestió de projectes hi ha una tasca amb un títol gens glamurós: «Wireframes de seccions interiors», els esquemes en caixes grises de cada pantalla abans de dissenyar-la. Pertany a la plataforma de comerç electrònic d’una gran institució, un projecte que combina catàleg de productes, botiga en línia, registre de clients professionals, validació de documentació, facturació i integracions amb l’ERP, altres plataformes corporatives i l’eina d’email.
Aquesta tasca va acumular 174 comentaris al llarg d’un bon nombre de setmanes: 85 nostres i 89 del client, una conversa a parts quasi iguals. En els anys que porta el projecte només la superen dues tasques: la de plantilles de contingut, que en va ser la continuació natural, i la de migració de continguts.
Aquest article explica què es va decidir en aquell fil i quin treball l’envolta. Per confidencialitat no identifiquem el client ni mostrem els seus lliurables; les xifres provenen de l’eina de gestió del projecte.
La fase que més es retalla
L’arquitectura de la informació és la disciplina que decideix quins continguts té una web, com s’agrupen, com es diuen, com s’hi arriba i què pot fer cada usuari a cada pantalla. Juntament amb la UX (l’experiència d’usuari) i la UI (la interfície visual), forma la fase en què un projecte es conceptualitza abans de construir-se.
És també la fase que més es tendeix a retallar. «Ja tenim clar què volem», «fem alguna cosa semblant a la web de X», «els wireframes els anirem ajustant sobre la marxa». S’entén: és la part del projecte en què encara no es veu res funcionant. En projectes grans, retallar-la surt car.
El que hi havia abans del primer wireframe
Quan aquell fil va començar, feia temps que conceptualitzàvem el projecte amb el client. Cap wireframe es dibuixa en blanc.
Quatre peces de treball prèvies
La conceptualització és un projecte dins del projecte, amb lliurables propis que el client revisa i valida.
Un qüestionari inicial i quatre reunions de grups de treball amb els diferents equips implicats, perquè cadascun fa servir la web d'una manera diferent i necessita coses diferents.
Un arbre i un pla de continguts, versionats i revisats pel client diverses vegades, recolzats en un benchmarking de plataformes de referència.
Cinc sessions de definició: com es crea un producte i les seves variants, com es registra i es verifica un client, com compra (un producte, diversos o un paquet), com es gestiona la part econòmica i de màrqueting, i amb quins sistemes s'integra tot.
Preus i descomptes, camps de registre i atributs de cada tipus de producte, omplerts amb el client.
Sense tot això, el wireframe hauria estat un exercici d’estètica. Amb tot això, era la primera vegada que el client veia el seu negoci convertit en pantalles.
Què es va decidir en aquells 174 comentaris
Sis decisions que es van prendre al fil
Al fil gairebé no hi ha comentaris del tipus «aquest botó, una mica més a l'esquerra». El que hi ha són decisions de negoci i de producte, preses quan canviar-les costava minuts.
El client tenia molts tipus de producte i volia distingir-los. La nostra recomanació era l'habitual als grans comerços electrònics: poques plantilles, perquè l'usuari aprengui una sola manera de consultar i comprar. El debat va ser llarg i molt bo. Va acabar en un punt intermedi: menys plantilles, però respectant la jerarquia entre tipus de producte que per al client era estratègica.
Vam preparar pantalles addicionals perquè el client provés el registre amb usuaris reals. Resultat: va caldre canviar l'ordre dels grups de camps del formulari. En un prototip això és arrossegar unes caixes. Amb el lloc ja publicat implica tocar formularis, validacions i correus.
Pot un usuari canviar el seu email? I el seu tipus de perfil? Què passa quan algú esborra el seu compte? Són preguntes que en Drupal tenen implicacions serioses. Les vam respondre amb el wireframe al davant, abans de prometre res, i el client va decidir coneixent el cost de cada opció.
L'autocompletat d'adreces i certes finestres modals es van passar conscientment a una segona fase, amb una solució provisional acordada. Saber deixar coses fora també és dissenyar, i és el que permet arribar a una data de llançament.
Per decidir com mostrar les variants de cada producte, el client va analitzar quantes en sol tenir d'actives alhora. El component es va dissenyar per a aquest cas i no per a l'exemple bonic.
Fins i tot el text del menú es va discutir: el nom del catàleg o «Explora»? En arquitectura de la informació, com es diuen les coses determina si l'usuari les troba.
Un fil així només se sosté si la conversa és oberta i ningú té por de portar la contrària, ni el client ni nosaltres.
Un comentari en un wireframe costa uns minuts. El mateix canvi en un lloc en producció costa dies de desenvolupament, proves i desplegament, i de vegades una migració de dades. La fase d’UX és l’únic moment del projecte en què equivocar-se surt barat.
La fase d'UX és l'únic moment del projecte en què equivocar-se surt barat.
Del wireframe al funcional
Un wireframe validat encara no és un projecte llest per desenvolupar. El que es va acordar en aquell fil es va traslladar a tres documents funcionals: mòduls, navegació i plantilles, i processos. Descriuen què fa cada component, què mostra segons el tipus de producte i el tipus d’usuari, i com s’encadena cada flux. Van passar per diverses rondes de comentaris fins a la seva versió definitiva, en paral·lel a la proposta gràfica i a una guia d’estil web que fixa la interfície.
Aquest conjunt permet que l’equip de desenvolupament treballi sense endevinar i que, anys després, qualsevol pugui saber per què una pantalla funciona com funciona.
Per què pesa més com més gran és el projecte
En una web corporativa petita, un error d’arquitectura s’arregla amb una tarda de feina. En una plataforma amb botiga, registre, facturació, integracions i diversos tipus d’usuari, cada pantalla mal resolta es multiplica: afecta formularis, permisos, correus transaccionals, informes del panell de gestió i processos interns del client.
Si haguéssim d’escollir on es guanya o es perd un projecte així, diríem que en els primers mesos. Per això defensem aquesta fase quan arriba la temptació de retallar-la.
Què comprovar abans de passar a desenvolupament
Si tens al davant un projecte d’aquesta mida, amb nosaltres o amb un altre equip, aquestes preguntes et diran si la fase de definició ha fet la seva feina.
Cinc preguntes sobre la fase de definició
Valen per a qualsevol equip i qualsevol plataforma.
Direcció, màrqueting, gestió i tecnologia han vist el mateix i han decidit sobre el mateix abans de gastar pressupost en codi?
Les limitacions tècniques, els casos estranys i els requisits que «es donaven per suposats» ja han aparegut en una reunió, o apareixeran a la fase de proves?
Cada decisió s'ha contrastat amb com navega i compra la gent, amb referents del sector i, quan cal, amb un test real?
El desenvolupament s'estimarà sobre un funcional tancat? Sense ell, les estimacions són desitjos.
Quan el projecte creixi en fases posteriors, l'arquitectura està pensada per absorbir-lo?
Aquells 174 comentaris diuen que el client i nosaltres ens vam prendre seriosament el projecte abans d’escriure una sola línia de codi. Quan va arribar el desenvolupament, ja sabíem què calia construir.