Belülről kifelé épített SaaS-weboldalak: miért a díjszabás és a dokumentáció az első

Összefoglaló

A SaaS-weboldalakkal kapcsolatos legtöbb tanács a kezdőlappal kezdi, és a díjszabást, a dokumentációt és a GYIK-et utólagos gondolatként kezeli – ezért az oldalak végül ellentmondanak egymásnak. Ez a cikk a belülről kifelé építés mellett érvel: kezdd a díjszabási oldallal és az API-dokumentációval, ahol a termék valódi korlátai élnek, és ezekből vezess le minden mást. Bemutat egy hatlépéses keretrendszert: gyűjtsd össze a korlátokat, építsd fel a díjszabási oldalt vázlatként, kezeld az API-dokumentációt termékfelületként, vezesd le a funkcióbemutatót a munkafolyamatokból, gyűjtsd a GYIK-et valódi beszélgetésekből, és végül végezz konzisztencia-ellenőrzést. A megközelítés olyan ügynökségeknek készült, amelyeknek ismételhető folyamatra van szükségük különböző ügyfeleknél. Emellett kitér arra is, hogy mikor túlzás a keretrendszer, és hogyan kezeljük az ügyfelek elvárásait.

A SaaS-weboldalak építésével kapcsolatos legtöbb tanács fordított. Azt mondja, hogy a kezdőlappal kezdd – a hero szekcióval, a címsorral, a termék képernyőképével –, a díjszabást, a dokumentációt és a GYIK-et pedig olyan oldalakként kezeld, amelyeket a design jóváhagyása után töltesz meg. Aztán hetekkel később egyezteted a címsor „minden korlátlan” ígéretét a díjszabási oldal tényleges használati korlátaival, a funkciószekció pedig büszkén mutat be egy béta funkciót, amelyet az API-dokumentáció említésre sem méltat. Ez a sorrend csak akkor működik, ha a termék elég egyszerű ahhoz, hogy ne kelljen egyeztetés, ami ritkán fordul elő. Ami valójában működik – különösen, ha ezt többször, teljesen különböző ügyfeleknél csinálod –, az a belülről kifelé építés: kezdd a leginkább korlátozott, legkevésbé csillogó oldalakkal (díjszabás és API-dokumentáció), és hagyd, hogy ezek generálják a kezdőlapot, a funkcióbemutatót és a GYIK-et. Íme egy hatlépéses keretrendszer ehhez, és közben jelzem, hol válik kényelmetlenné, mert az lesz.

A különbség gyors térképe, mert az egész érv ezen alapul:

	Oldal-először (leggyakoribb)	Korlát-először (ez a keretrendszer)
Hol kezded	Kezdőlap hero és vizuális elemek	Díjszabási oldal és API-dokumentáció
Mi vezérli a szöveget	Márkatörténet és design	A termék tényleges korlátai és munkafolyamatok
Funkcióbemutató	Felsorol mindent, amit a termék tud	A valódi felhasználók által bejárt utakat követi
GYIK	Utoljára íródik, találgatásokból	Támogatásból és értékesítésből gyűjtve
Eredmény induláskor	Következetlen állítások, rejtett konfliktusok	Az oldalak egyetlen termékként olvashatók

1. lépés – Olvasd el a díjszabási oldalt, mielőtt bármit írnál.

Egy ügyfél átad egy funkciólistát, egy márkabemutatót és egy demó linket, és egy kezdőlapot kér. Az első hívás végére már a hero szövegéről és színvilágáról beszéltek. Próbáld meg lelassítani ezt. Kérd el a díjszabási oldalt és a csomagkorlátokat – még akkor is, ha csak egy Google-dokumentum jegyzetekkel –, és látni fogod, hogy az egész projekt megváltozik.

A kemény korlátokat keresed: mit jelent egy felhasználói férőhely, hogyan számolják az adathasználatot, mely funkciók melyik csomagszinten érhetők el, van-e API, és valójában mire képes. Ezek a korlátok az alapigazságok. Minden későbbi marketingállításnak ki kell állnia a velük való érintkezést.

