Hjälp

Använd Hjälp som en sekundär mekanism för att hjälpa användarna att slutföra och bättre förstå uppgifter som den primära mekanismen är själva användargränssnittet. Använd de här riktlinjerna för att göra innehållet riktigt användbart och enkelt att hitta.

Ett hjälpsystem består av olika typer av innehåll som är utformade för att hjälpa användare när de inte kan slutföra en uppgift, vill förstå ett begrepp mer detaljerat eller behöver mer teknisk information än vad som är tillgängligt i användargränssnittet.

I den här artikeln refererar vi till Hjälp som sekundär till användargränssnittet. Användargränssnittet är primärt eftersom det är där användarna först försöker lösa sina problem. De konsulterar bara hjälpsystemet om de inte kan utföra sin uppgift med användargränssnittet.

Startsidan för Windows-hjälp och -support finns på Start-menyn.

Obs! Riktlinjer som rör stil och ton presenteras i en separat artikel.

Är det här rätt användargränssnitt?

Du kan ta ställning till följande frågor:

• Hur motiverade är dina målanvändare? Ju mer motiverade de är att upptäcka funktioner i ditt program och bli mellanliggande eller till och med avancerade användare av det, desto mer villiga är de att undersöka svar på sina frågor genom att konsultera hjälpämnen.
• Använder du Hjälp för att åtgärda ett felaktigt användargränssnitt? Desto bättre användargränssnitt, desto mindre kommer användarna att söka ytterligare hjälp. Om programmet har ett mycket tydligt, användbart primärt användargränssnitt (till exempel jargongfria felmeddelanden, välskrivna guider och entydiga dialogrutor) kanske du inte behöver något sekundärt hjälpsystem alls.
• Är ditt program relativt enkelt? I så fall bör du överväga att införliva allt nödvändigt hjälpinnehåll i dina primära gränssnittsytor. Användare är mer benägna att söka ytterligare hjälp i program som utför komplexa uppgifter.
• Är ditt program avsett för utvecklare, IT-proffs eller andra programvaruexperter? Dessa användare brukar förvänta sig referenshjälp för programmeringsspråkkonventioner och djupgående konceptuell hjälp för att behärska funktioner.

Designbegrepp

Om du bestämmer dig för att inkludera Hjälp i ditt program kan du integrera den i din övergripande design. Hjälpgränssnittet ska vara enkelt, effektivt och relevant. Det bör göra det möjligt för användare att enkelt få hjälp och sedan återgå till sin uppgift. Tänk på ditt hjälpsystem när det gäller användarnas tid: minimera störningar först genom att förutse var de kommer att stöta på problem i ditt program, sedan lösa dessa problem genom att införliva grundläggande hjälp direkt i användargränssnittet och skapa tydliga och konsekventa startpunkter i din mer detaljerade hjälp.

Windows-hjälpen utformades enligt dessa principer. Här följer några av designändringarna i Användarupplevelsen för Windows-hjälpen:

• Mer identifierbara startpunkter till Hjälp från det primära användargränssnittet (särskilt nya hjälplänkar från gränssnittsytor som dialogrutor, felmeddelanden och guider). Hjälplänkar tar dig direkt till det relevanta ämnet i hjälpen.
• En hjälpknappikon finns i det övre högra hörnet på de flesta kontrollpanelens hubbsidor samt gränssnittsmappar.
• Användare kan välja att få mest up-to- datum Hjälpinnehåll från Windows Online Hjälp och support när de är online.
• Hjälpavsnitten är nu aktivitetsbaserade snarare än funktionsfokuserade, så att användarna kan utföra sina uppgifter snabbt och effektivt.
• Hjälpavsnitten baseras nu till stor del på kända scenarier för de vanligaste användarna.
• Hjälptexter har en mer avslappnad och informell ton, med ett mer vardagligt språk.
• Hjälpavsnitt är utformade för effektiv genomsökning eftersom användarna sällan läser innehållet ord för ord.

