Cum spui unui programator cum vrei sa arate si sa functioneze un website

Nu de multe ori apar nemultumiri atunci cand un proiect intarzie, costa mult si nu iese asa cum se doreste. Pentru a preintampina astfel de situatii s-a convenit ca cel care doreste un website trebuie sa investeasca timp pentru a documenta in scris cum trebuie sa arate si sa functioneze website-ul. O astfel de documentare se poate denumi brief. In functie de nivelul tau de cunostinte, acest brief poate fi:

  • brief high level, adica o explicatie sumara, grosiera a ceea ce doresti. Abordarea high level este una foarte riscanta pentru proiect deoarece lasi multe decizii pentru dezvoltator. Aceasta fie executa cum crede, fie te intreaba pe tine. Si cu siguranta apar intarzieri si pretul proiectului creste.
  • brief low level, adica explicatii exhaustive. Aici va trebui sa te concentrezi suficient incat sa te asiguri ca ai documentat tot. Aici definesti fluxuri, specificatii tehnice, schite de design, samd. Un astfel de brief iti permite sa stabilesti calendar de activitati, data la care website-ul sa fie live. Totodata, pretul cerut de dezvoltator este exact si posibilele variatii sunt minore, asta daca nu ai gresit brief-ul, bineinteles. 😂

Aici nu vreau sa scriu despre brief-urile high level deoarece sunt self-explanatory si fiecare le documenteaza folosind tool-urile pe care le stie. De regula, acest tip de brief se poate realiza intr-un powerpoint dragut in care subliniezi cele mai importante chestii. Un fel de executive summary, o chestie succinta pentru cei care iau decizii in cadrul unei firme mai mari.

Revenind la brief-ul low level, din experienta mea, cele mai reusite proiecte au fost cele care au respectat urmatorul pattern:

S-a realizat un wireframe interactiv

Practic, un wireframe reprezinta o modalitate de reprezentare grafica a cum iti doresti sa arate website-ul. Acest wireframe poate veni sub o forma simpla, de exemplu o schita de mana, dar si-n forme digitale, cu interactivitate, adica dai click si vezi ce se intampla. Exista mai multe variante de reprezentare grafica pentru un website, dar pentru a le intelege mai bine, trebuie sa cauti pe google diferenta dintre mockup, wireframe si prototype. Incepand cu mockup-ul, aici poti incepe sa detaliezi inclusiv fluxuri si functionalitate de baza (se inchide, se deschide, merge stanga-dreapta, etc.). Intr-un prototype poti incepe sa lucrezi animatie, samd.

Asa arata un wireframe
Wireframe vs Mockup vs Prototype

Exista o multime de aplicatii pentru a face asta. Pentru un wireframe de baza, cu siguranta te vei descurca cu variantele gratuite ale acestora. Eu recomand Balsamiq pentru utilizatorii incepatori. Alte recomandari pentru avansati ar fi Figma, Adobe XD sau Moqups, o solutie made in Romania. ❤️ Sau traditionalul Axure, dar este o solutie complexa.

S-a documentat in scris sub forma de user stories

User stories este o forma prin care documentezi intr-un limbaj normal, simplu, ceea ce-ti doresti. Eu recomand ca explicatiile unui user story sa poata fi intelese de un copil de clasa a 5-a. Asta am imprumutat-o de la conceptul rubber duck debugging.

Stories-urile pot fi scrise sub multe forme, insa eu aleg intotdeauna Excel pentru ca este un tool pe care multa lume il intelege. Dupa foarte multe incercari, am gasit si o varianta ideala de fisier pe care am adaptat-o a.i. sa raspunda si altor nevoi in afara de documentarea stories si anume sa te ajuta sa prioritizezi stories-urile. Adica un fel de matrice decizionala bazata pe criterii de prioritate, valoare adaugata, risc la implementare si efort necesar. Deci, dupa ce ai finalizat user stories si le-ai asociat criteriile, vei avea un sheet separat de raportare. Ca analogie, tu ai scris brief low-level, exhaustiv, cu toate detaliile, iar acest sheet de raportare este un executive summary care te ajuta sa alegi mai usor si sa prioritizezi in functie de user stories-urile agregate. Ai mai jos un link catre fisier.

Pana verifici tu fisierul, iti spun care este header-ul sau capul de tabel care se potriveste introducerii de stories.

  • Epic – Aici trebuie sa imparti stories-urile in mai multe epics. Un epic este o parte high level din care face parte un story. De exemplu, pentru un blog, eu as pune ca epic Homepage. Si sub acest epic adaug toate stories-urile care au legatura cu Homepage.
  • User story – Aici intervine limbajul acela simplu despre care iti scriam mai sus. Trebuie sa fii scurt si concis. Totul trebuie comunicat din perspectiva unor roluri:

Ca [tip de utilizator/ rol], vreau sa pot [face asta], astfel incat [sa obtin asta]

  • Criteriu de acceptanta – Aici vei detalia ce trebuie sa se intample cu acest story astfel incat sa fie considerat ca finalizat. Pot fi unul sau mai multe criterii sau teste de acceptanta.
  • Observatii – Ca de obicei, un camp de notite este foarte binevenit. Aici vei adauga informatii care nu pot fi cuprinse in celelalte campuri.
  • [Optional] Dependente – Daca exista vreo dependenta de alt task sau trebuie facut ceva inainte de intra in lucru. Acest camp este folositor mai mult atunci cand fisierul de User Stories are si rol de organizare a task-urilor, samd.
  • [Optional] Solicitant – Este util atunci cand lucreaza mai multe persoane in acelasi document si trebuie sa poti urmari ownership-ul pe stories.

Fisierul poate fi descarcat de aici

S-au documentat fluxuri de lucru si navigare

Pentru fluxuri eu am folosit Overflow – stiu ca este scump, dar it gets the job done. Gasesti multe tool-uri pentru flow design, dar depinde de tipul de proiect. Trebuie sa documentezi si sa-ti imaginezi fiecare flux. In functie de tipul de proiect, fluxurile pot fi prima chestie cu care incepi si apoi te apuci de mockup/ wireframe.

Exemplu de user flow

Fisierul cu User Stories poate fi descarcat de aici

Leave a comment

Your email address will not be published. Required fields are marked *