Kode som over­legent design­verktøy

"Kode er egentlig det eneste verktøyet vi kan lage grensesnitt med" skriver Halvor i Bring.

Halvor William Sanden jobber som senior systemutvikler på Mybrings frontend-team. 📸: Privat
Halvor William Sanden jobber som senior systemutvikler på Mybrings frontend-team. 📸: Privat Vis mer

Har du tenkt over at brukere egentlig aldri er i kontakt med det designere lager?

Grensesnitt utvikles av de som er eksperter på brukernes omgivelser, men avgjørelsene er tatt av noen som jobber i helt andre verktøy. Høres det ikke ut som en suboptimal løsning å holde teknisk kunnskap og brukerkunnskap adskilt på denne måten? For er det egentlig slik at kunnskapen til menneskene i disse områdene er så klart oppdelt?

Hva om noen fortalte deg at det finnes et designverktøy som kan forbedre både disse tingene og arbeidsflyt samtidig.

Det høres kanskje ut som standard lovnader fra nye skisse- og prototypapplikasjoner, men her er det snakk om kode. Egentlig det eneste verktøyet vi kan lage grensesnitt med.

Brukersentrert utvikling

Å jobbe i kode betyr å jobbe mindre med skisser.

Det er ikke noe galt med skisser, men heller måten de blir brukt på. De er supre som enkle figurer når man skal kommunisere og diskutere konsepter, ideer og flyter. Men som detaljerte, pikselraffinerte overleveringer fra designer til utvikler har de utspilt sin rolle. Å bruke dem som en form for arkitekttegninger for web er en ineffektiv og lite brukervennlig måte å lage grensesnitt på. De forsøker å forutsi noe de ikke har forutsetninger for å vite, fordi de lages i andre omgivelser enn der skal brukes.

Grensenittbygging er ikke arkitektur eller husbygging, hvor alt er på mål. Dagens web har ikke faste rammer for innholdet.

Et rom er like stort uavhengig av om det er tomt eller du forsøker å fylle det med ti bord. Åpner du derimot en applikasjon, skal grensesnittet tilpasse seg din skjerm og innholdet du er ute etter. Ingen tegning kan planlegge noe slikt, det kan kun tilrettelegges via effektiv, menneskeskapt kode som kjører der hvor brukerne er.

«Det gjør at brukere aldri er i kontakt med det designere lager.»

Alle skisser, enten de er statiske eller fuske-interaktive, er laget for å bli overlevert. Det gjør at brukere aldri er i kontakt med det designere lager. Undersøkelser, intervjuer, analyser og en media-query fra eller til endrer ikke på det.

Hvordan innholdet oppfører seg, og hvilke teknikker man bør ta i bruk for å få det til å bli best mulig, blir først tydelig gjennom kode. Skulle man fastslått det på et skissestadie, måtte man gjort akkurat samme jobben som utvikleren. Og da sitter man fort igjen med et overflødig steg i prosessen.

Brobygging vs. fylle igjen

Overleveringen krever at det brukes tid og innsats på å oversette skisser, tanker og interaksjoner til oppgaver. I tillegg kommer det som regel noen runder frem og tilbake for avklaringer og justeringer, kanskje uker etter at grensesnittet ble designet. Innen skissene er implementert har jobben blitt gjort minst tre ganger. Og det er alltids en risiko for at utgangspunktet har endret seg i mellomtiden.

På tross av mengden programmer som hevder å kunne forbedre arbeidsflyt og samarbeid, driver de i bunn og grunn bare resirkulert innovasjon av den tjue år gamle arbeidsflyten PSD2HTML. Den beryktede designer-utvikler-kløften er kanskje ikke så stor som den var da, men effekten av brobyggingen er begrenset.

I en slik flyt er min erfaring at designere føler de ikke har kontroll over det som når ut til brukerne, og utviklerne føler de bare implementerer det de får beskjed om. Ved å erkjenne at disse to, sammen, er best kvalifisert til å avdekke og løse problemer og svakheter i tjenestene de lager, kan man gi sterkere følelse av eierskap og ansvar. Folk bryr seg mer om de tingene de kan påvirke; kan de påvirke grensesnitt, bygger de også bedre grensesnitt.

