Sažetak

Vaš ne-tehnički šef vidi zahtjev za web stranicu kao trošak, a ne kao ulaganje. Da biste dobili odobrenje, morate preoblikovati popravke web stranice u poslovne odluke povezane s metrikama poput konverzije probnog razdoblja, odljeva korisnika i opterećenja podrške. Ovaj članak daje vam okvir od šest koraka: imenujte poslovni problem, prevedite svoj zahtjev na jezik novca, izmjerite cijenu nečinjenja, provedite kirurški test, stavite plan na jednu stranicu i unaprijed odgovorite na prigovor "učinite moderno". Naučit ćete zašto je redizajn bez mjerenja projekt taštine i zašto sadržaj i struktura — a ne uglađenost — pokreću rast. Iskoristite ove korake danas da pretvorite svoj sljedeći argument o web stranici u odluku na koju će vaš šef reći da.

Vašem šefu nije stalo do web stranice. Natjerajte ga da mu bude stalo.

Vaš šef upravo je pitao zašto trošite još jedan sprint na web stranicu kada biste mogli pokretati plaćene oglase. Što mu odgovarate?

Ako je vaš odgovor "jer početna stranica izgleda zastarjelo", već ste izgubili. Zahtjev za redizajn zvuči kao mišljenje. Poslovni slučaj zvuči kao odluka. Evo okvira za tu promjenu.

Korak 1: Imenujte poslovni problem skriven u vašem dizajnerskom zahtjevu.

Prestanite opisivati što želite promijeniti. Opišite koliko trenutačna stranica košta posao.

Pogledajte svoju stranicu s cijenama. Odgovara li na pitanja koja zaustavljaju ljude tijekom besplatnog probnog razdoblja? Zadatak stranice s cijenama je prenijeti vrijednost, razlikovati planove i usmjeriti potencijalnog kupca prema odluci o kupnji. Ako vaša stranica skriva cijenu iza obrasca "kontaktirajte nas" ili preskače tablicu usporedbe, to nije greška u dizajnu — to je greška koja uzrokuje gubitak prodaje. Recite to izravno: "Ljudi dođu na našu stranicu s cijenama, ne mogu razlikovati planove i odu a da nikad ne čuju našu ponudu." To je poslovni trošak, a ne estetska preferencija.

Ista logika vrijedi i za vaš FAQ. Učinkoviti odjeljci s čestim pitanjima smanjuju opterećenje podrške i grade povjerenje. Ako vaš tim podrške svaki dan odgovara na istih pet pitanja, to su sati koje vaš šef plaća dvaput. Stoga zahtjev postaje "smanjimo broj zahtjeva podršci tako što ćemo odgovore staviti tamo gdje potencijalni kupci prvo gledaju", a ne "pospremimo stranicu s FAQ-om".

Zatim prevedite prikaz značajki. Vizuali poput snimaka zaslona, GIF-ova ili kratkih videozapisa postoje kako bi prikazali stvarno korisničko iskustvo. Ako je vaš prikaz zid s grafičkim oznakama značajki, posjetitelj se ne može zamisliti u korištenju proizvoda — pa odgađa probu ili je potpuno preskače. To je problem konverzije s poslovnim brojem koji mu je pridružen, čak i ako ga još niste izmjerili.

Kada sastavljate zahtjev, prvo napišite poslovni trošak, zatim dodajte dizajnersku promjenu. Obrnite redoslijed i izgubili ste poantu.

Korak 2: Prevedite svoj zahtjev na njegov jezik.

Vaš šef razmišlja u prihodu, odljevu korisnika i vremenu do vrijednosti. Prevedite svaku stranicu na te pojmove. Iskoristite ovu kartu za pripremu razgovora:

Što želite promijeniti	Poslovni problem koji rješava
Vizuali prikaza značajki	Prikazuje stvarno korisničko iskustvo, tako da oni koji se prijave na probu shvate vrijednost prije obveze
Stranica s cijenama i tablica usporedbe	Usmjerava posjetitelje prema odluci o kupnji; odgovara na prigovor "vrijedi li to"
API dokumentacija	Pomaže developerima da se brže integriraju, skraćujući vrijeme do vrijednosti i smanjujući zahtjeve podrške
FAQ odjeljak	Odgovara na česta pitanja, smanjujući broj zahtjeva podrške i gradeći povjerenje u trenutku oklijevanja

