Kommentar
Åtkomst till den här sidan kräver auktorisering. Du kan prova att logga in eller ändra kataloger.
Åtkomst till den här sidan kräver auktorisering. Du kan prova att ändra kataloger.
Program kan vara komplexa och ge effektiv hjälp till användarna kan avsevärt förbättra deras upplevelse. Alla program behöver inte ge hjälp till sina användare, och vilken typ av hjälp som ska ges kan variera mycket beroende på programmet.
Om du bestämmer dig för att ge hjälp följer du dessa riktlinjer när du skapar den. Hjälp som inte är till hjälp kan vara värre än ingen hjälp alls.
Intuitiv design
Så användbart som hjälpinnehåll kan vara, kan din app inte förlita sig på det för att ge en bra upplevelse för användaren. Om användaren inte kan identifiera och använda appens kritiska funktioner omedelbart kommer användaren inte att använda din app. Ingen mängd eller kvalitetshjälp kommer att ändra det första intrycket.
En intuitiv och användarvänlig design är det första steget för att skriva användbar hjälp. Det håller inte bara användaren engagerad tillräckligt länge för att de ska kunna använda mer avancerade funktioner, utan ger dem också kunskap om en apps kärnfunktioner, som de kan bygga vidare på när de fortsätter att använda appen och lära sig.
Allmänna instruktioner
En användare söker inte efter hjälpinnehåll om de inte redan har ett problem, så hjälpen måste ge ett snabbt och effektivt svar på problemet. Om hjälpen inte är direkt användbar, eller om hjälpen är för komplicerad, är det mer troligt att användarna ignorerar den.
All hjälp, oavsett vilken typ, bör följa dessa principer:
Lätt att förstå: Hjälp som förvirrar användaren är värre än ingen hjälp alls.
Enkelt: Användare som söker hjälp vill ha tydliga svar som presenteras direkt för dem.
Relevanta: Användarna vill inte behöva söka efter sitt specifika problem. De vill ha den mest relevanta hjälpen som presenteras direkt för dem (detta kallas "Sammanhangsbaserad hjälp"), eller så vill de ha ett lättnavigerat gränssnitt.
Direkt: När en användare söker hjälp vill de se hjälp. Om din app innehåller sidor för att rapportera buggar, ge feedback, visa tjänstvillkor eller liknande funktioner är det bra om din hjälp länkar till dessa sidor. Men de bör inkluderas som en eftertanke på huvudhjälpsidan och inte som objekt med samma eller större betydelse.
Konsekvent: Oavsett typ är hjälp fortfarande en del av din app och bör behandlas som någon annan del av användargränssnittet. Samma designprinciper för användbarhet, tillgänglighet och stil som används i resten av appen bör också finnas i den hjälp du erbjuder.
Typer av hjälp
Det finns tre primära kategorier av hjälpinnehåll, var och en med varierande styrkor och lämplig för olika ändamål. Använd valfri kombination av dem i din app, beroende på dina behov.
Instruktionsgränssnitt
Normalt bör användarna kunna använda alla kärnfunktioner i din app utan instruktioner. Men ibland beror din app på användningen av en specifik gest, eller så kan det finnas sekundära funktioner i din app som inte är direkt uppenbara. I det här fallet bör instruktionsgränssnittet användas för att utbilda användare med instruktioner om hur man utför specifika uppgifter.
Se riktlinjer för instruktionsgränssnitt
Hjälp i appen
Standardmetoden för att presentera hjälp är att visa den i programmet på användarens begäran. Det finns flera sätt på vilka detta kan implementeras, till exempel i hjälpsidor eller informativa beskrivningar. Den här metoden är idealisk för allmän hjälp som direkt besvarar en användares frågor utan komplexitet.
Se riktlinjer för hjälp i appen
Extern hjälp
För detaljerade självstudier, avancerade funktioner eller bibliotek med hjälpämnen som är för stora för att passa in i ditt program är länkar till externa webbsidor idealiska. Dessa länkar bör användas sparsamt om möjligt, eftersom de tar bort användaren från programupplevelsen.
Windows developer