På denne siden
Se for deg en produktside som åpner med tolv funksjoner: webhooks, egendefinerte felt, styring av nye forsøk, en revisjonslogg, en visuell feltmapping og et panel for tidsplaner. En butikkeier skanner listen, men kan fortsatt ikke svare på ett spørsmål: Kommer gårsdagens ordre frem til riktig kundepost?
Siden er et eksempel, ikke en beskrivelse av en faktisk side. Svakheten er lett å kjenne igjen fordi en funksjonsliste beskriver maskinen innenfra. Leseren står utenfor med en jobb som skal gjøres.
En kort samtale om produktkommunikasjon beskriver grepet enkelt: Fortell hva som skjer etter bruk før du ramser opp delene. Det betyr ikke at delene skal skjules. Det gir leseren en grunn til å undersøke dem.
Beskriv en endring noen kan se
«Koble sammen alle dataene dine» er for bredt til å testes. «Flytt en ny Shopify-ordre til den riktige Brevo-kontakten» gir leseren en post å undersøke. Setningen viser en tilstand før, en handling og en tilstand etter.
En resultatsetning kan ha denne formen:
Når denne hendelsen skjer, endres denne posten i dette systemet, slik at denne personen kan gjøre denne neste oppgaven.
For en synkronisering kan hendelsen være en ordreoppdatering. Posten kan være et kontaktattributt. Den neste oppgaven kan være å sende en melding knyttet til kjøpet til en kunde som har gitt samtykke. Hvert substantiv krever et valg. Hvilken ordre? Hvilken kontakt? Hvilket attributt? Hva regnes som samtykke?
Det er selve arbeidet. «Samlede kundedata» glir forbi spørsmålene.
Vår guide til Brevo-integrasjonen dekker oppsett og mapping. Den spør hvilket system som eier hvert felt, og hvordan resultatet kontrolleres. En produktside kan gi leseren første svar i én setning og lenke videre til detaljene når de trengs.
- Ordren endreskundehendelsenhendelse i kilden
- Finn og mapidentitet · felt · tillatelsetilstand i målsystemet
- Sjekk kontaktendet synlige resultatet
Legg beviset ved siden av løftet
Tekst som starter med resultatet, kan bli sin egen tåke. «Spar ti timer i uken» høres konkret ut fordi den har et tall. Uten målt arbeid og et utgangspunkt er det et tall i forkledning.
Innvendingen er rimelig: «Kjøpere trenger funksjoner og spesifikasjoner. En setning om resultater forteller ikke om dette virker med systemene mine.» Riktig. Resultatet forteller hvorfor de bør se nærmere. Spesifikasjonene forteller om de bør gå videre.
Bruk en kort kjede av bevis:
| Det leseren trenger | Det siden kan vise |
|---|---|
| Jobben | Ett eksempel på en post før og etter |
| Mekanismen | Utløseren, mappingen og målsystemet |
| Grensene | Støttede objekter, tidsforløp og krav til tillatelse |
| Dokumentasjonen | En testvei, dokumentasjon eller et målt resultat |
Hvis påstanden er at «en ordre kommer frem til riktig kontakt», vis et eksempel på inndata og det forventede feltet i målsystemet. Si om dette er en dokumentert funksjon, en tenkt arbeidsflyt eller et resultat som er målt hos kunder. Dette er ulike typer bevis.
For en butikkeier som velger en kobling, går guiden til Brevo-koblinger inn på identitet, synkroniseringstilstand og hva som kan feile etter lansering. Funksjonslisten er nyttig der. Spørsmålet er når du viser den. En leser som ennå ikke har kjent igjen jobben, kan ikke vurdere avveiningene.
Funksjonen er et middel, ikke en unnskyldning
Se på to beskrivelser av den samme mulige arbeidsflyten. Begge er tenkte eksempler.
Funksjon først: «Visuell feltmapping med versjonert konfigurasjon, hendelsesruting og styring av gjentatte kjøringer.»
Endring først: «Oppdater riktig kontakt når en ordre endres. Gå gjennom feltmappingen før den første sendingen, og undersøk hver post som feiler.»
Den andre setningen lover mindre og mer presist. Den stiller også et strengere krav. Produktet må faktisk finne riktig kontakt, holde mappingen tilgjengelig for gjennomgang og vise en post som feilet. God tekst gjør manglende arbeid vanskelig å skjule.
Derfor bør siden ikke hoppe fra «vi prøver igjen» til «du mister aldri en ordre». Nye forsøk kan feile. Et API-kall som ble mottatt, kan etterlate feil felt. Et løfte om resultater trenger kontroll av resultatene, ikke bare en liste over komponenter.
Kostnaden kommer før gevinsten: En side som begynner med resultatet, krever at noen sier nøyaktig hvilken atferd som støttes, hva som fortsatt er planlagt, og hva som avhenger av kundens oppsett. Det er vanskeligere enn å samle funksjonsnavn fra et veikart.
Tekst kan ikke fjerne et steg fra oppgaven
Denne artikkelen handler om forklaringen på en produktside. Et eget produktspørsmål er om brukeren må åpne et nytt dashboard, gi en ekstra tilgang eller utføre fem oppsettsteg før et resultat vises. Klar tekst kan ikke gjøre en lang arbeidsflyt kort.
Vår guide til første automatisering starter med én prosess og én sjekk av suksess. Bruk samme disiplin på siden: Velg én oppgave, forklar den endrede tilstanden, og la leseren finne testen.
Se så hvilket spørsmål som kommer. Hvis leserne stadig spør «men hvor ser jeg resultatet?», er resultatet fortsatt for abstrakt. Hvis de spør «støtter dette det egendefinerte feltet mitt?», har siden gjort sin første jobb. Nå vurderer de mekanismen.
Vis endringen. Vis så delene som gjør den virkelig.
Ofte Stilte Spørsmål
Bør en produktside begynne med resultater eller funksjoner?
Begynn med en konkret endring brukeren kan kjenne igjen. Vis så funksjonen og bevisene som gjør påstanden troverdig. Detaljerte spesifikasjoner er fortsatt viktige ved evaluering og bør være lette å finne.
Hvordan skriver du om et resultat uten å komme med en udokumentert påstand?
Beskriv starttilstanden, brukerens handling og et resultat som kan observeres. Skill mellom støttet produktatferd og en hypotetisk kundefordel, og unngå tall som ikke er målt.
Gjør resultatbasert tekst selve grensesnittet enklere?
Nei. Teksten kan forklare resultatet selv om oppgaven fortsatt har for mange steg. Test den faktiske veien til resultatet separat.