Íme egy tipikus forgatókönyv. Az ügyfél egy időkövető eszköz: Ingyenes csomag, Pro csomag, Vállalati csomag. Az értékesítési bemutató azt mondja: „bármely csapat számára méretezhető”. A Pro oldal azt mondja: „korlátlan projektek”. A támogatói csapat azonban megerősíti, hogy a Pro fiókok valójában munkaterületenként legfeljebb 10 aktív projektre korlátozódnak, és az API-dokumentáció szerint egy projektnek legfeljebb 50 tagja lehet. A kezdőlap soha nem íródik meg, amíg valaki meg nem oldja ezt, mert a „korlátlan projektek” mostantól jogi kérdés, nem szövegírási kérdés. Ha a kezdőlappal kezdted volna, azt írtad volna a hero szekcióba, hogy „korlátlan projektek”, és két héttel később fedezted volna fel a konfliktust, miután a design-t jóváhagyták. A korlátokkal kezdeni azt jelenti, hogy a konfliktus az első héten felszínre kerül, amikor a javítás még semmibe sem kerül.

Pontosan mit gyűjts össze ebben a lépésben? A csomagdefiníciókat és minden csomagonkénti funkció-összehasonlító táblázatot. Az API-dokumentációt, vagy legalább egy listát arról, hogy az API mit tud és mit nem. A támogatói csapat leggyakoribb kérdéseit (erről bővebben az 5. lépésben). Az értékesítési bemutatót, azzal a megjegyzéssel, hogy az értékesítési bemutatókban él a fantázia. És a tényleges terméket, megnyitva, hogy lássuk a beállítási oldalakat, ahol a korlátok érvényesülnek – mert a termék maga a végső tekintély. Egy beállítási képernyő, amely azt mondja: „Maximum 10 projekt”, felülír bármilyen táblázatot.

Ez a lépés nem hoz létre egy leszállítandó elemet. Egy tényekből álló listát hoz létre – korlátokból, definíciókból, kivételekből –, amelyhez minden más oldalt viszonyítasz. Egy ügynökség számára ez az a lépés, amely elválasztja az ismételhető munkát a tűzoltástól. Írd le a korlátokat egy közös dokumentumba, és máris elkészült az igazság forrása, amelyre minden jövőbeli oldalfrissítés hivatkozni fog.

2. lépés – Építsd meg a díjszabási oldalt az egész weboldal vázaként.

A díjszabási oldal nem tűnik jó kiindulópontnak. Ez egy táblázat számokkal és csomagnevekkel – az oldal legkevésbé csillogó oldala. De ez a termék szerződése a felhasználóval, és itt dől el a teljes weboldal információs architektúrája. Ha a weboldal feladata, hogy felvilágosítsa a látogatót, amíg készen nem áll a regisztrációra, akkor a díjszabási oldalon fut össze ez a nevelés. Minden funkció, amely számít a vásárlási döntésben, itt van megnevezve; minden releváns korlát itt van kimondva vagy ide hivatkozik.

Vedd az időkövető eszközt. Három csomag: Ingyenes, Pro, Vállalati. A táblázatnak olyan oszlopokra van szüksége, amelyek tükrözik, hogyan szegmentál a termék – projektek száma, integrációk, jelentéskészítési mélység. Minden cellába az őszinte értéket írd, nem az áhítottat. Ha a Pro 10 aktív projektet tartalmaz, a cella 10 aktív projektet mond, egy linkkel a díjszabási GYIK-hez, amely elmagyarázza, mit jelent az „aktív”, és mi történik, ha eléred a korlátot. Az egyik nehezebb döntés itt, hogy mit mondj arról a csomagról, amelyet a leginkább szeretnél, hogy a látogatók megvásároljanak. Sok díjszabási oldal nyilvánvalóvá teszi a kiemelt csomagot – kiemelve, „Legnépszerűbb” jelvénnyel –, és a körülötte lévő szöveg elmagyarázza, miért ez a legmegfelelőbb az adott látogató számára. Az időkövető eszköz esetében a Pro a kiemelt csomag: itt kezdődnek valójában az integrációk és a jelentéskészítési mélység, ezért az oldalnak ezt kifejezetten el kell mondania, nem pedig feltételeznie, hogy a látogató elolvassa a táblázatot, és magától levonja a következtetést.

