Atomic Design är ingen navigation

Det är fortfarande en väldigt användbar tanke. Det jag däremot blivit allt mer tveksam till är när samma modell används som primär struktur i komponentbibliotek. Atoms, Molecules och Organisms ser logiskt ut på ytan, särskilt om teamet redan använder Atomic Design som tankemodell. Men min erfarenhet är att problemen börjar visa sig först när någon faktiskt ska hitta något.

Atoms
 └─▶ Knapp

Molecules
 └─▶ En knapp tillsammans med exempelvis felmeddelande

Organisms
 └─▶ Inputfält och knappar i samspel

Templates
 └─▶ Formulär som använder knappen

Pages
 └─▶ Ett specifikt formulär

Var ligger DatePicker?

Jag har sett komponentbibliotek där Atoms, Molecules och Organisms fått bli den huvudsakliga strukturen. Det är lätt att förstå hur man hamnar där. Om komponenterna redan beskrivs med Atomic Design känns det naturligt att också låta biblioteket följa samma ordning.

Men när man börjar använda strukturen uppstår snabbt frågor som inte alltid känns särskilt hjälpsamma. Är en DatePicker en molekyl eller en organism? Är en Modal en organism? Var hamnar SearchInput? Det går säkert att resonera sig fram till ett svar, och ett team kan absolut enas om regler för hur gränserna ska dras. Jag är bara inte säker på att svaret hjälper den som försöker hitta rätt komponent.

░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░
░░░░┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓░░░
░░░░┃                                     ┃▓░░
░░░░┃  Välj ett datum                     ┃▓░░
░░░░┃  ┌────────────────────────┐         ┃▓░░
░░░░┃  │ åå-mm-dd             ▼ │         ┃▓░░
░░░░┃  └────────────────────────┘         ┃▓░░
░░░░┃                                     ┃▓░░
░░░░┃  ╭──────────────╮                   ┃▓░░
░░░░┃  │   Okej då!   │                   ┃▓░░
░░░░┃  ╰──────────────╯                   ┃▓░░
░░░░┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛▓░░
░░░░░▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓░░
░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░
░░░░┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓░░░
░░░░┃                                     ┃▓░░
░░░░┃  Välj två datum                     ┃▓░░
░░░░┃                                     ┃▓░░
░░░░┃  Från            Till               ┃▓░░
░░░░┃  ┌─────────────┐ ┌─────────────┐    ┃▓░░
░░░░┃  │ åå-mm-dd  ▼ │ │ åå-mm-dd  ▼ │    ┃▓░░
░░░░┃  └─────────────┘ └─────────────┘    ┃▓░░
░░░░┃                                     ┃▓░░
░░░░┃  ╭──────────────╮                   ┃▓░░
░░░░┃  │   Okej då!   │                   ┃▓░░
░░░░┃  ╰──────────────╯                   ┃▓░░
░░░░┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛▓░░
░░░░░▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓░░
░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░

Den som går in i Storybook för att leta efter en DatePicker har sannolikt redan ett ganska konkret behov framför sig. Ett formulär behöver ett datumfält, en bokning behöver ett datumintervall eller en sökning ska kunna begränsas i tid. I det läget är frågan sällan vilken abstraktionsnivå komponenten befinner sig på. Frågan är snarare om det redan finns något i systemet som löser problemet. I det här fallet handlar det om komponenter som låter användaren ange datum eller tid.

Det leder vidare till en mer grundläggande fråga: hanterar vårt system över huvud taget inmatning av datum och tid? Om svaret är ja finns det sannolikt ett område i biblioteket där sådana lösningar hör ihop. Där kanske DatePicker samsas med TimePicker, datumintervall, validering och andra närliggande mönster. Om svaret är nej är DatePicker kanske den första komponenten som gör att ett sådant område över huvud taget behöver uppstå.

┌─────────────┐     ┌────────┐      ┌───────────┐
│ Date & time │──┬─▶│ Input  │──┬──▶│ Date      │
└─────────────┘  │  └────────┘  │   └───────────┘
                 │              │   ┌───────────┐
                 │              ├──▶│ Time      │
                 │              │   └───────────┘
                 │              │   ┌───────────┐
                 │              └──▶│ Date&Time │
                 │                  └───────────┘
                 │  ┌────────┐
                 └─▶│ Output │
                    └────────┘

Det är där jag själv börjat skilja på Atomic Design som modell för hur komponenter byggs upp och den struktur vi använder för att göra dem möjliga att hitta. De två behöver inte vara samma sak.

En komponent kan ha ett kanoniskt hem

Jag tror fortfarande att en komponent behöver ett tydligt hem. En Button kan till exempel ha sitt kanoniska hem under Buttons. Där finns dokumentationen om varianter, states, storlekar, beteenden och regler, och där går jag när jag vill förstå komponenten i sig.