En analogi för hjälp

Om du vill tänka närmare på hur du utformar ditt hjälpsystem bör du överväga en analogi från vardagen. Du är vilse i en okänd stad. Vad gör du? Många skulle reagera så här:

• Bli orienterad; leta efter landmärken, gatuskyltar (namn och pekare till platser).
• Leta efter kartor.
• Slutligen, som en sista utväg, be om vägbeskrivning eller ring en vän.

Utformningen av stadens "gränssnitt" påverkar ditt behov av hjälp. Välmärkta gator, explicita riktningar (pekare till sjukhus, flygplatser, museer och postkontor) och tydliga landmärken som framstående geografiska funktioner eller byggnader hjälper dig att hitta din väg.

Du ber om hjälp som en sista utväg. Det är en indikation på att stadens "gränssnitt" har misslyckats genom att vara dåligt utformad och förvirrande. Du är mer benägna att be om hjälp på en plats som har en specifik etikett som tyder på användbarhet. Du är till exempel mer benägna att be om hjälp på en plats märkt "Directions" eller "Information" än en allmän plats som stadshuset, även om nästan vem som helst i stadshuset kan ge dig vägbeskrivningar.

När du ber om hjälp är chansen stor att du är frustrerad och bara vill komma till din avsedda destination. Du är förmodligen inte på humör för att spendera tid på att ta en rundtur i staden eller lära dig om dess historia. Dessutom beror din motivation på uppgiftens betydelse. Om du försöker hitta ditt hotellrum, kommer du att göra vad som krävs. Men om ditt mål är att hitta en plats av mindre betydelse, troligtvis kommer du bara att ge upp efter en blygsam ansträngning.

Alla dessa aspekter av att hitta din väg i verkligt utrymme motsvarar hur användare vanligtvis hittar sin väg i det virtuella utrymmet i ditt program. Att söka hjälp bortom det primära användargränssnittet är till sin natur förvirrande; gör ditt bästa för att minimera en sådan upplevelse genom väldesignade användargränssnitt och intelligenta "gatuskyltar" för att dirigera användarna till de svar de behöver.

Utforma användargränssnittet så att hjälpen inte behövs

Försök att göra hjälpen onödig i första hand genom att:

• Gör det enkelt att identifiera och utföra vanliga uppgifter.
• Ge tydliga huvudinstruktioner.
• Ger tydliga, koncisa kontrolletiketter som är mål- och uppgiftsorienterade.
• Ge kompletterande instruktioner och förklaringar där det behövs.
• Förutse problem som kan undvikas genom att använda kontroller som är begränsade till giltiga val, tillhandahålla lämpliga standardvärden, hantera alla indataformat och förhindra fel.
• Skriva felmeddelanden som ger en tydlig lösning eller åtgärd som användaren kan vidta.
• Undvika förvirrande användargränssnittsdesign, till exempel uppgifter med dåligt flöde eller att använda kontroller som är inaktiverade utan uppenbar anledning.
• Arbeta med författare och redigerare tidigt i utvecklingscykeln för att skapa högkvalitativ, konsekvent UI-text i hela programmet.

Användare ska inte behöva gå någon annanstans för att ta reda på hur du använder ditt användargränssnitt. Lägg till viktig information direkt i det primära användargränssnittet i stället för att tvinga användarna ur sin omedelbara kontext och i hjälpfönstret. Om viktig information bara finns i ett hjälpavsnitt finns det en god chans att användarna inte ser den. Information som är valfri och mer förklarande finns i Hjälplänkar från det primära användargränssnittet till relevant hjälpavsnitt för ytterligare hjälp.

Med tanke på användarens motivation

För de flesta användare är hastighet och effektivitet bland de viktigaste fördelarna med bra program. Användarna vill få sitt arbete gjort. I allmänhet är de inte intresserade av att lära sig om programmet och tekniken för sin egen skull; deras tålamod sträcker sig endast i den mån det programmet tjänar sina egna intressen och löser problem till hands.

