Ce trebuie clarificat înainte ca oferta pentru un site să însemne ceva: pagini, conținut, dovezi, sisteme, responsabilități și obiectivul comercial.

Să ofertezi un site după numărul de pagini este ca și cum ai oferta o clădire după numărul de camere. Nu spune nimic despre ce trebuie să se întâmple în ele, ce există deja sau cine răspunde de piesele care lipsesc.

O ofertă este la fel de bună ca definiția proiectului

Înainte să punem un preț pe proiect, trebuie să înțelegem obiectivul comercial, publicurile, paginile, conținutul și sistemele implicate. Altfel, prețul fie include o marjă mare pentru necunoscute, fie este suficient de mic încât să devină o problemă mai târziu. Marja mare este eșecul mai frecvent, pentru că este cel mai ușor de făcut discret — nimeni nu se plânge de un proiect care a ieșit sub o cifră care nu a fost niciodată onestă de la bun început.

Definiția proiectului transformă necunoscutele în decizii. Arată ce este inclus, ce nu este inclus, ce avem nevoie de la client și ce presupuneri ar schimba prețul dacă se dovedesc greșite. Un document de scop nu este o măsură de apărare. Este ce le permite celor două părți să cadă de acord, în scris, înainte ca vreuna dintre ele să fi pierdut o zi cu proiectul.

Ce verificăm prima dată

Patru întrebări apar de fiecare dată, în ordinea asta, pentru că fiecare o restrânge pe următoarea.

1. Ce trebuie să schimbe site-ul pentru afacere? Nu „ce ar trebui să aibă site-ul” — ce cifră este menită să se miște pentru că a avut loc acest proiect. Cereri de ofertă, aplicații, vânzările unui produs anume, timp economisit la suport. Un proiect fără răspuns la asta este un exercițiu de design cu termen limită.
2. Ce publicuri și ce decizii trebuie să susțină? Un site care vinde către trei tipuri diferite de cumpărători nu este un singur site cu trei secțiuni; sunt trei argumente care întâmplător împart o bară de navigare. Denumirea lor din start oprește pagina principală de la a încerca să vorbească tuturor celor trei deodată și de a sfârși prin a nu fi specifică niciunuia.
3. Ce conținut, dovezi și integrări există deja? Studii de caz, testimoniale, date de produs, un CRM, un procesator de plăți, un sistem de programări. Ce există se auditează, nu se presupune; ce nu există se programează, nu se descoperă în săptămâna șase.
4. Cine răspunde de feedback, aprobări și livrare de fiecare parte? Un singur nume de fiecare parte, nu un comitet. Un proiect cu doi decidenți din partea clientului care încă nu au căzut de acord între ei este un proiect care se va renegocia live, în timpul lucrului, exact în cel mai prost moment posibil pentru asta.

Ce conține documentul de proiect

Un document pe care suntem dispuși să îl ofertăm numește paginile, argumentul pe care îl susține fiecare pagină și dovezile de care are nevoie acel argument. De obicei încape în două-trei pagini A4. Dacă nu poate fi scris atât de scurt, proiectul nu este înțeles suficient de bine cât să fie ofertat.

Paginile și rolul lor

Fiecare pagină primește o propoziție care spune ce ar trebui să poată face sau să creadă un vizitator la finalul ei. Paginile care nu pot fi descrise așa sunt, de regulă, pagini de care nu avea nimeni nevoie. Doar acest pas reduce de obicei o hartă de site propusă cu un sfert — nu pentru că paginile erau greșite, ci pentru că nimeni nu întrebase până atunci ce rol avea fiecare.

Dovezile

Afirmațiile au nevoie de dovezi: studii de caz, cifre, clienți cu nume, capturi din proiecte reale. Strângerea lor este de multe ori partea cea mai lungă a unui proiect și cea mai predispusă să fie descoperită târziu, dacă nu a pus-o nimeni în document. O pagină care promite „vezi rezultatele noastre” și apoi nu are niciun rezultat de arătat este mai rea decât o pagină care nu a făcut niciodată promisiunea — este un argument rupt așezat exact unde ar fi trebuit să fie unul funcțional, și este găsit exact de vizitatorul care era cel mai aproape de a fi convins.

Sisteme și integrări

