đČ â mikrobloggeriet olorm - olorm-59 · olorm-60
Jeg digger Ă„ jobbe med designere som aktivt tar stilling til omfanget av jobben som skal gjĂžres. Les hvorfor.
Designskissen skinner sÄ du ser refleksjonen i den. Alt er perfekt. Fargene, forholdene. Teksten ser ut som en dessert fra en michelinstjernerestaurant. Du har et problem.
Hvor i all verden skal du starte?
IfÞlge DORA (dora.dev/capabilities/continuous-delivery) leverer produktteam som praktiserer kontinuerlig leveranse jevnt over bedre produkter. NÄr man skal levere kontinuerlig mÄ én bit leveres om gangen; og bitene som leveres informerer videre utvikling.
Men hvor i all verden skal du starte?
à finne det gode stedet Ä starte er en designjobb. Men det designet treffer ikke sluttbrukeren: det designet treffer utvikleren og designeren. En piksel-perfekt prototype peker ikke pÄ hvor det er best Ä starte. Den gjÞr det motsatte: den sidestiller alle tingene som kan gjÞres.
I stedet, finn ut hva fÞrste versjon av produktet skal gjÞre. Hvem skal oppnÄ hva?
Hvis du ikke stiller det spĂžrsmĂ„let og svarer pĂ„ det med en hypotese, har du ikke et tydelig mĂ„l. Da smetter âdet skal se ut som pĂ„ skissenâ inn som mĂ„l i stedet. Da fĂ„r du:
Jeg mener vi bÞr unngÄ Ä ta opp work in progress nÄr vi kan, se for eksempel OLORM-50: For mye opsjonalitet. NÄr mÄlet med arbeidet i tillegg er udefinert, har vi lagd flere problemer for oss selv enn vi har lÞst.
NivĂ„ 1 av jobben til den omfangsorienterte designeren er Ă„ ta âvi skal definere et smalt neste stegâ seriĂžst. Ikke gjĂžr mer enn nĂždvendig pĂ„ Ă©n gang. Tenk âhvordan skal det tas i brukâ fra steg 1. Da lager vi sĂ„ lite work in progress vi fĂ„r til; vi setter oss i posisjon hvor vi kan fullfĂžre.
NivÄ 2 av jobben til den omfangsorienterte designeren er Ä kode det opp direkte i HTML og CSS. Lag noen HTML-filer og CSS-filer i kodebasen. Det blir da ettertrykkelig tydelig hvordan man kan blÄse liv i prototypen med ekte data og ekte interaksjoner.
Med noen runder HTML og CSS i koden kommer utvikleren fort til Ă„ klĂž seg i hodet eller skjegget (eller andre steder med kroppshĂ„r) og tenke âhvorfor kan ikke designeren bare endre produktet direkte?â Det er et veldig godt spĂžrsmĂ„l! Og svaret er ja. Det gĂ„r. Men da mĂ„ du rigge kodebasen sĂ„ designeren faktisk fĂ„r gjort jobben sin nĂ„r desineren setter seg ned for Ă„ jobbe. Det betyr at designeren fĂ„r fokusert pĂ„ det visuelle utrykket, uten Ă„ bli distrahert av detaljer som ikke har med visuelt inntrykk Ă„ gjĂžre.
Redesignet Mikrobloggeriet fikk vinteren 2025 er skrevet rett i CSS av Neno, som er utdannet designer. Neno kjĂžrer kodebasen lokalt, endrer CSS-filer og pusher og prodsetter med Git. Vi har gjort âpush og prodsettâ til Ă©n kommando. Hvis den var et bash-script, ville den sett cirka sĂ„nn ut:
set -e # ellers stopper ikke Bash nÄr noe tryner, lol
./test.sh
./lint.shâš
./try-deploy.sh # deploy feiler hvis appen ikke klarer Ă„ starte oppâš
git pushâmen er ikke gĂ„ rett i prod skummelt, da?â I praksis, nei. Det er tryggere. Det er lettere Ă„ forbedre systemet, inkludert Ă„ legge pĂ„ nĂždvendig sikkerhetsnett.
Design-utvikler-interaksjonen i Mikrobloggeriet-arbeid er sĂ„pass bra at jeg vil jobbe hardt for Ă„ beholde den flyten. Som utvikler fĂ„r jeg fokusert pĂ„ domeneproblemer og tilgjengeliggjĂžring av data, og slipper âimplementer denne plxâ-gjĂžrejobber. Det gjĂžr at vi klarer Ă„ shippe redesign pĂ„ rekordtid pĂ„ et hobbyprosjekt vi gjĂžr ved siden av vanlig jobb.
Hvis du er designer eller utvikler, anbefaler jeg Ă„ prĂžve det. GĂžy og bra :)
Takk til Neno Mindjek og Eirik Backer for gode diskusjoner om samspillet mellom utviklere og designere, og til Christian Johansen og Magnar Sveen for gode tanker om hvordan framside-kode kan struktureres pÄ enkelt vis.