Kopsavilkums

Jūsu ne-tehniskais priekšnieks uztver mājaslapas pieprasījumu kā izdevumu, nevis ieguldījumu. Lai saņemtu apstiprinājumu, jums ir jāpārformulē mājaslapas labojumi kā biznesa lēmumi, kas saistīti ar tādiem rādītājiem kā izmēģinājuma konversija, atbirums un atbalsta slodze. Šis raksts sniedz sešu soļu ietvaru: nosauciet biznesa problēmu, pārvērtiet savu pieprasījumu naudas valodā, izmēriet bezdarbības izmaksas, veiciet precīzu testu, ievietojiet plānu vienā lapā un novērsiet iebildumu 'padarīt mūsdienīgu'. Jūs uzzināsiet, kāpēc pārveide bez mērījumiem ir iedomības projekts un kāpēc saturs un struktūra — nevis pulēts izskats — virza izaugsmi. Izmantojiet šos soļus jau šodien, lai pārvērstu savu nākamo mājaslapas argumentu lēmumā, kuram jūsu priekšnieks teiks 'jā'.

Jūsu priekšniekam vienalga par mājaslapu. Padari to viņam svarīgu.

Jūsu priekšnieks tikko jautāja, kāpēc jūs tērējat vēl vienu sprintu mājaslapai, ja varētu palaist apmaksātas reklāmas. Ko jūs atbildēsit?

Ja jūsu atbilde ir "jo mājaslapas sākumlapa izskatās novecojusi", jūs jau esat zaudējis. Pārveides pieprasījums izklausās kā viedoklis. Biznesa pamatojums izklausās kā lēmums. Lūk, ietvars, kā to panākt.

1. solis: Nosauciet biznesa problēmu, kas slēpjas jūsu dizaina pieprasījumā.

Pārtrauciet aprakstīt, ko vēlaties mainīt. Aprakstiet, cik pašreizējā lapa izmaksā uzņēmumam.

Paskatieties uz savu cenu lapu. Vai tā atbild uz jautājumiem, kas cilvēkus aptur bezmaksas izmēģinājuma laikā? Cenu lapas uzdevums ir komunicēt vērtību, atšķirt plānus un virzīt potenciālo klientu uz pirkuma lēmumu. Ja jūsu lapa slēpj cenu aiz "sazinieties ar mums" veidlapas vai izlaiž salīdzināšanas tabulu, tā nav dizaina kļūda — tā ir zaudēta pārdošana. Sakiet to tieši: "Cilvēki nonāk mūsu cenu lapā, nevar atšķirt plānus un aiziet, nekad neuzzinot mūsu piedāvājumu." Tās ir biznesa izmaksas, nevis estētiska izvēle.

Tā pati loģika attiecas uz jūsu BUJ. Efektīvas BUJ sadaļas samazina atbalsta slodzi un veido uzticību. Ja jūsu atbalsta komanda katru dienu atbild uz tiem pašiem pieciem jautājumiem, tās ir stundas, par kurām priekšnieks maksā divreiz. Tāpēc pieprasījums kļūst "samazināsim atbalsta biļetes, ievietojot atbildes tur, kur potenciālie klienti vispirms meklē", nevis "sakopsim BUJ lapu".

Pēc tam pārvērtiet funkciju demonstrējumu. Vizuālie materiāli, piemēram, ekrānuzņēmumi, GIF attēli vai īsi video, pastāv, lai parādītu faktisko lietotāja pieredzi. Ja jūsu demonstrējums ir funkciju saraksts ar punktiem, apmeklētājs nevar iedomāties sevi lietojam produktu — tāpēc viņi atliek izmēģinājumu vai izlaiž to pavisam. Tā ir konversijas problēma ar biznesa skaitli, pat ja vēl neesat to izmērījis.

Kad formulējat pieprasījumu, vispirms uzrakstiet biznesa izmaksas, pēc tam pievienojiet dizaina izmaiņas. Apgrieziet secību un esat pazaudējis būtību.

2. solis: Pārvērtiet savu pieprasījumu viņu valodā.

Jūsu priekšnieks domā ieņēmumos, atbirumā un laikā līdz vērtībai. Pārvērtiet katru lapu šajos terminos. Izmantojiet šo karti, lai sagatavotos sarunai:

Ko vēlaties mainīt	Kādu biznesa problēmu tas atrisina
Funkciju demonstrējuma vizuālie materiāli	Parāda reālo lietotāja pieredzi, lai izmēģinājuma reģistrācijas lietotāji saprastu vērtību pirms apņemšanās
Cenu lapa un salīdzināšanas tabula	Virza apmeklētājus uz pirkuma lēmumu; atbild uz iebildumu "vai tas ir tā vērts"
API dokumentācija	Palīdz izstrādātājiem ātrāk integrēt, samazinot laiku līdz vērtībai un atbalsta pieprasījumus
BUJ sadaļa	Atbild uz bieži uzdotiem jautājumiem, samazinot atbalsta biļetes un veidojot uzticību vilcināšanās brīdī