Cu ce trebuie să vorbească site-ul schimbă estimarea mai mult decât ce trebuie să afișeze. Un formular de contact este o după-amiază. Un formular de contact care trebuie să creeze o înregistrare într-un CRM, să anunțe un canal de Slack și să declanșeze o secvență de e-mail-uri este un mic proiect de integrare deghizat în formular. Listăm fiecare sistem cu care vorbește noul site — analytics, plăți, programări, stocuri, e-mail — înainte să ofertăm orice, pentru că API-ul de la terți cu documentație săracă nu este niciodată lucrul pe care își amintește cineva să îl menționeze de la început.

Conținutul

Cine scrie textele și până când. Un document care spune „clientul furnizează textele” fără o dată este un document care va întârzia proiectul, pentru că scrisul textelor concurează cu tot ce mai face echipa clientului în săptămâna aceea și este mereu termenul cel mai ușor de ratat discret. Numim paginile care au nevoie de text, cine îl redactează și data până la care avem nevoie de el ca să nu se clatine restul calendarului — iar acolo unde clientul preferă să scriem noi, asta se ofertează și se programează ca proiect separat, nu se strecoară tăcut în „design”.

Responsabilități și calendar

Cine furnizează ce piesă și până când. Text, imagini, verificare juridică, date de produs, active de brand — fiecare primește un responsabil și o dată, de ambele părți. Un document care listează doar ce va face agenția este jumătate de document; jumătatea care decide dacă rezistă calendarul este de obicei jumătatea clientului.

Ce se întâmplă fără el

Descoperirea la jumătatea proiectului că site-ul are nevoie de unsprezece studii de caz pe care nu le-a scris nimeni costă o lună — și pică exact în momentul în care s-a terminat răbdarea tuturor pentru orice nu este progres vizibil. Descoperirea că „site-ul” trebuia să includă un portal pentru clienți, iar o parte credea că e evident, cealaltă că e o fază doi, costă relația, nu doar calendarul. Niciuna dintre astea nu este neobișnuită. Sunt ce se întâmplă, implicit, când un proiect pornește de la un număr de pagini în loc de un document de scop — și sunt aproape imposibil de reparat elegant odată ce construcția a început, pentru că de atunci orice discuție despre scop se citește ca o discuție despre vină.

Clarificarea proiectului costă o săptămână. Eșecurile de mai sus costă o lună și o discuție pe care nimeni nu și-a dorit-o, și pică exact atunci când bunăvoința care ar fi făcut discuția ușoară s-a dus deja pe altceva.

Ce schimbă legitim prețul după ce documentul există

Un document de scop nu este o promisiune că prețul nu se mai schimbă — este o promisiune că se schimbă doar din motive pe care le pot numi ambele părți. Motive legitime: o pagină are nevoie de conținut care nu există încă și cineva trebuie să îl scrie; API-ul real al unei integrări este mai limitat decât sugera pagina ei de marketing; clientul adaugă o cerință cu adevărat nouă în timpul proiectului. Motive nelegitime: estimarea a fost optimistă ca să câștige proiectul, sau „strângerea designului” devine redesenarea a trei pagini care nu au fost niciodată în scop. Diferența dintre cele două este dacă schimbarea se leagă de un fapt pe care nimeni nu îl avea când s-a scris documentul, sau de o decizie pe care cineva o ia acum și speră să nu trebuiască să o justifice.

Cine îl scrie, de fapt

Clientul furnizează datele de intrare — obiectivul comercial, publicurile, orice dovadă și conținut există deja, decidentul intern. Agenția transformă asta în document: paginile, argumentul fiecăreia, sistemele pe care le atinge, ordinea în care trebuie să se întâmple totul. Scrierea documentului de scop nu este ceva cu care se așteaptă să vină clientul. Răspunsul onest și concret la cele patru întrebări de mai sus, da.

Această împărțire contează mai mult decât pare. Un client care încearcă să scrie singur documentul produce de obicei un număr de pagini cu opinii despre culoare atașate, pentru că așa arată „un site” privit din exterior. O agenție care scrie un document de scop fără răspunsuri reale la cele patru întrebări produce un document care se citește bine și se prețuiește greșit, pentru că umple golurile cu presupuneri în loc să întrebe. Documentul funcționează doar când fiecare parte furnizează bucata pe care numai ea o poate vedea.

Pe scurt

Decide ce are site-ul de demonstrat. Scrie cum demonstrează fiecare pagină acel lucru, ce trebuie să atingă și cine răspunde de piesele care lipsesc. Abia apoi desenează ceva în jurul argumentului — pentru că designul va fi mai rapid, mai ieftin și mai bun când nu mai e nimic de discutat.