SaaS-veebisaidid seestpoolt väljapoole: miks hinnakiri ja dokumendid on esikohal

Summary

Enamik nõuandeid SaaS-veebisaitide kohta algavad esilehest ning jätavad hinnakirja, dokumendid ja KKK hilisemaks mõtteks — seepärast need lehed lõpuks endaga vastuollu satuvad. See artikkel pooldab seestpoolt väljapoole ehitamist: alusta hinnakirja ja API dokumentatsiooniga, kus asuvad toote tegelikud piirangud, ja tuleta kõik muu nendest. See esitab kuue sammu raamistiku: kogu piirangud, ehita hinnakiri kui skeleti, käsitle API dokumente kui toote pinda, tuleta funktsioonide tutvustus töövoogudest, korja KKK päris vestlustest ning lõpeta järjepidevuskontrolliga. Lähenemine on loodud agentuuridele, kes vajavad korratavat protsessi erinevate klientide jaoks. See hõlmab ka hoiatusi selle kohta, millal raamistik on ülepingutatud ja kuidas hallata kliendi ootusi.

Enamik nõuandeid SaaS-veebisaitide ehitamiseks on pööratud pea peale. Need ütlevad, et alusta esilehest — kangelane, pealkiri, toote ekraanipilt — ning kohtle hinnakirja, dokumentatsiooni ja KKK-d lehtedena, mille täidad pärast kujunduse kinnitamist. Nädalaid hiljem lepid kokku pealkirja lubaduse "midagi piiramatut" hinnakirja tegeliku kasutuspiirangutega ning funktsioonide osa uhkeldab beetaversioonifunktsiooniga, mida API dokumendid üldse ei maini. See järjekord töötab ainult siis, kui toode on piisavalt lihtne, et vastavusse viimist pole vaja — mis on harva nii. Mis tegelikult töötab — eriti kui teed seda korduvalt täiesti erinevate klientidega — on saidi ehitamine seestpoolt väljapoole: alusta kõige piiratumate, kõige vähem glamuursete lehtedega (hinnakiri ja API dokumendid) ning lase neil genereerida esileht, funktsioonide tutvustus ja KKK. Siin on kuue sammu raamistik selle tegemiseks ja ma juhin tähelepanu kohtadele, kus see muutub ebamugavaks, sest see muutub.

Kiire kaart erinevusest, sest kogu argument toetub sellele:

	Leht esikohal (kõige levinum)	Piirangud esikohal (see raamistik)
Kust alustad	Esilehe kangelane ja visuaalid	Hinnakiri ja API dokumendid
Mis juhib teksti	Brändi lugu ja disain	Toote tegelikud piirangud ja töövood
Funktsioonide tutvustus	Loetleb kõik, mida toode teeb	Järgib teid, mida tegelikud kasutajad teevad
KKK	Kirjutatud viimaseks, oletuste põhjal	Korjatud toest ja müügist
Tulemus käivitamisel	Ebajärjekindlad väited, varjatud konfliktid	Lehed loevad ühtse tootena

Samm 1 – Loe hinnakiri läbi enne kui kirjutad ühegi sõna.

Klient annab sulle funktsioonide nimekirja, brändiesitluse ja demolingi ning küsib esilehte. Esimese kõne lõpuks arutate juba kangelase teksti ja värvilahendusi. Proovi aeglustada. Küsi hinnakirja ja plaanide piiranguid — isegi kui need on lihtsalt Google Doc märkmetega — ja avastad, et kogu projekt muutub.

Sa otsid kõvasid piiranguid: mida tähendab kasutajakoht, kuidas andmekasutust loetakse, millised funktsioonid on millise plaanitaseme juures, kas on API ja mida see tegelikult oskab. Need piirangud on maapealne tõde. Iga hilisem turundusväide peab nendega kokku puutudes vastu pidama.

Siin on tüüpiline stsenaarium. Klient on ajajälgimise tööriist: tasuta plaan, Pro plaan, Ettevõtte plaan. Müügimaterjal ütleb "skaleerub igale meeskonnale". Pro leht ütleb "piiramatud projektid". Kuid tugimeeskond kinnitab, et Pro kontod on tegelikult piiratud 10 aktiivse projektiga tööruumi kohta ning API dokumendid ütlevad, et projektil võib olla kuni 50 liiget. Esilehte ei kirjutata enne, kui keegi selle lahendab, sest "piiramatud projektid" on nüüd juriidiline küsimus, mitte teksti küsimus. Kui oleksid alustanud esilehest, oleksid kirjutanud "piiramatud projektid" kangelase teksti ja avastanud konflikti kaks nädalat hiljem, pärast disaini kinnitamist. Piirangutest alustamine tähendab, et konflikt ilmneb esimesel nädalal, kui selle parandamine ei maksa midagi.

