Bekräftelser

Not

Den här designguiden skapades för Windows 7 och har inte uppdaterats för nyare versioner av Windows. Mycket av vägledningen gäller fortfarande i princip, men presentationen och exemplen återspeglar inte vår nuvarande designvägledning.

En bekräftelse är en modal dialogruta som frågar om användaren vill fortsätta med en åtgärd.

En typisk bekräftelse.

Bekräftelser har följande grundläggande egenskaper:

• De visas som ett direkt resultat av en åtgärd som initierats av användaren.
• De kontrollerar att användaren vill fortsätta med åtgärden.
• De består av en enkel fråga och två eller flera svar.

Bekräftelser är mest användbara när åtgärden kräver att användaren gör ett relevant och distinkt val som inte kan göras senare. Det valet innebär ofta vissa riskelement som inte är uppenbara för användaren, men risken är inte nödvändig för bekräftelser. Dessa element är nödvändiga för att motivera avbrottet i att svara på en modal dialogruta.

Däremot varningsmeddelanden presentera ett villkor som kan orsaka problem i framtiden. Deras grundläggande egenskap är att de innebär risk:

• De innebär potentiell förlust av ett eller flera av följande:
  • En värdefull tillgång, till exempel dataförlust eller ekonomisk förlust.
  • Systemåtkomst eller integritet.
  • Sekretess eller kontroll över konfidentiell information.
  • Användarens tid (en betydande mängd, till exempel 30 sekunder eller mer).
• De får oväntade eller oavsiktliga konsekvenser.
• De kräver korrekt hantering nu eftersom misstag inte enkelt kan åtgärdas och kan till och med vara oåterkalleliga.

Om en bekräftelse innebär risk kan den också betraktas som en varning. Riktlinjerna för varningsmeddelanden gäller därför också.

Obs! riktlinjer som rör dialogrutor, felmeddelanden, layoutoch varningsmeddelanden visas i separata artiklar.

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

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

• Får användaren en fråga för att fortsätta med en åtgärd som har två eller flera svar? Annars är meddelandet inte en bekräftelse.
• Visar användargränssnittet ett fel eller problem som har uppstått? I så fall använder du ett felmeddelande i stället.
• Kräver det att användaren gör ett val som inte har en lämplig standard för att fortsätta med åtgärden? I så fall kan en bekräftelse vara lämplig.
• Finns det en alternativ design som eliminerar behovet av bekräftelsen? Behovet av en bekräftelse indikerar ibland ett designfel. Ofta finns det ett bättre designalternativ som inte behöver någon bekräftelse.
• Håller användaren på att utföra en riskfylld åtgärd? I så fall är en bekräftelse lämplig om åtgärden har betydande konsekvenser eller inte enkelt kan ångras.
• Håller användaren på att avbryta en uppgift? Bekräfta i så fall inte. Anta att användarna förstår konsekvenserna av att inte slutföra en uppgift.
• Får åtgärden konsekvenser som användarna kanske inte känner till? I så fall kan en bekräftelse vara lämplig.
• Är det troligt att användarna utför en felåtgärd med tanke på den aktuella kontexten? I så fall kan en bekräftelse vara lämplig.
• Utför användarna åtgärden ofta? I så fall bör du överväga en alternativ design. Frekventa bekräftelser är irriterande och har lite värde eftersom användarna lär sig att svara utan att tänka.
• Har åtgärden säkerhetskonsekvenser? I så fall kan en bekräftelse krävas även om de tidigare testerna anger något annat.

Designbegrepp

Onödiga bekräftelser är irriterande

Den första Windows-bekräftelsen som någonsin skapats såg utan tvekan ut så här:

Den ursprungliga irriterande bekräftelsen.

Det här var en väldigt dålig start. Om du vill att användarna ska hata ditt program, strö bara bekräftelser som detta hela. Tänk på användarens synvinkel för att förstå varför. Användaren bad bara att utföra en åtgärd enligt definitionen av en bekräftelse så om inte något på något sätt klickades eller trycktes på av misstag, naturligtvis vill användaren fortsätta.

Inte bara är onödiga bekräftelser irriterande, men de är inte effektiva för att skydda användaren från misstag. Användarna upptäcker snabbt när ett program har onödiga bekräftelser och deras naturliga svar är att stänga dem så snabbt som möjligt, ofta utan att läsa. Därför gör sådana bekräftelser inte mycket mer än att lägga till ett extra steg i dessa uppgifter.