Ez az a pont is, ahol eldöntöd, mely kifejezések lesznek kanonikusak az egész weboldalon. Ha a termék „munkaterületeknek” hívja a csoportokat a díjszabási oldalon, de a marketing szöveg „csapatoknak” mondja, minden további oldal örökli a következetlenséget. A díjszabási oldal megírása először arra kényszerít, hogy kiválaszd a szókincset, és azt válaszd, amit maga a termék használ – mert a terméknek és a dokumentációnak is illeszkednie kell hozzá, és a marketingoldal az, amelyik hajlítható.

A díjszabási oldalnak saját GYIK-re is szüksége van. Azok a kérdések tartoznak ide, amelyek a csomagok konkrét mechanikájához kapcsolódnak: mi számít felhasználónak, mi történik, ha lejjebb lépsz, éves vagy havi-e a számlázás, mit jelent az „aktív” egy projektnél. Jól kidolgozott gyakorlatanyag létezik a díjszabási oldalak konverzióra való felépítéséről, és a mechanikákat érdemes tanulmányozni. De ebben a keretrendszerben a díjszabási oldal feladata nem csak a konverzió – hanem azoknak a tényszerű döntéseknek a rögzítése, amelyeknek minden más oldal engedelmeskedik. Ha a mélyebb mechanikákra is kíváncsi vagy, ez az SaaS-árazási oldalak javításáról szóló útmutató részletesen foglalkozik velük.

3. lépés – Kezeld az API-dokumentációt termékfelületként, ne kézikönyvként.

Egy fejlesztő éppen értékeli az időkövető eszközt. A cégének automatikusan kell betöltenie a jelenléti íveket egy bérszámfejtő rendszerbe. A dokumentáció végpontok szerint ábécérendben van szervezve: /projects, /reports, /timesheets, /users. A fejlesztőnek fogalma sincs, melyik hívással kezdje, és az „Authentication” rész olyan tudást feltételez, amivel nem rendelkezik – a dokumentáció nem magyarázza el, hogy az API-kulcsot a beállítások oldalán, az „Integrations” menüpont alatt kell létrehozni. A fejlesztő bezárja a fület, meggyőződve, hogy a termék nem fog zökkenőmentesen integrálódni. Pedig minden szükséges információ megvolt a dokumentációban; csak olyan sorrendben volt szervezve, ahogy egy referencia-kézikönyv használná, nem pedig ahogy egy ember.

A munkafolyamatok szerint szervezett dokumentáció megváltoztatta volna ezt az eredményt: „Gyorsindítás”, „Hitelesítés”, „Jelenléti ívek lekérése”, „Projekt létrehozása”, „Webhookok és szinkronizálás”. Minden szekció a feladattal kezd, majd megmutatja a végpontot. A gyorsindítás öt percet vesz igénybe, és egy sikeres API-hívást eredményez – ami a dokumentáció ingyenes próbaverziója. Egy fejlesztő-központú terméknél ez az oldal a leghatékonyabb az oldalon.

Bármely SaaS esetében, amelynek van API-ja, a dokumentáció a weboldalad egyik oldala, akár tervezted így, akár nem. Az iparági benchmark – amelyet olyan cégek állítanak fel, mint a Stripe, a GitHub és a Twilio – olyan dokumentáció, amelyet termékként olvas az ember: elmagyarázza, hogy a fejlesztő milyen feladatot próbál elvégezni, nem csak az elérhető végpontokat sorolja fel. Az elv az, hogy az API-dokumentáció a termékélmény része, és ugyanazt a belülről kifelé elvet kell követnie, mint a weboldal többi részének: kezdd azokkal a feladatokkal, amelyeket a fejlesztő elvégezhet, majd mutasd meg a mechanikát.

Az ügynökség számára az előnye, hogy a dokumentáció így írva felszínre hozza a korlátok listáját – mit tud valójában az API, hol vannak az aránykorlátok, melyik végpontok hiányoznak –, és ezeket a konfliktusokat még azelőtt elkapod, mielőtt megjelennének egy marketingoldalon. Ha az API-dokumentáció az ügyfél weboldalának fő részét képezi, itt van egy alaposabb útmutató a fejlesztők által ténylegesen használt dokumentáció megírásához.

