De unde pornește cu adevărat un proiect bun?
În părțile anterioare am ajuns la o concluzie importantă - nu proiectăm un site doar pentru că o companie „are nevoie de un site nou”.
Proiectăm un instrument care să rezolve o problemă concretă.
Uneori problema este vânzarea slabă. Alteori numărul prea mic de cereri. Uneori clienții nu reușesc să găsească informațiile. Alteori vânzătorii răspund zilnic la aceleași întrebări pentru că site-ul nu transmite informațiile de bază. Se întâmplă și ca firma pur și simplu să fi crescut și site-ul anterior să nu mai reflecte dimensiunea reală a activității.
De aceea primul pas nu ar trebui să fie Photoshop, Figma sau alegerea unui framework.
Primul pas ar trebui să fie o discuție.
Mai întâi cunoaștem afacerea
Un bun proiectant UX nu trebuie să devină expert în fiecare industrie pentru care proiectează. Trebuie însă să înțeleagă suficient de bine afacerea clientului ca să știe ce probleme încearcă să rezolve.
De aceea întrebăm lucruri care la început pot părea nelegate de proiectare;
- De unde vin clienții?
- De ce aleg tocmai această companie?
- De ce pleacă?
- Ce întreabă cel mai des înainte de a cumpăra?
- Cum arată procesul de vânzare?
- Cine răspunde de gestionarea cererilor?
- Ce se întâmplă cu leadul după trimiterea formularului?
- Care produse sunt cele mai importante?
- Care servicii au cel mai mare potențial?
- Compania vrea să crească numărul cererilor, valoarea comenzilor, numărul de clienți sau, mai degrabă, să își îmbunătățească imaginea?
Doar răspunsurile la astfel de întrebări permit stabilirea a ceea ce ar trebui de fapt să proiectăm.
Discovery - înainte de a apărea primul mockup
În proiectele digitale se folosește adesea termenul Discovery.
Este etapa de cunoaștere a problemei, a utilizatorilor, a obiectivelor de business, a constrângerilor și a posibilităților tehnologice înainte de a începe proiectarea și dezvoltarea propriu-zisă.
Nu este o „pierdere de timp înainte de a începe munca”. Într-un proiect bine condus, Discovery are rolul de a limita riscul de a construi ceva care va arăta bine, dar nu va rezolva problema reală.
Putem descoperi, de exemplu, că clientul nu are deloc nevoie de un site nou.
Poate avea nevoie de o arhitectură a informației mai bună.
Sau de simplificarea procesului de cumpărare.
Sau de integrarea site-ului cu CRM-ul.
Sau de automatizarea gestionării cererilor.
Sau de o modalitate complet diferită de prezentare a ofertei.
Și tocmai de aceea uneori merită să ne oprim înainte de a porni producția.
UX nu începe cu aspectul
UX, adică User Experience, înseamnă experiența utilizatorului în timpul folosirii produsului sau serviciului.
În cazul unui site web include mult mai mult decât aspectul interfeței.
Este de asemenea:
- modul de navigare pe site,
- ușurința găsirii informațiilor,
- claritatea mesajelor,
- procesul de cumpărare,
- formulare,
- ierarhia conținutului,
- viteza efectuării sarcinilor,
- răspunsul sistemului la acțiunile utilizatorului,
- accesibilitate,
- senzația de siguranță și încredere.
De aceea UX începe înainte ca cineva să deseneze primul ecran.
Mai întâi trebuie înțeles ce încearcă utilizatorul să realizeze.
User Flow - prin ce cale trebuie să ajungă utilizatorul la scop?
Unul din instrumentele de bază în proiectarea UX este User Flow. Este descrierea traseului pe care îl parcurge utilizatorul pentru a îndeplini o anumită sarcină.
De exemplu, într-un magazin poate arăta astfel: reclamă → pagina produsului → alegerea variantei → coș → livrare → plată → confirmare comandă.
Într-o companie de servicii: Google → pagina serviciului → realizări → referințe → formular → contact cu un agent de vânzări.
Pentru un producător: motor de căutare → produs → parametri tehnici → documentație → solicitare ofertă.
Fiecare dintre aceste trasee necesită decizii de proiectare diferite.
Dacă cel mai important obiectiv al utilizatorului este cumpărarea, nu putem să-l forțăm să citească zeci de ecrane de text. Dacă însă produsul este scump, complex și necesită consultare, direcționarea prea rapidă către formular poate fi tot o soluție proastă.
UX înseamnă, printre altele, găsirea nivelului potrivit de ghidare a utilizatorului.
Wireframe - înainte să „împodobim”
Următoarea etapă poate fi wireframe, adică schema simplificată a ecranului care arată dispunerea conținutului și funcțiilor.
Wireframe nu trebuie să fie frumos. Și e bine că nu este. În această fază nu contează dacă culoarea butonului e aleasă corect.
Este vorba de răspunsuri la întrebări:
- Ce va vedea utilizatorul primul?
- Ce va fi cel mai important?
- Ce ar trebui să fie plasat mai sus?
- Unde vom pune informațiile adiționale?
- Cum trece utilizatorul la pasul următor?
- Ce se întâmplă la clic?
E puțin ca proiectarea unei locuințe.
Mai întâi stabilim unde vor fi pereții, ușile și camerele. Abia apoi ne gândim la culoarea peretelui.
Design system - ca proiectul să nu fie un amestec de elemente întâmplătoare
În proiectele mai mari apare un element important - Design System.
Este un set organizat de reguli, componente și patternuri care definesc modul de construire a interfeței.
Poate include, printre altele:
- culori,
- tipografie,
- buttoane,
- formulare,
- carduri,
- tabele,
- mesaje,
- pictograme,
- spațieri,
- reguli de responsive,
- comportamente ale componentelor.
De ce? - pentru coerența interfeței.
Dacă pe o pagină un buton se comportă într-un fel, iar pe alta total diferit, utilizatorul trebuie să învețe interfața de fiecare dată de la zero.
Design System ajută și echipa de dezvoltare. În loc să construiască componente de la zero de fiecare dată, poate folosi elementele stabilite anterior.
Asta duce la mai multă coerență, dezvoltare mai ușoară și adesea costuri mai mici de întreținere a proiectului.
Unde se mai află tehnologia în toate acestea?
Tehnologia ar trebui introdusă suficient de devreme, dar nu ar trebui să dicteze întregul proiect. Aceasta este o diferențiere importantă.
Designerul poate inventa o funcție grozavă care din punct de vedere business are sens. Developerul poate însă observa că implementarea va fi foarte costisitoare sau va crea probleme de performanță.
Pe de altă parte, developerul poate propune o soluție tehnologică foarte convenabilă de implementat, dar care din perspectiva utilizatorului nu rezolvă suficient problema.
De aceea cele mai bune proiecte apar acolo unde UX, design, development și business discută împreună de la început.
Nu în sensul: „Mai întâi designerii, apoi programatorii”.
Ci: „Gândim împreună cum să rezolvăm cel mai bine problema”.
Tehnologia nu ar trebui aleasă doar pentru că e la modă
React, Vue, Next.js, Laravel, Symfony, .NET, WordPress, headless CMS, aplicație nativă, PWA... se pot enumera multe tehnologii.
Doar că clientul nu cumpără tehnologie. Cumpără o soluție.
De aceea întrebarea: „Ce framework vom folosi?”
este adesea mult mai puțin importantă decât: „Ce probleme trebuie rezolvate de sistem?” Abia apoi se poate alege arhitectura potrivită.
O tehnologie diferită este necesară pentru un site simplu de prezentare, alta pentru un magazin care deservește mii de comenzi și alta pentru o platformă B2B cu integrări complexe și permisiuni individuale pentru utilizatori.
Tehnologia ar trebui să rezulte din cerințe, nu cerințele din tehnologie.
Backend, frontend și locul pe care utilizatorul nu îl vede
Trebuie să ne amintim că un site web nu este doar ceea ce vedem în browser.
Frontend răspunde de partea aplicației cu care utilizatorul interacționează direct.
Backend răspunde de logica care rulează pe server - prelucrarea datelor, comunicarea cu baza, gestionarea proceselor sau integrările.
Și, între ele, există adesea multe elemente suplimentare;
- CRM.
- ERP.
- Sistem de plăți.
- Platformă de email marketing.
- Sistem de gestiune a stocurilor.
- API.
- Analitică.
- Automatizări.
- Sistem de suport clienți.
Dacă proiectăm un site nou fără a lua în considerare acest ecosistem, putem crea un frontend frumos care va funcționa ca o insulă izolată.
Dar scopul ar trebui să fie cu totul altul.
Un site bun poate face mult mai mult decât „a colecta formulare”
Un site modern poate fi parte dintr-un proces de business mai amplu;
- Utilizatorul trimite o cerere.
- Sistemul îi recunoaște subiectul.
- Lead-ul intră în CRM.
- Agentul de vânzări primește o notificare.
- Clientul primește o confirmare automată.
- Datele sunt atribuite categoriei potrivite.
- Sistemul poate verifica disponibilitatea produsului.
- Poate pregăti informații pentru agentul comercial.
- Poate declanșa un workflow specific.
În cazul unui magazin, comanda poate trece automat prin etapele de procesare. În cazul B2B, clientul poate avea acces la prețuri individuale, documente și istoricul comenzilor.
Atunci site-ul încetează să mai fie doar o „carte de vizită”. Devine parte din infrastructura de business.
Ce facem cu AI?
AI poate fi, de asemenea, un element al unui astfel de sistem. Dar, din nou, nu ar trebui adăugată doar pentru că „toată lumea are AI acum”.
Dacă un chatbot nu rezolvă nicio problemă reală, va fi doar o fereastră în plus pe site.
Dacă, însă, utilizatorul poate găsi mai rapid produsul potrivit, poate configura serviciul, poate primi un răspuns la o întrebare sau poate parcurge procesul de selecție cu ajutorul AI, atunci tehnologia devine justificată.
La fel este și cu personalizarea.
Putem afișa utilizatorului conținut diferit în funcție de comportament, sursa de intrare sau stadiul în procesul de cumpărare. Putem analiza date și prevedea mai bine nevoile clienților.
Dar întotdeauna trebuie să începem cu întrebarea: „Ce problemă rezolvăm?”
Abia apoi: „Este AI cea mai bună modalitate de a rezolva problema?”
Testăm nu doar dacă funcționează
Una dintre cele mai frecvente greșeli este testarea site-ului abia la final. Atunci descoperim că formularul e prea lung, procesul de cumpărare e neintuitiv, iar utilizatorul nu găsește informația esențială.
Cu cât descoperim mai târziu o astfel de problemă, cu atât repararea ei va fi mai scumpă.
De aceea merită testat proiectul pe etape. Putem verifica prototipul. Putem observa comportamentul utilizatorilor. Putem efectua teste de uzabilitate. Putem analiza date din Google Analytics sau alte instrumente analitice. Putem folosi înregistrări de sesiuni sau hărți termice, dacă sunt implementate în conformitate cu cerințele de confidențialitate. Putem, de asemenea, pur și simplu să vorbim cu agenții de vânzări.
Ultimul lucru este adesea subestimat.
Agentul de vânzări aude zilnic întrebările clienților; știe ce nu înțeleg; știe de ce se tem; știe ce informații trebuie oferite înainte de cumpărare.
Acesta este un mare bagaj de cunoștințe pentru proiectare.
MVP nu înseamnă „orice”
În proiectele digitale apare frecvent conceptul MVP - Minimum Viable Product.
Este prima versiune a produsului care conține setul minim de funcții necesare pentru a verifica ipotezele și a livra valoare utilizatorilor.
MVP nu ar trebui să însemne: „Să facem ceva la întâmplare și vedem mai târziu”.
Un MVP bun ar trebui să răspundă la întrebarea: „Care este cea mai mică versiune a soluției care ne permite să verificăm dacă am ales direcția corectă?”
Acest lucru este foarte important și pentru site-uri și aplicații.
În loc să construim din start treizeci de funcții, uneori e mai bine să lansăm cinci esențiale și să vedem cum le folosesc utilizatorii. Apoi dezvoltăm sistemul pe baza datelor reale, nu doar a ipotezelor de la prima întâlnire.
Site-ul nu se termină în ziua publicării
Acesta este un alt lucru pe care îl uităm adesea.
Momentul publicării site-ului este de fapt începutul vieții sale reale. Abia atunci apar utilizatorii reali. Abia atunci vedem ce conținut funcționează. Abia atunci știm ce elemente sunt ignorate. Abia atunci putem verifica dacă a crescut numărul cererilor, vânzările, timpul petrecut pe site sau alți indicatori stabiliți anterior.
De aceea proiectul ar trebui să fie dezvoltat;
- Analiză.
- Concluzii.
- Schimbare.
- Test.
- Re-analiză.
Este mai degrabă un ciclu decât un eveniment punctual.
Ce ar trebui de fapt măsurat?
Depinde de obiectivul proiectului.
Pentru un magazin online pot fi:
- rata de conversie,
- valoarea medie a comenzii,
- abandonele coșului,
- venit,
- valoarea clientului în timp.
Pentru o companie de servicii:
- numărul de lead-uri valoroase,
- rata de conversie a formularului,
- numărul de consultări programate,
- costul de achiziție al lead-ului,
- calitatea cererilor.
Pentru un site informativ:
- găsirea anumitor informații,
- implicarea utilizatorilor,
- numărul de reveniri,
- descărcări de materiale.
Nu trebuie măsurat totul. Trebuie însă să știm ce este important.
Pentru că dacă compania vrea să crească numărul de cereri valoroase, creșterea traficului pe site nu înseamnă neapărat succes. Putem avea de zece ori mai multe vizite și niciun client în plus.
Cea mai mare greșeală? Proiectarea fără răspuns la întrebarea „de ce?”
Se poate crea un site vizual excelent.
Se poate folosi un stack tehnologic modern.
Se pot pregăti animații perfecte.
Se poate îngriji fiecare pixel.
Și totuși proiectul poate să nu aducă rezultatele așteptate pentru business. - De ce?
Pentru că a lipsit răspunsul la cea mai importantă întrebare: De ce facem toate astea?
Dacă răspunsul este: „Pentru că vechiul site e urât”,
asta e puțin cam insuficient.
Dacă însă răspunsul este: „Vrem să creștem numărul de cereri de la clienți B2B, să scurtăm timpul până la găsirea serviciului potrivit și să eliberăm departamentul de vânzări de întrebările repetitive”,
brusc avem o problemă concretă de rezolvat.
Și putem proiecta o soluție.
La Web24 nu vrem doar să livrăm site-uri
Este diferența dintre executarea unei comenzi și colaborarea tehnologică.
Dacă clientul vine cu o idee concretă, nu înseamnă că sarcina noastră este să o implementăm fără reflecție.
Sarcina noastră este și să spunem: „Are sens”.
Sau: „Se poate face mai bine”.
Sau: „Tehnic putem construi asta, dar nu vedem justificare de business”.
Sau: „Înainte de a face asta vom verifica dacă utilizatorii chiar au nevoie de ea”.
Uneori cea mai bună decizie de proiect este adăugarea unei funcții. Uneori, eliminarea ei. Uneori, schimbarea completă a presupunerilor.
Și tocmai aici stă experiența echipei - nu în a putea construi totul, ci în a recunoaște ce merită cu adevărat construit.
Nu există două proiecte identice
Revenim la punctul de plecare.
Putem avea doi clienți din aceeași industrie. Putem avea doi producători. Două magazine. Două case de avocatură. Două software house-uri.
Site-urile lor pot arăta similar. Dar nu ar trebui să fie identice doar pentru că operează în aceeași categorie.
Pentru că îi diferențiază oamenii. Strategia. Procesul de vânzare. Oferta. Bugetul. Tehnologia. Clienții. Obiectivele.
Și tocmai de aceea fiecare proiect necesită decizii proprii.
Nu întotdeauna spectaculoase. Nu întotdeauna revoluționare. Dar conștiente.
Site-ul ca instrument, nu ca decor
Un site bine proiectat ar trebui să fie pentru o companie ceva mai mult decât o carte de vizită digitală.
Ar trebui să ajute utilizatorul să ia o decizie. Ar trebui să faciliteze vânzarea. Ar trebui să răspundă la întrebări. Ar trebui să construiască încredere. Ar trebui să susțină angajații. Ar trebui să se integreze cu celelalte sisteme acolo unde are sens.
Și, mai presus de toate, ar trebui să îndeplinească un obiectiv de business concret.
De aceea nu există un singur răspuns la întrebarea: „Cum ar trebui să arate un site bun?”
O întrebare mai bună este: „Cum ar trebui să funcționeze site-ul acestei companii concrete pentru a o ajuta să-și atingă obiectivele?”
Și de la această întrebare ar trebui să pornească fiecare proiect bun.
La final - regula cea mai importantă
Nu proiectăm site-ul pentru ca clientul să poată spune: „Ce frumos!”
Proiectăm pentru ca, după câteva luni, clientul să poată spune: „Asta ne ajută cu adevărat să facem business”.
Pentru că diferența între un site frumos și un produs digital bun nu este adesea vizibilă pe primul ecran.
Se vede abia în rezultate.
Rezumatul seriei
În această serie ne-am uitat la motivele pentru care nu proiectăm două site-uri identice.
Am pornit de la o presupunere simplă: aceeași industrie nu înseamnă același business.
Apoi am arătat cum strategia companiei, modul de vânzare, publicul țintă și nevoile utilizatorilor influențează UX, arhitectura informației și funcționalitățile.
În ultima parte am parcurs procesul de proiectare - de la Discovery și cunoașterea afacerii, prin User Flow, wireframe-uri și Design System, până la tehnologie, integrări, testare, analiză și dezvoltare ulterioară.
Pentru că un proiect individual nu înseamnă pur și simplu „un alt aspect”.
Înseamnă decizii diferite rezultate din probleme diferite.
Și tocmai de aceea fiecare companie ar trebui să primească o soluție proiectată pentru ea, nu pentru „o companie medie din industrie”.