Använd inte bekräftelser bara för att det finns möjlighet för användare att göra ett misstag. I stället är bekräftelser mest effektiva när de används för att bekräfta åtgärder som har betydande eller oavsiktliga konsekvenser. Bra bekräftelser anger aldrig det uppenbara; de bör kommunicera något som användarna måste vara medvetna om en god anledning att inte fortsätta. Och de används bara när de verkligen behövs av en åtgärd, till exempel att be användare att spara ändringar endast när det finns ändringar som är värda att spara. Detta kräver endast användarens uppmärksamhet när det verkligen är befogat.

För andra typer av bekräftelser finns det ofta ett bättre designalternativ än att tvinga användarna att svara på en fråga.

Överväg designalternativen

Här följer några designalternativ som eliminerar behovet av rutinmässiga bekräftelser:

• Förhindra fel. Utforma uppgifter så att betydande misstag är svåra att göra av misstag. Du kan till exempel fysiskt separera destruktiva kommandon från andra kommandon och kräva flera åtgärder för att slutföra.
• Ange ångra. Ge möjlighet att återställa åtgärder. Att till exempel ta bort en fil i Microsoft Windows kräver vanligtvis ingen bekräftelse eftersom borttagna filer kan återställas från papperskorgen. Observera att om en åtgärd är mycket enkel att utföra kan det vara tillräckligt att bara låta användarna göra om åtgärden.
• Ge feedback. Gör oönskade resultat uppenbara. Det räcker inte att bara ångra om användarna inte inser när de gör ett misstag. Till exempel bör effekten av direkt manipulering (till exempel en drag-och-släpp-åtgärd) alltid vara uppenbar.
• Anta det troliga resultatet, men gör det enkelt att ändra. Om du inte är säker på vad användarna vill ha, men det finns ett sannolikt, säkert och säkert val, antar du det valet, klargör vad som hände och gör det enkelt att ändra med hjälp av en snabbmeny. Microsoft Word förutsätter till exempel att användarna vill stava ord korrekt. Om det känner igen ett felstavat ord och det känner till den troliga korrekta stavningen, gör Word automatiskt korrigeringen men tillåter användare att återgå.
• Eliminera valet helt. Om valet inte är viktigt bryr sig inte användarna. Bättre att förenkla ditt program och eliminera valet.

Få bekräftelser att kräva eftertanke

För att en bekräftelse ska ha ett värde måste användarna förstå orsaken till att inte fortsätta. Ibland är orsaken uppenbar, som när användare stänger ett dokument med ändringar som inte har sparats:

I det här exemplet är orsaken till bekräftelsen uppenbar.

I andra situationer kanske orsaken inte är så uppenbar.

När du väljer incheckningsknappetiketter för dialogrutor är allmänna riktlinjerna att välja etiketter som är specifika svar på huvudinstruktionen. Detta leder till ett effektivt beslutsfattande eftersom användarna måste läsa en minsta mängd text för att kunna fortsätta. Det här effektivitetsmålet kan dock vara kontraproduktivt för bekräftelser. Tänk på det här exemplet:

felaktig:

I det här exemplet kräver rätt svar eftertanke.

Om du visar den här bekräftelsen omedelbart efter att användaren gav kommandot Avinstallera är det troligt att användarens svar är "Naturligtvis vill jag avinstallera!" Användaren klickar på Avinstallera utan att ge det en andra tanke.

För bekräftelser vill vi inte att användarna ska fatta för hastiga, känslomässiga beslut. För att uppmuntra användarna att tänka på sitt svar måste vi tillhandahålla ett litet farthinder i beslutsfattandet. När det är praktiskt är det vanligtvis bättre att göra detta genom att noggrant formulera incheckningsknappar. Vi kan till exempel använda ytterligare språk för att indikera att det finns en anledning att inte fortsätta.

Bättre:

I det här exemplet läggs "anyway" till i incheckningsknappetiketten för att indikera att bekräftelsen ger anledning att inte fortsätta.

Om den metoden inte är praktisk kan vi använda ja/nej-incheckningsknappar.

Också bättre:

I det här exemplet tvingar användning av ja/nej-incheckningsknappar användarna att åtminstone läsa huvudinstruktionen.

Ange all information

Om du ska ställa en fråga måste du tillhandahålla tillräckligt med information för att användarna ska kunna besvara den frågan på ett intelligent sätt. Överväg dialogrutan Bekräfta fil ersätter från Windows XP:

Dialogrutan Bekräfta fil ersätt i Windows XP.