Samtidigt behöver det inte betyda att Button bara förekommer där. Samma komponent kan visas i dokumentationen för ett formulär, i en CTA eller i en större produktkomponent som använder den. Jag tänker på det ungefär som en canonical URL: det finns en huvudversion, men det kan finnas många vägar dit.

Det viktiga blir då att relationen är tydlig. Om jag ser en knapp i ett formulär ska jag förstå att det är samma Button som finns dokumenterad under Buttons, inte en särskild FormButton som råkar se likadan ut. Annars har vi ganska snabbt återskapat ett av de problem som komponentbiblioteket var tänkt att hjälpa oss undan från.

Vi letar efter olika saker beroende på uppgiften

Säg att en designer får frågan från marknad om att ta fram en karusell med nya produkter till startsidan. Två ganska naturliga frågor är då: har vi några karuseller idag, och hur brukar vi visa ett mindre urval av produkter?

Den första frågan utgår från designmönstret. Designern vill kanske titta på befintliga Carousels och se hur de beter sig, vilka varianter som finns och om någon av dem går att återanvända. Den andra frågan utgår istället från innehållet. Hur brukar fyra, fem eller sex produkter presenteras i dagens design? Finns det redan en ProductCard? Hur ser den ut i olika sammanhang? Finns det ett befintligt sätt att hantera pris, bild, kampanjmärkning och CTA?

Men undersökningen kan också leda till en annan slutsats: vi använder inte karuseller för att lista innehåll idag. Att införa en sådan lösning innebär då inte bara att lägga till ännu en komponent, utan att introducera ett nytt designmönster i produkten.

Där får designern ett bättre underlag för att ta ställning till själva önskemålet. Karusellen kanske fortfarande är rätt lösning, men det kan också finnas goda skäl att föreslå något som bygger vidare på hur mindre urval av produkter redan presenteras. På så sätt blir komponentbiblioteket inte bara en plats där vi hittar saker som redan finns. Det hjälper oss också att se vilka mönster produkten faktiskt består av, och ger oss ett bättre underlag när vi ska avgöra om vi ska återanvända, förändra eller introducera något nytt.

Flera sätt att beskriva samma komponent

Det här får mig att tro att ett komponentbibliotek behöver kunna beskriva komponenter från mer än ett håll.

Ett perspektiv är vad komponenten är: Buttons, Carousels, Tables, Modals, Inputs.

Ett annat är vad den används till eller vilket innehåll den förmedlar: Products, Search, Checkout, Account.

Och sedan finns ytterligare ett perspektiv: vad komponenten består av.

En ProductCarousel kanske använder ProductCard. ProductCard kanske i sin tur använder Image, Price och Button. Här tycker jag att Atomic Design fortfarande är väldigt användbart. Modellen hjälper oss förstå relationerna mellan komponenterna och hur större delar byggs av mindre.

┌─────────────────┐      ┌───────────────────────┐
│ ProductCarousel │──┬──▶│ är en Carousel        │
└─────────────────┘  │   └───────────────────────┘
                     │   ┌───────────────────────┐
                     ├──▶│ listar Produkter      │
                     │   └───────────────────────┘
                     │   ┌───────────────────────┐      ┌────────┐
                     └──▶│ består av ProductCard │──┬──▶│ Image  │
                         └───────────────────────┘  │   └────────┘
                                                    │   ┌────────┐
                                                    ├──▶│ Price  │
                                                    │   └────────┘
                                                    │   ┌────────┐
                                                    └──▶│ Button │
                                                        └────────┘

Det är också här jag tycker att Atomic Design gör det den gör bäst. Den hjälper oss se hur samma byggstenar kan återkomma i flera sammanhang utan att vi behöver uppfinna en ny lösning varje gång.

Jag är bara mindre övertygad om att den relationen också ska vara den primära navigationen i Storybook.

Man har mindre nytta av att veta vad karusellen befinner sig enligt Atomic Designs klassificering och mer vad den används till.

Avslutningsvis

Kanske är problemet egentligen att vi ibland försöker få en enda taxonomi att göra för mycket. Vi vill att samma struktur ska förklara vad komponenten är, vad den används till och hur den är uppbyggd, trots att de frågorna uppstår i olika situationer och hos olika personer.

Jag tror därför inte särskilt mycket på en universell struktur för komponentbibliotek. Däremot tror jag på att en komponent kan ha ett kanoniskt hem och samtidigt vara möjlig att hitta från flera håll, beroende på vad den som tittar försöker göra.

En ganska bra fråga att ställa sig är därför: om någon i teamet får en konkret uppgift i morgon, vilka frågor kommer den personen att ställa för att ta reda på vad vi redan har?