Yhteenveto

Ei-teknisen pomosi näkee verkkosivustopyynnön kustannuksena, ei sijoituksena. Saadaksesi hyväksynnän sinun on muotoiltava verkkosivuston korjaukset liiketoimintapäätöksiksi, jotka liittyvät mittareihin, kuten kokeilun konversio, asiakaspoistuma ja tukikuorma. Tämä artikkeli antaa sinulle kuusivaiheisen viitekehyksen: nimeä liiketoimintaongelma, käännä pyyntösi rahan kielelle, mittaa toimimattomuuden hinta, suorita kirurginen testi, laita suunnitelma yhdelle sivulle ja ennakoi "tee siitä moderni" -vastaväite. Opit, miksi uudelleensuunnittelu ilman mittausta on turhamaisuusprojekti, ja miksi sisältö ja rakenne — eivät kiillotus — ohjaavat kasvua. Käytä näitä vaiheita tänään muuttaaksesi seuraavan verkkosivustoväitteesi päätökseksi, jolle pomosi sanoo kyllä.

Pomosi ei välitä verkkosivustosta. Saa hänet välittämään.

Pomosi kysyi juuri, miksi käytät toisen sprintin verkkosivustoon, kun voisit ajaa maksettuja mainoksia. Mitä vastaat?

Jos vastauksesi on "koska etusivu näyttää vanhentuneelta," olet jo hävinnyt. Uudelleensuunnittelupyyntö kuulostaa mielipiteeltä. Liiketoimintatapaus kuulostaa päätökseltä. Tässä on viitekehys, jolla teet vaihdon.

Vaihe 1: Nimeä liiketoimintaongelma, joka piilee suunnittelupyyntösi takana.

Lopeta kuvaamasta, mitä haluat muuttaa. Kuvaile, mitä nykyinen sivu maksaa yritykselle.

Katso hinnoittelusivuasi. Vastaako se kysymyksiin, jotka pysäyttävät ihmiset ilmaisen kokeilun aikana? Hinnoittelusivun tehtävä on viestiä arvoa, erottaa suunnitelmat toisistaan ja ohjata potentiaalinen asiakas ostopäätökseen. Jos sivusi piilottaa hinnan "ota yhteyttä" -lomakkeen taakse tai jättää vertailutaulukon pois, se ei ole suunnitteluvirhe — se on menetettyjen kauppojen virhe. Sano se suoraan: "Ihmiset päätyvät hinnoittelusivullemme, eivät erota suunnitelmia toisistaan ja poistuvat kuulematta koskaan myyntipuhettamme." Se on liiketoiminnan kustannus, ei esteettinen mieltymys.

Sama logiikka pätee usein kysyttyihin kysymyksiin (UKK). Toimivat UKK-osion vähentävät tukikuormaa ja rakentavat luottamusta. Jos tukitiimisi vastaa samoihin viiteen kysymykseen joka päivä, se on tunteja, jotka pomosi maksaa kahdesti. Joten pyynnöstä tulee "vähennetään tukipyyntöjä sijoittamalla vastaukset sinne, mihin potentiaaliset asiakkaat katsovat ensin," ei "siivotaan UKK-sivu."

Muotoile sitten ominaisuuksien esittely. Visuaaliset elementit, kuten kuvakaappaukset, GIF-tiedostot tai lyhyet videot, on tarkoitettu esittelemään todellista käyttäjäkokemusta. Jos esittelysi on pelkkä seinä ominaisuusluetteloita, kävijä ei voi kuvitella itseään käyttämässä tuotetta — joten he lykkäävät kokeilua tai jättävät sen kokonaan väliin. Se on konversio-ongelma, johon liittyy liiketoiminnallinen luku, vaikka et olisikaan vielä mitannut sitä.

Kun luonnostelet pyyntöä, kirjoita liiketoiminnan kustannus ensin ja liitä sitten muutossuunnitelma. Jos käännät järjestyksen, olet menettänyt pääasian.

Vaihe 2: Käännä pyyntösi heidän kielelleen.

Pomosi ajattelee tulojen, asiakaspoistuman ja ajan arvon kautta. Käännä jokainen sivu näihin termeihin. Käytä tätä karttaa keskustelun valmisteluun:

Mitä haluat muuttaa	Minkä liiketoimintaongelman se ratkaisee
Ominaisuuksien esittelyn visuaalit	Esittelee todellisen käyttäjäkokemuksen, joten kokeilun rekisteröityjät ymmärtävät arvon ennen sitoutumista
Hinnoittelusivu ja vertailutaulukko	Ohjaa kävijöitä kohti ostopäätöstä; vastaa "onko se sen arvoista" -vastaväitteeseen
API-dokumentaatio	Auttaa kehittäjiä integroitumaan nopeammin, lyhentää aikaa arvon tuottamiseen ja vähentää tukipyyntöjä
UKK-osio	Vastaa yleisiin kysymyksiin, vähentää tukipyyntöjä ja rakentaa luottamusta epäröinnin hetkellä