Ger den här bekräftelsen all information som användarna kan behöva för att besvara frågan? Innan du svarar bör du överväga de vanligaste användarscenarierna:

• Kopiera (eller flytta) den andra filen och ersätt den befintliga filen.
• Behåll den befintliga filen utan att kopiera eller flytta den andra filen.
• Behåll eller kopiera den nyare filen (det översta scenariot).
• Behåll antingen den befintliga filen eller kopiera den andra filen, beroende på kriterier som filinnehåll och storlek.
• Behåll den befintliga filen och kopiera den andra filen med ett annat namn.
• Avbryt åtgärden om något är fel eller oväntat.

Användare kan uppnå scenario 1 genom att klicka på Ja och scenario 2 genom att klicka på Nej. De kan uppnå scenario 3 genom att jämföra fildatumen och klicka på lämplig knapp, men observera hur mycket tanke det tar att fastställa den nyare filen och sedan fastställa lämplig knapp, särskilt för vad som sannolikt är det vanligaste scenariot.

Scenarier 4, 5 och 6 är också förvånansvärt svåra. Filstorlekarna avrundas, så det är till exempel omöjligt att avgöra om dessa filer har samma storlek eller även om de är samma fil. Ikonerna är till för programmet som används för att öppna filen, så användarna måste öppna filerna för att inspektera och jämföra sitt innehåll. Det skulle vara mycket mer användbart att ha miniatyrbilder av filinnehållet för att besvara frågan.

Kopieringsfilens bekräftelse från Windows Vista gör ett mycket bättre jobb med att hantera dessa scenarier genom att ge mer information och lägga till alternativet för att behålla båda filerna:

Bekräftelse av Windows Vista-kopieringsfilen.

Ange specifik, användbar information

Om du ska ställa en fråga ska du se till att användarna förstår frågan och konsekvenserna av de alternativa svaren. Överväg den här säkerhetsbekräftelsen i Windows Internet Explorer:

En vag säkerhetsbekräftelse.

Den här bekräftelsen ställer en fråga som användarna inte kan svara intelligent på. Användaren har begärt att Windows Internet Explorer ska visa en sida, och det här meddelandet avråder implicit från den genom textens formulering och genom att markera Nej som standardval.

Det specifika säkerhetsproblemet som sidan utgör förklaras inte tillräckligt, så risken för att fortsätta är inte tydlig. Vilken information i bekräftelsen skulle göra att användaren någonsin klickar på Nej? På grund av meddelandets vaghet kommer bekräftelsen sannolikt inte att avskräcka användare från att fortsätta, men kommer att få dem att må dåligt över att göra det.

För att bekräftelsen ska vara användbar måste den innehålla mer information som kan få användaren att besluta att inte fortsätta. För varje svar i en bekräftelse bör du i allmänhet överväga de scenarier som kräver det och se till att det finns tillräckligt med information för att användarna ska kunna välja det. Ge val, inte dilemman.

Så här avgör du om en bekräftelse krävs

Att tänka igenom scenarierna och sannolikheten för att välja varje svar tyder på ett systematiskt sätt att avgöra om en bekräftelse är nödvändig. Om användarna sannolikt kommer att välja alla svar är bekräftelsen nödvändig och användbar. Men om endast ett svar är sannolikt (till exempel 98 procent av tiden) är bekräftelsen helt klart onödig och bör tas bort. Observera att bekräftelser som rör säkerhets-, juridiska och säkerhetsrelaterade problem är möjliga undantag.

Är den här bekräftelsen nödvändig? Kommer användarna någonsin att välja Nej? Det är möjligt men mycket osannolikt. Den här bekräftelsen bör tas bort.

Om du bara gör tre saker...

1. Kontrollera att din bekräftelse verkligen är nödvändig. Det bör finnas en legitim och tydlig anledning att inte fortsätta, och en chans att användarna ibland inte gör det.

2. Om orsaken till bekräftelsen inte är omedelbart uppenbar väljer du incheckningsknappar som uppmuntrar användarna att tänka på sitt svar. Detta görs vanligtvis genom att formulera bekräftelsen som en ja- eller nej-fråga och ge helt självförklarande eller Ja/Nej-svar.

3. Överväg alla scenarier och ange den information som krävs för att besvara frågan på ett intelligent sätt.

Användningsmönster

Bekräftelser har flera användningsmönster:

