Santrauka

Jūsų netechninis bosas svetainės užklausą vertina kaip išlaidas, o ne investiciją. Norėdami gauti pritarimą, turite performuluoti svetainės pataisymus kaip verslo sprendimus, susijusius su tokiais rodikliais kaip bandomosios versijos konversija, klientų praradimas (churn) ir pagalbos apkrova. Šiame straipsnyje pateikiama šešių žingsnių sistema: įvardykite verslo problemą, išverskite savo prašymą į pinigų kalbą, įvertinkite neveikimo kainą, atlikite chirurginį testą, sudėkite planą į vieną puslapį ir iš anksto atsakykite į „padarykite moderniau“ prieštaravimą. Sužinosite, kodėl pertvarkymas be matavimų yra tuštybės projektas ir kodėl turinys bei struktūra – ne blizgesys – skatina augimą. Naudokite šiuos veiksmus jau šiandien, kad kitą svetainės argumentą paverstumėte sprendimu, kuriam jūsų bosas pasakytų „taip“.

Jūsų bosui nerūpi svetainė. Priverskite jį susirūpinti.

Jūsų bosas ką tik paklausė, kodėl skiriate dar vieną sprintą svetainei, kai galėtumėte vykdyti mokamas reklamas. Ką atsakysite?

Jei jūsų atsakymas yra „nes pagrindinis puslapis atrodo pasenęs“, jūs jau pralaimėjote. Pertvarkymo prašymas skamba kaip nuomonė. Verslo atvejis skamba kaip sprendimas. Štai sistema, kaip tai pakeisti.

1 žingsnis: Įvardykite verslo problemą, slypinčią jūsų dizaino prašyme.

Nustokite apibūdinti, ką norite pakeisti. Apibūdinkite, kiek dabartinis puslapis kainuoja verslui.

Pažiūrėkite į savo kainų puslapį. Ar jis atsako į klausimus, kurie sustabdo žmones nemokamos bandomosios versijos metu? Kainų puslapio darbas – perteikti vertę, atskirti planus ir nukreipti potencialų klientą pirkimo sprendimo link. Jei jūsų puslapis paslepia kainą už „susisiekite su mumis“ formos arba praleidžia palyginimo lentelę, tai ne dizaino trūkumas – tai prarasto pardavimo trūkumas. Pasakykite tiesiogiai: „Žmonės patenka į mūsų kainų puslapį, negali atskirti planų ir išeina niekada neišgirdę mūsų pasiūlymo.“ Tai verslo kaina, o ne estetinis pasirinkimas.

Ta pati logika galioja jūsų DUK (dažnai užduodami klausimai). Veiksmingi DUK skyriai sumažina pagalbos apkrovą ir didina pasitikėjimą. Jei jūsų pagalbos komanda kasdien atsako į tuos pačius penkis klausimus, tai valandos, už kurias jūsų bosas moka du kartus. Taigi prašymas tampa „sumažinkime pagalbos bilietus, pateikdami atsakymus ten, kur potencialūs klientai pirmiausia ieško“, o ne „sutvarkykime DUK puslapį“.

Tada išverskite funkcijų pristatymą. Vaizdinės medžiagos, pvz., ekrano nuotraukos, GIF ar trumpi vaizdo įrašai, skirtos parodyti realią vartotojo patirtį. Jei jūsų pristatymas yra funkcijų sąrašo siena, lankytojas negali įsivaizduoti savęs naudojant produktą – todėl jis atideda bandomąją versiją arba visai jos praleidžia. Tai konversijos problema su verslo skaičiumi, net jei dar to neišmatavote.

Kai rengiate prašymą, pirma užrašykite verslo kainą, tada pridėkite dizaino pakeitimą. Pakeiskite tvarką – ir pametėte esmę.

2 žingsnis: Išverskite savo prašymą į jų kalbą.

Jūsų bosas galvoja apie pajamas, klientų praradimą ir laiką iki vertės. Išverskite kiekvieną puslapį į šiuos terminus. Naudokite šį žemėlapį pokalbiui pasiruošti:

Ką norite pakeisti	Kokią verslo problemą tai sprendžia
Funkcijų pristatymo vaizdinė medžiaga	Parodo realią vartotojo patirtį, kad bandomosios versijos užsiregistravusieji suprastų vertę prieš įsipareigodami
Kainų puslapis ir palyginimo lentelė	Nukreipia lankytojus pirkimo sprendimo link; atsako į „ar verta“ prieštaravimą
API dokumentacija	Padeda kūrėjams integruotis greičiau, sutrumpina laiką iki vertės ir sumažina pagalbos užklausas
DUK skyrius	Atsako į dažnus klausimus, sumažina pagalbos bilietus ir didina pasitikėjimą dvejonės momentu