Utforma ditt hjälpsystem så att det matchar användarnas motivation. Tänk dig till exempel en användare som har promenerat upp till en kiosk på ett museum. Om hon inte kan ta reda på hur hon ska utföra uppgiften snabbt, kommer hon sannolikt bara att ge upp och gå iväg. Det är osannolikt att hon kommer att ägna tid åt att använda hjälp. Alternativt har en mycket motiverad användare en högre tolerans för den tid som ägnas åt att söka efter svar i hjälpsystemet. En företagsanvändare som till exempel måste balansera böckerna är förmodligen villig att konsultera hjälpinnehåll för att få ut mesta möjliga av det nya redovisningsprogrammet.

Skriva innehåll för genomsökning

Skriv hjälpavsnitt med vetskap om att de kommer att genomsökas efter specifik information, snarare än att läsas ord för ord. Skriv kortfattat, komma till saken snabbt och ge information som användarna kan agera på.

• Skriv "instruktioner"-ämnen med hjälp av numrerade steg i ett konsekvent format så att användarna inser att de får hjälp med proceduren.
• Skriv referensämnen med enkel genomsökning i åtanke, med tabeller, till exempel för att presentera UI-alternativ eller språksyntax.
• Skriv konceptuella ämnen som är logiskt ordnade efter underrubriker, så att användaren kan hoppa över hela avsnitt av mindre intresse.

I allt hjälpinnehåll är det enklare att skanna punktlistor än standardstyckeblock med text. använd dock punktlistor omdömesgillt, inte som en krycka för oorganiserat material.

Skapa innehåll som är viktigt

Med tanke på att inget hjälpsystem kan förutse varje fråga som varje användare kan ha, fokuserar du det mesta av innehållet på att besvara de viktigaste frågorna i de främsta scenarierna för dina målanvändare. Effektiv sökning och hur du upprättar nätverksanslutningar (bland andra uppgifter) kan till exempel vara mycket eftertraktade ämnen. Fokusera också på uppgifter i dina främsta användarscenarier i stället för att dokumentera en funktion eller teknik fullständigt för sin egen skull.

Tips: Teknisk support är en bra källa för hjälpinnehåll. Supportavdelningen för ofta register över vanliga frågor om vissa program eller uppgifter som användarna försöker (och misslyckas med) att utföra.

Det är inte nödvändigt att ge hjälp för varje funktion i användargränssnittet. Ganska ofta resulterar ohjälpsam hjälp från att försöka skapa hjälp för allt. Om användargränssnittet är väl utformat är de flesta av dessa hjälpavsnitt inte särskilt användbara. de kommer bara att upprepa det uppenbara.

Om det finns mer än ett sätt att utföra en uppgift kan du i de flesta fall bara dokumentera det vanligaste sättet som används av oerfarna användare. Undantag till detta omfattar hjälpmedelsöverväganden (till exempel att dokumentera tangentbordsekvivalenter för musåtgärder) och plattformsöverväganden (dokumentera för tablettformfaktorn, till exempel för servermiljöer där kommandoraden kan ersätta det grafiska användargränssnittet).

Kom ihåg att användarna ofta inte tänker på de problem de stöter på i exakt samma termer som du. Användare kan till exempel tycka att det är konstigt att se sig själva som ett "konto". Se sedan till att utforma sök- och indexeringsfunktionen för att ta hänsyn till sannolika terminologivariationer och synonymer.

Mellan det primära användargränssnittet och hjälpsystemet bör termerna dock vara mycket lika om de inte är identiska. Användare kan bli förvirrade när hjälpsystemspråket inte korrelerar särskilt nära det de ser på skärmen.

Skriva övertygande hjälplänktext

När du länkar till ett hjälpavsnitt från ditt primära användargränssnitt ska du skriva övertygande hjälplänktext. Tydligt och specifikt språk inger förtroende. Användarna tenderar att tro att allmänna hjälplänkar (en knapp med ordet "Hjälp" eller "Läs mer" på den) inte leder till rätt information utan en betydande tidsinvestering.