4. lépés – Vezesd le a funkcióbemutatót a munkafolyamatokból, ne a funkciólistából.

Az ügyfél küld egy táblázatot 40 funkcióval, és egy funkcióoldalt kér. A könnyű válasz egy rács: 40 elem, mindegyik ikonnal és felirattal. Az eredmény alaposnak tűnik, de zajként olvasható, mert a rácsnak nincs története. Senki sem azért látogat el egy SaaS-weboldalra, hogy minden funkciót megismerjen; azért jönnek, hogy megtudják, vajon ez a termék elvégzi-e azt az egy feladatot, amiért jöttek. Tehát a bemutatót munkafolyamatokból kell felépíteni, nem a funkciólistából.

Járd végig a példát. Az időkövető eszköz leggyakoribb nyerő útja – az ügyfél támogatói csapata szerint – az, hogy egy csapatvezető regisztrál, meghív három kollégát, létrehoz egy projektet, és a hét végén riportot futtat. Ez a munkafolyamat. A funkcióbemutatónak ezt kell követnie: egy szekció a csapat meghívásáról (a felhasználói férőhelyekről és szerepekről), egy szekció a projekt beállításáról (a sablonokról és a projektbeállításokról), egy szekció a jelentéskészítési irányítópultról (a diagramokról és az exportálási lehetőségekről). Minden szekció egy képernyőképet mutat a termék adott pillanatából, nem pedig egy ritkán használt beállítási panel levágott képernyőképét. A látogató a saját útját látja, és a funkciók, amelyeket útközben lát, azok a számukra fontosak.

A következő munkafolyamat egy kicsit más látogató számára a vezető, aki soha nem használja maga az eszközt: jóváhagyja a jelenléti íveket, és átnézi a heti riportot. A bemutató végén hozzáadhat egy szekciót az ilyen látogatók számára – „Vezetőknek” – anélkül, hogy megtörné a narratívát. Két munkafolyamat általában elegendő kezdetnek; nem kell minden személyhez egy.

A fenntartás – és ez valós – az, hogy a munkafolyamat-alapú bemutatóhoz tudni kell, hogy melyek a gyakori munkafolyamatok. Ehhez támogatókkal és értékesítőkkel kell beszélni, nem csak a termékmenedzserrel. Ha az ügyfél nem tudja megmondani a termék használatának három fő módját, ezt kell először megjavítani, mert különben a weboldal találgatni fog. Ez a lépés gyakran felfedi, hogy a terméknek nincs egyértelmű elsődleges munkafolyamata – ez termékprobléma, nem weboldal-probléma. Jelezd ezt őszintén; egy weboldal nem tud olyan munkafolyamatot létrehozni, amely nem létezik. A munkafolyamatok szisztematikus sorrendjéhez ez a cikk a funkcióbemutató konverzióra való felépítéséről végigvezet a döntési sorrenden.

5. lépés – Gyűjtsd a GYIK-et a támogatásból és az értékesítésből, ne a képzeletedből.

Két nap van az oldal élesítéséig, és a GYIK még mindig üres. Az ösztön az, hogy egy délután alatt megírj tíz kérdést – általában azokat, amelyeket szívesen látnál a termékre válaszolva, nem pedig azokat, amelyeket a tényleges ügyfelek kérdeznek. Ez fordítva van. A GYIK-nek konkrét feladata van: eltávolítani az utolsó kétségeket a látogató és a regisztráció között. A hatékony GYIK-oldalak, mint amilyeneket a HubSpot, a Slack és a Zendesk oldalán látsz, azért működnek, mert valódi lekérdezések köré szerveződnek, kereshetők és tömörek. Ezek a hallgatás termékei, nem a kitalálásé.