Sutrumpinkite šią lentelę iki vienos ar dviejų eilučių tikram susitikimui. Nepateikite visko. Pasirinkite puslapį, kurį norite pakeisti, ir vienu sakiniu nurodykite jo verslo rezultatą. „Kainų puslapis nepaaiškina, kodėl mūsų Pro planas vertas dvigubai nei Starter planas, todėl skaitytojas spusteli ir išeina“ yra išsamus argumentas. Lentelė yra tik jūsų pasiruošimas, kad nereikėtų plepėti.

Jei prieš kurdami pasiūlymą jums reikia šablonų, kainų puslapio taisymas prasideda nuo šių konversijos blokų.

3 žingsnis: Įvertinkite neveikimo kainą – sąžiningai.

Trūkstamas žingsnis daugelyje prašymų: projekcija. Jūsų bosas paklaus: „Koks tikėtinas pagerėjimas?“ Nesugalvokite procentų.

Štai ką pasakykite vietoj to: „Mes nežinome dabartinio skaičiaus, nes niekada jo nesekame. Būtent todėl turėtume pradėti sekti prieš ką nors keisdami. Nustatykite pradinį lygį, atlikite testą, tada turėsime tikrą skaičių.“ Tai skamba mažiau užtikrintai, bet apskritai yra įtikinamiau, nes to negalima paneigti.

Konkrečiai: pridėkite įvykį prie savo analitikos, kuris skaičiuotų, kiek bandomosios versijos vartotojų peržiūri kainų puslapį ir tada išeina per tą pačią sesiją. Jei šis skaičius didelis, radote trinties tašką. Suskaičiuokite, kiek pagalbos bilietų kyla iš klausimo, į kurį jau atsakyta dokumentacijoje. Jei tai pasikartojanti tema, įvertinote DUK nesėkmę. Užsirašykite šiuos skaičius prieš teikdami pasiūlymą.

Tai priešinga nuomonė: pertvarkymas be matavimų yra tuštybės projektas. Gauti pritarimą „padarykite moderniau“ lengva, o tada įstringate bandydami įrodyti grąžą iš subjektyvaus pakeitimo. Pasiūlymas, kuris prasideda „pirmiausia man reikia sužinoti tikrąjį skaičių“, skamba kaip vadovo, o ne rinkodaros specialisto. Būtent tokios pozicijos jums ir reikia.

4 žingsnis: Pasiūlykite chirurginį testą, o ne pertvarkymą.

Niekada neprašykite visiško svetainės atnaujinimo. Tai brangu, lėta ir suteikia jūsų bosui pagrindą atsisakyti. Vietoj to pasirinkite vieną puslapį ir vieną kintamąjį.

Kurį puslapį? Naudokite neveikimo kainos logiką: puslapį, kuriame vyksta labiausiai išmatuojama trintis. Tada pasiūlykite dviejų savaičių eksperimentą. Pakeiskite vieną dalyką tame puslapyje, palyginkite su pradiniu lygiu ir arba palikite, arba grąžinkite. Viskas.

Pasitikėjimas kyla iš dokumentuotų modelių. API dokumentacija, kurią kūrėjai labiausiai gerbia – tokių įmonių kaip „Stripe“, „GitHub“ ir „Twilio“ – ne tik išvardija galinius taškus; ji paaiškina naudojimą. Funkcijų pristatymai, kuriuose naudojamos ekrano nuotraukos ar trumpi GIF, rodantys tikrą sąsają, laimi prieš sąrašus, nes atsako į klausimą „Ką aš iš tikrųjų naudosiu?“ Kainų DUK skyrius veikia, nes išsklaido prieštaravimus tiksliai tuo momentu, kai jie kyla. Tai ne dekoratyviniai pasirinkimai; tai struktūriniai mechanizmai.

Pateikite testą savo bosui kaip mažos rizikos: „Pakeisime vieną puslapį, matuosime dvi savaites, o jei metrika nepajudės, grąžinsime. Blogiausiu atveju prarandame dvi savaites ir sužinome, kas neveikia.“ Tai lengvas „taip“.

Pasipriešinkite norui pakeisti du dalykus vienu metu. Jei metrika pajudės, nežinosite, kuris pakeitimas ją sukėlė.

Jei puslapis, kurį testuojate, yra DUK, šis DUK puslapių, kaip konversijos turto, išskaidymas suteiks jums, ką testuoti.