Mida täpselt peaksid selles etapis koguma? Plaanide määratlused ja funktsioonide võrdlustabel plaanide kaupa. API dokumentatsioon või vähemalt nimekiri, mida API saab ja ei saa teha. Tugimeeskonna kõige sagedasemad küsimused (sellest lähemalt sammus 5). Müügimaterjal, hoiatusega, et müügimaterjal on koht, kus elab fantaasia. Ja tegelik toode, mis on avatud, et näha seadete lehti, kus piiranguid rakendatakse — sest toode ise on lõplik autoriteet. Seadete ekraan, mis ütleb "Maksimaalselt 10 projekti", tühistab iga tabeli.

See etapp ei anna tarnitavat tulemust. See annab faktide loendi — piirangud, määratlused, erandid — mille vastu kontrollid iga teist lehte. Agentuuri jaoks on see ka samm, mis eraldab korratava töö tulekahjukustutamisest. Kirjuta piirangud ühisesse dokumenti ja oled loonud tõe allika, millele iga tulevane lehe värskendus viitab.

Samm 2 – Ehita hinnakiri kogu saidi skeletina.

Hinnakiri ei tundu kohana, kust alustada. See on tabel numbrite ja plaanide nimedega — saidi kõige vähem glamuursem leht. Kuid see on toote leping kasutajaga ja seal otsustatakse kogu saidi infotehnoloogia arhitektuur. Kui saidi ülesanne on harida külastajat, kuni ta on valmis registreeruma, siis hinnakiri on koht, kus see haridus koondub. Iga funktsioon, mis on ostuotsuse jaoks oluline, on seal nimetatud; iga piirang, mis on oluline, on seal välja toodud või lingitud.

Võta ajajälgimise tööriist. Kolm plaani: tasuta, Pro, Ettevõte. Tabel vajab veerge, mis peegeldavad seda, kuidas toode tegelikult segmentidest koosneb — projektide arv, integratsioonid, aruandluse sügavus. Iga lahtri kohta on vaja ausat väärtust, mitte püüdlikku. Kui Pro sisaldab 10 aktiivset projekti, siis lahter ütleb 10 aktiivset projekti, lingiga hinnakirja KKK-le, mis selgitab, mida "aktiivne" tähendab ja mis juhtub piiri ületamisel. Üks raskemaid otsuseid on see, mida öelda plaani kohta, mida kõige rohkem soovid, et külastajad ostaksid. Paljud hinnakirjad muudavad ankruplaani ilmseks — esiletõstetuna, silt "Kõige populaarsem" — ja seda ümbritsev tekst selgitab, miks see sobib sellele külastajale. Ajajälgimise tööriista puhul on Pro ankur: see on koht, kus integratsioonid ja aruandluse sügavus tegelikult algavad, seega peaks leht seda selgesõnaliselt välja tooma, mitte eeldama, et külastaja loeb tabeli ise läbi ja järeldab seda.

Samuti otsustad siin, millised terminid on kogu saidil kanoonilised. Kui toode nimetab gruppe "tööruumideks" hinnakirjas, aga turundustekst ütleb "meeskonnad", siis iga järgnev leht pärib selle ebajärjekindluse. Hinnakirja esimesena kirjutamine sunnib sind sõnavara valima ja sa peaksid valima selle, mida toode ise kasutab — sest toode ja dokumendid peavad sellega ühtima ning turundusleht on see, mis saab painduda.

Hinnakiri vajab ka oma KKK-d. Küsimused, mis seal on, on seotud plaanide konkreetse mehaanikaga: mis loetakse kasutajakohaks, mis juhtub, kui oma plaani alandad, kas arveldus on aastane või igakuine, mida "aktiivne" tähendab projekti puhul. On olemas hästi välja arenenud praktika hinnakirjade struktureerimiseks konversiooniks ja mehaanikat tasub uurida. Kuid selle raamistiku sees ei ole hinnakirja ülesanne ainult konverteerida — see on fikseerida faktilised otsused, millele iga teine leht allub. Kui soovid sügavamat mehaanikat, siis see juhend SaaS-i hinnakirjade parendamiseks käsitleb seda üksikasjalikult.

Samm 3 – Käsitle API dokumentatsiooni toote pinnana, mitte kasutusjuhendina.

