Hvordan-gjør-det-guider: Struktur, trinn og skjema
Bygg en hvordan-gjør-det-guide som omdanner leserens mål til ordnede, testbare trinn med forutsetninger, suksesssignaler, gjenopprettingsveier og feilsøking.
En hvordan-gjør-det-guide er en ordnet prosedyre som tar leseren fra en kjent starttilstand til et verifisert resultat. Den svarer på «Hvordan fullfører jeg denne oppgaven?» uten å la leseren finne opp et manglende trinn.
Hvert trinn trenger en imperativ tittel, sin grunn, handlingen, en observerbar suksess-tilstand og en gjenopprettingsvei. Kun-klikk-instruksjoner fungerer bare når leserens konto, tilgang, data og grensesnitt tilfeldigvis samsvarer med forfatterens forutsetninger.
Leserspørsmål besvart: «Hva trenger jeg, hva gjør jeg i rekkefølge, hvordan vet jeg at det fungerte, og hvordan gjenoppretter jeg hvis det ikke gjorde det?»
Spørsmål den besvarer
En hvordan-gjør-det-guide tjener informasjonshensikt , noe som betyr at leseren prøver å lære eller fullføre en oppgave snarere enn å evaluere en liste med produkter. Spørringen begynner ofte med «hvordan», men ordlyd alene er ikke nok. Det tiltenkte resultatet må være noe leseren kan utføre og verifisere.
Skriv for spørsmålene folk faktisk bærer med seg inn i prosedyren:
- «Har jeg den nødvendige planen, tilgangen, verktøyene og tiden?»
- «Hvilke handlinger må skje i rekkefølge, og hva bør vises etter hver?»
- «Kan dette overskrive, publisere, belaste, slette eller eksponere noe?»
- «Hvordan gjenoppretter jeg fra et annet resultat og bekrefter at hele oppgaven fungerte?»
Det direkte svaret bør angi resultatet, startbetingelsen, forventet tid og vanskelighetsgrad før den første lange forklaringen. «På omtrent 20 minutter kan en kontoadministrator koble til Search Console og verifisere den første vellykkede importen» er nyttig. «Denne guiden utforsker integrasjonens beste praksis» er det ikke.
Når du skal bruke denne innholdstypen
Prosedyrer mislykkes ved antakelsesgrenser. Forfatteren vet hvilken tilgang, forsinkelse eller innstilling som betyr noe; leseren vet det ikke. Dette formatet gjør skjulte avhengigheter, tilstandsendringer og gjenopprettingsbeslutninger synlige i sekvens.
| Forvekslingsbar type | Velg den når leseren starter med | Svarform | Hvorfor det ikke er denne typen |
|---|---|---|---|
| Hvordan-gjør-det-guide | Et mål: «Jeg må fullføre X» | Forutsetninger, ordnede trinn, suksesssignaler, gjenoppretting, fullføringssjekk | Det er selve prosedyren. |
| Hvordan velge X | En beslutning: «Hvilken X passer meg?» | Kriterier, alternativer, avveininger, anbefaling | «Velge» beskriver evaluering, ikke en handlingssekvens med et testbart resultat. |
| Feilsøkingsartikkel | Et symptom: «X mislyktes» eller «Jeg ser feil Y» | Diagnosetre fra symptom til årsak til løsning | Den begynner etter at en forsøkt prosedyre allerede har skapt et problem. |
| Dokumentasjonsartikkel | Et behov for å slå opp oppførsel, felt, begrensninger eller syntaks | Referanse organisert for oppslag snarere enn én lesevei | Den støtter mange oppgaver og lover ikke én narrativ rute til ett resultat. |
Velg en hvordan-gjør-det-guide kun når rekkefølgen betyr noe. Hvis uavhengige kontroller kan utføres i vilkårlig rekkefølge, publiser en sjekkliste. Hvis emnet er bredt nok til å inneholde flere distinkte mål, bruk en ultimat guide som kart og lag separate hvordan-gjør-det-guider for prosedyrene. Hvis leseren primært spør hva et konsept betyr, bruk en hva-er-X-side .
Best for disse forretningstypene
Rangeringen reflekterer hvor ofte modellen avhenger av at en leser fullfører en gjentakbar prosess, ikke den totale verdien av innhold for virksomheten.
- SaaS . Oppsett, konfigurasjon, migrering og gjentakende arbeidsflyter avgjør om brukere når verdi. Skill mellom plangrenser, roller, grensesnitttilstander og destruktive endringer.
- E-handel . Kjøpere trenger montering, størrelsesvalg, installasjon, bruk og vedlikeholdsprosedyrer. Vis fysisk orientering når ord ikke trygt kan gjøre det.
- Lokal tjeneste . Forberedelsesguider hjelper kunder med å samle innspill og forstå avtaler. Skill trygt kundearbeid fra arbeid forbeholdt en kvalifisert fagperson.
- Markedsplasser . Selgere, kjøpere, leverandører og administratorer kan følge forskjellige arbeidsflyter. Angi målgruppe og rolle før forutsetninger.
- B2B-tjenester . Onboarding-, godkjennings-, overleverings- og gjennomgangsguider tydeliggjør eierskap og viser hvordan fullført arbeid ser ut.
- Mediepubliserere og tilknyttede . Ekspertveiledninger kan tjene oppgavedrevet etterspørsel, men publiserere må teste prosedyren og vedlikeholde opptak heller enn å omskrive leverandørdokumentasjon.
Søkehensikt
Søkehensikt er resultatet en person forventer fra en spørring. For prosedyrehensikt er forventet svarform en umiddelbar gjennomførbarhetssjekk etterfulgt av en utførbar rute: resultat, tid, vanskelighetsgrad, forutsetninger, ordnede handlinger, verifisering, feilsøking og neste trinn.
Oppgaveresultater kan blande videoer, trinnutdrag, produktdokumentasjon, samfunnssvar og veiledninger. AI-svar komprimerer ofte ruten til en nummerert sekvens med kilder. Hvert ekstraherte trinn må beholde sitt objekt, betingelse og forventede resultat; advarsler må plasseres før risikable handlinger.
Ta begge eksemplene på samme dato og noter spørringen, plassering, enhet, påloggingsstatus og grensesnitt. Resultater endres; designleksjonen bør komme fra svarformen, ikke en påstand om at én leverandør alltid viser en bestemt funksjon.
Sidestruktur
Ordområder styrer vektlegging, ikke kvoter. Legg til ord bare når de fjerner en beslutning leseren ellers ville tatt alene.
| Seksjon | Ordområde | Formål | Status |
|---|---|---|---|
| Helt og direkte svar | 60–100 | Angi resultatet, leseren, starttilstanden, tid og vanskelighetsgrad. | Påkrevd |
| Forutsetninger | 120–220 | List opp tilgang, verktøy, innspill, kostnader, versjoner, sikkerhetsbetingelser og irreversible forpliktelser før arbeidet begynner. | Påkrevd |
| Rask oversikt | 60–120 | Forhåndsvis hovedfasene og den endelige suksesstilstanden uten å duplisere hver instruksjon. | Påkrevd |
| Ordnet prosedyre | 700–1 500 | Led leseren gjennom imperative, begrunnede, testbare, gjenopprettbare trinn. | Påkrevd |
| Fullføringssjekk | 100–180 | Bekreft sluttresultatet med observerbar dokumentasjon og list opp hva «ferdig» inkluderer. | Påkrevd |
| Feilsøking | 250–500 | Løs vanlige feil i denne prosedyren etter symptom, sannsynlig årsak og neste handling. | Påkrevd |
| Varianter | 150–350 | Forklar meningsfulle plan-, enhets-, rolle- eller versjonsforskjeller. | Betinget |
| FAQ | 200–350 | Svar på gjenværende spørsmål som ikke hører hjemme i et trinn. | Påkrevd; 5–7 spørsmål |
| CTA | 40–90 | Tilby én logisk handling etter at leseren har fullført eller evaluert oppgaven. | Påkrevd |
Påkrevde elementer
Trinnlisten eier prosedyrekontrakten. Forutsetninger beskytter starttilstanden, og avslutningssjekken beviser det lovede resultatet; ingen av dem har en egen elementside, så de forblir navngitte strukturelle seksjoner snarere enn oppfunne elementer.
| Element | Status | Nøyaktig plassering | Hvorfor det hører hjemme der |
|---|---|---|---|
| trinnliste | Alltid | Etter forutsetninger og rask oversikt | Sekvensen er sidens kjerneleveranse; hvert trinn inneholder grunn, handling, suksess og gjenoppretting. |
| Kommentert skjermbilde | Betinget | Umiddelbart etter instruksjonen hvis grensesnitt eller tilstand er tvetydig | Et opptak løser romlig tvetydighet bare så lenge det forblir ved siden av den relevante handlingen. |
| Tipsboks | Betinget | Etter den påkrevde instruksjonen den forbedrer | Valgfri optimalisering må ikke forveksles med en betingelse for suksess. |
| Advarselsboks | Betinget, obligatorisk når risiko finnes | Før den risikable eller irreversible handlingen | En advarsel kan endre atferd bare før konsekvensen utløses. |
| FAQ-struktur | Alltid | Etter feilsøking, før CTA-en | Gjenværende spørsmål hører hjemme etter den komplette prosedyren slik at svar ikke fragmenterer sekvensen. |
| CTA-blokk | Alltid | Siste innholdsblokk | Neste handling blir rimelig først etter at siden har levert det lovede resultatet. |
Når skjermbilder er obligatoriske
Et skjermbilde er obligatorisk når tekst ikke pålitelig kan identifisere riktig kontroll, plassering, tilstand, orientering eller resultat. Bruk ett for like kontroller, skjulte innstillinger, umerkede visuelle tilstander eller fysiske deler som kan forveksles. Beskjær til beslutningsområdet, behold orienteringskontekst, marker målet og forklar det i tekst.
Et skjermbilde er støy når det gjentar «Velg Lagre», viser en hel skjerm for én åpenbar kontroll, eller erstatter tekst. Gjør aldri et bilde til den eneste kilden for en kommando, advarsel, verdi eller suksesskriterium.
Frontmatter
Frontmatter-felt må beskrive prosedyren like presist som den synlige siden gjør.
| Felt | Påkrevd verdi eller regel |
|---|---|
entity | En stabil verb–objekt-verdi for oppgaven, for eksempel connect-google-search-console, ikke det brede emnet search-console. |
schemaType | HowTo når den synlige siden er en ordnet prosedyre med et resultat; ellers Article. |
name | Samme oppgavenavn som leserne ser i tittelen eller det direkte svaret. |
description | Kortfattet resultat og omfang, ikke en liste med nøkkelord. |
totalTime | Ærlig ISO 8601-varighet utledet fra testet fullføringstid; skill ventetid i synlig tekst. |
estimatedCost | Inkluder kun når prosedyren krever et kjøp eller gebyr, med synlig beløp og valuta. |
supply og tool | List kun elementer som er nevnt i de synlige forutsetningene. Ikke kall programvaretilgang for en fysisk forsyning. |
step | Samme antall, rekkefølge, navn, tekst, URL-er og bilder som de synlige trinnene. |
inLanguage og datoer | Samsvar med publisert språk og synlig publiserings- eller endringsregistrering. |
| FAQ | Bruk 5–7 virkelige gjenværende spørsmål i [[faq]]; enhver synlig akkordion og strukturerte data må samsvare nøyaktig med dem. |
Skjemamerking
er maskinlesbare data om synlig innhold. Publiser HowTo som JSON-LD
kun når implementeringen er trofast. Merk aldri en forutsetning som et trinn, slå sammen synlige trinn, legg til skjulte instruksjoner eller fest feil bilde. Bruk Article når nøyaktig samsvar ikke kan opprettholdes.
Fullstendig eksempel
Dette kopierbare skjelettet bruker en virkelig oppgave. Hakeparenteser med produksjonsinstrukser angir dokumentasjonen en skribent må sette inn.
# Slik kobler du Google Search Console til Northstar Analytics
Koble en verifisert Search Console-egenskap til Northstar Analytics slik at den første spørringsrapporten kan importeres. En kontoadministrator kan fullføre oppsettet på omtrent 15 minutter; importen kan ta opptil 30 minutter ekstra. Vanskelighetsgrad: nybegynner.
## Før du begynner
- En Northstar Analytics-konto med Administrator-rollen
- Eiertilgang til Search Console-egenskapen du vil koble til
- Den nøyaktige HTTPS-egenskapen som samsvarer med nettstedets kanoniske vert
- Tillatelse til å dele Search Console-ytelsesdata med Northstar Analytics
Ikke fortsett med en testegenskap eller en annen vert. Tilkoblingen kan teknisk sett lykkes mens den importerer data for feil nettsted.
## Rask oversikt
Du velger nettstedet, autoriserer tilgang, velger den samsvarende egenskapen, starter importen og verifiserer at en datert spørringsrad vises i Northstar Analytics.
## 1. Bekreft at nettsted og egenskap samsvarer
**Hvorfor dette trinnet finnes:** Search Console kan inneholde domene- og URL-prefiks-egenskaper med like navn. Å velge feil ene produserer en gyldig tilkobling med irrelevant eller ufullstendig data.
**Gjør dette:** I Northstar Analytics åpner du nettstedets Innstillinger-side og kopierer dens kanoniske vert. I Search Console bekrefter du at den tiltenkte egenskapen inkluderer den verten og protokollen.
**Når det fungerte:** Verten som vises i begge produktene, stemmer nøyaktig overens, inkludert `www` og HTTPS.
**Hvis det ikke gjorde det:** Spør eiendomseieren hvilken egenskap som representerer produksjon. Ikke gjett fra visningsnavnet.
## 2. Start Search Console-tilkoblingen
**Hvorfor dette trinnet finnes:** Å starte fra det valgte nettstedet binder autorisasjonen til riktig Northstar Analytics-arbeidsområde.
**Gjør dette:** Åpne **Innstillinger → Integrasjoner → Google Search Console**, og velg deretter **Koble til**.
**Når det fungerte:** Et Google-autorisasjonsvindu navngir Northstar Analytics og ber deg velge en konto.
**Hvis det ikke gjorde det:** Tillat popup-vinduer og prøv igjen. Hvis Koble til er deaktivert, bekreft din Administrator-rolle.
[Sett inn et beskåret, kommentert opptak av Integrasjoner-panelet kun når Koble til er vanskelig å skille fra en annen kontroll.]
## 3. Autorisere riktig Google-konto
**Hvorfor dette trinnet finnes:** Northstar kan kun liste opp egenskaper den autoriserte Google-kontoen har tilgang til.
**Gjør dette:** Velg Google-kontoen som eier den tiltenkte egenskapen, vurder den forespurte tilgangen og godkjenn den.
**Når det fungerte:** Du returnerer til Northstar Analytics og ser en egenskapsvelger.
**Hvis det ikke gjorde det:** Bruk et privat vindu og gjenta autorisasjon med eiendomseierens konto.
## 4. Velg produksjonsegenskapen
**Hvorfor dette trinnet finnes:** Autorisasjon beviser kontotilgang, men den valgte egenskapen bestemmer hvilke data som importeres.
**Gjør dette:** Velg egenskapen som nøyaktig samsvarte med den kanoniske verten i trinn 1, og velg deretter **Lagre og importer**.
**Når det fungerte:** Integrasjonsstatusen endres til **Import satt i kø** og viser den valgte egenskapen.
**Hvis det ikke gjorde det:** Gå tilbake til trinn 3 med en autorisert konto. Sammenlign fullstendige identifikatorer når egenskaper ser like ut.
## 5. Bekreft den første importen
**Hvorfor dette trinnet finnes:** Et tilkoblet-merke beviser autorisasjon, ikke at brukbare data nådde rapporten.
**Gjør dette:** Etter den viste ventetiden åpner du **Rapporter → Søkespørringer** og setter datoperioden til en periode som har Search Console-data.
**Når det fungerte:** Minst én rad viser en spørring, landingsside, dato, klikk eller visninger fra den valgte egenskapen.
**Hvis det ikke gjorde det:** For **Import satt i kø**, vent og prøv igjen. For **Tillatelse utløpt**, koble til på nytt. For **Ingen data**, sjekk datoperioden og kildeegenskapen.
## Fullføringssjekkliste
- Integrasjonen navngir den tiltenkte produksjonsegenskapen.
- Statusen er Til-koblet snarere enn bare Kø.
- Spørringsrapporten inneholder en datert rad fra den egenskapen.
- En annen administrator kan identifisere hvilken konto som eier tilkoblingen.
## Feilsøking
### Egenskapsvelgeren er tom
Den autoriserte Google-kontoen mangler tilgang, eller tilgangen er fjernet. Reautorisér med en eiendomseier, og last deretter velgeren på nytt.
### Tilkoblingen lykkes, men rapporten er tom
Sammenlign rapportens datoperiode med Search Console, og bekreft deretter den nøyaktige egenskapsidentifikatoren før du kobler fra.
### Importen går gjentatte ganger tilbake til Kø
Noter nettstedet, egenskapsidentifikatoren, starttidspunktet og siste status, og kontakt deretter støtte. Disse detaljene lar støtte inspisere importen uten å be deg om å gjenta autorisasjon blindt.
## FAQ
[Legg til fem til syv gjenværende spørsmål om tillatelser, dataforsinkelse, egenskapstyper, gjenoppkobling og fjerning. Ikke gjenta trinnene.]
## Neste trinn
[Tilby én handling som bruker de importerte dataene, for eksempel å gjennomgå den første spørringsmulighetsrapporten.]
Designeksempler
Hver gallerivariant må vise de samme forutsetningene, fem trinnene, suksesstilstandene, gjenopprettingsteksten, feilsøkingen og fullføringssjekken.
Kvalitetssjekkliste
En guide kan publiseres bare når en anmelder kan fullføre den fra en ren starttilstand uten forfatteren.
- Heltet angir ett testbart resultat, tiltenkt leser, forventet aktiv tid, ventetid og vanskelighetsgrad.
- Forutsetninger navngir roller, tilgang, versjoner, verktøy, innspill, kostnader og sikkerhetsbetingelser som kan blokkere et senere trinn.
- Hvert trinn starter med en imperativ tittel og forklarer hvorfor, handling, suksess og gjenoppretting.
- Rekkefølgen har blitt testet; å flytte et trinn ville endre, blokkere eller ugyldiggjøre resultatet.
- Advarsler vises før risiko, og valgfrie tips skjuler aldri påkrevd arbeid.
- Skjermbilder løser genuin tvetydighet, har aktuell grensesnittkontekst og tilgjengelige forklaringer, og er ikke den eneste kilden til instruksjoner.
- Sluttsjekken verifiserer det lovede resultatet snarere enn det siste klikket.
- Feilsøking dekker observerte eller troverdig reproduserbare feil med spesifikke neste handlinger.
- HowTo-data samsvarer nøyaktig med hvert synlige trinn og egenskap, eller siden bruker Article i stedet.
- En annen tester har fullført guiden på den støttede kontoen, enheten, rollen og versjonen.
Vanlige feil
Den vanligste feilen er en klikktranskripsjon: «Åpne Innstillinger. Klikk Integrasjoner. Klikk Koble til.» Den utelater hvorfor egenskapen betyr noe, hva som bør vises, og hvordan man gjenoppretter fra manglende tillatelse.
Andre feil er like spesifikke:
- Å gjemme forutsetninger inne i trinn. Å oppdage i trinn 4 at administrator-tilgang tar en dag å få, kaster bort leserens tid og kan etterlate delvis arbeid.
- Å plassere advarsler etter handlinger. En slettingsadvarsel under Slett-instruksjonen kan ikke forhindre sletting.
- Å bruke forløpt tid som aktiv tid. «Tar 40 minutter» er misvisende når arbeidet tar 10 minutter pluss en 30 minutters import. Oppgi begge.
- Å teste kun forfatterens konto. Administratorer ser ofte kontroller som vanlige medlemmer ikke gjør. Test rollen som er nevnt i heltet.
- Å behandle det siste klikket som suksess. «Lagret» kan bety kun at en forespørsel ble akseptert. Verifiser den påfølgende tilstanden eller utdata.
- Å la skjemaet drive. Å gi nytt navn til, omorganisere eller slå sammen synlige trinn uten å oppdatere HowTo-data skaper to inkompatible prosedyrer på én URL.
Intern lenking
En hvordan-gjør-det-guide lenker utover kun når destinasjonen forklarer en forutsetning, støtter en beslutning eller gir neste prosedyre. Definer faguttrykk før sekvensen eller ved første gangs bruk.
Andre sider bør lenke til guiden når de navngir den nøyaktige oppgaven, men bør ikke duplisere dens trinn. En produktside kan lenke fra en kapabilitet til oppsett. En ultimat guide kan lenke fra en bred fase til den relevante prosedyren. En feilsøkingsartikkel kan lenke tilbake til guidens starttilstand etter at symptomet er løst.
Ikke dupliser en «hvordan velge»-beslutningsguide, en symptomledet feilsøkingssti eller generell dokumentasjon. Hvis en søsterside trenger mer enn et kort sammendrag av samme sekvens, etabler én kanonisk prosedyre og lenk til den. Hold versjonsspesifikke varianter på én side når hovedruten er felles; splitt dem kun når trinnene eller forutsetningene vesentlig avviker.
Slik måler du resultater
Måling følger guidens løfte: ble prosedyren funnet for den tiltenkte oppgaven, valgt som en nyttig kilde, fulgt og koblet til en meningsfull neste tilstand? Bruk AI-rangeringsovervåking for å overvåke gjentakende målorienterte spørringer, og inspiser deretter Prompt-sporing for svarordlyd, sitert URL, motor og konkurrentkilder. Den fungerende dylenken er åpne Prompt Tracking .
Noter promptsettet og en baseline før publisering. Spor siteringer separat fra merkeomtaler. På nettstedet, bruk fullføringsbevis som å nå sluttsjekken, velge neste-trinns CTA, fullføre en tilknyttet produkthendelse, eller redusert støttebehov. Hver er bevis, ikke beviskraft; rulledybde kan ikke vise at prosedyren fungerte.
FAQ
Ofte stilte spørsmål
Hva gjør en hvordan-gjør-det-guide forskjellig fra dokumentasjon?
Trenger hvert trinn et skjermbilde?
Hvor mange trinn bør en hvordan-gjør-det-guide ha?
Bør en hvordan-gjør-det-guide inkludere HowTo-skjema?
Hvor bør feilsøking plasseres?
Hvordan bør et team måle en hvordan-gjør-det-guide?
Sett guiden i produksjon
Test prosedyren med en representativ leser, og bruk deretter CTA-blokken for å tilby én handling som følger naturlig etter verifisert fullføring.
Flere veiledninger i denne delen
Klar til å sette det ut i livet?
Gratis sjekk · 7 dagers prøveperiode · ingen kredittkort