Jeg snakker altså ikke her om at designere og utviklere må kommunisere bedre med hverandre – vi er forbi det for lengst. Veien framover er å begynne gjøre designere til utviklere – og samtidig øke designkunnskapen hos tradisjonelle utviklere. Å holde dem adskilt, som separate disipliner, dreier seg verken om gode arbeidsflyter eller hva som gir best resultat. Så lenge vi bare forsøker å bygge broer, vil kløften bestå. Den eneste måten å bli kvitt den på, er å fylle igjen – med kode.

Design, hele veien

Design er prosessen, ikke resultatet. Det betyr at design for skjerm ikke er en enkelt ting som løses bare man jobber via en skjerm.

Det betyr også at det ikke er et steg i en oppdelt prosess med begrensede rammer. Og det er ikke slik at jo mer definert stegene blir, jo mer riktig blir resultatet. Man ender kanskje bare opp nærmere de skissene en liten håndfull mennesker midt i prosessen har bestemt. Da er det bedre å fjerne rammene og heller designe gjennom hele løpet. I planlegging og diskusjoner – som i dag – men også utvikling.

«Da er det bedre å fjerne rammene og heller designe gjennom hele løpet.»

Tilbakemeldinger fra utviklere på alle nivåer i stacken sier meg at de gjør en bedre jobb når de løser problemer for brukerne fremfor at de må gjøre krumspring for å løse skisseskapte problemer.

Når de kan være med å bestemme og utfordre, istedenfor å bare implementere ferdigtygde oppgaver som skaper unødvendige problemer.

En workshop med relevante personer, som resulterer i noen grovskisser der og da, har større verdi enn pikselraffinerte overleveringer. Og få ting slår en arbeidsflyt som gir rom for iterering og testing med faktiske data i miljøer som er helt likt det som brukerne befinner seg i. Det gjør det mulig å jobbe i en mer fornuftig rekkefølge, med de rette menneskene, istedenfor å lage detaljerte stillbilder av det ferdige produktet halvveis inn i prosjektet.

Med personer som har både habile utvikler- og designkunnskaper kan du begynne å utvikle tidligere og med det du har. Du kan vente med visuelle detaljer til senere – de kan alltids endres eller overlates til et designsystem.

Politi og oversettere

Jeg leder et frontend-team i Bring som jobber på et logistikkverktøy sammen med en god håndfull andre team. Detaljene om arbeidsmetodene våre er litt på siden av hva jeg forsøker å formidle her, og de kan fylle egne innlegg. Men noe av det vi har gjort, er å sette sammen folk med forskjellig design- og utviklerbakgrunner.

Vi lager grovskisser i workshops med andre team, vi bruker DevTools til kjappe demoer, vi koder en og annen presentasjonsproto som benytter logistikkverktøyets eget designsystem.

Men aller viktigst, hver og en av oss produserer (og sletter) tusenvis av linjer produksjonskode hvert eneste år. Det blir tegnet og overlevert eksakt null skisser for implementering – de eksisterer ikke.

Og istedenfor å være godkjennere og politi, forsøker vi å lære opp, assistere og sammen de andre teamene forbedre frontenden de bygger.

Du må selv finne ut hva som fungerer i din organisasjon. Teknologien er der, kunnskapen er ikke langt unna, men strukturen må som regel løsnes på for å skape rom for denne arbeidsformen. Det holder ikke å flytte om på stoler og titler for å fortsette i gammelt spor.

Begynn med de mest ivrige. Det er stor sjanse for at det allerede er designere med kodekunnskap i nærheten – som kanskje kaster bort tid og evner på å være oversettere i skisseoverleveringer eller kun får kode noen prototyper, men ikke produksjonskode. På tide å bruke dem mer fornuftig.

«Det er stor sjanse for at det allerede er designere med kodekunnskap i nærheten.»

Det samme gjelder for de mange utviklere med uvurderlig innsikt og unike ideer som et tradisjonelt designteam ikke har mulighet til å avdekke eller benytte seg av så lenge mandatet deres er å fortelle disse utviklere hvordan ting skal være.

Lag heterogene team hvor ulike personer kan begynne å bruke og videreutvikle forskjellige ferdigheter og kunnskap. Hold tavlebaserte diskusjoner, lær fra hverandre, delta i hverandres arbeid. I en slik endring er det også viktig å la folk komme til orde med tanker, bekymringer og utfordringer.

Vurder, tilpass og prøv igjen.

For vår del er jeg ikke tvil om at effektivitet og samarbeid er bedre når alle utvikler. Ikke bare er det til det beste for brukerne – det er også god butikk.