BIZZ Insights

Viden og indsigter fra IT Minds

Fra design til kode

Skrevet af Mindster og Software Developer hos IT Minds on 25-06-19 10:47
Mindster og Software Developer hos IT Minds

Fra design til kode grafik-01

 

Kan nye teknologier og frameworks påvirke strukturerne og roller, der er involveret i en softwareudviklingsproces?

 

Introduktion

Hver dag popper der nye frameworks og teknologier frem. Nogle af disse bidrager med en mulighed for at gentænke måden, vi samarbejder i et softwareudviklingsteam om at bygge god og engagerende software radikalt. Derfor holder vi, i IT Minds, hele tiden øje med udviklingen af de nye teknologier og mulighederne, de giver, for at sikre, at vi benytter de teknologier og udviklingsprocesser, der giver mest værdi for vores kunder.

I det følgende har vores Senior Software Developer i IT Minds, Martin, sammenkogt en artikel om, hvordan man, som mindre udviklingsafdeling, kan udvikle brugervenlig software og mindske dobbeltarbejde væsentligt, gennem tæt samarbejde helt fra design af brugergrænseflade til datamodel.

 

Baggrund

Der er en generel diskussion om, hvad “frontend” er. Ofte bestiller en kunde eller en produktejer bare “en frontend” eller, hvis de er (mere?) tekniske; “noget Angular”.  

Hvis man er softwareudvikler, så er design, og implementering af design, ikke det første, man, som softwareudvikler, tænker på, når man hører ovenstående. Og i fremtiden behøver vi slet ikke at tænke videre over, hvad kunden lægger i det. Det forholder sig nemlig således, at arbejdet med UX, design og frontend-programmeringen overlapper og gentager hinanden, og man kan rent faktisk tage fat på nogle af disse gentagnede processer og fjerne dem. Styling og markup er lige nu en integreret del af det arbejde, udvikleren laver. Men sådan behøver det ikke at være.

Hver gang jeg har modtaget et design fra en hvilken som helst kundes designer, tænker jeg over, om ikke det er spildt arbejde, at jeg modtager det i billedform i PNG eller PSD og så sidder og laver samme design - eks. i HTML og CSS. Jeg har været ude på mange projekter, og der altid har været en UX’er, en arkitekt, en backend- og en frontend-specialist - det vil sige mange hoveder inde over et produkt. Et af de første overlap, jeg er stødt på, foregår mellem UX, grafisk design og frontend-udvikling. Mange virksomheder ser de tre trin som værende den samme ting. De kalder det måske bare “en brugergrænseflade” - at det bare er “hjemmesiden”.

 

Arbejde med “brugergrænsefladen” forklaret - roller og opgaver

UX, UI, Design, Frontend, Client, Wireframe, Sketches, Mockups. Mange af de ord er komponenter, der kan opsummeres med én simpel sætning: "What the user sees, feels and remembers." (Karri Saarinen, AirBnB). Men UX, grafisk design og frontend er ikke det samme. Dog spiller nogle ting sammen.

Meget af det, en grafisk designer laver, laver en udvikler også - bare i kode. Har en UX’er (mere korrekt; UIer / grafisk designer) tegnet en orange knap med en blå baggrund, laver udvikleren det samme. Der er mange nye værktøjer derude, der kan være med til at autogenerere denne styling, men problemet er, at de ikke fungerer ret godt i mange arbejdsprocesser. For at fjerne mange af de overlap skal man derfor tænke på et mere grundlæggende niveau, når man starter processen. Når vi, som softwareudviklere, påbegynder et projekt, starter vi typisk bagfra med at finde ud af, hvordan vi skal opbygge projektet, altså hvordan datamodellen skal opbygges. Her kan man lade sig inspirere af designerens tilgang. Atomic design components er et designbegreb, der handler om bryde designet ned til de allermindste elementer - atomernes design. På samme måde kan man introducere begrebet data-atoms, der handler om samme atomers data. Ved at forbinde dem kan man begynde at snakke samme sprog, og det vil være en forbedring.

 

Frontendudvikling gentænkt

Ved at have en ide om forbindelsen mellem design- og data-atomer og heraf et grundlag for samarbejdet, er næste oplagte skridt at bruge nogle designværktøjer, der kan eksportere design til kode, eller i hvert fald kan eksportere style sheets. “Sketch” er et godt eksempel på et program, som grafiske designere kan bruge til at sidde og tegne brugergrænseflader, som kan udvides, så det lægger sig tættere op af et udviklingsmiljø og eksportere design til kode. Det vil kræve lidt træning i det, men vil til gengæld spare en del dobbeltarbejde.

Herved kan designeren designe brugergrænsefladen, så udvikleren kan se, hvordan det skal se ud, men også eksportere det som stylesheets, så udviklere “bare” skal implementere dem på selve systemet, der udvikles.

Ved at lave denne arbejdsdeling, vil man, specielt på udvikling af mindre systemer, kunne gå fra at have et team på fire medarbejdere (UX, UI/Designer, frontendudvikler og backendudvikler), der stort set gentager den samme opgave 2-3 gange, til at have et team på 2 personer, hvis arbejde overlapper væsentligt mindre.

På større systemer, specielt dem med advancerede funktioner eller ønske om meget tilpasset og lækker brugergrænseflade, vil man måske fortsat have flere roller i spil, men dog, det til trods, kunne undgå at gentage arbejdsopgaverne vedr. grafisk produktion af brugergrænsefladen.

Næste skridt, er at udvide brugen af eks. “Sketch”, til også at give ekstern adgang, så man kan dele designet som en klikbar hjemmeside. Herved vil en potentiel kunde eller bruger kunne få en føling af, hvordan systemet er tænkt bygget op og sikre en langt bedre forventningsafstemning og mentalt ejerskab af produktet, da nye features kan testes, i takt med at de frigives.

 

Opsamling

Ovenstående er et indblik i, de erfaringer, vi har gjort os, når vi leverer softwareprojekter. Jeg har forsøgt, i en kort form, både at give et indblik i tankerne bag vores valg, vores erfaringer med de valg vi har truffet og vores konstante fokus på at forbedre processen og den værdi, vi kan skabe undervejs.

Både jeg og mine kolleger fra IT Minds’ leveranceafdeling vil altid gerne sparre om muligheder og alternative løsninger, ligesom vi gerne graver et spadestik dybere og sætter ord på, hvordan vi eksempelvis forbinder ovenstående med begreber som “continuous delivery”.

 

Insights fra IT-branchen

Tendenser i IT-branchen, nytænkende projektudvikling, agile metoder og meget mere - direkte fra IT Minds' partnere og nøglepersoner.

Seneste indlæg