# Skrev om applikasjonens feilmeldinger i tråd med en skriftlig tonestandard etter at en avvist innlogging ga brukeren skylden for en skrivefeil når leverandøren egentlig krevde et appspesifikt passord, og dekket det med en test som navngir leverandøren. september 2026 **Situasjon.** En innlogging hos en stor e‑postleverandør feilet, og appen fortalte brukeren at passordet var feil. Det var ikke feil. Den leverandøren krever et appspesifikt passord for tredjepartsklienter og avviser kontopassordet uansett hvor nøye det skrives inn. Meldingen sendte brukeren tilbake for å skrive inn på nytt noe som aldri kunne fungere, og den egentlige instruksen — gå og lag en annen type passord — sto ingen steder. **Oppgave.** Feilmeldingene måtte skrives om etter en skriftlig standard i stedet for å lappes én om gangen, siden denne var det synlige eksempelet på en vane som gikk igjen i alle sammen. **Handling.** Standarden har tre krav: si hva som skjedde, antyd aldri at brukeren har gjort noe galt når årsaken ligger et annet sted, og oppgi neste handling når det finnes en. Da standarden ble brukt på alle feilmeldingene, brøt de fleste minst ett av kravene — flere var feilstrengen fra det underliggende biblioteket sendt rett gjennom, og den beskriver en tilstand for en programmerer i stedet for en situasjon for et menneske. Tilfellet med leverandøren ble skrevet om til å nevne leverandøren, si at den krever et appspesifikt passord for andre klienter, og si hvor man lager et. Testen er det som hindrer at feilen kommer tilbake, og den er bevisst spesifikk: den fremkaller en mislykket innlogging mot den leverandøren og sjekker at meldingen inneholder leverandørens navn og frasen som beskriver hvilken type påloggingsinformasjon som kreves. En test som bare sjekket at en eller annen feil dukket opp, ville bestått med den opprinnelige, feilaktige meldingen, så sjekken gjelder innholdet, som er den eneste delen som noen gang var ødelagt. **Resultat.** Feilmeldingene følger en uttalt standard, og tilfellet som utløste den, er dekket av en test som feiler på den gamle teksten. Det som står uløst, er skala: standarden håndheves ved gjennomgang og med én test på én melding, og de andre leverandørene med sine egne særlige krav har ingen tilsvarende test, så feiltypen er dokumentert og ikke lukket. --- - Rolle: Innholdsdesigner - Kategorier: [Frontend‑utvikling](https://advisory.engineer.company/nb/categories/frontend/), [Sikkerhet](https://advisory.engineer.company/nb/categories/security/), [Testing og kvalitetssikring](https://advisory.engineer.company/nb/categories/testing/), [UX/UI‑design](https://advisory.engineer.company/nb/categories/ux-ui/), [Produkt og krav](https://advisory.engineer.company/nb/categories/product/), [Dokumentasjon](https://advisory.engineer.company/nb/categories/documentation/) - Tjenester: [UI/UX‑design og designsystemer](https://advisory.engineer.company/nb/services/ui-ux-design/), [Produktstrategi og krav](https://advisory.engineer.company/nb/services/product-strategy/), [Teknisk dokumentasjon](https://advisory.engineer.company/nb/services/technical-documentation/)