Användning	Exempel
Rutinbekräftelser bekräfta att användaren vill fortsätta med en rutinåtgärd med låg risk.	Dessa bekräftelser är vanligtvis frasade "är du säker...?" och har ofta en kryssruta som inte visar det här meddelandet igen för att minimera deras irritation. Exempel på rutinbekräftelser. Obs! Det här mönstret är vanligtvis onödigt och bör undvikas.
Riskfyllda åtgärdsbekräftelser bekräfta att användaren vill fortsätta med en åtgärd som har en viss risk och inte enkelt kan ångras.	Eftersom de har risk har dessa bekräftelser vanligtvis en varningsikon. Exempel på riskfyllda åtgärdsbekräftelser.
Bekräftelser av oavsiktliga konsekvenser bekräfta att användaren vill fortsätta med en åtgärd som har oväntade eller oavsiktliga konsekvenser.	Förutom att ställa en fråga pekar dessa bekräftelser på de oavsiktliga konsekvenserna. eftersom de har oavsiktliga konsekvenser har dessa bekräftelser vanligtvis en varningsikon. exempel på oavsiktliga konsekvensbekräftelser. Detta mönster kräver dock att konsekvenserna verkligen är oavsiktliga. fel: Konsekvenserna är avsedda här, så detta är en rutinmässig bekräftelse.
förtydliganden klargöra hur användaren vill fortsätta med en åtgärd som kan få tvetydiga eller oväntade konsekvenser.	Dra och släpp-åtgärder kan resultera i förtydliganden om åtgärdens effekt kan misstolkas. Exempel på förtydliganden. Obs! Det här mönstret bör undvikas eftersom det är bättre att utforma åtgärder utan tvetydiga konsekvenser och anta det mest sannolika önskade resultatet.
säkerhetsbekräftelser bekräfta att användaren vill fortsätta med en åtgärd med säkerhetskonsekvenser.	Exempel på säkerhetsbekräftelser.
Baktanksbekräftelser ange information om en åtgärd, men presentera den som en bekräftelse.	Dessa dialogrutor presenteras som bekräftelser, men deras verkliga mål är användarutbildning eller annonsering av funktioner. Ett exempel på en baktankesbekräftelse. Obs! Det här mönstret rekommenderas inte eftersom det vanligtvis finns ett bättre och mer direkt alternativ. Till exempel är animeringar ett bättre sätt att visa relationen mellan orsak och effekt.

Riktlinjer

Allmänt

• Använd "Spara ändringar"-bekräftelser endast när det finns betydande ändringar. Bekräfta inte ändringar som inte har gjorts direkt av användaren, till exempel automatisk omformatering av dokument.

felaktig:

Det här exemplet är felaktigt när det används för ett tomt e-postmeddelande eller dokument som inte har ändrats av användaren.

Ikoner

• Bekräftelser använder inte namnlistikoner.

• Innehållsområdesikonen för en bekräftelse baseras på dess designmönster:

  Mönster	Ikon
  Rutinbekräftelser	Ingen ikon.
  Bekräftelser av riskfyllda åtgärder	Varningsikon.
  Bekräftelser av oavsiktliga konsekvenser	Använd en varningsikon om det finns risk, funktionsikonen om den är tillgänglig. annars ingen ikon.
  Förtydliganden	Om bekräftelsen omfattar ett dokument använder du dokumentets miniatyrbild. Annars använder du funktionsikonen om den är tillgänglig eller ingen ikon.
  Säkerhetsbekräftelser	Varningsikon.
  Bekräftelser av baktankar	Ingen ikon.

• Använd inte varningsikoner för rutinfrågor. Att göra det strider mot den uppmuntrande tonen i Windows och gör att användning av ditt program känns som en farlig aktivitet. Anta att användarna förstår konsekvenserna av att avbryta en uppgift innan den är klar.

felaktig:

I det här exemplet används en varningsikon för att ställa en rutinfråga.

Incheckningsknappar

• Använd specifika svar på huvudinstruktionen om orsaken till bekräftelsen är uppenbar eller kan göras självförklarande.

I det här exemplet är orsaken till bekräftelsen uppenbar, så Spara och Spara fungerar inte bra.

• Annars använder du knapparna Ja och Nej för bekräftelsesvar. Detta gör att användarna ger bekräftelsen en tanke innan de svarar. Använd aldrig OK och Avbryt för bekräftelser.

rätt:

I det här exemplet tvingar användning av ja/nej-incheckningsknappar användarna att åtminstone läsa huvudinstruktionen.

felaktig:

I det här exemplet är det förvirrande att använda OK/Avbryt.

