# Skrev om applikationens felmeddelanden enligt en skriftlig tonstandard efter att en nekad inloggning hade skyllt på användaren för felskrivning när leverantören i själva verket krävde ett appspecifikt lösenord, och täckte det med ett test som namnger leverantören. september 2026 **Situation.** En inloggning mot en stor e‑postleverantör misslyckades, och applikationen sa till användaren att lösenordet var fel. Det var inte fel. Den leverantören kräver ett applikationsspecifikt lösenord för klienter från tredje part och avvisar kontots lösenord hur noggrant det än skrivs. Meddelandet skickade användaren till att skriva om något som aldrig kunde fungera, och den faktiska instruktionen — gå och skapa en annan sorts lösenord — fanns ingenstans. **Uppgift.** Felmeddelandena måste skrivas om mot en nedskriven standard i stället för att lappas ett i taget, eftersom det här var det synliga exemplet på en vana som löpte genom dem alla. **Handling.** Standarden har tre krav: säg vad som hände, antyd aldrig att användaren gjorde något fel när orsaken ligger någon annanstans, och ange nästa steg när det finns ett. Tillämpad på alla felmeddelanden bröt de flesta mot minst ett krav — flera var det underliggande bibliotekets felsträng som skickades vidare, vilket beskriver ett tillstånd för en programmerare snarare än en situation för en människa. Leverantörsfallet skrevs om så att det namnger leverantören, anger att den kräver ett appspecifikt lösenord för andra klienter och säger var man skapar ett. Testet är det som hindrar regression, och det är medvetet specifikt: det framkallar ett inloggningsfel mot den leverantören och kontrollerar att meddelandet innehåller leverantörens namn och den fras som beskriver vilken typ av inloggningsuppgift som krävs. Ett test som bara kontrollerade att något fel visades skulle godkänna det ursprungliga felaktiga meddelandet, så kontrollen gäller innehållet, som är den enda del som någonsin var trasig. **Resultat.** Felmeddelandena följer en uttalad standard och fallet som gav upphov till den täcks av ett test som fallerar på den gamla texten. Det som återstår olöst är skalan: standarden upprätthålls genom granskning och genom ett test på ett meddelande, och de andra leverantörerna med sina egna särskilda krav har inget motsvarande test, så felklassen är dokumenterad snarare än stängd. --- - Roll: Innehållsdesigner - Kategorier: [Frontendutveckling](https://software.engineer.company/sv/categories/frontend/), [Säkerhet](https://software.engineer.company/sv/categories/security/), [Test och kvalitetssäkring](https://software.engineer.company/sv/categories/testing/), [UX/UI‑design](https://software.engineer.company/sv/categories/ux-ui/), [Produkt och krav](https://software.engineer.company/sv/categories/product/), [Dokumentation](https://software.engineer.company/sv/categories/documentation/) - Tjänster: [UI/UX‑design och designsystem](https://software.engineer.company/sv/services/ui-ux-design/), [Produktstrategi och krav](https://software.engineer.company/sv/services/product-strategy/), [Teknisk dokumentation](https://software.engineer.company/sv/services/technical-documentation/)