Design for helheten, ikke detaljene 25

Starter vi å designe små perfekte detaljer, uten blikk for helhet og innhold, kommer vi til å feile.

Brad Frost på Webdagene 2014
Brad Frost på Webdagene 2014

På Webdagene 2014 snakket Brad Frost om hvorfor «one size fits all»-rammeverk som Foundation og Bootstrap ikke funker særlig bra til å bygge unike nettsider, og hvordan vi kan bygge style guides på en smart måte. Det er vi enig med han i. Han er opptatt av å starte med små «atomer», i form av frittstående elementer (som for eksempel en label, et input-felt eller en knapp), for så å veve dem sammen i molekyler, organismer, maler og deretter nettsider. Vi er usikre på hvor godt akkurat dette funker i praksis.

«Responsiv design» misforstås

Frost har et veldig godt poeng som alle som jobber med web bør ta innover seg: vi må slutte å designe for forskjellige eksakte skjermstørrelser. Det er ikke dét som er responsiv design.

Idéen om at det skal funke på iPhone, opp til iPad og videre opp til iMac (alltid Apple-produkter…) er usmart, og en misforståelse av web som medium. For hva med dingsene som kommer i fremtiden? Og hva med alle de som ikke bruker Apple-produkter? Det ligger i nettets natur at alt flyter. Derfor må vi behandle det som det det er: flytende, ikke statisk.

«Atomic design»

Som alternativ foreslår Brad Frost sin tilnærming til å bygge nettsider, som er konseptet «atomic design.» Brad definerer det slik:

«Atomic design is methodology for creating design systems. There are five distinct levels in atomic design:»

  1. Atoms
  2. Molecules
  3. Organisms
  4. Templates
  5. Pages

Tanken er at man starter med å bygge små «atomer», i form av frittstående elementer (som for eksempel en label, et input-felt eller en knapp), for så å veve dem sammen i molekyler, organismer, maler og deretter nettsider.

Men er det egentlig så lurt å jobbe i den rekkefølgen?

Det blir farlig om vi som designere skal isolere oss og jobbe med små, perfekte atomer og molekyler uten å tenke på hvordan disse skal fungere i samspill med innholdet. Og det blir enda farligere når vi starter med detaljene og tror helheten kan dannes derifra.

Derfor kan vi ikke starte med å lage reglene, de må oppstå av det vi prøver å formidle. Når det kommer til stykket er ikke maler, styleguides og alt det der mer enn et middel for at det som formidles skal få gode forutsetninger. Det bør ikke ligge i sentrum. Man bør ikke starte med det, man bør avslutte med det.

«Stamcelledesign»

Idéen om «Atomic design» er besnærende som metafor på designsystemer. Men hva om vi heller snur dette på hodet: Er det ikke smartere å tenke på helheten som utgangspunkt, for så arbeide frem detaljer ut fra den, basert på innhold og overordnet design? Da kan «stamcelledesign» være en bedre metafor på hvordan vi bør jobbe smart.

Vi er altså ikke sikre på om Frosts tilnærming funker så bra i praksis. Selv om detaljene (atomene) er viktige, så er ikke det stedet man bør starte. Detaljer skal dannes ut i fra en helhet – og de skal tilpasse seg helheten. Metaforisk sett ville det kanskje vært riktigere å se på atomene (detaljene) som stamceller, som skal formes av cellene rundt. Starter vi med noen prinsipper, en merkevare og et konsept kan vi heller la atomene tilpasse seg ut ifra det.

Mo’ content, mo’ problems (to solve)

Gode designere reiser problemstillinger og prøver å løse dem. For å ha problemer å løse må vi skape dem. De oppstår ikke i en styleguide. Ei heller i en sidemal med Lorum Ipsum-tekst, som Frost viste eksempler på. De oppstår når ekte innhold møter design i en helhet.

Jørgen Blindheim

Flere artikler av Jørgen CV

Øyvind Storli Hoel

