Sådan-guider: Struktur, trin og skema
Byg en sådan-guide, der omdanner læserens mål til ordnede, testbare trin med forudsætninger, succesindikatorer, genoprettelsesveje og fejlfinding.
En sådan-guide er en ordnet procedure, der fører en læser fra en kendt starttilstand til et verificeret resultat. Den besvarer “Hvordan udfører jeg denne opgave?” uden at lade læseren opfinde et manglende trin.
Hvert trin har brug for en imperativ titel, dets begrundelse, handlingen, en observerbar successtatus og en genoprettelsesvej. Klik-kun-instruktioner fungerer kun, når læserens konto, adgang, data og interface tilfældigvis matcher forfatterens antagelser.
Læserens spørgsmål besvaret: “Hvad har jeg brug for, hvad gør jeg i rækkefølge, hvordan ved jeg, at det virkede, og hvordan kommer jeg tilbage, hvis det ikke gjorde?”
Spørgsmål det besvarer
En sådan-guide tjener informationshensigt , hvilket betyder, at læseren forsøger at lære eller udføre en opgave frem for at evaluere en liste af produkter. Forespørgslen starter ofte med “hvordan”, men ordlyd alene er ikke nok. Det tilsigtede resultat skal være noget, læseren kan udføre og verificere.
Skriv til de spørgsmål, folk rent faktisk bærer ind i proceduren:
- “Har jeg den krævede plan, adgang, værktøjer og tid?”
- “Hvilke handlinger skal ske i rækkefølge, og hvad skal vises efter hver enkelt?”
- “Kan dette overskrive, publicere, opkræve, slette eller blotlægge noget?”
- “Hvordan kommer jeg tilbage fra et andet resultat og bekræfter, at hele opgaven virkede?”
Det direkte svar bør angive resultatet, startbetingelsen, den forventede tid og sværhedsgraden før den første lange forklaring. “På cirka 20 minutter kan en kontoadministrator forbinde Search Console og verificere den første vellykkede import” er nyttigt. “Denne guide udforsker integrationsbedste praksis” er det ikke.
Hvornår skal dette indlægstype bruges
Procedurer fejler ved antagelsesgrænser. Forfatteren ved, hvilken adgang, forsinkelse eller indstilling der betyder noget; læseren gør ikke. Dette format gør skjulte afhængigheder, tilstandsændringer og genoprettelsesbeslutninger synlige i rækkefølge.
| Forvekslelig type | Vælg den, når læseren starter med | Svarform | Hvorfor det ikke er denne type |
|---|---|---|---|
| Sådan-guide | Et mål: “Jeg skal udføre X” | Forudsætninger, ordnede trin, succesindikatorer, genoprettelse, afslutningskontrol | Det er selve proceduren. |
| Sådan vælger du X | En beslutning: “Hvilket X passer til mig?” | Kriterier, alternativer, afvejninger, anbefaling | “Vælg” beskriver evaluering, ikke en handlingssekvens med et testbart resultat. |
| Fejlfindingsartikel | Et symptom: “X mislykkedes” eller “Jeg ser fejl Y” | Diagnosetræ fra symptom til årsag til løsning | Den begynder, efter at en forsøgt procedure allerede har skabt et problem. |
| Dokumentationsartikel | Et behov for at slå adfærd, felter, grænser eller syntaks op | Opslagsværk organiseret til genfinding snarere end én læsevej | Den understøtter mange opgaver og lover ikke én narrativ rute til ét resultat. |
Vælg en sådan-guide kun, når rækkefølgen betyder noget. Hvis uafhængige kontroller kan udføres i vilkårlig rækkefølge, så udgiv en tjekliste. Hvis emnet er bredt nok til at indeholde flere forskellige mål, så brug en ultimativ guide som kort og opret separate sådan-guider til procedurerne. Hvis læseren primært spørger, hvad et begreb betyder, så brug en hvad-er-X-side .
Bedst til disse forretningstyper
Rangeringen afspejler, hvor ofte modellen afhænger af, at en læser gennemfører en gentagelig proces, ikke den overordnede værdi af indhold for virksomheden.
- SaaS . Opsætning, konfiguration, migration og gentagne arbejdsgange bestemmer, om brugere når værdi. Skel mellem plangrænser, roller, interfacetilstande og destruktive ændringer.
- E-handel . Købere har brug for monterings-, størrelses-, installations-, brugs- og plejeprocedurer. Vis fysisk orientering, når ord ikke kan gøre det sikkert.
- Lokal service . Forberedelsesguider hjælper kunder med at samle input og forstå aftaler. Adskil sikkert kundearbejde fra arbejde forbeholdt en kvalificeret fagperson.
- Markedspladser . Sælgere, købere, udbydere og administratorer kan følge forskellige arbejdsgange. Angiv målgruppe og rolle før forudsætningerne.
- B2B-tjenester . Onboarding-, godkendelses-, overdragelses- og reviewguider tydeliggør ejerskab og viser, hvordan færdigt arbejde ser ud.
- Medieudgivere og affilierede . Ekspert-tutorials kan imødekomme opgavedrevet efterspørgsel, men udgivere skal teste proceduren og vedligeholde optagelser frem for at omskrive leverandørdokumentation.
Søgehensigt
Søgehensigt er det resultat, en person forventer fra en forespørgsel. For procedurehensigt er den forventede svarform en umiddelbar gennemførlighedskontrol efterfulgt af en udførbar rute: resultat, tid, sværhedsgrad, forudsætninger, ordnede handlinger, verifikation, fejlfinding og næste trin.
Opgaveresultater kan blande videoer, trinuddrag, produktdokumentation, fællesskabssvar og tutorials. AI-svar komprimerer ofte ruten til en nummereret sekvens med kilder. Hvert ekstraheret trin skal bevare sit objekt, sin betingelse og sit forventede resultat; advarsler skal placeres før risikable handlinger.
Optag begge eksempler på samme dato, og notér forespørgslen, placering, enhed, login-status og interface. Resultater ændrer sig; designlektien bør komme fra svarformen, ikke en påstand om, at én udbyder altid viser en bestemt funktion.
Sidestruktur
Ordintervaller styrer vægtning, ikke kvoter. Tilføj kun ord, når de fjerner en beslutning, læseren ellers skulle tage alene.
| Sektion | Ordinterval | Formål | Status |
|---|---|---|---|
| Hero og direkte svar | 60–100 | Angiv resultatet, læseren, starttilstanden, tiden og sværhedsgraden. | Påkrævet |
| Forudsætninger | 120–220 | Liste over adgang, værktøjer, input, omkostninger, versioner, sikkerhedsbetingelser og irreversible forpligtelser før arbejdet begynder. | Påkrævet |
| Kort oversigt | 60–120 | Forhåndsvisning af hovedfaser og den endelige successtatus uden at duplikere hver instruktion. | Påkrævet |
| Ordnet procedure | 700–1.500 | Før læseren gennem imperative, begrundede, testbare, genoprettelige trin. | Påkrævet |
| Afslutningskontrol | 100–180 | Verificér slutresultatet med observerbar dokumentation, og liste hvad “færdig” inkluderer. | Påkrævet |
| Fejlfinding | 250–500 | Løs almindelige fejl i denne procedure efter symptom, sandsynlig årsag og næste handling. | Påkrævet |
| Variationer | 150–350 | Forklar meningsfulde forskelle i plan, enhed, rolle eller version. | Betinget |
| FAQ | 200–350 | Besvar resterende spørgsmål, der ikke hører til inde i et trin. | Påkrævet; 5–7 spørgsmål |
| CTA | 40–90 | Tilbyd én logisk handling, efter at læseren har gennemført eller vurderet opgaven. | Påkrævet |
Påkrævede elementer
Trinlisten har procedurekontrakten. Forudsætninger beskytter dens starttilstand, og afslutningskontrollen beviser det lovede resultat; ingen af dem har en separat elementside, så de forbliver navngivne strukturelle sektioner frem for opfundne elementer.
| Element | Status | Præcis placering | Hvorfor det hører til der |
|---|---|---|---|
| trinliste | Altid | Efter forudsætninger og den korte oversigt | Sekvensen er sidens kerneleverance; hvert trin indeholder begrundelse, handling, succes og genoprettelse. |
| Annoteret skærmbillede | Betinget | Umiddelbart efter instruktionen, hvis interface eller tilstand er tvetydig | En optagelse løser rumlig tvetydighed kun, så længe den forbliver ved siden af den relevante handling. |
| Tipboks | Betinget | Efter den påkrævede instruktion, den forbedrer | Valgfri optimering må ikke forveksles med en betingelse for succes. |
| Advarseboks | Betinget, obligatorisk når risiko findes | Før den risikable eller irreversible handling | En advarsel kan kun ændre adfærd, før konsekvensen udløses. |
| FAQ-struktur | Altid | Efter fejlfinding, før CTA | Resterende spørgsmål hører efter den komplette procedure, så svar ikke fragmenterer sekvensen. |
| CTA-blok | Altid | Sidste indholdsblok | Den næste handling bliver først rimelig, efter at siden har leveret det lovede resultat. |
Hvornår skærmbilleder er obligatoriske
Et skærmbillede er obligatorisk, når tekst ikke pålideligt kan identificere den korrekte knap, placering, tilstand, orientering eller resultat. Brug et for lignende kontroller, skjulte indstillinger, umærkede visuelle tilstande eller fysiske dele, der kan forveksles. Beskær til beslutningsområdet, behold orienteringskontekst, markér målet, og forklar det i tekst.
Et skærmbillede er støj, når det gentager “Vælg Gem”, viser en hel skærm for én åbenlys knap eller erstatter tekst. Gør aldrig et billede til den eneste kilde for en kommando, advarsel, værdi eller succes-kriterium.
Frontmatter
Frontmatteren skal beskrive proceduren lige så præcist som den synlige side.
| Felt | Påkrævet værdi eller regel |
|---|---|
entity | En stabil verbum–objekt-værdi for opgaven, f.eks. connect-google-search-console, ikke det brede emne search-console. |
schemaType | HowTo når den synlige side er en ordnet procedure med et resultat; ellers Article. |
name | Samme opgavenavn som læserne ser i titlen eller det direkte svar. |
description | Kortfattet resultat og omfang, ikke en liste af nøgleord. |
totalTime | Ærlig ISO 8601-varighed afledt af testet gennemførelsestid; adskil ventetid i synlig tekst. |
estimatedCost | Inkludér kun, når proceduren kræver et køb eller gebyr, med synligt beløb og valuta. |
supply og tool | List kun elementer, der er nævnt i de synlige forudsætninger. Kald ikke softwareadgang for en fysisk forsyning. |
step | Samme antal, rækkefølge, navne, tekst, URL’er og billeder som de synlige trin. |
inLanguage og datoer | Match det publicerede sprog og synlig publicerings- eller ændringsregistrering. |
| FAQ | Brug 5–7 rigtige resterende spørgsmål i [[faq]]; enhver synlig accordion og strukturerede data skal matche dem nøjagtigt. |
Skemamarkering
er maskinlæsbare data om synligt indhold. Publicér HowTo som JSON-LD
kun, når implementeringen er tro mod indholdet. Markér aldrig en forudsætning som et trin, flett ikke synlige trin sammen, tilføj ikke skjulte instruktioner, eller vedhæft det forkerte billede. Brug Article, når nøjagtig overensstemmelse ikke kan opretholdes.
Fuldstændigt eksempel
Dette kopiérbare skelet bruger en virkelig opgave. Produktionsprompter i kantede parenteser angiver den dokumentation, en skribent skal indsætte.
# Sådan forbinder du Google Search Console til Northstar Analytics
Forbind en verificeret Search Console-ejendom til Northstar Analytics, så dens første forespørgselsrapport kan importeres. En kontoadministrator kan gennemføre opsætningen på cirka 15 minutter; importen kan tage op til 30 minutter ekstra. Sværhedsgrad: begynder.
## Før du starter
- En Northstar Analytics-konto med rollen Administrator
- Ejeraadgang til den Search Console-ejendom, du vil forbinde
- Den nøjagtige HTTPS-ejendom, der matcher sidens kanoniske værtsnavn
- Tilladelse til at dele Search Console-præstationsdata med Northstar Analytics
Fortsæt ikke med en testejendom eller et andet værtsnavn. Forbindelsen kan teknisk set lykkes, mens den importerer data for det forkerte site.
## Kort oversigt
Du vil vælge sitet, godkende adgang, vælge den matchende ejendom, starte importen og verificere, at en dateret forespørgselsrække vises i Northstar Analytics.
## 1. Bekræft, at sitet og ejendommen matcher
**Hvorfor dette trin findes:** Search Console kan indeholde domæne- og URL-præfiksejendomme med lignende navne. At vælge den forkerte giver en gyldig forbindelse med irrelevant eller ufuldstændig data.
**Gør dette:** I Northstar Analytics åbner du sitets Indstillingsside og kopierer dets kanoniske værtsnavn. I Search Console bekræfter du, at den påtænkte ejendom inkluderer det værtsnavn og den protokol.
**Når det virkede:** Værtsnavnet vist i begge produkter matcher nøjagtigt, inklusive `www` og HTTPS.
**Hvis det ikke gjorde:** Spørg ejendomsejeren, hvilken ejendom der repræsenterer produktion. Gæt ikke ud fra dens visningsnavn.
## 2. Start Search Console-forbindelsen
**Hvorfor dette trin findes:** At starte fra det valgte site binder godkendelsen til det korrekte Northstar Analytics-arbejdsområde.
**Gør dette:** Åbn **Indstillinger → Integrationer → Google Search Console**, og vælg derefter **Forbind**.
**Når det virkede:** Et Google-godkendelsesvindue nævner Northstar Analytics og beder dig vælge en konto.
**Hvis det ikke gjorde:** Tillad pop-ups og prøv igen. Hvis Forbind er deaktiveret, bekræft din Administrator-rolle.
[Indsæt et beskåret, annoteret skærmbillede af Integrationspanelet kun, når Forbind er svær at skelne fra en anden knap.]
## 3. Godkend den korrekte Google-konto
**Hvorfor dette trin findes:** Northstar kan kun liste ejendomme, som den godkendte Google-konto har adgang til.
**Gør dette:** Vælg den Google-konto, der ejer den påtænkte ejendom, gennemgå den anmodede adgang, og godkend den.
**Når det virkede:** Du vender tilbage til Northstar Analytics og ser en ejendomsvælger.
**Hvis det ikke gjorde:** Brug et privat vindue og gentag godkendelsen med ejendomsejerkontoen.
## 4. Vælg produktionsejendommen
**Hvorfor dette trin findes:** Godkendelse beviser kontoadgang, men den valgte ejendom bestemmer, hvilke data der importeres.
**Gør dette:** Vælg den ejendom, der nøjagtigt matchede det kanoniske værtsnavn i trin 1, og vælg derefter **Gem og importer**.
**Når det virkede:** Integrationens status ændres til **Import i kø** og viser den valgte ejendom.
**Hvis det ikke gjorde:** Vend tilbage til trin 3 med en godkendt konto. Sammenlign fulde identifikatorer, når ejendomme ligner hinanden.
## 5. Verificér den første import
**Hvorfor dette trin findes:** Et tilsluttet badge beviser godkendelse, ikke at brugbare data nåede rapporten.
**Gør dette:** Efter den viste ventetid åbner du **Rapporter → Søgeforespørgsler** og indstiller datoperioden til en periode, der har Search Console-data.
**Når det virkede:** Mindst én række viser en forespørgsel, landingsside, dato, klik eller visninger fra den valgte ejendom.
**Hvis det ikke gjorde:** For **Import i kø**, vent og prøv igen. For **Tilladelse udløbet**, genopret forbindelsen. For **Ingen data**, tjek datoperioden og kildeejendommen.
## Afslutningstjekliste
- Integrationen nævner den påtænkte produktionsejendom.
- Dens status er Forbundet snarere end blot I kø.
- Forespørgselsrapporten indeholder en dateret række fra den pågældende ejendom.
- En anden administrator kan identificere, hvilken konto der ejer forbindelsen.
## Fejlfinding
### Ejendomsvælgeren er tom
Den godkendte Google-konto mangler adgang, eller adgangen blev fjernet. Godkend igen med en ejendomsejer, og genindlæs derefter vælgeren.
### Forbindelsen lykkes, men rapporten er tom
Sammenlign rapportens datoperiode med Search Console, og bekræft derefter den nøjagtige ejendomsidentifikator før du afbryder forbindelsen.
### Importen vender gentagne gange tilbage til I kø
Notér sitet, ejendomsidentifikatoren, starttidspunktet og seneste status, og kontakt derefter support. Disse detaljer gør det muligt for support at inspicere importen uden at bede dig gentage godkendelsen blindt.
## FAQ
[Tilføj fem til syv resterende spørgsmål om tilladelser, dataforsinkelse, ejendomstyper, genoprettelse af forbindelse og fjernelse. Gentag ikke trinene.]
## Næste trin
[Tilbyd én handling, der bruger de importerede data, såsom at gennemgå den første forespørgselsmulighedsrapport.]
Designeksempler
Hver gallerivariant skal vise de samme forudsætninger, fem trin, successtatusser, genoprettelsestekst, fejlfinding og afslutningskontrol.
Kvalitetstjekliste
En guide kan kun publiceres, når en reviewer kan gennemføre den fra en ren starttilstand uden forfatteren.
- Helten angiver ét testbart resultat, den påtænkte læser, forventet aktiv tid, ventetid og sværhedsgrad.
- Forudsætninger nævner roller, adgang, versioner, værktøjer, input, gebyrer og sikkerhedsbetingelser, der kunne blokere et senere trin.
- Hvert trin starter med en imperativ titel og forklarer hvorfor, handling, succes og genoprettelse.
- Rækkefølgen er blevet testet; at flytte et trin ville ændre, blokere eller ugyldiggøre resultatet.
- Advarsler vises før risiko, og valgfrie tips skjuler aldrig påkrævet arbejde.
- Skærmbilleder løser reel tvetydighed, har aktuel interfacekontekst og tilgængelige forklaringer og er ikke den eneste kilde til instruktioner.
- Den endelige kontrol verificerer det lovede resultat frem for det sidste klik.
- Fejlfinding dækker observerede eller troværdigt reproducerbare fejl med specifikke næste handlinger.
- HowTo-data matcher hvert synligt trin og ejendom nøjagtigt, eller siden bruger Article i stedet.
- En anden tester har gennemført guiden på den understøttede konto, enhed, rolle og version.
Almindelige fejl
Den mest almindelige fejl er en klik-transskription: “Åbn Indstillinger. Klik på Integrationer. Klik på Forbind.” Den udelader hvorfor ejendommen betyder noget, hvad der burde vises, og hvordan man kommer sig efter manglende tilladelse.
Andre fejl er lige så specifikke:
- At skjule forudsætninger inde i trin. At opdage i trin 4, at administratoradgang tager en dag at få, spilder læserens tid og kan efterlade delvist arbejde.
- At placere advarsler efter handlinger. En sletningsadvarsel under Slet-instruktionen kan ikke forhindre sletning.
- At bruge forløbet tid som aktiv tid. “Tager 40 minutter” er vildledende, når arbejdet tager 10 minutter plus en 30-minutters import. Angiv begge.
- Kun at teste på forfatterens konto. Administratorer ser ofte kontroller, som almindelige medlemmer ikke gør. Test den rolle, der er nævnt i helten.
- At betragte det sidste klik som succes. “Gemt” kan kun betyde, at en anmodning blev accepteret. Verificér den efterfølgende tilstand eller output.
- At lade skemaet drive. Omdøbning, omorganisering eller sammenlægning af synlige trin uden at opdatere HowTo-data skaber to uforenelige procedurer på én URL.
Intern linkning
En sådan-guide linker kun udad, når destinationen forklarer en forudsætning, understøtter en beslutning eller giver den næste procedure. Definér specialist-termer før sekvensen eller ved første brug.
Andre sider bør linke til guiden, når de nævner den nøjagtige opgave, men bør ikke duplikere dens trin. En produktside kan linke fra en funktion til opsætning. En ultimativ guide kan linke fra en bred fase til den relevante procedure. En fejlfindingsartikel kan linke tilbage til guidens starttilstand, efter symptomet er løst.
Duplikér ikke en “sådan vælger du”-beslutningsguide, en symptomledet fejlfindingssti eller generel dokumentation. Hvis en søsterside har brug for mere end et kort resumé af den samme sekvens, etablér én kanonisk procedure og link til den. Hold versionsspecifikke variationer på én side, når hovedruten er delt; del dem kun, når trinene eller forudsætningerne reelt adskiller sig.
Sådan måles resultater
Måling følger guidens løfte: blev proceduren fundet til den påtænkte opgave, valgt som en nyttig kilde, fulgt og forbundet til en meningsfuld næste tilstand? Brug AI-rangsporing til at overvåge gentagne målorienterede prompts, og inspicér derefter Prompt Tracking for svarordlyden, citeret URL, motor og konkurrentkilder. Det fungerende deep link er åbn Prompt Tracking .
Registrér promptsættet og en før-publiceringsbaseline. Spor citationer separat fra brandomtaler. På sitet, brug gennemførelsesdokumentation som at nå den endelige kontrol, vælge næste-trins CTA, gennemføre en tilknyttet produktbegivenhed eller reduceret supportefterspørgsel. Hver er dokumentation, ikke bevis; scrol-dybde kan ikke vise, at proceduren virkede.
FAQ
Ofte stillede spørgsmål
Hvad adskiller en sådan-guide fra dokumentation?
Skal hvert trin have et skærmbillede?
Hvor mange trin skal en sådan-guide have?
Bør en sådan-guide inkludere HowTo-skema?
Hvor skal fejlfinding placeres?
Hvordan måler et team en sådan-guide?
Sæt guiden i produktion
Test proceduren med en repræsentativ læser, og brug derefter CTA-blokken til at tilbyde én handling, der følger naturligt efter verificeret gennemførelse.
Flere tutorials i dette afsnit
Klar til at føre det ud i livet?
Gratis tjek · 7-dages prøveperiode · intet kreditkort