Un brief bun pentru o aplicație încape pe o pagină. Spune ce problemă rezolvi, pentru cine, care sunt cele trei lucruri pe care oamenii le fac cel mai des în aplicație, pe ce dispozitive, cu ce sisteme se leagă și cum arată succesul. Nu are nevoie de liste de ecrane sau de tehnologii. Din el iese o ofertă cu scop, etape și termen, nu o cifră aruncată pe ghicite.
De ce contează brieful
Fără brief, discuția începe de la „vreau o aplicație ca X”. Asta spune cum arată ceva, nu ce problemă rezolvă. Manualul de servicii publice al guvernului britanic spune același lucru: o nevoie bună descrie problema omului, nu soluția. Exemplul lor: omul are nevoie de o reamintire, nu de un e-mail sau de o scrisoare.
Un brief clar ne scutește pe amândoi de o lună de presupuneri. Pe pagina noastră de servicii scrie la fel: oferta vine după brief, pentru că de scop depind câte ecrane are aplicația, ce face și ce sisteme atinge.
Cele zece întrebări ale unui brief
- Problema, în două propoziții. Ce merge prost azi și cât te costă (timp, bani, clienți pierduți).
- Cine o folosește. Rolurile, nu doar „clienții”: cine comandă, cine aprobă, cine lucrează pe teren, cine vede rapoartele.
- Cele trei fluxuri principale. Ce fac oamenii cel mai des, pas cu pas. Restul vine după.
- Platformele. Web, iOS, Android sau toate. Și unde se folosește: la birou, pe stradă, în mașină.
- Ce există deja. Excelul, grupul de WhatsApp, programul vechi. Datele de acolo trebuie mutate?
- Integrările. Plăți, hărți, facturare, curierat, e-mail.
- Datele personale. Ce date strângi, de ce și cât timp le ții.
- Termenul. Și de ce e acela: un sezon, un eveniment, un contract.
- Cum arată succesul. O cifră pe care o poți măsura după lansare.
- Ce NU intră în prima versiune. Lista asta salvează cele mai multe proiecte.
Rolurile și cele trei fluxuri
Pentru fiecare rol, scrie nevoia în forma pe care o folosește ghidul britanic: „Ca [rol], am nevoie să [ce], ca să [de ce]”. De exemplu: „Ca tehnician, am nevoie să închid lucrarea din telefon, cu poze, ca să nu mai trec pe la birou seara.”
De ce doar trei fluxuri? Pentru că acolo se decide dacă aplicația e folosită. Ghidul Apple pentru iPhone observă că, de multe ori, oamenii stau într-o aplicație doar un minut sau două, și le cere designerilor să-i lase să se concentreze pe sarcina principală, cu cât mai puține butoane pe ecran. Dacă primele trei fluxuri merg repede, restul se poate adăuga în versiunile următoare.
Un exemplu: o aplicație de tractări are de obicei trei roluri legate în timp real, clientul, firmele partenere și șoferii. Fiecare rol are fluxul lui, iar în brief fiecare primește cele trei fluxuri ale lui, scrise separat.
Platforme și ce te așteaptă în store
Nu orice idee are nevoie de o aplicație în App Store. O aplicație web merge pe orice telefon, fără instalare, și se actualizează pentru toți odată. O aplicație în store are sens când folosește mult funcțiile telefonului (cameră, notificări, lucru fără semnal) sau când vrei ca oamenii să te găsească în magazin.
Dacă alegi store-ul, câteva reguli de la Apple intră direct în brief:
- aplicația trebuie să aibă un link spre politica de confidențialitate, în store și în aplicație;
- dacă oamenii își pot face cont, trebuie să și-l poată șterge din aplicație;
- o aplicație care e doar un site reîmpachetat poate fi respinsă.
Datele și GDPR
În brief scrii ce date personale strânge aplicația și de ce. Regulamentul general privind protecția datelor cere ca datele să fie limitate la ce e necesar pentru scop (minimizarea datelor) și ca protecția lor să fie gândită din faza de proiectare, cu setări care, implicit, prelucrează doar ce trebuie.
Practic: dacă îți trebuie locația doar la pontaj, aplicația o cere la pontaj, nu toată ziua. Dacă noi construim și găzduim aplicația, lucrăm pe datele tale în numele tău, iar regulamentul cere un contract scris pentru asta. E bine să știi din brief cine e de fiecare parte.
Un exemplu de brief completat
Firma e inventată: o firmă de instalații termice cu 12 oameni pe teren.
| Întrebare | Răspuns |
|---|---|
| Problema | Lucrările se dau pe WhatsApp, pozele se pierd, pontajul se strânge din mesaje la sfârșit de lună. Închidem luna în trei zile. |
| Roluri | patron, birou (dispecer), tehnician |
| Fluxuri | 1. Biroul dă lucrarea unui tehnician. 2. Tehnicianul o închide din telefon, cu poze și semnătura clientului. 3. Patronul vede pontajul lunar și îl exportă. |
| Platforme | aplicație web pe telefon pentru tehnicieni, pe calculator pentru birou |
| Ce există | un Excel cu clienții și adresele, de importat |
| Integrări | hărți (adresa lucrării), export spre programul de facturare |
| Date | nume, telefon, adresa clientului; locația tehnicianului doar la începutul și sfârșitul lucrării |
| Termen | înainte de sezonul de revizii la centrale |
| Succes | luna se închide într-o zi în loc de trei |
| Nu intră acum | plăți online, aplicație în store, portal pentru clienți |
E un brief de jumătate de pagină. Din el putem estima scopul, etapele și termenul, și putem spune ce se poate face mai întâi. Pentru firmele care țin pontajul sau lucrările în Excel și pe WhatsApp, de obicei începem cu un singur modul și construim restul pe același sistem.
Surse
- Learning about users and their needs, GOV.UK Service Manualforma „Ca… am nevoie să… ca să…” și ideea că o nevoie descrie problema, nu soluția
- Designing for iOS, Apple Human Interface Guidelinessesiunile scurte de un minut sau două și sfatul de a pune sarcina principală în față, cu puține butoane pe ecran
- App Review Guidelines, Apple5.1.1 (link spre politica de confidențialitate, ștergerea contului din aplicație) și 4.2 (aplicațiile care sunt doar un site reîmpachetat)
- Regulamentul (UE) 2016/679 (GDPR), EUR-Lexart. 5 alin. (1) lit. c) minimizarea datelor, art. 25 protecția datelor din faza de proiectare și implicit, art. 28 alin. (3) contractul cu persoana împuternicită
Verificat: surse Xenia Pușcașu · editare Nora Vlăsceanu · SEO Mihnea Tăbăcaru