Sagrieziet šo tabulu līdz vienai vai divām rindām faktiskajai sapulcei. Neizgāziet visu. Izvēlieties lapu, kuru vēlaties mainīt, un sniedziet tās biznesa rezultātu vienā teikumā. "Cenu lapa nepaskaidro, kāpēc mūsu Pro plāns ir dubultu Starter plāna vērtībā, tāpēc lasītājs aiziet prom" ir pilnīgs arguments. Tabula ir tikai jūsu sagatavošanās, lai jūs neplāpātu.

Ja jums ir nepieciešami paraugi pirms runas sagatavošanas, cenu lapas labošana sākas ar šiem konversijas blokiem.

3. solis: Godīgi kvantificējiet bezdarbības izmaksas.

Lielākajā daļā pieprasījumu trūkst prognozes. Jūsu priekšnieks jautās: "Kāds ir paredzamais pieaugums?" Neizdomājiet procentus.

Lūk, ko tā vietā sakiet: "Mēs nezinām pašreizējo skaitli, jo nekad to neesam izsekojuši. Tieši tāpēc mums jāsāk izsekot pirms kaut ko mainām. Iestatiet bāzes līniju, veiciet testu, tad mums būs reāls skaitlis." Šobrīd tas izklausās mazāk pārliecinoši, bet kopumā ir pārliecinošāk, jo to nevar atspēkot.

Konkrēti: pievienojiet savai analītikai notikumu, kas uzskaita, cik daudz izmēģinājuma lietotāju skatās cenu lapu un pēc tam atstāj to tajā pašā sesijā. Ja šis skaitlis ir liels, esat atradis savu berzes punktu. Saskaitiet, cik atbalsta biļešu rodas no jautājuma, uz kuru jau ir atbilde jūsu dokumentācijā. Ja tas atkārtojas, esat kvantificējis BUJ neveiksmi. Pierakstiet šos skaitļus pirms savas runas.

Tas ir pretējais viedoklis: pārveide bez mērījumiem ir iedomības projekts. Saņemt apstiprinājumu "padarīt to mūsdienīgu" ir viegli, un tad jums jāmēģina pierādīt atdevi no subjektīvas izmaiņas. Priekšlikums, kas sākas ar "man vispirms jāzina reālais skaitlis", izklausās pēc vadītāja, nevis mārketinga speciālista. Tā ir pozīcija, kuru vēlaties.

4. solis: Piedāvājiet precīzu testu, nevis pārveidi.

Nekad neprasiet pilnīgu mājaslapas pārstrādi. Tā ir dārga, lēna un dod jūsu priekšniekam iemeslu pateikt nē. Tā vietā izvēlieties vienu lapu un vienu mainīgo.

Kuru lapu? Izmantojiet bezdarbības izmaksu loģiku: lapu, kur notiek visizmērāmākā berze. Pēc tam piedāvājiet divu nedēļu eksperimentu. Mainiet vienu lietu šajā lapā, salīdziniet ar bāzes līniju un paturiet vai atceliet. Tas arī viss.

Pārliecība nāk no dokumentētiem modeļiem. API dokumentācija, kuru izstrādātāji visvairāk ciena — no tādiem uzņēmumiem kā Stripe, GitHub un Twilio — ne tikai uzskaita galapunktus; tā izskaidro lietošanu. Funkciju demonstrējumi, kuros izmantoti ekrānuzņēmumi vai īsi GIF, lai parādītu reālo saskarni, pārspēj punktu sarakstu, jo tie atbild: "Ko es faktiski izmantošu?" Cenu BUJ sadaļa darbojas, jo tā izkliedē iebildumus tieši tajā brīdī, kad tie rodas. Tās nav dekoratīvas izvēles; tās ir strukturālas mehānikas.

Piedāvājiet testu savam priekšniekam kā zema riska: "Mēs mainīsim vienu lapu, mērīsim divas nedēļas, un, ja tas neietekmēs metriku, mēs atcelsim. Sliktākajā gadījumā mēs zaudējam divas nedēļas un uzzinām, kas nedarbojas." Tas ir viegls 'jā'.

Pretojieties kārdinājumam mainīt divas lietas vienlaikus. Ja metrika mainās, jūs nezināsiet, kura izmaiņa to izraisīja.

Ja lapa, kuru testējat, ir BUJ, šis BUJ lapu kā konversijas aktīva apskats sniegs jums, ko testēt.