5 žingsnis: Sudėkite planą į vieną puslapį.

Jūsų bosas neskaito 40 puslapių pristatymų ir nepasitiki 10 skaidrių santraukomis, kurios slepia detales. Duokite jam vieną puslapį su penkiais blokais:

• Problema — vienas sakinys apie verslo kainą, slypinčią už puslapio.
• Pataisymas — tikslus pakeitimas (vienas puslapis, vienas kintamasis).
• Metrika — skaičius, kurį stebėsite (perėjimas iš bandomosios versijos į mokamą, pagalbos bilietai, laikas iki vertės).
• Laikas — dvi savaitės, tada sprendimo taškas.
• Rizika — maža, nes grąžinsite, jei metrika pajudės netinkama kryptimi.

Šis formatas daro du dalykus. Jis verčia būti tiksliems ir leidžia jausti, kad sprendimas yra grįžtamas. Grįžtamam sprendimui daug lengviau pasakyti „taip“. Jums nereikia biudžeto eilutės; jums reikia patvirtinto testo.

Įvardykite recenzentą prieš išsiųsdami puslapį. Jei atsakymas yra „mums reikia, kad keli žmonės pažiūrėtų“, esate komiteto pragare. Tikslas – vienas sprendimų priėmėjas ir vienas terminas. Jei jūsų bosas nori tai aptarti, suplanuokite vieną peržiūros susitikimą su visais iš karto, kad neprarastumėte dviejų savaičių lango.

Kai gausite tą sprendimą, nelaukite kūrėjų ciklo, kuris prasidės kitą ketvirtį. Testo puslapio kūrimas neturėtų užtrukti mėnesį. Jei puslapiui reikia būti internete per kelias minutes, kad būtų išbandyta hipotezė, toks greitis yra eksperimento dalis.

6 žingsnis: Iš anksto atsakykite į „padarykite moderniau“ prieštaravimą.

Labiausiai nuspėjamas prieštaravimas yra: „Man tiesiog atrodo, kad svetainė atrodo pasenusi.“ Nesiginčykite su jausmu. Pripažinkite jį, tada nukreipkite į esmę.

Pasenęs nėra verslo problema. Aiškus, vidutiniškai atrodantis puslapis, kuris paaiškina jūsų vertę, konvertuos geriau nei nuostabus puslapis, slepiantis žinią. Blizgesys yra pasitikėjimo signalas; tai ne konversijos strategija. SaaS svetainių tyrimai tai patvirtina: funkcijų pristatymai laimi, kai demonstruoja vartotojo patirtį – ne tada, kai tik įspūdingai atrodo. DUK puslapiai, kurie pateikiami kaip pavyzdžiai, pvz., „HubSpot“, „Slack“ ir „Zendesk“, sėkmingi dėl organizuoto turinio ir aiškių atsakymų, o ne dėl blizgesio.

Taigi sutikite su pertvarkymu, bet pridėkite vieną sąlygą: „Pertvarkymas turėtų aiškiau pasakyti [konkretų vertės pasiūlymą] nei dabartinė svetainė.“ Jei naujas dizainas aiškiau neišreiškia jūsų produkto vertės, jis žlunga, kad ir kaip moderniai atrodytų. Tai paverčia skonio diskusiją į išmatuojamą tikslą.

Pasipriešinkite pagundai žadėti pajamų skaičių iš vizualaus atnaujinimo. Jūs negalite to numatyti, kol neatlikote testo.

Laikykite visą argumentą susietą su pajamomis. Pakartojama nuoseklių SaaS svetainių kūrimo sistema parodo, kaip suderinti kiekvieną puslapį su tuo tikslu, kad nereikėtų kovoti puslapis po puslapio.

Išvada

Nustokite siūlyti svetainės pakeitimus kaip dizaino nuomones. Siūlykite juos kaip verslo sprendimus su metrika, testu ir terminu. Pradėkite nuo puslapių, kur jūsų lankytojai nusprendžia likti ar išeiti: kainų, DUK, API dokumentacijos ir funkcijų pristatymo. Išmatuokite pradinį lygį prieš ką nors keisdami. Testuokite vieną puslapį dvi savaites. Sudėkite planą į vieną puslapį. Ir kai jūsų bosas sako „padarykite moderniau“, nukreipkite į „padarykite aiškiau“.

Kai kitą kartą iškils tas klausimas – „kodėl vėl liečiate svetainę?“ – nesustingsite. Jau turėsite skaičių, testą ir vieno puslapio planą priešais save. Tai skirtumas tarp prašymo leidimo ir verslo atvejo vykdymo.