• Om du vill stänga ett program eller starta om Windows använder du specifika svar på huvudinstruktionen. Om du vill förhindra missförstånd ska du inte använda Stäng eller Ja/Nej för det här ändamålet.

rätt:

felaktig:

I det felaktiga exemplet används Ja för att starta om Windows.

Kommandolänkar

• För förtydligandemönstret bör du överväga att använda kommandolänkar för att göra alternativen tydliga.

acceptabelt:

Bättre:

I det bättre exemplet gör kommandolänkarna alternativen tydliga.

• Presentera de vanligaste kommandolänkarna först. Den resulterande ordningen bör ungefär följa sannolikheten för användning, men också ha ett logiskt flöde.
• Om en kommandolänk kräver ytterligare förklaring ge en kompletterande förklaring. kompletterande förklaringar beskriver varför användare kanske vill välja alternativet eller vad som händer om alternativet väljs.

Fler riktlinjer och exempel finns i Kommandolänkar.

Standardvärden

• Standardsvaret för en bekräftelse baseras på dess designmönster:

  Mönster	Standardsvar
  Rutinbekräftelser	Fortsätta.
  Bekräftelser av riskfyllda åtgärder	Fortsätt inte (eller det säkra valet).
  Bekräftelser av oavsiktliga konsekvenser	Om konsekvenserna är betydande ska du inte fortsätta. annars fortsätter du.
  Förtydliganden	Det mest sannolika svaret.
  Säkerhetsbekräftelser	Fortsätt inte.
  Bekräftelser av baktankar	Fortsätta.

Visa inte det här meddelandet igen

• Använd endast det här alternativet för de rutinmässiga och bakvända motivbekräftelsemönstren. Om informationen behövs för de andra mönstren bör den alltid visas.
• Ange inte det här alternativet för att motivera att du visar en onödig bekräftelse. Gör dig bara av med bekräftelsen istället.

felaktig:

Fortfarande felaktig:

I de här exemplen löser det inte en onödig bekräftelse när du lägger till alternativet Visa inte det här meddelandet igen.

Fler riktlinjer finns i dialogrutor.

Massåtgärder

• För bekräftelser som gäller för massåtgärder kan du ange ett alternativ för att tillämpa bekräftelsen på hela åtgärden.

Det här exemplet har ett alternativ för massåtgärder.

• Eliminera eller skjuta upp bekräftelser i en massåtgärd.

felaktig:

I det här exemplet bekräftar Utforskaren i Windows XP varje skrivskyddad fil under en massflytt. Bättre att bara kopiera skrivskyddade filer utan att fråga, eller skjuta upp hanteringen av dessa filer och presentera bekräftelsen i slutet av uppgiften.

Progressivt avslöjande

• Om du måste inkludera avancerad information i ett bekräftelsemeddelande kan du visa den med hjälp av progressiva upplysningsknappar (till exempel "Visa information"). Detta förenklar bekräftelsen för typisk användning. Dölj inte nödvändig information eftersom användarna kanske inte hittar den.
• Använd inte "Visa information" om det inte finns mer information. Upprepa inte bara den befintliga informationen i ett annat format.

Riktlinjer för etikettering finns i Progressive Disclosure.

Kontroll av användarkonto

• Använd inte användargränssnittet för UAC-utökade privilegier (User Account Control) som ersättning för en bekräftelse. Om en åtgärd behöver en bekräftelse använder du en separat dialogruta. Under utökade användargränssnittetmåste användarna fokusera på om de startade uppgiften och om programmet är tillförlitligt.
• Visa bekräftelsen före användargränssnittet för utökade privilegier. Detta eliminerar onödiga utökade privilegier.

SMS

Allmänt

• Ta bort redundant text. Leta efter redundant text i rubriker, huvudinstruktioner, kompletterande instruktioner, innehållsområden, kommandolänkar och incheckningsknappar. I allmänhet lämnar du fulltext i instruktioner och interaktiva kontroller och tar bort eventuell redundans från de andra platserna.
• Använd inte "varning" eller "varning" i texten. Om användarna behöver fortsätta med försiktighet anger du detta med hjälp av en varningsikon i stället.

felaktig:

I det här exemplet är termen "varning" onödig.

Titlar

• Använd rubriken för att identifiera kommandot eller funktionen där bekräftelsen kom ifrån. Undantag:
  • Om en bekräftelse visas med många olika kommandon bör du överväga att använda programnamnet i stället.
  • Om rubriken skulle vara redundant eller förvirrande med huvudinstruktionen använder du programnamnet i stället.