Arendaja hindab ajajälgimise tööriista. Nende ettevõte peab automaatselt tõmbama ajaaruanded palgasüsteemi. Dokumendid on korraldatud tähestikuliselt lõpp-punktide järgi: /projects, /reports, /timesheets, /users. Arendajal pole aimugi, millise kõnega alustada, ja "Autentimine" jaotis eeldab teadmisi, mis puuduvad — dokumendid ei selgita kunagi, et API-võtme loote seadete lehel "Integratsioonid" all. Arendaja sulgeb vahekaardi, veendununa, et toode ei integreeru puhtalt. Ometi oli kogu vajalik teave dokumentides olemas; see oli lihtsalt korraldatud viitejuhendi järjekorras, mitte inimese kasutatavas järjekorras.

Töövoo järgi korraldatud dokumentatsioon oleks seda tulemust muutnud: "Kiire alustus", "Autendi", "Tõmba ajaaruanded", "Loo projekt", "Veebihaagid ja sünkroonimine". Iga jaotis alustab ülesandest, seejärel näitab lõpp-punkti. Kiire alustamine võib võtta viis minutit ja anda eduka API-kõne — mis on dokumentatsiooni mõistes tasuta prooviperiood. Arendaja-esimese toote jaoks on see saidi kõige veenvam leht.

Iga SaaS-i puhul, millel on API, on dokumentatsioon sinu veebisaidi leht, olenemata sellest, kas plaanisid seda nii või mitte. Tööstuse võrdluspunkt — mille on seadnud Stripe, GitHub ja Twilio — on dokumentatsioon, mis loeb nagu toode: see selgitab tööd, mida arendaja üritab teha, mitte ainult saadaolevaid lõpp-punkte. Põhimõte on, et API dokumendid on osa toote kogemusest ja need peaksid järgima sama seestpoolt-väljapoole loogikat nagu ülejäänud sait: alusta töökohtadega, mida arendaja saab teha, seejärel paljasta mehaanika.

Agentuurile on boonus see, et dokumentide kirjutamine sel viisil toob piirangute loendi pinnale — mida API tegelikult oskab, kus on kiiruse piirid, millised lõpp-punktid puuduvad — ja sa tabad need konfliktid enne, kui need ilmuvad turunduslehele. Kui API dokumentatsioon on selle kliendi saidi oluline osa, siis on olemas sügavam juhend arendajatele mõeldud dokumentide kirjutamiseks.

Samm 4 – Tuleta funktsioonide tutvustus töövoogudest, mitte funktsioonide nimekirjast.

Klient saadab sulle tabeli 40 funktsiooniga ja küsib funktsioonilehte. Lihtne vastus on ruudustik: 40 üksust, igaühel ikoon ja pealdis. Tulemus tundub põhjalik, kuid loeb mürana, sest ruudustikul pole lugu. Keegi ei külasta SaaS-veebisaiti, et kõiki funktsioone õppida; nad külastavad, et teada saada, kas see toode teeb seda üht tööd, mille pärast nad tulid. Seega peaks tutvustus olema üles ehitatud töövoogude, mitte funktsioonide nimekirja põhjal.

Tööta näide läbi. Ajajälgimise tööriista kõige levinum võidutee on kliendi tugimeeskonna andmetel meeskonna juht, kes registreerub, kutsub kolm kolleegi, loob projekti ja käivitab nädala lõpus aruande. See on töövoog. Funktsioonide tutvustus peaks seda järgima: jaotis oma meeskonna kutsumiseks (hõlmates kasutajakohti ja rolle), jaotis projekti seadistamiseks (hõlmates malle ja projektiseadeid), jaotis aruandluse juhtpaneeli jaoks (hõlmates diagramme ja ekspordivalikuid). Iga jaotis näitab ekraanipilti täpselt sellest hetkest tootes, mitte kärbitud ekraanipilti harva kasutatavast seadete paneelist. Külastaja näeb oma teed ja funktsioonid, mida ta teel näeb, on need, mis on tema jaoks olulised.

Jätkuv töövoog, veidi erineva külastaja jaoks, on juht, kes ise tööriista ei kasuta: ta kinnitab ajaaruandeid ja vaatab üle nädalaaruande. Tutvustus võib lisada sellele külastajale jaotise lõppu — "Juhtidele" — ilma narratiivi katkestamata. Tavaliselt piisab kahest töövoost alustamiseks; sa ei vaja iga persona jaoks ühte.