Skratite ovu tablicu na jedan ili dva retka za stvarni sastanak. Nemojte iznositi sve. Odaberite stranicu koju želite promijeniti i navedite njezin poslovni ishod u jednoj rečenici. "Stranica s cijenama ne objašnjava zašto je naš Pro plan vrijedan dvostruko više od Starter plana, pa čitatelj klikne dalje" potpuni je argument. Tablica je samo vaša priprema da ne lutate.

Ako vam trebaju obrasci prije nego sastavite prezentaciju, popravljanje vaše stranice s cijenama počinje s ovim blokovima konverzije.

Korak 3: Kvantificirajte cijenu ništa nečinjenja — pošteno.

Korak koji nedostaje u većini zahtjeva: projekcija. Vaš šef će pitati: "Koji je očekivani porast?" Ne izmišljajte postotak.

Umjesto toga recite: "Ne znamo trenutačni broj jer ga nikada nismo pratili. Upravo zato bismo trebali početi pratiti prije nego išta promijenimo. Postavite osnovnu liniju, provedite test, onda ćemo imati stvarni broj." To u trenutku zvuči manje samouvjereno, ali je uvjerljivije u cjelini jer se ne može opovrgnuti.

Konkretno: dodajte događaj u svoju analitiku koji broji koliko korisnika probnog razdoblja pogleda stranicu s cijenama i zatim ode unutar iste sesije. Ako je taj broj visok, pronašli ste svoju točku trenja. Izbrojite koliko zahtjeva podršci proizlazi iz pitanja na koje je već odgovoreno u vašoj dokumentaciji. Ako se to ponavlja, kvantificirali ste neuspjeh FAQ-a. Zapišite te brojeve prije nego krenete u prezentaciju.

Ovo je kontradiktorna poanta: redizajn bez mjerenja projekt je taštine. Dobiti odobrenje za "učinite da izgleda moderno" lako je, a onda ste zaglavili pokušavajući dokazati povrat na subjektivnu promjenu. Prijedlog koji počinje s "Prvo moram znati stvarni broj" zvuči kao menadžer, a ne kao marketer. To je pozicija koju želite.

Korak 4: Predložite kirurški test, a ne redizajn.

Nikada ne tražite potpunu obnovu web stranice. To je skupo, sporo i daje vašem šefu razlog da kaže ne. Umjesto toga, odaberite jednu stranicu i jednu varijablu.

Koju stranicu? Upotrijebite logiku cijene nečinjenja: stranicu na kojoj se događa najmjernije trenje. Zatim predložite dvotjedni eksperiment. Promijenite jednu stvar na toj stranici, usporedite je s osnovnom linijom i zadržite je ili vratite na staro. To je to.

Samopouzdanje dolazi iz dokumentiranih obrazaca. API dokumentacija koju developeri najviše poštuju — od tvrtki poput Stripea, GitHuba i Twilija — ne navodi samo krajnje točke; provodi kroz upotrebu. Prikazi značajki koji koriste snimke zaslona ili kratke GIF-ove da pokažu stvarno sučelje pobjeđuju nabrajanja jer odgovaraju na pitanje "Što ću zapravo koristiti?" FAQ odjeljak s cijenama funkcionira jer razbija prigovore točno u trenutku kada se pojave. To nisu dekorativni izbori; to su strukturalni mehanizmi.

Predstavite test svom šefu kao niskorizičan: "Promijenit ćemo jednu stranicu, mjeriti je dva tjedna i ako ne pomakne metriku, vraćamo se na staro. U najgorem slučaju izgubimo dva tjedna i naučimo što ne funkcionira." To je lako odobriti.

Oduprite se porivu da promijenite dvije stvari odjednom. Ako se metrika pomakne, nećete znati koja je promjena to uzrokovala.

Ako je stranica koju testirate FAQ, ova analiza FAQ stranica kao sredstva konverzije dat će vam što testirati.

Korak 5: Stavite plan na jednu stranicu.

