Najprej opišite spremembo, šele nato funkcijo

Predstavljajte si stran izdelka, ki se začne z dvanajstimi funkcijami: spletnimi kavlji, polji po meri, ponovnimi poskusi, revizijsko sledjo, vizualnim urejevalnikom preslikav in razporejanjem. Trgovec preleti seznam in še vedno ne zna odgovoriti na vprašanje: Ali bo včerajšnje naročilo doseglo zapis prave stranke?

Stran je ponazoritvena. Njena napaka je znana, ker seznam funkcij opisuje stroj od znotraj. Bralec stoji zunaj njega in želi dokončati delo.

Pregledan kratek pogovor o predstavitvi izdelka poda osnovno potezo: opišite, kaj se zgodi po uporabi, namesto da začnete z deli. To ne pomeni, da dele skrijete. Bralcu najprej dajte razlog, da jih pregleda.

Poimenujte spremembo, ki jo lahko nekdo vidi

„Povežite vse svoje podatke“ je preširoko za preizkus. „Prenesite novo naročilo Shopify v ustrezni stik Brevo“ bralcu poda zapis, ki ga lahko preveri. Določi začetno stanje, dejanje in končno stanje.

Stavek o rezultatu ima lahko takšno obliko:

Ko se zgodi ta dogodek, se ta zapis spremeni v tem sistemu, da lahko ta oseba opravi naslednjo nalogo.

Pri sinhronizaciji je dogodek morda posodobitev naročila. Zapis je lahko atribut stika. Naslednja naloga je morda pošiljanje sporočila o nakupu stranki, ki je dala privolitev. Vsak samostalnik zahteva odločitev. Katero naročilo? Kateri stik? Kateri atribut? Kaj šteje kot privolitev?

Prav to je delo. „Poenoteni podatki o strankah“ drsijo mimo njega.

Naš vodnik za integracijo Brevo obravnava nastavitev in preslikavo. Vpraša, kateri sistem ima v lasti vsako polje in kako se preverja rezultat. Stran izdelka lahko bralcu poda prvi odgovor v enem stavku, nato pa ga poveže s podrobnostmi, ko jih potrebuje.

1. Naročilo se spremeni

   dogodek stranke
   izvorni dogodek
2. Ujemite in preslikajte

   identiteta · polje · dovoljenje
   stanje v ciljnem sistemu
3. Preverite stik

   vidni rezultat

Dokaz postavite ob obljubo

Pisanje, ki začne z rezultatom, lahko postane druga vrsta meglice. „Prihranite deset ur na teden“ zveni konkretno, ker vsebuje številko. Brez izmerjenega dela in izhodišča je ta številka le preobleka.

Ugovor je pošten: „Kupci potrebujejo funkcije in specifikacije. Stavek o rezultatu mi ne pove, ali bo to delovalo z mojimi sistemi.“ Res je. Rezultat pove, zakaj naj pogledajo. Specifikacije povedo, ali naj nadaljujejo.

Uporabite kratko verigo dokazov:

Kaj bralec potrebuje	Kaj lahko stran pokaže
Nalogo	En primer zapisa pred spremembo in po njej
Mehanizem	Sprožilec, preslikavo in vpleteni ciljni sistem
Omejitve	Podprte objekte, časovni potek in zahteve glede dovoljenj
Dokaz	Pot preizkusa, dokumentacijo ali izmerjeni rezultat

Če trdite, da „eno naročilo doseže ustrezni stik“, pokažite vhodni primer in pričakovano polje v ciljnem sistemu. Povejte, ali gre za dokumentirano zmožnost, ponazoritveni potek ali rezultat, izmerjen pri strankah. To so različne vrste dokazov.

Za trgovca, ki izbira priključek, vodnik za priključek Brevo podrobno obravnava identiteto, stanje sinhronizacije in možne napake po zagonu. Seznam funkcij je tam uporaben. Vprašanje je, kdaj ga pokazati. Bralec, ki še ni prepoznal naloge, ne more presoditi kompromisov.

Funkcija je sredstvo, ne opravičilo

Primerjajte dva opisa istega možnega poteka dela. Oba sta ponazoritvena.

Najprej funkcija: „Vizualni urejevalnik preslikav z različicami nastavitev, usmerjanjem dogodkov in nadzorom ponovnih izvedb.“

Najprej sprememba: „Posodobite pravi stik, ko se naročilo spremeni. Pred prvim pošiljanjem preglejte preslikavo polj in preučite vsak zapis, pri katerem pride do napake.“

Druga trditev je ožja. Ustvari tudi zahtevnejšo obveznost. Izdelek mora res prepoznati pravi stik, omogočiti pregled preslikave in pokazati neuspešen zapis. Dobro besedilo naredi manjkajoče delo nemogoče skriti.

Zato stran ne sme preskočiti od „imamo ponovne poskuse“ do „nikoli ne izgubite naročila“. Ponovni poskusi lahko odpovejo. Sprejet klic API lahko pusti napačno polje. Obljuba o rezultatih potrebuje preverjanje rezultatov, ne naštevanja sestavnih delov.

Ceno plačate pred zmago: stran, ki izhaja iz rezultata, zahteva, da nekdo natančno pove, katero vedenje je podprto, katero je šele načrtovano in katero je odvisno od nastavitev stranke. To je težje kot zbiranje imen funkcij z načrta razvoja.

Besedilo ne more odstraniti koraka naloge

Ta članek govori o razlagi na strani izdelka. Ločeno vprašanje izdelka je, ali mora uporabnik odpreti novo nadzorno ploščo, podeliti dodatno dovoljenje ali opraviti pet nastavitvenih korakov, preden vidi rezultat. Jasno besedilo dolgega poteka ne skrajša.

Naš vodnik za prvo avtomatizacijo začne z enim procesom in enim preverjanjem uspeha. Enako disciplino uporabite na strani: izberite eno nalogo, razložite spremenjeno stanje in bralcu omogočite najti preizkus.

Nato opazujte naslednje vprašanje. Če bralci nenehno sprašujejo „Kje bom videl rezultat?“, je izid še vedno preveč abstrakten. Če vprašajo „Ali podpira moje polje po meri?“, je stran opravila prvo nalogo. Zdaj ocenjujejo mehanizem.

Pokažite spremembo. Nato pokažite dele, zaradi katerih je resnična.