Hoiatus — tõeline — on see, et töövoopõhine tutvustus nõuab teadmist, mis on tavalised töövood. See nõuab vestlemist toe ja müügiga, mitte ainult tootejuhiga. Kui klient ei oska sulle öelda kolme peamist viisi, kuidas inimesed toodet kasutavad, on see esimene asi, mida parandada, sest muidu arvab veebisait. See samm näitab sageli, et tootel puudub selge põhiline töövoog — mis on tooteprobleem, mitte veebiprobleem. Märgi see ausalt; veebisait ei saa toota töövoogu, mida pole olemas. Selleks, et neid töövoogusid süstemaatiliselt järjestada, see lugu funktsioonide tutvustuse struktureerimisest konversiooniks viib läbi otsuste jada.

Samm 5 – Korja KKK toest ja müügist, mitte oma kujutlusvõimest.

Sul on kaks päeva enne saidi käivitamist ja KKK on endiselt tühi. Instinkt on kirjutada kümme küsimust õhtupoolikuga — tavaliselt küsimused, millele sa tahaksid, et toode vastaks, mitte küsimused, mida tegelikud kliendid küsivad. See on pööratud. KKK-l on konkreetne ülesanne: eemaldada viimased kahtlused külastaja ja registreerumise vahel. Tõhusad KKK lehed, nagu need, mida näed HubSpotilt, Slackilt ja Zendeskilt, töötavad, sest need on korraldatud tegelike päringute ümber, otsitavad ja lühidad. Need on kuulamise, mitte väljamõtlemise tulemus.

Realistlik stsenaarium: oled hinnakirja lehel ja tead, et ajajälgimise tööriista suurim takistus on integreerimine: "Kas see töötab QuickBooksiga?" Tugilogide ülevaade näitab, et see on kõige levinum müügieelne küsimus. See küsimus koos vastusega kuulub hinnakirja KKK-sse. Teine kõige levinum, müügikõnedest, on "Mis juhtub minu ajaaruannetega, kui tühistan?" See kuulub samuti sinna. Iga vastus lühendab müügitsüklit ja vähendab toe koormust, sest külastaja, kes näeb vastust kirjas, usaldab toodet rohkem kui külastaja, kes peab küsima.

Reegel agentuurile: ära kirjuta ühtegi KKK vastust enne, kui oled vaadanud tugipileteid, müügikõnede märkmeid ja sisseelamise e-kirju. Millised küsimused tegelikult korduvad? Need lähevad sisse. Kõik muu läheb funktsioonilehele või mitte kuhugi. Ja kui sait areneb, vaata KKK uuesti läbi — iga uus hinnamuudatus või funktsiooni käivitamine loob uusi küsimusi ja KKK on kõige odavam koht nende tabamiseks.

On ka põhjus mõelda KKK struktuurile, mitte ainult sisule. Pikk keriv küsimuste loend on raskesti skaneeritav; kategooriate kaupa rühmitamine (Arveldus, Integratsioonid, Konto haldamine) sisukorraga ülaosas muudab selle tegelikult kasutatavaks. Otsingufunktsioon aitab, kui loend kasvab üle teatud suuruse — see on lehe osa, kus disain loeb sama palju kui tekst, sest otsimatu KKK on lugematu KKK.

Veel üks asi, mis on ebamugav osa: KKK on sageli saidi kõige ausam leht, sest see on ainus leht, kus vastatakse küsimusele, mida külastaja kardab küsida. Kui küsimus tundub ebamugav, millele vastata — "Kas ma tõesti saan igal ajal tühistada?" "Kas tasuta plaan näitab reklaame?" — see ebamugav tunne on tõend, et see kuulub sinna, mitte põhjus selle välja jätmiseks. Külastajal on see küsimus sõltumata sellest, kas sa vastad; kui sa ei vasta, tuletavad nad vastuse ise ja see, mida nad tuletavad, on halvem kui tõde.

Samm 6 – Ühtlusta ja tee kvaliteedikontroll kõigil lehtedel enne kliendile näitamist.

Sa oled näitamas kliendile valmis saiti. Enne seda ava hinnakiri ja funktsioonileht kõrvuti. Kontrolli iga funktsiooni nime: kas need ühtivad? Kontrolli iga numbrit: kas hinnakiri ütleb "10 projekti", funktsioonileht "kuni 10 projekti" ja API viide "max 10" — kas kõik on sama? Kontrolli iga lubadust: kas "piiramatud projektid" on kuskil saidil, ja kui on, siis kas see on tõsi? Seejärel otsi toote enda sõnavara: kas see ütleb kõikjal "tööruumid" või libiseb "meeskondadeks"? Siin tabad, et esileht ütleb "krediitkaarti pole vaja", samas registreerumisvoog tegelikult küsib tasuta prooviperioodi jaoks krediitkaarti — täpselt see ebajärjekindluste klass, mis tapab usalduse.

