Hitta nått kul:
13 Pixlar   /   Artiklar   /   Designprocessen i webbprojekt flyttar in i browsern

Designprocessen i webbprojekt flyttar in i browsern

Pixelperfekta skisser i Photoshop blir både krångliga och onödiga när processen i webbprojekt förändras. Att designa direkt i browsern blir allt viktigare.

20 april, 2014

I och med den snabba utvecklingen av webbstandarder, webbläsare och de mobila enheternas intåg har webbdesignerns arbetsprocess förändrats. Det är inte längre hållbart att arbeta fram exakta skisser i Photoshop (eller annan likvärdig mjukvara) för att sedan omsätta dessa i kod. I och med att vi nuförtiden bygger webb för enheter med många olika storlekar har det blivit en omöjlighet att göra ut alla varianter i våra skisser. Vi har börjat designa direkt i browsern. Det är något våra kunder behöver förstå och acceptera.

Att designa i browsern

Att ta fram en design direkt i browsern är både enkelt och roligt. Den största fördelen är att man omedelbart kan se hur olika delar ser ut och känns, hur de fungerar i olika storlekar och att man kan göra förändringar vilka syns direkt. Även i den responsiva webbutvecklingen sparar man tid då man kan växla mellan olika bredder och utveckla dessa parallellt. Detta ger en snabbare och enklare kod eftersom man kan anpassa sina elements egenskaper medan man bygger dem.

Mobil först

Uttrycket mobil först eller mobile first myntades av Luke Wroblewski och innebär att man i designprocessen utgår ifrån en smal skärmyta för att sedan skala upp till större storlekar.

Mobile devices require software development teams to focus on only the most important data and actions in an application. There simply isn’t room in a 320 by 480 pixel screen for extraneous, unnecessary elements. You have to prioritize.

Detta är något som kan kännas obekvämt för många som är vana vid att utgå ifrån en deskop-bredd när de börjar skissa. En fördel med Mobile first är, precis som Wroblewski säger, att man tvingas prioritera sitt innehåll hårt. Då man har en begränsad yta att få ut sitt budskap på blir man tvungen att renodla och vikta sitt innehåll på riktigt.

Stortavlor, karuseller och sidebars är traditionella sätt att försöka få plats med så mycket information som möjligt på en liten yta. Om man designar först och främst för mobila enheter blir detta ohållbart och man tvingas att välja, något som ofta är väldigt nyttigt i slutändan. Genom att göra denna prioritering direkt i browsern blir det enkelt att testa olika idéer direkt och iterationer blir mindre smärtsamma.

Iterationer med kunder

Att kunder förväntar sig en skarp skiss är vårt eget fel. Det är så vi har talat om för dem att det fungerar. Vi levererar en skiss över alla delar i projektet och först efter ett antal iterationer och ändringar är allt godkänt och vi börjar utvecklingen. Det är så vi alltid gjort och det är så många fortfarande gör.

Anledningarna till att man håller kvar vid denna gamla process är många. Det kan kännas svårt att förklara för kunden att det inte går att säga exakt hur projektet kommer att se ut förrän det är färdigt. Att kostnaderna tredubblats för att man tvingas göra ut fler exempel och skriva mer kod är heller inget roligt besked att komma med. Dessutom kanske det ligger utanför vår konfortzon att börja visa skarpa exempel direkt.

Det är i det sistnämnda fallet som vi som webbdesigners och utvecklare måste våga förnya oss. Vi måste orka ta diskussionen med våra kunder och medarbetare. För i slutändan är det projektets kostnader och kvalitet som blir lidande.

Den nya arbetsprocessen

Istället för de detaljerade skisser som både vi och kunderna är vana vid kan vi jobba på andra sätt. Genom att göra tydliga wireframes och sidkartor får vi en bra överblick över funktionalitet och funktion. Vi skapar ett grafiskt designdokument där vi sätter färg, form text och rubriker, etc, i moduler som kan återanvändas. I och med detta dokument har vi tillsammans med vår wireframe ett fullgott alternativ till den tidigare modellen. Men redan innan vi är överens om den övergripande känslan och funktionaliteten kan vi börja koda.

Bygg en prototyp

Börja koda tidigt. Använd ett ramverk som t.ex. Twitter Bootstrap eller Zurb Foundation och börja bygga upp de grundläggande beståndsdelarna. Redan efter ett par timmar har vi en enklare prototyp som vi kan navigera i. Vi kan se hur vårt innehåll anpassar sig efter olika skärmstorlekar, vi kan byta ordning på olika element, vi kan göra saker större eller mindre, vi kan till och med göra olika versioner av viktiga delar för att testa vad som fungerar bra och vad som fungerar mindre bra.

Och bäst av allt; vår beställare kan komma in tidigt i processen och få en förståelse för vår vision.

Utvecklas eller dö

Evolve or die. Det kan låta tufft och riktigt så illa är det kanske inte men faktum är att vi måste utveckla våra processer och anpassa dessa efter den verklighet vi befinner oss i. Vi måste vara modiga och uthålliga i vår strävan att göra bästa möjliga resultat i en bransch där både utmaningarna och möjligheterna växer exponentiellt med varje nytt framsteg tekniken gör.

Koda tidigt, koda mer, använd koden som ditt främsta vapen i kampen för en bättre webb.

Må kraften vara med dig.

Yterliggare läsning

I den fjärde delen av sin utmärkta serie om responsiv webbutveckling skriver Triggerfish om detta ämne.
Mer om Mobile First i Luke Wobrlemskis bok.


  • Linus95

    Mycket bra skrivet!

    Har själv gått ifrån att sitta i Photoshop till att bara dra upp en vanlig HTML fil och börja koda basen!

    • Adam Rehal

      Tack. Photoshop är bra till vissa saker men med tanke på webbens utveckling och hur snabbt det går att ta fram fungerande prototyper känns det som en bökig metod att ta fram odynamiska skisser först. Utmaningen är som sagt att få beställaren att vara med på noterna.

      • Linus95

        Jo oftast brukar jag bara dra upp photoshop för skissa upp hur siten ska se ut på datorn/surfplattan! Brukar vara lättare att sätta allt där kunden vill ha de! 🙂