Na tejto stránke
Predstavte si produktovú stránku, ktorá začína dvanástimi funkciami: webhooky, vlastné polia, riadenie opakovaných pokusov, protokol auditu, vizuálny nástroj na mapovanie, panel plánovania. Obchodník preletí zoznam a stále nevie odpovedať na jednu otázku: Dostane sa včerajšia objednávka k správnemu zákazníckemu záznamu?
Stránka je ilustratívna. Jej chyba je známa, pretože zoznam funkcií opisuje stroj zvnútra. Čitateľ stojí mimo neho a potrebuje dokončiť prácu.
Krátka načítaná diskusia o komunikácii produktu pomenúva základný krok: opíšte, čo sa stane po použití, namiesto úvodného výpočtu súčastí. To neznamená súčasti skrývať. Znamená to dať čitateľovi dôvod preskúmať ich.
Pomenujte zmenu, ktorú niekto uvidí
„Prepojte všetky svoje dáta“ je príliš široké tvrdenie na test. „Preneste novú objednávku zo Shopify k zodpovedajúcemu kontaktu v Brevo“ dáva čitateľovi záznam, ktorý môže skontrolovať. Určuje stav pred zmenou, krok a stav po nej.
Veta o výsledku môže mať takýto tvar:
Keď nastane táto udalosť, tento záznam sa zmení v tomto systéme, aby tento človek mohol vykonať ďalšiu úlohu.
Pri synchronizácii môže byť udalosťou aktualizácia objednávky. Záznamom môže byť atribút kontaktu. Ďalšou úlohou môže byť odoslanie správy súvisiacej s nákupom zákazníkovi, ktorý s tým súhlasil. Každé podstatné meno vynucuje voľbu. Ktorá objednávka? Ktorý kontakt? Ktorý atribút? Čo sa počíta ako súhlas?
Práve tieto otázky tvoria prácu. „Jednotné zákaznícke dáta“ ich obíde.
Náš sprievodca integráciou Brevo pokrýva nastavenie a mapovanie. Pýta sa, ktorý systém vlastní každé pole a ako sa kontroluje výsledok. Produktová stránka môže čitateľovi poskytnúť prvú odpoveď v jednej vete a odkázať na podrobnosti, keď ich potrebuje.
- Zmena objednávkyzákaznícka udalosťzdrojová udalosť
- Priradenie a mapovanieidentita · pole · súhlasstav v cieli
- Kontrola kontaktuviditeľný výsledok
Dôkaz umiestnite vedľa sľubu
Text začínajúci výsledkom sa môže stať vlastnou hmlou. „Ušetríte desať hodín týždenne“ znie konkrétne, pretože obsahuje číslo. Bez merania práce a východiskového stavu je to len číslo v prestrojení.
Námietka je oprávnená: „Kupujúci potrebujú funkcie a špecifikácie. Veta o výsledku mi nepovie, či to bude fungovať s mojimi systémami.“ Správne. Výsledok im hovorí, prečo sa pozrieť. Špecifikácie hovoria, či pokračovať.
Použite krátku reťaz dôkazov:
| Čo čitateľ potrebuje | Čo môže stránka ukázať |
|---|---|
| Úlohu | Jediný príklad záznamu pred zmenou a po nej |
| Mechanizmus | Spúšťač, mapovanie a cieľový systém |
| Hranice | Podporované objekty, načasovanie a požiadavky na oprávnenia |
| Dôkazy | Testovaciu cestu, dokumentáciu alebo nameraný výsledok |
Ak tvrdíte, že „jedna objednávka sa dostane k zodpovedajúcemu kontaktu“, ukážte príklad vstupu a očakávané cieľové pole. Uveďte, či ide o zdokumentovanú schopnosť, ilustratívny postup alebo výsledok nameraný u zákazníkov. Sú to rôzne druhy dôkazov.
Pre obchodníka, ktorý vyberá konektor, ide sprievodca konektorom Brevo do identity, stavu synchronizácie a možných zlyhaní po spustení. Zoznam funkcií je tam užitočný. Otázkou je, kedy ho ukázať. Čitateľ, ktorý ešte nespoznal svoju úlohu, nevie posúdiť kompromisy.
Funkcia je prostriedok, nie ospravedlnenie
Porovnajte dva opisy rovnakého možného postupu. Oba sú ilustratívne.
Najprv funkcia: „Vizuálne mapovanie polí s verziovanou konfiguráciou, smerovaním udalostí a možnosťami opätovného prehratia.“
Najprv zmena: „Pri zmene objednávky aktualizujte správny kontakt. Pred prvým odoslaním skontrolujte mapu polí a prezrite si každý záznam, ktorý zlyhá.“
Druhé tvrdenie je užšie. Zároveň vytvára náročnejší záväzok. Produkt musí skutočne určiť správny kontakt, umožniť kontrolu mapy a odhaliť neúspešný záznam. Dobrý text znemožňuje skryť chýbajúcu prácu.
Preto stránka nemá preskočiť od „máme opakované pokusy“ k „nikdy nestratíte objednávku“. Aj opakované pokusy môžu zlyhať. Prijaté volanie API môže zanechať nesprávne pole. Sľub o výsledku potrebuje kontrolu výsledku, nie recitáciu komponentov.
Cena prichádza pred prínosom: stránka zameraná na výsledok vyžaduje, aby niekto presne povedal, ktoré správanie je podporované, čo je iba plánované a čo závisí od nastavenia zákazníka. To je ťažšie než pozbierať názvy funkcií z plánu vývoja.
Text nedokáže odstrániť krok z úlohy
Tento článok sa týka vysvetlenia na produktovej stránke. Samostatnou produktovou otázkou je, či používateľ musí otvoriť nový panel, udeliť ďalšie oprávnenie alebo vykonať päť nastavovacích krokov, než uvidí výsledok. Jasný text neskráti dlhý postup.
Náš sprievodca prvou automatizáciou začína jedným procesom a jednou kontrolou úspechu. Rovnakú disciplínu použite na stránke: vyberte jednu úlohu, vysvetlite zmenený stav a umožnite čitateľovi nájsť test.
Potom sledujte ďalšiu otázku. Ak sa čitatelia stále pýtajú „kde uvidím výsledok?“, opis je príliš abstraktný. Ak sa pýtajú „podporuje to moje vlastné pole?“, stránka splnila svoju prvú úlohu. Teraz hodnotia mechanizmus.
Ukážte zmenu. Potom ukážte časti, ktoré ju umožňujú.
Často Kladené Otázky
Má produktová stránka začínať výsledkami alebo funkciami?
Začnite konkrétnou zmenou, ktorú používateľ spozná, a potom ukážte funkciu a dôkaz, vďaka ktorým je uveriteľná. Podrobné špecifikácie zostávajú dôležité pri hodnotení a majú sa dať ľahko nájsť.
Ako opísať výsledok bez nepodloženého tvrdenia?
Pomenujte počiatočný stav, krok používateľa a pozorovateľný výsledok. Odlišujte doložené správanie produktu od hypotetického prínosu pre zákazníka a vyhnite sa nenameraným číslam.
Zjednoduší text zameraný na výsledok aj rozhranie?
Nie. Text môže vysvetliť výsledok, aj keď úloha stále vyžaduje príliš veľa krokov. Skutočnú cestu k výsledku testujte osobitne.