Karsi tämä taulukko yhteen tai kahteen riviin itse tapaamista varten. Älä tyhjennä sitä kaikkea. Valitse sivu, jonka haluat muuttaa, ja anna sen liiketoiminnallinen tulos yhdessä lauseessa. "Hinnoittelusivu ei selitä, miksi Pro-suunnitelmamme on kaksi kertaa Starter-suunnitelman arvoinen, joten lukija klikkaa pois" on täydellinen argumentti. Taulukko on vain valmistautumistasi, jotta et jaarittele.

Jos tarvitset malleja ennen myyntipuheen rakentamista, hinnoittelusivun korjaaminen alkaa näistä konversiolohkoista.

Vaihe 3: Mittaa toimimattomuuden hinta — rehellisesti.

Puuttuva vaihe useimmista pyynnöistä: ennuste. Pomosi kysyy: "Mikä on odotettu parannus?" Älä keksi prosenttilukua.

Näin sanot sen sijaan: "Emme tiedä nykyistä lukua, koska emme ole koskaan seuranneet sitä. Juuri siksi meidän pitäisi aloittaa seuranta ennen kuin muutamme mitään. Asetetaan perustaso, ajetaan testi, ja sitten meillä on todellinen luku." Tämä kuulostaa vähemmän itsevarmalta tässä hetkessä, mutta se on kaiken kaikkiaan vakuuttavampaa, koska sitä ei voi kumota.

Konkreettisesti: lisää analytiikkaasi tapahtuma, joka laskee, kuinka monta kokeilukäyttäjää katsoo hinnoittelusivua ja poistuu saman istunnon aikana. Jos luku on korkea, olet löytänyt kitkakohdan. Laske, kuinka moni tukipyyntö johtuu kysymyksestä, johon on jo vastattu dokumenteissasi. Jos tämä toistuu, olet kvantifioinut UKK:n epäonnistumisen. Kirjoita nämä luvut ylös ennen myyntipuhettasi.

Tämä on vastakkainen näkökulma: uudelleensuunnittelu ilman mittausta on turhamaisuusprojekti. Hyväksynnän saaminen "tee siitä modernin näköinen" on helppoa, ja sitten olet jumissa yrittäessäsi todistaa subjektiivisen muutoksen tuottoa. Ehdotus, joka alkaa "minun on ensin tiedettävä todellinen luku", kuulostaa johtajalta, ei markkinoijalta. Se on se asema, jonka haluat.

Vaihe 4: Ehdota kirurgista testiä, älä uudelleensuunnittelua.

Älä koskaan pyydä koko verkkosivuston peruskorjausta. Se on kallista, hidasta ja antaa pomollesi syyn sanoa ei. Valitse sen sijaan yksi sivu ja yksi muuttuja.

Mikä sivu? Käytä toimimattomuuden kustannuksen logiikkaa: sivu, jolla mitattavin kitka tapahtuu. Ehdota sitten kahden viikon kokeilua. Muuta yhtä asiaa sillä sivulla, vertaa sitä perustasoon ja joko pidä se tai palauta se. Siinä kaikki.

Luottamus tulee dokumentoiduista malleista. API-dokumentaatio, jota kehittäjät kunnioittavat eniten — yrityksiltä kuten Stripe, GitHub ja Twilio — ei vain listaa päätepisteitä; se käy läpi käytön. Ominaisuuksien esittelyt, jotka käyttävät kuvakaappauksia tai lyhyitä GIF-animaatioita näyttääkseen oikean käyttöliittymän, voittavat luettelot, koska ne vastaavat kysymykseen "Mitä minä oikeasti käytän?" Hinnoittelun UKK-osio toimii, koska se poistaa vastaväitteet juuri sillä hetkellä, kun ne syntyvät. Nämä eivät ole koristeellisia valintoja; ne ovat rakenteellisia mekaniikkoja.

Esitä testi pomollesi pieniriskisenä: "Muutamme yhden sivun, mittaamme sitä kaksi viikkoa, ja jos se ei liikuta mittaria, palautamme sen. Pahimmassa tapauksessa menetämme kaksi viikkoa ja opimme, mikä ei toimi." Se on helppo kyllä.

Vastusta halua muuttaa kahta asiaa kerralla. Jos mittari liikkuu, et tiedä, mikä muutos sen aiheutti.

Jos testattava sivu on UKK, tämä erittely UKK-sivuista konversio-omaisuutena antaa sinulle, mitä testata.