5. solis: Ievietojiet plānu vienā lapā.

Jūsu priekšnieks nelasa 40 lappušu prezentācijas un neuzticas 10 slaidu kopsavilkumiem, kas slēpj detaļas. Dodiet viņiem vienu lapu ar pieciem blokiem:

• Problēma — viens teikums par biznesa izmaksām aiz lapas.
• Labojums — precīza izmaiņa (viena lapa, viens mainīgais).
• Metrika — skaitlis, ko novērosiet (izmēģinājuma-pirkuma konversija, atbalsta biļetes, laiks līdz vērtībai).
• Laika posms — divas nedēļas, tad lēmuma punkts.
• Risks — zems, jo atcelsiet, ja metrika virzīsies nepareizajā virzienā.

Šis formāts veic divas lietas. Tas liek jums būt precīzam un padara apstiprinājumu atgriezenisku. Atgriezeniskam lēmumam ir daudz vieglāk pateikt 'jā'. Jums nav nepieciešama budžeta pozīcija; jums ir nepieciešams apstiprināts tests.

Nosauciet recenzentu pirms lapas nosūtīšanas. Ja atbilde ir "mums vajag, lai daži cilvēki to apskata", jūs esat komiteju ellē. Mērķis ir viens lēmumu pieņēmējs un viens termiņš. Ja jūsu priekšnieks vēlas to apspriest, ieplānojiet vienu apskates sapulci ar visiem vienlaikus, lai nezaudētu divu nedēļu logu.

Kad esat saņēmis lēmumu, negaidiet izstrādātāju ciklu, kas sāksies nākamajā ceturksnī. Testa lapas izveide nedrīkst aizņemt mēnesi. Ja lapai jābūt tiešsaistē dažu minūšu laikā, lai pārbaudītu hipotēzi, šī ātrums ir daļa no eksperimenta.

6. solis: Novērsiet iebildumu "padarīt mūsdienīgu".

Visprognozējamākais iebildums ir: "Man vienkārši šķiet, ka vietne izskatās novecojusi." Nestrīdieties ar sajūtu. Atzīstiet to, pēc tam novirziet uz saturu.

Novecojusi nav biznesa problēma. Skaidra, vidēja izskata lapa, kas izskaidro jūsu vērtību, konvertēs labāk nekā satriecoša lapa, kas apglabā vēstījumu. Pulēts izskats ir uzticības signāls; tā nav konversijas stratēģija. Pētījumi par SaaS vietnēm to apstiprina: funkciju demonstrējumi uzvar, kad tie parāda lietotāja pieredzi — nevis tikai izskatās iespaidīgi. BUJ lapas, kuras min kā piemērus, piemēram, HubSpot, Slack un Zendesk, gūst panākumus, pateicoties sakārtotam saturam un kodolīgām atbildēm, nevis hromam.

Tāpēc piekrītiet pārveidei, bet pievienojiet tai vienu nosacījumu: "Pārveidei vajadzētu skaidrāk nekā pašreizējā vietne izteikt [konkrēto vērtības piedāvājumu]." Ja jaunais dizains neizskaidro jūsu produkta vērtību skaidrāk, tas neizdodas, lai cik mūsdienīgs tas izskatītos. Tas pārvērš gaumes diskusiju par izmērāmu mērķi.

Pretojieties kārdinājumam solīt ieņēmumu skaitli no vizuālās atsvaidzināšanas. Jūs nevarat to paredzēt, kamēr neesat veicis testu.

Turiet visu argumentu saistītu ar ieņēmumiem. Atkārtojama sistēma sakarīgu SaaS vietņu veidošanai parāda, kā saskaņot katru lapu ap šo mērķi, lai jums nebūtu jācīnās par katru lapu atsevišķi.

Secinājums

Pārtrauciet piedāvāt mājaslapas izmaiņas kā dizaina viedokļus. Piedāvājiet tās kā biznesa lēmumus ar metriku, testu un termiņu. Sāciet ar lapām, kur jūsu apmeklētāji izlemj palikt vai aiziet: cenu lapa, BUJ, API dokumentācija un funkciju demonstrējums. Izmēriet bāzes līniju, pirms kaut ko maināt. Testējiet vienu lapu divas nedēļas. Ievietojiet plānu vienā lapā. Un, kad jūsu priekšnieks saka "padarīt mūsdienīgu", novirziet uz "padarīt skaidru".

Nākamreiz, kad radīsies šis jautājums — "kāpēc jūs atkal pieskaraties mājaslapai?" — jūs nesastingsiet. Jums jau būs skaitlis, tests un vienas lapas plāns priekšā. Tā ir atšķirība starp lūgt atļauju un īstenot biznesa pamatojumu.