Velkommen tilbake til neste installasjon av Development for Designers! Hvis du har gått glipp av den siste artikkelen, vennligst gi den en lesning. I denne artikkelen vil jeg diskutere en tankegang som muligens broer gapet mellom utvikling og design.
Fangstfrasen, søkeordet eller konseptet som du trenger for å bli seriøst kjent med, er "Atomic Design". Atomisk design ble laget som:
"... en metode for å skape design systemer." - Brad Frost
For meg var dette et gjennombrudd. Som utvikler vet jeg at logikken er bygget opp fra de minste begreper; variabler, arrayer, funksjoner, klasser. Som designer gjelder det samme. Jeg kan bygge noe komplisert fra å velge komplementære farger, fonter, positiv eller negativ plass og form. Faktisk er det en stor metafor for vår egen menneskelige eksistens.
Den vil vær en bokI hovedsak virker Atomic Design som følger: Atomer danner molekyler, molekyler danner organismer. Organismer kan være komplekse eller enkle. En bakterier eller et menneske som sitter bak denne datamaskinen skriver om selve konseptet. Vi er alle eksempler på Atomic Design.
Denne metodikken karakteriseres perfekt for webopplevelser, IoT (Internet of Things) eller mobilutvikling, da det gir en arkitektur som størkner enkelhet for å skape noe komplisert. Tross alt er ikke enkelhet den ultimate sofistikeringen?
Atomic Design er et system. Et system som fungerer sammen med flere deler for å skape noe unikt. Det er et system som kan forstås om du er designer eller utvikler, og dermed gjør begge jobbene enkle å vedlikeholde, endre og skyve fremover. For ikke å nevne, lindrer det også stress og press hvis en nøkkeldesigner eller utvikler må byttes ut eller forlate et lag.
Her er en rask oversikt:
Atomer er de grunnleggende byggeblokkene; enheter som ikke kan brytes ned lenger mens de fortsatt er funksjonelle. De er HTML-kodene som ,
,
,
.
Atomer kan også brukes til fargepaletter eller fonter. Det ville imidlertid være bra å merke seg at atomer kan være ganske abstrakte alene uten kontekst. Et veldefinert atom vil produsere et godt dannet molekyl.
Molekyler er kombinasjoner og arrangementer av atomer. I hovedsak ryggraden i designsystemet ditt. Et molekyl ville være noe som navigasjon eller et søkeskjema, som for eksempel består av en atom,
atom og a
atom. Sammen med noen flere hvis du føltes som å skape et komplekst molekyl.
En organisme bygger enda mer, noe som gir oss en kombinasjon av molekyler. Hele header på et nettsted kan betraktes som en organisme. Fra sin grunnstruktur innebærer det et unikt arrangement av atomer og molekyler for å skape en kompleks organisme. En bunntekstseksjon vil bli betraktet som en organisme. Hvis vi ser på det i kontekst, vil produktgitteret i en WooCommerce-mal betraktes som en organisme; det gjentar det samme molekylet med forskjellig innhold, eller til og med de samme atomer med forskjellige verdier for hver.
Grayson - Et stilig og allsidig butikk temaSelv om denne delen ikke har noe å gjøre med analogien, har Brad utviklet seg, maler kan brukes eller gjenbrukes for å vise arrangementer av organismer.
På dette tidspunktet blir utformingen virkelig viktig. Mennesker starter som enkle celler, vokser til et foster, en fullstendig baby, barn, tenåring, ung voksen, og vi stopper analogien når vi kommer til vår primære. Hovedmalen er et estetisk tiltalende, semantisk arrangement av organismer, molekyler og atomer. I hovedsak refererer vi til wireframes som har blitt utviklet over tid.
Når en mal når førsteklasses, og vi kutter den ut med bilder, innhold og copywriting, etc., har vi en side. En side, for eksempel, ville bli lastet opp til et verktøy som InVision for grunnleggende brukertesting før du går inn i utviklingen.
Jeg vil forlate deg med noen få siste tanker. Det er ingen riktig måte å håndtere forholdet mellom utviklere og designere. Å bygge en nettopplevelse - det være seg et nettsted, plattform, nettverk, SaaS eller PaaS - handler om å kombinere talenter og innsikt for både designere og utviklere. Den kan ikke leve uten den andre. Således, ingen prosjekt bør aldri være ugyldig av enten designer eller utvikler. Jeg håper på slutten av denne serien at du vil forstå hva jeg får på i bedre lys, og kanskje det vil gi deg noen ideer om hvordan du skal jobbe bedre med dine lagkamre.
Jeg vil også nevne at så mye som denne serien er fokusert på utviklere og designere, betyr det ikke å si at jeg ikke anerkjenner innholdsforvaltere eller copywriters; arbeidet ditt er like viktig når det gjelder å gjøre en nettopplevelse stor.
Nå som du har en forståelse av Atomic Design, kan vi virkelig komme til å arbeide med å finne ut hvordan det overgår til design og utvikling.
I de kommende artiklene kommer vi til å dykke dykk inn i de respektive verdener av front og back-end. Hvis du er designer, eller til og med en nybegynnerutvikler, vil de neste to artiklene hjelpe deg med å få den nødvendige grunnleggende kunnskapen. Hvis du kommer fra designverdenen, eller til og med skrive ut, beveger deg mot utvikling, vil konseptene jeg skal forklare hjelpe deg med å lukke gapet i å forstå det som er overgangen fra design til utvikling.