Men om bekräftelsen kommer från en tidskrävande uppgift och kan visas långt efter att aktiviteten har startat använder du alltid kommandot eller funktionen för att tydligt identifiera kontexten.

• Använd inte rubriken för att förklara vad du ska göra i dialogrutan det är syftet med huvudinstruktionen.
• Om det ger klarhet startar du rubriken med ordet Bekräfta.
• För riskfyllda åtgärdsbekräftelser kan du lägga till namnet på det objekt som ingår för extra betoning.

I det här exemplet ingår den enhet som ska formateras i rubriken.

• Använd versalisering i rubrikformat, utan att avsluta skiljetecken.

Huvudinstruktioner

• Huvudinstruktionen för en bekräftelse baseras på dess designmönster:

  Mönster	Huvudinstruktion
  Bekräftelser av oavsiktliga konsekvenser	ange den oavsiktliga konsekvensen. undantag: om en fråga som frågar om användaren vill fortsätta tydligt innebär den oavsiktliga konsekvensen, ställ i stället frågan. I det här exemplet förmedlar be användaren att fortsätta tillräckligt konsekvenserna av åtgärden.
  Alla andra	Ställ en enda fråga för att avgöra om användaren vill fortsätta.

• Var kortfattad använd bara en enda, fullständig mening. Ta bort huvudinstruktionen till den viktiga informationen. Om du måste förklara något mer, använd en kompletterande instruktion.

• Var specifik om det finns objekt som är inblandade, ge deras fullständiga namn.

• Använd positiv frasering. Positiv frasering är enklare för användarna att förstå.

rätt:

Vill du aktivera fil- och skrivardelning?

felaktig:

Vill du inaktivera fil- och skrivardelning?

Frasen måste dock matcha det associerade kommandot, även om kommandot är negativt formulerat. Använd till exempel inaktivera för att bekräfta ett Inaktivera-kommando.

• Det finns inga strikta regler för frasering, men dessa vanliga bekräftelsefraser har den angivna konnotationen:

  Fras	Konnotation
  Vill du [utföra en åtgärd]?	Bekräfta det direkta resultatet av en användarbegäran.
  Vill du [utföra en åtgärd]?	Bekräfta en bieffekt av en användarbegäran.
  Vill du [välja ett resultat]?	Behöver ett klargörande.
  [Utför en åtgärd]?	Ingen konnotation.

• För riskfyllda åtgärdsbekräftelser använder du termen permanent för att ange att en åtgärd inte kan ångras.

I det här exemplet anger "permanent" att åtgärden inte kan ångras.

• Använd versalisering i meningsformat.

Kompletterande instruktioner

• Den kompletterande instruktionen för en bekräftelse baseras på dess designmönster:

Etikett	Värde
Mönster	kompletterande instruktioner
Bekräftelser av oavsiktliga konsekvenser	Ställ en enda fråga för att avgöra om användaren vill fortsätta.
Alla andra	Förklara eventuella icke-uppenbara orsaker till varför användaren kanske inte vill fortsätta. Sådana orsaker är: Potentiell förlust av ett eller flera av följande: En värdefull tillgång, till exempel dataförlust eller ekonomisk förlust. Systemåtkomst eller integritet. Sekretess eller kontroll över konfidentiell information. Åtgärder som inte kan ångras.

• Upprepa inte huvudinstruktionen med lite olika formuleringar. Utelämna i stället den kompletterande instruktionen om det inte finns mer att lägga till.
• För oavsiktliga konsekvensbekräftelser bör du överväga att använda termen ändå för att kortfattat ange att det finns en anledning att inte fortsätta om användaren förbisett huvudinstruktionen. Mer information finns i Designbegrepp.
• Använd fullständiga meningar, versalisering i meningsformat och avslutande skiljetecken.

Dokumentation

När du refererar till bekräftelser:

• Se en bekräftelse med dess titel om rubriken är specifik för bekräftelsen (det vill: inte programnamnet); I annat fall hänvisar du till den med dess huvudinstruktion.
• Om det behövs kan du referera till en bekräftelsedialogruta som ett meddelande.
• Använd den exakta texten, inklusive dess versaler.
• Formatera texten med fet stil när det är möjligt. Annars placerar du texten endast inom citattecken om det behövs för att förhindra förvirring.

Exempel: I meddelandet Kopiera fil klickar du på den nyare filen.