Seestpoolt-väljapoole järjekorra tasuvus saabub siin. Kuna iga leht tuletati samadest piirangutest, on järjepidevuse töö kontrollimiskäik, mitte päästemissioon. Kuid ära jäta seda vahele. Ellujäänud vastuolud on peened — funktsioon nimega "kinnitused" hinnakirjas, kuid "ülevaatusvood" API dokumentides, ekraanipilt esilehel näitamas tumedat režiimi juhtpaneeli, mida toode ei paku, väide, et toode on "usaldatud kaugmeeskondade poolt", mis tuli brändiesitlusest ja ei klapi kliendi tegeliku kliendiloendiga.

Praktiline tehnika: muuda piirangute loend kvaliteedikontrolli stsenaariumiks. Käi iga leht läbi ja kontrolli iga fakti loendi vastu. See töötab, sest piirangute loend kirjutati esimesel nädalal, enne lehtede olemasolu, seega on see tõeliselt sõltumatu allikas. Kui alustad kvaliteedikontrolli disainist või mälust, jäävad märkamata faktid, mis muutusid ehitamise ajal.

Siinkohal muutub selgeks põhjus tööd järjestada. Kui lehed ehitatakse paralleelselt erinevatest allikatest, leiab see kvaliteedikontroll igal kord konflikte ja iga konflikt tähendab ümbertegemist pealtnäha valmis lehel. Kui lehed ehitatakse järjestikku ühest piirangute loendist, leiab kvaliteedikontroll trükivigu. See on erinevus korratava protsessi ja pideva kriisi vahel. Et hoida kogu sait pärast käivitamist ühte lugu rääkimas — uued funktsioonid, uued meeskonnad, uued tekstikirjutajad — vajad sama distsipliini hooldusversiooni ja raamistik SaaS-i veebisaidi loo ühtlustamiseks lehtede lõikes on loomulik järgmine samm.

Hoiatused, mis hoiavad selle ausana.

Kolm asja, mida see raamistik ei väida. Esiteks, väga varajase faasi SaaS-i puhul, millel pole API-t, on üks plaan ja üks ilmne kasutusjuhtum, on järjekord palju vähem oluline; seda saiti võid ehitada mis tahes järjekorras ja vastavusse viimine oleks tühine. Raamistik tasub end ära siis, kui on tõeline keerukus — mitu plaani, API, palju funktsioone, mitu sihtrühma. Ära rakenda seda dogmana tootele, mis on sisuliselt maandumisleht registreerumisnupuga.

Teiseks tekitab seestpoolt-väljapoole ehitamine alguses aeglaselt nähtavat edu. Klient küsis esilehte ja sina tood hinnakirja tabeli ja piirangute dokumendi. Nad panevad vastu, sest esileht on see, mida nad saavad investoritele ja oma meeskonnale näidata. Selle ootuse haldamine — näidates neile, kuidas hinnakirja otsused kujundavad kõike allavoolu — on osa tööst, mitte ebaõnnestumine. Üks viis hoogsuse säilitamiseks on teha varakult umbkaudne esilehe makett, selgelt märgistatud kui konteiner, mis ootab sisu, et klient näeks sihtkohta, samal ajal kui sina ehidad skeleti.

Kolmandaks, piirangute loend muutub. Hinnad muutuvad, API-d kasvavad, plaanid paljunevad. Raamistik eeldab, et hoiad piirangute dokumenti pärast käivitamist värskendatuna, sest veebisait hääbub hetkest, kui see lakkab kajastamast toote tegelikke piire. See on seestpoolt-väljapoole lähenemise hoolduskulu: tõe allikas on tõene ainult siis, kui keegi seda omab.

Kokkuvõte.

Kõige levinum ebaõnnestumine SaaS-veebiprojektides ei ole nõrk tekst ega halb disain — vaid lehed, mis on üksteisega vastuolus, sest need ehitati vales järjekorras. Alusta hinnakirja ja API dokumentatsiooniga, kus asuvad toote tegelikud piirangud; tuleta funktsioonide tutvustus tegelikest töövoogudest; korja KKK päris vestlustest; ja lõpeta järjepidevuskontrolliga, mis kontrollib, mitte päästab. Tee seda mõne erineva kliendiga ja avastad, et see on vähem loominguline protsess ja rohkem koosteliin — mis agentuuris on täpselt see, mida tahad. Loominguline töö on siiski olemas; see on lihtsalt rakendatud seal, kus sellel on kõige suurem mõju.