A reális forgatókönyv: a díjszabási oldalon vagy, és tudod, hogy az időkövető eszköznél a legnagyobb buktató az integráció: „Működik ez a QuickBooks-szal?” A támogatási napló átnézése megmutatja, hogy ez a leggyakoribb értékesítés előtti kérdés. Ez a kérdés a válaszával együtt a díjszabási oldal GYIK-jébe tartozik. A második leggyakoribb, az értékesítési hívásokból: „Mi történik a jelenléti íveimmel, ha lemondom?” Az is oda tartozik. Minden válasz lerövidíti az értékesítési ciklust és csökkenti a támogatási terhelést, mert a látogató, aki írásban látja a választ, jobban megbízik a termékben, mint az, akinek kérdeznie kell.

Az ügynökség szabálya: egyetlen GYIK-választ se írj, amíg meg nem nézted a támogatási jegyeket, az értékesítési hívások jegyzeteit és a bevezető e-maileket. Melyek azok a kérdések, amelyek valóban ismétlődnek? Azok kerülnek be. Minden más a funkcióoldalra kerül, vagy sehová. És ahogy a weboldal fejlődik, térj vissza a GYIK-hez – minden új árazási változás vagy funkcióindítás új kérdéseket vet fel, és a GYIK a legolcsóbb hely, ahol ezeket elkaphatod.

Van ok arra is, hogy a GYIK szerkezetére gondolj, ne csak a tartalmára. Egy hosszú, görgethető kérdéslistát nehéz áttekinteni; a kategóriánkénti csoportosítás (Számlázás, Integrációk, Fiókkezelés) a tetején lévő tartalomjegyzékkel valóban használhatóvá teszi. A keresési funkció akkor segít, ha a lista egy bizonyos méret fölé nő – ez az oldal azon része, ahol a design ugyanolyan fontos, mint a szöveg, mert a kereshetetlen GYIK egy olvasatlan GYIK.

Még egy dolog, ami a kényelmetlen rész: a GYIK gyakran a weboldal legőszintébb oldala, mert ez az az oldal, ahol arra a kérdésre válaszolsz, amelyet a látogató fél feltenni. Ha egy kérdés kényelmetlenül érint – „Tényleg bármikor lemondhatom?” „Megjelennek hirdetések az ingyenes csomagban?” – ez a kényelmetlen érzés bizonyíték arra, hogy oda tartozik, nem pedig ok arra, hogy kihagyd. A látogatónak ez a kérdése akkor is megvan, ha válaszolsz rá, ha nem; ha nem válaszolsz, következtetni fognak egy válaszra, és az általuk kikövetkeztetett válasz rosszabb lesz, mint az igazság.

6. lépés – Egységesíts és végezz minőségbiztosítást minden oldalon, mielőtt megmutatod az ügyfélnek.

Készen állsz, hogy megmutasd az ügyfélnek a kész weboldalt. De előtte nyisd meg egymás mellett a díjszabási oldalt és a funkcióoldalt. Ellenőrizd minden funkció nevét: egyeznek-e? Ellenőrizd minden számot: a díjszabási oldalon „10 projekt” szerepel, a funkcióoldalon „legfeljebb 10 projekt”, az API-referenciában „max 10” – mind ugyanaz? Ellenőrizd minden ígéretet: szerepel-e valahol az oldalon a „korlátlan projektek”, és ha igen, igaz-e? Aztán keresd a termék saját szókincsét: mindenhol „munkaterületek” szerepel, vagy becsúszik a „csapatok”? Itt kapod el, hogy a kezdőlap azt mondja: „nincs szükség bankkártyára”, miközben a regisztrációs folyamat valójában bankkártyát kér az ingyenes próbaidőszak alatt – pontosan az a fajta következetlenség, amely megöli a bizalmat.

A belülről kifelé építés megtérülése itt érkezik el. Mivel minden oldal ugyanazokból a korlátokból lett levezetve, a konzisztenciamunka ellenőrzési lépés, nem pedig mentőakció. De ne hagyd ki. A túlélő ellentmondások a finomak – egy „jóváhagyások” nevű funkció a díjszabási oldalon, de „felülvizsgálati folyamatok” az API-dokumentációban, egy kezdőlapi képernyőkép, amely sötét módú irányítópultot mutat, amit a termék nem tartalmaz, egy állítás, hogy a terméket „távmunkás csapatok bíznak meg”, ami a márkabemutatóból jött, és nem egyezik az ügyfél tényleges ügyféllistájával.

