Greșeli frecvente în colaborarea design-development (și cum le eviți)

Un designer ia câteva zeci de decizii pe fiecare ecran, iar fiecare are un motiv în spate. Butonul stă sus pentru că acolo se uită primul un vizitator venit din Google, formularul are patru câmpuri pentru că al cincilea scădea conversia în varianta testată anterior, iar spațiul acela generos dintre secțiuni ține de ritmul de citire. Programatorul primește fișierul, vede rezultatul și nu vede niciunul dintre motive. Când ceva din machetă intră în conflict cu o constrângere tehnică, el rezolvă conflictul singur, folosind logica lui, care e perfect rezonabilă și complet ruptă de intenția inițială. Așa ajunge butonul cu 40 de pixeli mai jos, formularul cu încă două câmpuri cerute de CRM și spațierea strânsă ca să încapă totul fără scroll. Fiecare mutare arată corect izolat, iar împreună produc un site care funcționează și nu convertește.

Macheta arată cum se vede pagina într-o singură stare, pe un singur ecran, cu un singur set de conținut. Programatorul are nevoie de restul: ce se întâmplă la 380 de pixeli lățime, cum arată butonul apăsat sau dezactivat, ce scrie când titlul are 90 de caractere în loc de 40, cum se comportă lista când e goală. Când răspunsurile nu sunt scrise nicăieri, ele se inventează în timpul implementării, apoi se corectează la review, iar corectura înseamnă rework. La un proiect mediu vorbim de câteva sute de astfel de stări nedefinite, și e suficient ca 10% dintre ele să fie ghicite greșit ca să pierzi o săptămână.

"Nu e chiar ce am vrut" e propoziția care costă cel mai mult într-un proiect web, pentru că trimite pe cineva înapoi în muncă fără să îi spună unde să se uite. Programatorul modifică ce crede că a înțeles, tu vezi rezultatul peste patru zile, și tot nu e. Trei runde din astea consumă două săptămâni fără să adauge nimic. Peste ele vine scope-ul: în săptămâna șase apare un modul de facturare la care nimeni nu s-a gândit la kickoff, se replanifică tot, iar estimarea inițială devine o amintire. La final, testarea prinde restul, sau nu îl prinde, pentru că a rămas ultima în calendar și calendarul era deja depășit.

Un site de prezentare estimat la opt săptămâni și 15.000 de euro înseamnă puțin sub 1.900 de euro pe săptămână de echipă. Trei săptămâni de rework, ceea ce e o medie modestă când jumătate din ecrane se refac, adaugă 5.600 de euro peste buget. Lansarea se mută cu o lună, iar dacă site-ul urma să aducă opt lead-uri pe lună, la o rată de închidere de 20% și o valoare medie de 4.000 de euro pe client, luna aceea pierdută mai costă 6.400 de euro în vânzări care nu s-au întâmplat. Un proiect de 15.000 de euro te-a costat 27.000 și a ajuns pe piață în noiembrie, nu în octombrie.

Un design system, chiar unul mic, rezolvă jumătate din problemă înainte să apară: butoane, spațieri, stări și breakpoint-uri definite o singură dată, la care se raportează amândoi. Brief-ul tehnic scris înainte de prima machetă spune ce constrângeri există în CRM, în sistemul de plăți și în datele reale, ca designul să nu le descopere la implementare. Review-urile intermediare, la fiecare două săptămâni pe ceva funcțional, prind derapajul cât e ieftin de reparat, în locul unei singure predări mari la final. Feedback-ul se dă pe ecranul concret și pe comportamentul concret, nu pe senzație. Iar un singur punct de contact, care ține și designul, și implementarea, elimină traducerea cu totul.

Când aceeași persoană decide și construiește, motivul din spatele deciziei nu se pierde nicăieri, pentru că nu trece prin nimeni. Întrebările primesc răspuns în ora în care apar, iar stările nedefinite se rezolvă în momentul în care sunt observate. Rămân proiectele mari, cu mai multe echipe, unde structura de agenție își merită costul, și acolo recomandarea de mai sus nu se aplică. Pentru un site sau un produs digital de dimensiune medie, unde termenul contează, mai puține straturi bat mai multe mâini. Dacă vrei să vezi cum ar arăta calendarul tău fără predare, o discuție de o jumătate de oră e suficientă ca să îți spun unde ai pierde timpul și cât.