Design-QA – kontrollera bygget mot designen
Av CodexierPublicerad 5 min läsning
Mellan en godkänd design och en släppt produkt uppstår alltid avvikelser: avstånd som är lite fel, ett hovertillstånd som ingen byggde, ett felmeddelande som förstör layouten på en liten telefon. Inget av det är dramatiskt var för sig, men tillsammans gör det att produkten känns ofärdig. Design-QA är granskningssteget som fångar det före release. Här får du en rutin som fungerar i alla projekt, med eller utan designer i teamet.
När design-QA ska göras
Design-QA fungerar bäst som ett litet, återkommande steg snarare än en stor granskning i slutet. När en funktion når testmiljön kontrollerar designern eller en tränad granskare den innan den godkänns. Då är avvikelserna billiga att rätta, eftersom utvecklaren har koden färsk. En enda granskning veckan före lansering hittar samma fel, men alla på en gång och när det inte finns tid att rätta dem ordentligt.
Jämför bygge och design
Öppna designen och bygget bredvid varandra i samma bredd. Mät inte varje pixel; leta efter skillnader som en användare skulle märka. Designsystemet är facit för allt som designfilen inte anger: skiljer sig en knapp i bygget från knappkomponenten är det en avvikelse även om skissen inte säger något.
- Avstånd och linjering: jämna mellanrum, kanter som linjerar
- Typografi: storlekar, vikter, radlängder, inga ensamma ord i rubriker
- Färger: tokens används, inte hårdkodade nästan-lika nyanser
- Komponenter: rätt variant av knapp, fält och kort
- Innehåll: riktiga texter och bilder, inte platshållare
- Ikoner och bilder: skarpa, rätt storlek, med alt-text där det behövs
Responsiva kontroller och enheter
Designer ritas oftast i två eller tre bredder; användarna kommer i alla bredder däremellan. Dra webbläsaren från minsta till största storlek och se var brytpunkterna gör att saker radbryts illa. Testa sedan på riktiga enheter: minst en liten Androidtelefon, en iPhone och en surfplatta. Emulering i webbläsaren missar tangentbordets beteende, säkra ytor och verkliga tryckytor.
| Kontroll | Det här letar du efter |
|---|---|
| Smal telefon | Text som flödar över, knappar som staplas, vågrät rullning |
| Stor telefon och surfplatta | Klumpiga mellanlägen, utdragna bilder |
| Bred datorskärm | För långa rader, innehåll som svävar i tomrum |
| Tangentbord på skärmen | Fält som döljs bakom tangentbordet, fasta fält som täcker |
| Zoom till 200 procent | Inget kapat, ingen överlappande text |
Tillstånd och specialfall
De flesta avvikelser gömmer sig i tillstånd som skissen aldrig visade. En design visar den lyckliga vägen med perfekt data; bygget måste klara tomma listor, långa namn, långsamt nät och fel. Gå igenom varje vy och tvinga fram tillstånden: töm datan, klistra in ett mycket långt företagsnamn, stäng av nätet, skicka ett ogiltigt formulär.
Interaktionstillstånd
Hover, fokus, aktiv, inaktiverad och laddar för varje klickbart element. Fokus måste synas för tangentbordsanvändare.
Innehållstillstånd
Tomt, ett objekt, många objekt, mycket lång text, saknad bild.
Systemtillstånd
Laddar, fel, offline, klart. Varje tillstånd behöver ett meddelande som en människa förstår.
Tillgänglighet hör hemma i samma genomgång: kontrast, fokusordning, etiketter på formulärfält och felmeddelanden som säger vad som gick fel och hur det rättas. Vår guide om design för WCAG 2.2 listar de kriterier som oftast fallerar.
Logga och prioritera avvikelser
En avvikelse från design-QA behöver tre saker: en skärmbild av bygget, förväntat resultat (en länk till designramen eller komponenten) och en allvarlighetsgrad. Lägg avvikelserna i samma verktyg som buggarna, så att de prioriteras tillsammans, inte i ett separat dokument som ingen öppnar.
- Blockerande: användaren kan inte slutföra en uppgift, eller ett tillgänglighetsfel
- Allvarlig: tydligt fel och synligt på en viktig sida
- Mindre: märks för ett vant öga men påverkar inte användningen
- Finputs: samla dessa och åtgärda dem i en planerad städning
Återkommande avvikelser pekar på en grundorsak. Dyker samma avstånds- eller knappfel upp på varje sida sitter lösningen i komponentbiblioteket, inte på varje sida. Det är argumentet för ett designsystem och UI-kit: det gör det rätta till standard. När du inte behöver det: en liten marknadssajt byggd av en person motiverar sällan ett fullständigt designsystem – en kort stilguide och en checklista som denna räcker. Läs om ditt företag behöver ett designsystem innan du investerar.
Nästa steg
Ta med checklistan till nästa release och kör den på en funktion. Räkna avvikelserna och notera vilka som återkommer. Pekar de återkommande på saknade komponenter eller en otydlig överlämning kan ett kort samtal visa om lösningen är en rutin, ett designsystem eller en bättre överlämning från Figma.
Vanliga frågor
Vem ska göra design-QA?
Helst designern som gjorde designen, eftersom hen känner avsikten. Utan designer kan en utvecklare eller produktägare köra checklistan med designsystemet som facit.
Är design-QA samma sak som testning?
Nej. Funktionstester kontrollerar att saker fungerar; design-QA kontrollerar att de ser ut och beter sig som designat, i alla tillstånd och storlekar. De överlappar i tillgänglighet och felhantering.
Hur lång tid tar design-QA?
För en enskild funktion oftast klart under en timme när det görs löpande. En stor granskning i slutet tar betydligt längre och hittar felen för sent för att de ska rättas ordentligt.
Behövs särskilda verktyg?
Egentligen inte. Designfilen, testmiljön, några riktiga enheter och buggverktyget räcker. Webbläsartillägg som lägger designen ovanpå bygget kan hjälpa men är inte nödvändiga.
Glider bygget ifrån designen hela tiden?
Femton minuter: visa en nyligen släppt version, så säger vi om lösningen är en rutin, ett komponentbibliotek eller en bättre överlämning.
Boka ett kostnadsfritt 15-minuterssamtal