Om du bara gör fem saker...

1. Utforma användargränssnittet så att användarna inte behöver hjälp.
2. Gör din hjälp användbar genom att fokusera innehållet på de viktigaste frågorna i de främsta scenarierna för dina målanvändare.
3. Presentera hjälpinnehållet så att det är enkelt att skanna.
4. Förstå att du inte behöver ge hjälp för varje funktion i användargränssnittet.
5. Gör startpunkterna för hjälpen identifierbara och övertygande.

Användningsmönster

Olika typer av innehåll har olika syften.

Innehållstyp	Exempel
procedurhjälp innehåller stegen för att utföra en uppgift.	Procedurhjälp bör fokusera på "hur" information snarare än "vad" eller "varför". I det här exemplet beskriver hjälpavsnittet hur du använder en funktion i verktyget Diskrensning, med steg att följa i följd.
Konceptuell Hjälp innehåller bakgrundsinformation, funktionsöversikter eller processer.	Konceptuell hjälp bör ge "vad" eller "varför" information utöver det som behövs för att slutföra en uppgift. I det här exemplet definierar hjälpavsnittet vad skrivbordet är och ger ytterligare information om vad det innehåller och varför användarna interagerar med det.
Referenshjälp fungerar som en onlinereferensbok.	Du kan använda referenshjälp för att dokumentera ett programmeringsspråk eller programmeringsgränssnitt. I det här exemplet listar hjälpavsnittet typografiska konventioner som används för det här språket eller programmet, vilket ger informationen i en lättgenomsökningstabell.

Riktlinjer

Startpunkter

• Länk till specifika, relevanta hjälpavsnitt. Länka inte till startsidan för hjälpen, innehållsförteckningen, en lista med sökresultat eller en sida som bara länkar till andra sidor. Undvik att länka till sidor som är strukturerade som en stor lista med vanliga frågor, eftersom det tvingar användare att söka efter den som matchar länken de klickade på. Länka inte till specifika hjälpavsnitt som inte är relevanta och användbara för den aktuella uppgiften. Länka aldrig till tomma sidor.

• Placera inte hjälplänkar i varje fönster eller sida för konsekvensens skull. Att tillhandahålla en hjälplänk på ett ställe betyder inte att du måste ange dem överallt.

• Använd hjälplänkar för dialogrutor, felmeddelanden, guider och egenskapsblad. Om hjälplänken gäller för specifika kontroller placerar du den under dem, vänsterjusterad. Om hjälplänken gäller för hela fönstret placerar du den i det nedre vänstra hörnet i fönstrets innehållsområde.

  

  I det här exemplet gäller den andra hjälplänken för en grupp kontroller.

  

  I det här exemplet gäller hjälplänken för hela fönstret.

• Använd hjälplänkar i stället för allmänna textreferenser till Hjälp när det är tekniskt möjligt.

  rätt:

  Hur kan jag reparera diskfel?

  felaktig:

  Mer information om hur du reparerar diskfel finns i Hjälp och support.

• Använd en hjälpknapp med hjälpikonen för hubbsidorna för kontrollpanelsobjekt. Placera den i det övre högra hörnet. De här knapparna har ingen etikett, men har en knappbeskrivning som läser Hjälp.

  

  Ett kontrollpanelobjekt med hjälpknappen.

• F1 Hjälp är valfritt. Användarna har vant sig vid att hitta hjälpinformation om användargränssnittets omedelbara kontext på skärmen genom att trycka på F1-tangenten, som är märkt Hjälp på standardtangentbord. Du kan inkludera F1-hjälp om till exempel användbarhetsstudier visar att användarna förväntar sig att hitta den, eller om programmets användargränssnitt är tillräckligt komplext för att dra nytta av sammanhangsberoende hjälp.