Innholdsrådgiver og følsom detaljfanatiker som elsker tekst, tone og kode.

Flere artikler av Øyvind CV

25 kommentarer

  1. Jeg ble litt trist når jeg leste dette jeg. Her synes jeg vi bommer, eller kanskje vi velger å misforstå?

    Jeg har hørt flere varianter av presentasjonen til Brad Frost om Atomic design, og kan ikke forstå at han argumenterer for å designe slik dere påstår han gjør. Jeg tror Atomic design og pattern-lab.io er laget for å løse utfordringene med den «tradisjonelle» arbeidsflyten i webprosjekter.

    1. Interaksjonsdesigner jobber med grå bokser på papir (til nøds digitalt).
    2. Designer tar over stafettpinnen og gjør alt fint og flott (i Photoshop).
    3. Til slutt sendes alt til utviklerne (frontend + backend), med en PDF full av piler, streker og kommentarer som angir hvordan designet må løses.
    4. Resultatet skal være pikselperfekt.

    Ingen av eksemplene jeg har sett i presentasjonene til Brad Frost gir meg inntrykk av at hele designet er bygget opp fra atomer til sidemal. Så hvorfor velger dere å tolke det slik?

    Brad Frost jobber stort sett i team som absolutt tenker på helheten. Det han vet, som vi også vet, er at designavgjørelser bør tas i nettleseren. Da skader det ikke at han begynner å bygge enkelte atomer, molekyler og organismer, parallelt med designarbeidet i prosjektet. Senere bygges designsystemet ut, basert på de designvalgene som blir tatt.

    «Atomic design is methodology for creating design systems.» Jeg kan ikke forstå at helheten uteblir om denne metodikken benyttes.

    I foredragene Brad Frost holder, er fokus på HTML. God strukturert markup. CSS oppfordrer han folk til å kode selv.

    Et skjema kommer til å bygges opp med ‘label’ + ‘input/select/textarea’. De atomene, molekylene og organismene kan bygges tidlig. En rekke andre byggeklosser kan også settes sammen før designet er klart. Dette løses også av rammeverk som Bootstrap og Foundation, men der følger det ofte med flere moduler med “ferdig” CSS og JS enn de fleste prosjekter trenger.

    Hvis vi skal utfordre Atomic design og pattern-lab, synes jeg vi skal ta utgangspunkt i noe annet enn en misforståelse. Se heller på enklere måter å få inn reelt innhold i pattern-lab enn å mate det inn via JSON.

    Også er kanskje ikke en norsk bloggpost det beste utgangpunktet om Brad Frost selv skal delta i diskusjonen :)

  2. Den «tradisjonelle» arbeidsflyten i webprosjekter tror jeg vi alle er enige om at har mange svake punkter. Selv har jeg kun hørt foredrag med Brad Frost på Webdagene, så det blir vanskelig for meg å nyansere det han snakket om der med ting han har sagt andre steder.

    Der jeg er veldig enig med kritikken Jørgen og Øyvind fremlegger, er i at dokumentasjonen av designarbeidet i en styleguide er feil ende å begynne i. Designsystemer? Ja, takk! Styleguide? Gjerne! Men, å sitte lenge med små atomer og skisser som er fulle av «Lorem ipsum» er farlig.

    For meg er det helt avgjørende for en god designprosess at man klarer å veksle hyppig mellom å jobbe med helhet og detaljer. Slik jeg tolket foredraget på Webdagene er jeg enig med Jørgen og Øyvind i at det ble lite helhet og mye detaljer.

  3. Hvor i presentasjonen fra Webdagene anbefaler Brad Frost å starte med dokumentasjon av en styleguide, eller å skisse ut molekyler og organismer fulle av «Lorem Ipsum»?

    Jeg tror kanskje vi har funnet kjernen av misforståelsen eller uenigheten. Min påstand er at Atomic design ikke er en komplett løsning for alle som skal bidra inn i responsive designprosjekt, men et godt grep for å løse noe av designarbeidet i kode. Modellen/systemet er ikke ment å løse helheten, slik jeg vurderer det, og jeg tolker heller ikke foredraget slik.

  4. Ideen bak Atomic Design er ikke nødvendigvis å begynne med atomene, men å bryte ned elementene som inngår i designet til atomer, molekyler, osv.

    Når man vet hvilke moduler og inneholdstyper inngår i designet, står man fritt til å designe disse hver for seg og sammen med de andre elementene. Det må selvfølgelig være en rød tråd mellom elementer i et design. En styleguide kan samle elementene og vise hvordan de opptrer sammen.

    Konseptet med sidemaler er kanskje på vei ut, siden det egentlig bare er snakk om en viss layout og skall rundt elementene på en side, som er avhengig av arealet man har til rådighet til enhver tid.

    Tenk på elementene som eiendelene til en familie. Uansett hvor familien flytter, har de med seg eiendelene, og hvordan de fordeler og plasserer seg i boligen kommer an på hvor mye plass det er og på planløsningen.

    Heldigvis er det uendelig plass på en nettside totalt sett!

  5. Sorry, men her bommer dere skikkelig…
    Regner med dere ikke var med på workshopen :)
    Dette er ingen trinnvis modell, snarere tvert i mot. Filosofien er å lage noe i browseren så snart som mulig, gjerne wireframe-aktig, for så å kunne danne seg et inntrykk av helheten. Reelt innhold er vel og bra, men man bør uansett designe for “det man ikke vet” og ikke nødvendigvis et spesifikt innhold. Kongstanken er gjenbruk av elementer (eller molekyler om du vil), for å lage et konsistent grensesnitt. Og man kan begynne akkurat hvor man ønsker, eller berre, switche mellom helhet og detaljer.

  6. Uff da, nå ble jeg også litt trist. Hele poenget til Brad Frost er jo å tenke på helheten fra start gjennom å bygge opp et konsistent system basert på moduler. Det han gjør er altså å bruke teknologien på sitt beste gjennom å sette opp en fullt fungererende wireframe fra start som man så kan teste ut reelt innhold og design på gjennom å prøve variasjoner av design på de ulike atomene og molekylene. Slik ser du hvordan sidene endrer sitt utrykk og hvordan helheten skalerer i ulike størrelser med en gang, i motsetning til rett før lansering slik det er i “tradisjonell webutvikling”.

    Det geniale med atomisk design er jo nettopp dette han forsøkte å forklare at når du endrer utseendet på én knapp som har en gitt funksjonalitet, trenger du kun å endre den på ett sted og så blir det endret på alle sider der denne knappen har blitt plassert. Et lite nettsted på noen få sider vil kanskje ikke ha opplevd dette som veldig kompliserende, men når man begynner å dra på litt med x antall produktsider, samleproduktsider og ulike andre mellomsider vil denne måten å bygge nettsider på virkelig skape enorme fordeler – både for utviklerne som forvalter løsningen, og for designerne som forsøker å opprettholde et helhetlig utrykk. For ikke å snakke om hvilke økonomiske fordeler det vil gi for den som eier og betaler for nettstedets videre liv i universet.

  7. Ser nå at vi antagelig burde formulert oss mer ydmykt om Brad Frost :) Jeg er enig med han i enormt mye bare så det er sagt. Liker Atomic design metaforen og hvordan han tenker rundt struktur av design komponenter. Elsker det han sier om responsivt design og om å jobbe ut design i kode.

    Det jeg derimot ikke er så enig i er hvordan han mener vi skal jobbe så isolert med komponenter i designet. Uten reelt innhold.

    Det handler egentlig om forskjellige veier til et mål. Vi ender jo alltid opp med et sett med robuste designkomponenter når vi lager en webside. Men jeg mener kompenentene må komme frem av hva man prøver å formidle. Slik det fremstår i hans foredrag, så fremmer han veldig en metode som går ut på å jobbe isolert med elementer for så å sy det sammen til en helhet. Det jeg ønsket å få frem var at man bør starte annerledes, og la komponentene komme når man ser nødvendigheten av dem.

    Arrester meg gjerne (enda mer) om jeg har oppfattet han feil :)

  8. Minner meg litt om form versus innhold debatten i reklamebransjen på 80-tallet.

  9. Jeg kan se for meg at å starte med atomene kan fungere bra når designprosessen er en A til B prosess der man lager alt fra scratch, men i et kontinuerlig prosjekt kan det nok være en fordel å lage atomer som passer. Jeg har flere ganger bestilt et “atom” fra en designer og glemt å referere til helheten. Det var litt som å prøve å få Lego til å passe med Duplo, så ting måtte smeltes om litt ;-)

    Videre kjøper jeg ikke frarådingen av bootstrap og lignende rammeverk, med mindre man ikke har lært seg LESS og f.eks. Grunt eller Gulp eller rammeverket ikke er tilgjengelig med variabler som kan tilpasses. Det er også veldig enkelt å håndplukke de komponentene man trenger fra CSS og JS biten av slike rammeverk til sin build.

    Ang. responsivt design er jeg både enig og uenig. Jeg gjorde genistreken å bomme med noen pixler på en media query breakpoint for iPad. Det fungerte helt sikkert ypperlig for alle pads som er littegrann større, men man må passe på at man er innafor de mest populære enhetene, samtidig som det skal skal fungere for de aller fleste kommende enheter uten å måtte tilpasse ytterligere.

    Det skal forsåvidt sies at jeg ikke kjenner Atomic Design filosofien i dybden, men førsteinntrykket mitt er at det handler mye om DRY koding og god oppdeling for å ende opp med et helhetlig produkt som er lett å maintaine. Hvilken rekkefølge man starter i er kanskje ikke en regel som på død og liv skal følges, men absolutt interessant for diskusjon hva som er best :)

  10. Synes jo det er pussig at dere faktisk har missforstått en del av grunnkonseptet bak Atomic design, men samtidig er såpass arrogante at dere lirer av dere slike kommentarer… “Minner meg litt om form versus innhold debatten i reklamebransjen på 80-tallet.”…

  11. Fredrik: Hvem “dere” er det du sikter til?

  12. Fredrik Jensen, Trond Blindheim var ikke artikkelforfatter.

  13. Sorry!! Han med kommentaren hadde samme etternavn som den ene artikkelforfatteren… Å sammeligne dette med “form versus innhold” er fullstendig missfortstått… Konseptet med PatternLab er jo snarere motsatt, kort vei til reelt innhold – i browseren… Produktet er ikke perfekt, og detkan gjøres bedre! Bl.a. kreves det vel mye kodekunnskap. Men konseptet er kult, og kult å lansere det som open source :)

  14. […] Det jeg derimot ikke er så enig i er hvordan han mener vi skal jobbe så isolert med komponenter i designet. Uten reelt innhold. […]
    – Jørgen

    Jeg forstår ikke hvor det kommer frem at vi blir oppfordret til å jobbe slik. Hvor har dere det fra?

  15. Jeg tror kanskje dere skal se foredraget en gang til jeg, gutter. Dere har nok gått dere litt vill i den metaforiske beskrivelsen av hvordan nettsider er bygget av atomer og molekyler, for hele grunnpoenget til Brad er jo nettopp å designe for helheten ved å forstå hvordan det alt er bygget opp.
    Han sier ikke at man skal pusse og flikke på atomer for så å sette det sammen – han sier nettopp det motsatte, at man skal kaste opp en rimelig strippet løsning bestående av ferdig kodede elementer uten design, for så å legge inn innhold, bilder og design direkte i løsningen. Slik ser man hvordan de ulike komponentene samspiller, skalerer og hvordan helheten fungerer – samtidig som man får full kontroll over endringer som gjøres på design både i prosessen og etter at produktet er lansert.

  16. Og vi sier at vi tror det er smartere å starte med innholdet og bygge/designe disse komponentene basert på innholdet.

  17. Slik jeg har forstått eksemplene fra Brad, pågår det arbeid ved siden av etableringen av prototypen. Dette arbeidet vil jeg tro tar utgangspunkt i innholdet? Det er ikke slik at prosjektet starter og slutter med Atomic design og Patter Lab. Poenget er ikke nødvendigvis å designe i nettleseren, men å ta beslutninger der.

  18. Jeg var ikke på workshop, men reagerte litt på det samme som Jørgen og Øyvind da jeg hørte foredraget (som var veldig bra). Dette blir forsterket av den prosessen som Brad Frost skisserer her: http://bradfrostweb.com/blog/post/atomic-web-design/
    Kan godt være at han ikke egentlig mener at prosessen er så lineær som den fremstår her, men ting som:
    “Things start getting more interesting and tangible when we start combining atoms together. ”
    og “Pages are specific instances of templates. Here, placeholder content is replaced with real representative content to give an accurate depiction of what a user will ultimately see.” og “We’re starting to get increasingly concrete. A client might not be terribly interested in the molecules of a design system, but with organisms we can see the final interface beginning to take shape. ”
    fremstår som en litt merkelig måte å gjøre ting på: må man ikke vite hvor de ulike atomene skal opptre, hvilke andre elementer de skal samspille med osv., hvilket reellt innhold som skal inn – før atomene designes? Er ikke enhver fornuftig designprosess en veksling mellom helheten og delene i en herlig hermeneutisk prosess? Samtidig er jeg helt enig i det aller meste Brad Frost sier og tar høyde for at en metode er i konstant utvikling og kanskje den ser annerledes ut nå enn da han blogget om den i 2013. Innser også at bloggen vår burde vært på engelsk slik at Brad kunne svart selv :)

  19. Jeg var nå faktisk på workshopen :)

    Jostein: Ditt neste spørsmål svarer egentlig på det første: “Er ikke enhver fornuftig designprosess en veksling mellom helheten og delene i en herlig hermeneutisk prosess?”
    Ja, og også en vekseling mellom design, innhold og strategi. Man må ikke ha fullt ferdig reelt innhold i det desginprosesen starter, det mener jeg kan være direkte skadelig for en god, kreativ og skapende desginprosess. Design og innhold spiller hverandre gode i løpet av designprosessen (Noe PatternLab er et meget godt verktøy for) og designtekning bør være like viktig som innhodsstrategi.

    Men det er en fordel å vite innholdstypen. Å designe for det “ukjente” er noe Brad predikerer. Det er er en hatbølge mot “Lorem ipsum”, men er det egentlig alltid feil? Om man f.eks. skal embedde en nyhet, man faktisk vite hva den nyheten er helt bokstavelig. Trolig ikke. Må du vite type innhold, media-type, prioritering osv. Ja.

  20. Ang. vekslingen så er vi nok kjedelig enige. Poenget var at slik Brad Frost fremstiller prosessen på foredrag og i bloggposten er den en strek, ikke en sirkel. Det fremstår som om du starter med atomene og går videre derfra. Som tidligere nevnt: Det kan godt være at workshopen etc. sier noe annet og det er i tilfelle bra. Ang. Lorem ipsum så kan det godt være det finnes noen få unntak, men de er jammen ikke mange. Skal du designe den trettende nyhetsboksen og vet hvor store de skal være, hvilke elementer de skal inneholde osv. så kan man til nøds bruke Lorem Ipsum. Men, i de aller fleste tilfellene så funker det hverken designfaglig eller i kommunikasjonen overfor kunden å snakke latin.

  21. Dere er nok egentlig kjedelig enige med Brad Frost også :)

    Han snakker også mye om itterative prosesser og kundeinvolvering, og hvordan han jobbet tett med innhold bl.a. i forb. med TechCrunch designet. Den lineære visualiseingen er nok kun ment som bilde på hvordan et gresensnitt er bygget opp (altså ikke hvordan man skal jobbe).
    Lorem ipsum, eller ikke. Reelt innhold er vel og bra, men vel så viktig er det å designe for det ukjente – innholdet vil alltid endre seg over tid. Personlig tror jeg modulære, fleksible systemer med tilhørende pattern libary er et godt utgangspunkt. Med det vet jeg dere verdsetter også :)

  22. Jeg forstår kritikken av manglende helhetstenking i Atomisk design, og i starten var jeg også bekymret for akkurat dette. Nå er det litt anderledes

    Jeg var på webdagene og har sett flere andre foredrag til Brad Frost. Jeg var også på workshoppen hans, hvor jeg spurte han selv om akkurat dette. “Hvordan holder du oversikten og tenker på helheten i atomisk design? Og hvordan unngår du for tidlig detaljfokus?”

    Han sa da, og har sagt flere ganger før, at selv om oppbyggingen fremstår som stegvis, så skjer i praksis alt (atomer, molekyler, organismer osv) samtidig. Og det vil ofte være en konseptfase først. Slik at i praksis er det ikke sånn at vi setter oss ned og lager alle atomene først, så molekylene, så organismene osv.
    Det var nemlig min oppfatning i starten, og jeg synes ikke Brad Frost har kommunisert godt nok at dette foregår samtidig og hvordan vi fokuserer på helheten midt i alle atomene og molekylene.

    Satt inn i en større kontekst, og etter å ha snakket med Brad Frost selv, har jeg forstått at det henger sammen med resten av en typisk prosess på denne måten:

    1. Innsikt og analyse
    2. Konsept
    3. Prototyping og evaluering med atomisk design

    Slik jeg ser det har han egentlig bare systematisert oppbyggingen og tankene vi sjonglerer med hver dag, slik at vi ikke skal glemme noe, og slik at vi lager konsistente brukeropplevelser som er robuste.

    Det jeg derimot synes mangler litt i atomisk design er fokuset på å designe med reelt innhold. Og akkurat her hadde det vært interessant å høre hva Brad Frost selv mener. Og hvordan får man inn reelt innhold i prototypen, samtidig som den lages.

    Martin nevnte at det burde finnes noe bedre enn JSON, og der er jeg helt enig!
    Før sommeren eksperimenterte vi litt med markdown, slik at innholdsekspertene kunne legge inn innhold (og se effekten av det), samtidig som html-prototypen ble laget. Det fungerte ikke helt som ønsket (vanskelig å få teksten plassert på riktig sted), og vi endte opp med å skrive i Google Docs og copy-paste inn i HTML.
    Har noen av dere funnet en god måte å håndtere dette på?

    Mine ustrukturerte og litt rotete notater fra Brad Frost sin workshop: https://www.evernote.com/shard/s232/sh/0f4a11c9-7338-404e-bfe7-c49bd76022bc/0c4188d2b2b24c686ad7309d41be1368

  23. Anders: Noe vi har relativt god erfaring med er å implementere et CMS direkte i deler av prototypen i en så tidlig fase som mulig. For så å la innholdsfolk og kunde jobbe med innhold direkte her, gjerne med så hyppige møter og dialog som mulig. Krever litt fra begge parter, men gjør ofte at man støter på de rette utfordringene i en tidlig fase.

  24. Skjerpings Fredrik Jensen! Min kommentar var til debatten, ikke til selve artikkelen eller Brad Frost-foredraget som jeg ikke har hørt. :-)

  25. Har allerede beklaget kommentaren, og beklager gjerne igjen. Mistolket i en opphetet debatt både avsender og at kommentaren var en “meta”-kommentar. Anbefaler dog både foredraget og bloggen til Brad Frost http://bradfrost.com/blog/

Skriv en kommentar

  • *

XHTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>