Vaihe 5: Laita suunnitelma yhdelle sivulle.

Pomosi ei lue 40-sivuisia esityksiä, eikä hän luota 10 diain tiivistelmiin, jotka piilottavat yksityiskohdat. Anna hänelle yksi sivu, jossa on viisi lohkoa:

• Ongelma — yksi lause sivun taustalla olevasta liiketoiminnan kustannuksesta.
• Korjaus — tarkka muutos (yksi sivu, yksi muuttuja).
• Mittari — luku, jota seuraat (kokeilusta maksulliseksi, tukipyynnöt, aika arvon tuottamiseen).
• Aikataulu — kaksi viikkoa, sitten päätöspiste.
• Riski — matala, koska palautat, jos mittari liikkuu väärään suuntaan.

Tämä muoto tekee kaksi asiaa. Se pakottaa sinut olemaan täsmällinen ja saa hyväksynnän tuntumaan peruutettavalta. Peruutettavaan päätökseen on paljon helpompi sanoa kyllä. Et tarvitse budjettiriviä; tarvitset hyväksytyn testin.

Nimeä arvioija ennen kuin lähetät sivun. Jos vastaus on "meidän täytyy saada muutama ihminen katsomaan sitä", olet komiteahelvetissä. Tavoitteena on yksi päättäjä ja yksi määräaika. Jos pomosi haluaa jakaa sen muille, sovi yksi arviointikokous kaikkien kanssa kerralla, jotta et menetä kahden viikon ikkunaa.

Kun sinulla on päätös, älä odota kehittäjien sykliä, joka alkaa ensi neljänneksellä. Testisivun rakentaminen ei saa kestää kuukautta. Jos sivun on oltava livenä minuuteissa hypoteesin testaamiseksi, nopeus on osa kokeilua.

Vaihe 6: Ennakoi "tee siitä moderni" -vastaväite.

Ennustettavin vastaväite on: "Minusta sivusto näyttää vain vanhentuneelta." Älä väittele tunteen kanssa. Vahvista se ja ohjaa sitten asiaan.

Vanhentuneisuus ei ole liiketoimintaongelma. Selkeä, keskinkertaisen näköinen sivu, joka selittää arvosi, konvertoi paremmin kuin upea sivu, joka hautaa viestin. Kiillotus on luottamuksen signaali; se ei ole konversiostrategia. SaaS-verkkosivustoja koskeva tutkimus tukee tätä: ominaisuuksien esittelyt voittavat, kun ne esittelevät käyttäjäkokemuksen — eivät vain silloin, kun ne näyttävät vaikuttavilta. UKK-sivut, joita nostetaan esimerkkeinä, kuten HubSpotin, Slackin ja Zendesk yrityksissä, menestyvät organisoidun sisällön ja ytimekkäiden vastausten ansiosta, eivät ulkoasun.

Joten suostu uudelleensuunnitteluun, mutta liitä siihen yksi ehto: "Uudelleensuunnittelun pitäisi sanoa [tietty arvolupaus] selvemmin kuin nykyinen sivusto." Jos uusi muotoilu ei ilmaise tuotteesi arvoa selkeämmin, se epäonnistuu, olipa se kuinka modernin näköinen tahansa. Tämä muuttaa makukiistan mitattavaksi tavoitteeksi.

Vastusta kiusausta luvata tulolukua visuaalisesta päivityksestä. Et voi ennustaa sitä, ennen kuin olet ajanut testin.

Pidä koko argumentti sidottuna tuloihin. Toistettava järjestelmä yhtenäisten SaaS-verkkosivustojen rakentamiseen näyttää, miten kohdistat jokaisen sivun tähän tavoitteeseen, ettet käy tätä taistelua sivu kerrallaan.

Lopuksi

Lopeta verkkosivuston muutosten esittäminen suunnittelun mielipiteinä. Esitä ne liiketoimintapäätöksinä, joissa on mittari, testi ja määräaika. Aloita sivuilta, joilla kävijäsi päättävät jäädä vai lähteä: hinnoittelu, UKK, API-dokumentit ja ominaisuuksien esittely. Mittaa perustaso ennen kuin muutat mitään. Testaa yhtä sivua kahden viikon ajan. Laita suunnitelma yhdelle sivulle. Ja kun pomosi sanoo "tee siitä moderni", ohjaa hänet "tee siitä selkeä."

Seuraavan kerran, kun kysymys tulee esiin — "miksi kosket verkkosivustoa uudelleen?" — et jäädy. Sinulla on jo numero, testi ja yhden sivun suunnitelma edessäsi. Se on ero luvan kysymisen ja liiketoimintatapauksen ajamisen välillä.