Eliminar el gap entre disseny i desenvolupament
Hi ha un moment especialment delicat en qualsevol desenvolupament digital: el pas del disseny al producte final.
Aquesta transició no hauria de ser problemàtica si hi ha coordinació, però quan disseny i desenvolupament no estan alineats, el resultat es deforma.
El que en Figma semblava mil·limètric, equilibrat i clar, acaba implementat de manera desajustada, imprecisa i ple de petites incoherències.
I llavors passa: el client es veu obligat a jugar a les 7 diferències entre el que va aprovar i el que veu en pantalla… però, aquesta vegada, les diferències no són només set.
Els botons no encaixen, els marges es mouen pel seu compte, els textos criden en negreta i el responsive fa el que li dona la gana.
El que semblava professional i sòlid acaba desvirtuant el treball de tot l’equip.
Un mal repartiment de rols
Durant anys s’ha assumit que el disseny i el desenvolupament són fases seqüencials: el dissenyador acaba i entrega, el desenvolupador interpreta i executa. Però eixa visió no funciona en productes complexos, ni en entorns amb equips àgils, i molt menys en empreses que volen iterar i aprendre amb rapidesa.
UX i desenvolupament no són “departaments” que treballen per torns. Són parts d’un mateix procés, i com més prompte comencen a col·laborar, menys fricció hi haurà després.
Quan sabem que hi ha un problema?
- Quan el disseny i la implementació visual no coincideixen, i ningú sap si és un error o una decisió tècnica.
- Quan hi ha múltiples versions del mateix arxiu de disseny i no està clar quina és la vàlida.
- Quan el feedback arriba massa tard i refer alguna cosa implica descartar hores de treball.
- Quan els estats, les transicions o l’accessibilitat no estan contemplats, ni en el disseny ni en el desenvolupament.
Com podem salvar eixe gap?
La nostra manera de treballar entre disseny i desenvolupament no ha sorgit per casualitat.
És el resultat d’experiència directa, molts projectes i una decisió clara: no volíem que el treball es diluïra o es reinterpretara en l’última milla.
Hem vist —i també viscut— el que passa quan els equips no estan alineats: entregues desajustades, funcionalitats mal interpretades, interfícies que no respecten la intenció original. I vam entendre ràpid que eixe model no era sostenible.
Per això vam construir un enfocament diferent: col·laboratiu, continu i transversal.
El disseny i desenvolupament deixen de ser fases separades i passen a formar part d’un mateix procés.
Perquè una bona idea mereix arribar bé al producte. I això només ocorre quan els equips construeixen junts des del principi.
I seguim afinant. Perquè encara que hui treballem d’una manera molt més coordinada, cada projecte ens deixa nous aprenentatges. I això és, precisament, el que fa que continuem millorant.
Algunes coses que sí ens funcionen
1. Sincronització contínua: daily + reunions per fases
No cal fer reunions eternes, però sí cal estar sincronitzats. Una daily ben enfocada per alinear prioritats, i reunions breus per funcionalitat o etapa, ens ajuden a evitar desajustaments.
Disseny i desenvolupament han de tindre clar què es farà i per què, fins i tot abans de començar.
2. Revisar junts la funcionalitat
Abans de dissenyar o desenvolupar, revisem la funcionalitat amb representants dels dos equips —normalment les persones responsables de disseny i desenvolupament implicades en eixe bloc.
Analitzem el flux, els possibles bloquejos i els punts sensibles. Entendre bé el que es construirà evita interpretacions i malbaratament d’esforç. No és documentació, és conversa.
3. Prototips interactius, també per al client
No es tracta només de mostrar pantalles. Utilitzem prototips navegables en Figma que permeten veure el comportament real de la interfície: fluxos, transicions, estats.
Serveixen per a alinear internament l’equip i també perquè el client entenga amb claredat què rebrà, sense haver-se d’imaginar res.
Un disseny interactiu compartit és molt més eficaç que qualsevol document funcional.
4. Dissenyar amb intenció, no només amb estil
El disseny no pot limitar-se a l’estètica. Cal deixar clar com es comporta la interfície en condicions reals: què passa si el contingut s’allarga, si alguna cosa falla, si l’usuari interactua malament.
Sense eixe context, el desenvolupament es veu obligat a interpretar… i això quasi sempre ix car.
5. Components compartits, realistes i reutilitzables
Dissenyem sobre sistemes connectats amb el codi. Això permet treballar amb components reals, testar diferents estats i mantindre la coherència visual sense esforç extra.
Si alguna cosa no es pot provar, no està ben definida.
6. Validació progressiva
Revisem el desenvolupament mentre es construeix, no després. Mostrem avanços parcials encara que no estiguen polits, perquè corregir a temps sempre costa menys que refer al final.
És una validació col·laborativa, no un control de qualitat al tancament.
7. Una veu unificada davant del client
Disseny i desenvolupament comuniquen el mateix. No hi ha versions diferents ni respostes contradictòries.
Quan l’equip està alineat per dins, el client ho nota per fora. I confia més.
Eines que ajuden
- Figma / Zeplin / UXPin Merge: Per assegurar que allò que es dissenya es pot construir i mantindre.
- Storybook / Codux: Per veure el disseny en la seua versió real, navegable i testeable.
- Slack / Notion / Loom: Per documentar decisions, compartir idees i evitar malentesos en remot.
En resum
Un disseny no s’entrega. Es construeix. El visual i el funcional són dues cares de la mateixa moneda, i qualsevol separació excessiva entre ambdues és una font probable d’errors i frustracions.
A WonderBits creiem en el treball conjunt des del primer dia. Perquè quan disseny i desenvolupament col·laboren de manera fluida, no només guanyem temps i qualitat. També construïm productes més coherents, mantenibles i pensats per a durar.