• Program med menyrader kan ha en hjälpmenykategori. Riktlinjer för hjälpmenyn finns i Menyer.

  

  I det här exemplet har Windows Paint-tillbehöret en hjälpmenykategori.

• För tangentbordsnavigering, ange tabbstopp för hjälpknappar och länkar.

• Hjälpknappen och länkbeteendet bör vara följande: Hjälpfönstret öppnas och ett dedikerat hjälpavsnitt visas. Användargränssnittet som anropade hjälpfönstret bör vara öppet för att bevara kontextupplevelsen.

• Använd inte följande föråldrade startpunktsformat för hjälp: "Läs mer" eller "Läs mer om..." länkar, allmänna hjälpknappar och sammanhangsberoende hjälpknappar i namnlisten. Även om de har använts tidigare har användbarhetsstudier fastställt att användare tenderar att ignorera dem. Använd länkar till specifika hjälpavsnitt i stället. Riktlinjer för att skriva bra hjälplänkar finns i hjälplänkar.

  felaktig:

  

  Använd inte "Läs mer" eller "Läs mer om..." Länkar.

  felaktig:

  

  Använd inte allmänna hjälpknappar.

  felaktig:

  

  Använd inte sammanhangsberoende hjälpknappar i namnlisten.

Innehåll

• Skapa inte uppenbart innehåll. Hjälpavsnitt som upprepar vad som finns i det primära användargränssnittet lägger inte till värde.
• Skapa inte innehåll som användaren inte kan agera på på något sätt.
  • Undantag: En del konceptuellt innehåll ger viktig bakgrundsinformation utan att nödvändigtvis leda till användaråtgärder.
• Undvik vaga lösningar på problem. Till exempel tenderar "kontakta systemadministratören" eller "installera om programmet" att frustrera användarna.
  • Undantag: Rekommenderar att du kontaktar systemadministratören om det är den enda praktiska lösningen, och systemadministratörer förväntar sig att kontaktas för problemet.
• Undvik innehåll som hanterar mycket osannolika användarscenarier. Utveckla ditt huvudsakliga hjälpinnehåll för vad du förväntar dig kommer att vara normal användning; Observera viktiga undantag för förväntad användning, men behandla det här innehållet som en lägre prioritet.
• Samla in feedback från dina användare om hur användbara hjälpavsnitten är. Tillåt användare att betygsätta enskilda ämnen. Utför användbarhetsstudier på din dokumentation för att fastställa problem som rör kvalitet och upptäckt av innehåll.
  • Tips: Användarfeedback är också ett bra sätt att generera mer uppgiftsbaserat innehåll, fokuserat på vad användarna faktiskt gör med ditt program, i motsats till funktionsbaserat innehåll, fokuserar helt enkelt på en beskrivning av tekniken.
• Ange flera sätt att komma åt ditt innehåll. En innehållsförteckning, ett index och en sökmekanism är tre av de vanligaste metoderna för att förbättra identifieringen.
• Om det finns mer än ett sätt att utföra en uppgift kan du i de flesta fall bara dokumentera det vanligaste sättet som används av oerfarna användare.

Ikoner

• Använd endast hjälpikonen för Utforskarens fönster och hubbsidorna för kontrollpanelobjekt. Använd inte hjälpikonen med hjälplänkar.

rätt:

I det här exemplet använder ett Windows Explorer-fönster en hjälpikon för att ge åtkomst till Hjälp.

felaktig:

I det här exemplet används hjälpikonen längst ned till vänster felaktigt med hjälplänken.

Text

Hjälplänkar