Egy praktikus technika: a korlátlista legyen a minőségbiztosítás forgatókönyve. Menj végig minden oldalon, és ellenőrizd az összes tényt a listával szemben. Ez azért működik, mert a korlátlista az első héten készült el, mielőtt az oldalak léteztek volna, tehát valóban független forrás. Ha a designból vagy emlékezetből indulsz a minőségbiztosításnál, el fogod veszíteni azokat a tényeket, amelyek az építés közben megváltoztak.

Ezen a ponton nyilvánvalóvá válik a munkafázisok sorrendjének oka. Amikor az oldalakat párhuzamosan, különböző forrásokból építik, ez a minőségbiztosítási lépés minden alkalommal konfliktusokat talál, és minden konfliktus újramunkát jelent egy késznek látszó oldalon. Amikor az oldalakat egyetlen korlátlistából, sorrendben építik, a minőségbiztosítás csak elírásokat talál. Ez a különbség az ismételhető folyamat és az állandó válság között. Ahhoz, hogy a weboldal az indulás után is egyetlen történetet meséljen – új funkciók, új csapatok, új szövegírók –, szükséged van ugyanennek a fegyelemnek a karbantartási változatára, és a SaaS-weboldal történetének oldalak közötti egységesítésére szolgáló keretrendszer a természetes következő lépés.

A fenntartások, amelyek ezt hitelessé teszik.

Három dolgot nem állít ez a keretrendszer. Először is, egy nagyon korai fázisú SaaS-nél, amelynek nincs API-ja, egyetlen csomagja és egy nyilvánvaló felhasználási esete, a sorrend sokkal kevésbé számít; az oldalt akármilyen sorrendben felépíthetnéd, és az egyeztetési munka triviális lenne. A keretrendszer akkor térül meg, amikor valódi komplexitás van – több csomag, API, sok funkció, több célközönség. Ne alkalmazd dogma gyanánt olyan termékre, amely lényegében egy landing page egy regisztrációs gombbal.

Másodszor, a belülről kifelé építés lassú látható haladást eredményez az elején. Az ügyfél kezdőlapot kért, te pedig egy árazási táblázatot és egy korlátokról szóló dokumentumot szállítasz. Ellenállást fog tanúsítani, mert a kezdőlap az, amit a befektetőknek és a saját csapatuknak meg tudnak mutatni. Ennek az elvárásnak a kezelése – megmutatni nekik, hogy a díjszabási oldal döntései hogyan formálnak mindent lefelé – a munka része, nem pedig kudarca. Az egyik mód a lendület fenntartására, ha korán készítesz egy durva kezdőlap-makettet, amelyet egyértelműen tartalomra váró konténerként jelölsz meg, hogy az ügyfél lássa a célt, miközben te a vázat építed.

Harmadszor, a korlátlista változik. Az árak változnak, az API-k bővülnek, a csomagok szaporodnak. A keretrendszer feltételezi, hogy az indulás után is frissíted a korlátokról szóló dokumentumot, mert a weboldal elkezd hanyatlani, amint nem tükrözi a termék valós korlátait. Ez a belülről kifelé megközelítés karbantartási költsége: az igazság forrása csak akkor igazmondó, ha valaki gondját viseli.

Összegzés.

A SaaS-weboldal projektek leggyakoribb kudarca nem a gyenge szöveg vagy a rossz dizájn – hanem az, hogy az oldalak nem értenek egyet egymással, mert rossz sorrendben épültek fel. Kezdd a díjszabási oldallal és az API-dokumentációval, ahol a termék valós korlátai élnek; vezasd le a funkcióbemutatót a tényleges munkafolyamatokból; gyűjtsd a GYIK-et valódi beszélgetésekből; és zárd egy olyan konzisztencia-ellenőrzéssel, amely ellenőriz, nem pedig megment. Csináld ezt néhány különböző ügyfélnél, és azt fogod tapasztalni, hogy ez kevésbé kreatív folyamat, inkább futószalag – ami egy ügynökségnél pontosan az, amit akarsz. A kreatív munka még mindig ott van; csak ott alkalmazod, ahol a legnagyobb a hatása.