Vaš šef ne čita prezentacije od 40 stranica i ne vjeruje sažecima od 10 slajdova koji skrivaju detalje. Dajte mu jednu stranicu s pet blokova:

• Problem — jedna rečenica o poslovnom trošku iza stranice.
• Popravak — točna promjena (jedna stranica, jedna varijabla).
• Metrika — broj koji ćete promatrati (od probnog razdoblja do plaćanja, zahtjevi podrške, vrijeme do vrijednosti).
• Vremenski okvir — dva tjedna, zatim točka odluke.
• Rizik — nizak jer ćete se vratiti na staro ako se metrika pomakne u pogrešnom smjeru.

Ovaj format čini dvije stvari. Prisiljava vas da budete precizni i čini odobrenje reverzibilnim. Reverzibilnu odluku puno je lakše prihvatiti. Ne trebate proračunsku stavku; trebate odobreni test.

Imenujte pregledavača prije nego pošaljete stranicu. Ako je odgovor "trebamo nekoliko ljudi da to pogledaju", u odboru ste paklu. Cilj je jedan donositelj odluka i jedan rok. Ako vaš šef želi to podijeliti s drugima, zakažite jedan sastanak za pregled sa svima odjednom kako ne biste izgubili dvotjedni prozor.

Jednom kada dobijete tu odluku, ne čekajte ciklus developera koji počinje sljedeći kvartal. Testna stranica ne bi trebala trajati mjesec dana za izradu. Ako stranica treba biti dostupna u roku od nekoliko minuta kako biste isprobali hipotezu, ta brzina dio je eksperimenta.

Korak 6: Unaprijed neutralizirajte prigovor "učinite moderno".

Najpredvidljiviji prigovor je: "Samo mislim da stranica izgleda zastarjelo." Ne raspravljajte se s osjećajem. Potvrdite ga, a zatim preusmjerite na sadržaj.

Zastarjelost nije poslovni problem. Jasna, prosječno izgledajuća stranica koja objašnjava vašu vrijednost pretvorit će posjetitelje bolje od prekrasne stranice koja skriva poruku. Uglađenost je signal povjerenja; nije strategija konverzije. Istraživanja o SaaS web stranicama to podržavaju: prikazi značajki pobjeđuju kada demonstriraju korisničko iskustvo — ne kada samo izgledaju impresivno. FAQ stranice koje se često navode kao primjeri, iz tvrtki poput HubSpota, Slacka i Zendeska, uspijevaju zbog organiziranog sadržaja i sažetih odgovora, a ne zbog ukrasa.

Stoga pristanite na redizajn, ali mu dodajte jedan uvjet: "Redizajn bi trebao jasnije reći [specifična vrijednosna ponuda] od trenutačne stranice." Ako novi dizajn ne artikulira vrijednost vašeg proizvoda na jasniji način, ne uspijeva, bez obzira na to koliko moderno izgleda. To pretvara raspravu o ukusu u mjerljiv cilj.

Oduprite se iskušenju da obećate broj prihoda od vizualnog osvježenja. Niste u poziciji to predvidjeti dok ne provedete test.

Držite cijeli argument povezan s prihodom. Ponovljivi sustav za izgradnju koherentnih SaaS web stranica pokazuje vam kako uskladiti svaku stranicu s tim ciljem kako se ne biste borili stranicu po stranicu.

Zaključak

Prestanite prodavati promjene web stranice kao dizajnerska mišljenja. Prodajte ih kao poslovne odluke s metrikom, testom i rokom. Počnite sa stranicama na kojima vaši posjetitelji odlučuju hoće li ostati ili otići: cijene, FAQ, API dokumentacija i prikaz značajki. Izmjerite osnovnu liniju prije nego išta promijenite. Testirajte jednu stranicu dva tjedna. Stavite plan na jednu stranicu. I kada vaš šef kaže "učinite moderno", preusmjerite na "učinite jasno".

Sljedeći put kad se pojavi to pitanje — "zašto opet diraš web stranicu?" — nećete se ukočiti. Već ćete imati broj, test i jednosatni plan pred sobom. To je razlika između traženja dopuštenja i vođenja poslovnog slučaja.