Atomic Design | Designmetodik för utvecklare

Atomic Design är en designmetodik utvecklad av Brad Frost, och det är idag känt som ett av de mest essentiella koncept för UI design i webbprojekt. Även om metodiken har sin grund i UI-design så användare många utvecklare Atomic Design som en ryggrad när de utvecklar element, funktioner och hela applikationer. Nedan har jag listat en kort översikt av Atomic Design.

Atomer Atomer är den mest grundläggande bland alla komponenter och byggblock. Dessa block exemplifieras ofta som HTML-element som exempelvis textfält (inputs), knappar (buttons) och etiketter (labels). De inkluderar ofta även animationer och färgpaletter.

Molekyler Molekyler är komponenter som består av en grupp atomer. En molekyl kan exempelvis vara ett sökfält med en sökknapp. I detta exempel är sökfältet ett HTML input-fält (atom) och sökknappen är en HTML-knapp (även denna en atom). Tillsammans bildar de en molekyl i form av en sökkomponent.

Organismer Organismer skapar genom att slå samman flera molekyler. Ett vanligt exempel på en organism är en navigations-bar som består både av en meny och ett sökformulär.

Mallar Jag brukar tänka att mallar är prototyper, wireframes och layoutkomponenter. Mallar är väldigt konkreta och över tid börjar de mer och mer likna den färdiga produkten.

Sidor Som du kanske redan har listat ut så är sidor specifika instanser av mallar. Två sidor kan exempelvis använda samma mall, men visa olika typer av innehåll.

Jag tänker inte gå in närmare på detaljer kring Atomic Design och hur det fungerar. Istället vill jag lista de fördelar som jag ser med metodiken, och vad som får mig att använda det om och om igen.

Modularitet och struktur Genom att bryta ned större komponenter i mindre delar så kan vi underlätta både för projektets struktur men också för återanvändning av kod. Atomic Design minimerar mängden överflödig och repetitiv kod eftersom man kan återanvända en och samma grundkomponent i flera större komponenter - istället för att koda samma grundkomponent flera gånger om. Vi kan också skapa en layoutkomponent och därefter använda denna där vi vill implementera samma layout. På detta sätt gör vi inte enbart vår kod mer städad, och strukturerar, utan vi ökar även testbarheten av koden och applikationen som helhet.

Testning Att skriva enhetstester, komponenttester och lista ut vad som är fel har aldrig varit enklare. Enligt min erfarenhet så är modulär kod och Atomic Design en stor tidssparare när man ska lista ut vart i en komponent som ett fel sker. Atomic Design gör “gissningsarbetet” med att hitta roten till fel mycket mer precist. Detta beror allra främst på att metodiken har sin grund i UI-design, vilket underlättar den visuella felsökningen eftersom både den visuella representationen och koden är relativt lika vad gäller struktur. Vi kan helt enkelt snabbare hitta fel genom att enbart felsöka applikationen i webbläsare.

Ett exempel på detta skulle vara om navigationen ser trasig ut. Då vet vi att vi snabbt kan titta i koden för navigationskomponenten och iterera nedåt i strukturen till den atom som högst troligtvis orsakar felet. Om den atomen ser OK ut kan vi gå “upp” en nivå och ned till nästa atom som kan orsaka felet. Om ingen atom orsakar felet kan det istället bero på att komponenter krockar på molekyl- eller organismnivå.

Viktigt att notera här är att Atomic Design inte underlättar testning om utvecklaren inte skriver modulär kod.

Snabbare utveckling när grundstenarna är lagda När alla grundkomponenter (atomer och molekyler) är utvecklade så kan vi snabbt skapa prototyper och börja utveckla webbplatsen.

Om du inte har använt kod/designmetodik likt denna tidigare, så rekommenderar jag att du ger det ett försök. Vi ses i nästa bloggpost, ta hand om er!