Vad är en rocklåt i relation till en låt?
Jag har märkt att jag får en ganska tydlig reaktion när jag kommer in i ett system där människor har svårt att förklara vad saker faktiskt är. Inte när någon missar en detalj, utan när själva begreppen börjar flyta.
Säg att jag ska göra om ett system för musik och i navigationen hittar Låtar, Rocklåtar, Album och Artister. Då kommer jag ganska snart fråga vad en rocklåt är i relation till en låt. Det borde vara en enkel fråga, men om svaret börjar med att rocklåtar är lite annorlunda hos oss, att vanliga låtar också kan vara rock och att genre finns men inte riktigt betyder samma sak överallt, då vet jag att designarbetet kommer bli besvärligt.
★ •
┏━━━━━━━━┓
┌───Finns på─────┨ Abum ┠───Hör till──┐ ◍
│ ┗━━━━━━━━┛ │
┏━━━┷━━━┓ │
┃ Låt ┠───Gjord av──┐ ☆ ┏━━━┷━━━━┓
┗━━━┯━━━┛ │ ┌─────┨ Genre ┃
· └┬───────────Låter┼som────────┘ ┗━━━┯━━━━┛
│ ○ ┏━━━┷━━━━┓ │
│ ┃ Artist ┠──Spelar───────┬┘
│ ┗━━━━━━━━┛ │
Söker efter / lyssnar på / delar / sparar │
│ │
┏━━━┷━━━━━━━┓ │ ★
┃ Användare ┠───────Älskar / hatar────────┘
★ ┗━━━━━━━━━━━┛
×Inte för att alla behöver kunna beskriva systemets datamodell på rak arm, utan för att ett gränssnitt till slut måste representera något. Om vi inte riktigt vet vad saker är och hur de förhåller sig till varandra kommer den oklarheten förr eller senare dyka upp i navigationen, söket, filtreringen och alla specialfall vi behöver lägga till.
När gränssnittet börjar skvallra
I vårt musiksystem kanske låtar, artister och album är ganska tydliga. En låt har ett namn, är kopplad till en artist och kan ligga på ett album. Sedan finns genre, men när vi tittar närmare visar det sig att genre mest är ett textfält där det står Rock, rock, Rock music, Hard rock eller Metal/Rock.
Samtidigt ska användaren kunna hitta musik efter genre.
Då är frågan inte främst hur filtret ska se ut, utan om det finns en struktur som filtret kan bygga på. Om Rocklåtar bara betyder alla låtar som klassificerats som rock är det antagligen inte en egen sorts objekt, utan en vy av låtar. Samma sak gäller David Bowies låtar eller de hundra mest spelade rocklåtarna. Det är olika sätt att plocka fram samma grunddata.
Det är ofta här gränssnittet börjar avslöja hur systemet ser ut under ytan. Många specialfall i designen kan vara ett tecken på att samma specialfall redan finns i informationen eller i koden.
För att använda några begrepp någorlunda konsekvent i den här texten: nomenklatur är vad vi kallar saker, informationsmodellen beskriver vad som finns och hur det hänger ihop, taxonomin beskriver hur saker klassificeras och datamodellen är hur detta faktiskt har byggts i systemet. Ovanpå det bygger vi sedan informationsarkitektur och gränssnitt.
Så vill jag se datan
När jag får den här känslan vill jag ofta lämna gränssnittet en stund och förstå råvaran. Vilka objekt finns? Vilka egenskaper har de? Hur hänger de ihop? Vad används för sökning, filtrering och sortering?
Det är också därför vi ganska ofta arbetar i Airtable när vi tar oss an informationsrika produkter. Det är dyrt som satan för vad det ser ut att vara, men för oss kan det vara minst lika värdefullt som Figma. Vi använder det för att börja nysta i hur datan hänger samman, vilka relationer som finns och vilka vyer som uppenbarar säg genom att bara ställa rätt databas frågor. Frikopplat gränssnitt och eventuella undantag som kan konstrueras längre upp i stacken.
Om vi inte kan skapa en begriplig lista över rocklåtar utan att först reda ut fyra olika sätt att skriva rock har vi lärt oss något. Om samma artist förekommer flera gånger därför att namnet skrivits olika har vi lärt oss något annat. Framför allt tvingas vi förklara modellen för oss själva och för andra, och det är ofta först då som oklarheterna blir synliga.
Så enkelt som möjligt, men fortfarande begripligt
Det betyder inte att vi ska modellera verkligheten in i minsta detalj. Tvärtom behöver ett system vara en förenkling, ungefär som en karta. Kartan är användbar därför att den utelämnar nästan allt och behåller det som behövs för ett visst syfte.
Spotify kan till exempel kalla Guns N' Roses för en artist trots att Guns N' Roses är ett band. Man skulle kunna skapa separata modeller för band, personer, bandmedlemmar, sångare, gitarrister, producenter och låtskrivare, men om syftet bara är att användaren ska kunna söka på Guns N' Roses och hitta deras musik kanske det är helt onödigt.
Då kan det räcka att definiera artist som den person eller grupp under vars namn musik publiceras. Det viktiga är inte att modellen beskriver verkligheten perfekt, utan att den är tillräckligt enkel för att vara användbar och tillräckligt tydlig för att människor ska förstå vad begreppen betyder.
Om produkten senare behöver svara på vilka andra band en viss gitarrist har spelat i får modellen byggas ut. Det är inte ett misslyckande. Behovet har bara förändrats.
Samma sak gäller verksamheten runt systemet. Om varje ny produkt, regel eller kategori är ett undantag från allt som redan finns blir även den digitala produkten snart en samling undantag. Ett system kan bara vara så enkelt som det som systemet förväntas beskriva tillåter.
En målbild räcker långt
Det svåra är förstås när systemet redan finns och gamla beslut sitter i databaser, API, integrationer och kod. Då kan det vara både dyrt och riskfyllt att rätta till allt.
Vi är inte experter på att refaktorera sådana system, men vi tror mycket på att börja med en målbild: hur borde saker egentligen hänga ihop, vilka begrepp behöver vara tydliga och vilka förenklingar vill vi göra medvetet?
Den målbilden behöver inte beskriva systemet som det ser ut idag. Det är nästan själva poängen. När vi vet hur det borde fungera går det att börja röra sig åt det hållet steg för steg.
För mig är det här också UX. Gränssnittet är inte frikopplat från informationen det representerar. Om jag ska hjälpa en användare att hitta, förstå eller förändra något behöver jag först förstå vad det där något är.
När en enkel fråga om ett begrepp inte riktigt går att svara på slutar jag därför gärna rita en stund och börjar nysta. Inte för att jag vill göra någon annans jobb, utan för att mitt eget blir väldigt svårt att göra bra om jag inte förstår vad jag faktiskt designar.