• Ange specifik information om innehållet i hjälpavsnittet med så mycket relevant, koncis text som behövs. Användare ignorerar ofta allmänna hjälplänkar. Se till att resultaten av länken är förutsägbara användare bör inte bli förvånade över resultatet.

  • Undantag: Du kan använda "Mer information" för att komplettera instruktioner som finns direkt i användargränssnittet, särskilt om tillhandahållande av specifik information i hjälplänken leder till onödig upprepning eller gör länken mindre övertygande.

  felaktig:

  Ett starkt lösenord har minst sex blandade stora och små bokstäver, siffror och symboler. Vad är ett starkt lösenord?

  rätt:

  Ett starkt lösenord har minst sex tecken och består av både stora och små bokstäver, siffror och symboler. Mer information

  I det felaktiga exemplet är hjälplänken repetitiv. Den ställer en fråga som verkligen redan har besvarats.

• Formulera, när det är möjligt, hjälplänkstexten utifrån den primära frågan som besvaras i hjälpinnehållet. Använd inte formuleringen "Läs mer om", "Berätta mer om" eller "Få hjälp med det här".

  felaktig:

  Läs mer om att lägga till undantag

  Rätt:

  Vilka är riskerna med att tillåta undantag?

  Hur lägger jag till undantag?

  I rätt exempel formuleras länken i termer av den primära fråga som besvaras av hjälpavsnittet.

• Om den mest relevanta informationen kan sammanfattas kortfattat placerar du sammanfattningen direkt i användargränssnittet i stället för att använda en hjälplänk. Du kan dock använda en hjälplänk för att tillhandahålla kompletterande information.

  felaktig:

  

  rätt:

  

  Bättre:

  

  Det korrekta exemplet sammanfattar hjälpinformationen kortfattat, vilket avsevärt förbättrar sannolikheten för att användarna läser den. Det bättre exemplet innehåller en hjälplänk för mer information om det här komplexa ämnet.

• Frashjälplänkar för att tydligt ange hjälp. Hjälplänkar bör aldrig läsas som åtgärdslänkar.

• Använd hela hjälplänken för länktexten, inte bara nyckelorden.

  Rätt:

  Vilka är riskerna med att tillåta undantag?

  felaktig:

  Vilka är riskerna med att tillåta undantag?

  I rätt exempel används hela hjälplänkens mening för länktexten.

  • Undantag: hjälplänkar till externa webbplatser bör helt enkelt använda namnet på webbplatsen eller sidan som länk. All text som introducerar namnet på webbplatsen behöver inte inkluderas i själva länken.

• Hjälplänkar behöver inte matcha rubrikerna i hjälpavsnittet exakt, men det bör finnas en stark och uppenbar koppling mellan de två. Utforma länkar och rubriker i par av den anledningen.

  rätt:

  Hur kan jag förbättra prestandan för den här funktionen? (länktext)

  Konfigurera den här funktionen för optimal prestanda (ämnesrubrik)

  felaktig:

  Hur kan jag förbättra prestandan för den här funktionen? (länktext)

  Fullständig översikt över den här funktionen (ämnesrubrik)

  I det felaktiga exemplet skiljer sig rubriken i hjälpavsnittet avsevärt i omfånget från hjälplänktexten och kan vara desorienterad.

• Om hjälpinnehållet är online gör du det tydligt i länktexten. Om du gör det blir resultatet av länkarna förutsägbart.

  rätt:

  Om du vill ha fler format och verktyg går du till Microsofts webbplats.

  felaktig:

  Var hittar jag ytterligare format och verktyg?

• Använd fullständiga meningar.

• Använd inte avslutande skiljetecken, förutom frågetecken.

• Använd inte ellipser för hjälplänkar eller kommandon.

Hjälpinnehåll

• Formatera gränssnittselement med fetstil för att göra dem enkla att identifiera. Detta är särskilt användbart för hjälpavsnitt för procedurer, så att användarna kan söka igenom procedurer och snabbt se relevanta gränssnittselement.
• Formatera undertexter med kursiv stil. Detta gäller tabeller, bilder, skärmbilder och andra grafiska element som har nytta av en kort textförklaring.
• Se Hjälp helt enkelt som hjälp. I allmänhet ska du inte använda frasen onlinehjälp om du inte i själva verket refererar till innehåll på webbplatsen.