Du som är designer besitter den magiska superkraften av att kunna förvandla en utvecklares dag till ren glädje, men… du kan likaväl få dem att bli skogstokiga. Jag hoppas givetvis att du strävar efter det förstnämnda och vill därför ge några rekommendationer på hur du kan förenkla samarbetet mellan dig som designer och utvecklare i ditt team!

9 steg till en utvecklares hjärta

  1. Vikten av kontinuerlig kommunikation
  2. Att tydligt namnge och skapa struktur
  3. Hur dina designbeslut påverkar utvecklingen
  4. Att designa med ett ”komponenttänk”
  5. Designa för ”edge cases” och ”corner cases”
  6. Att skapa en konsekvent design
  7. Brytpunkter och responsivitet
  8. Specifikationer och dokumentation
  9. Färdigställning av assets

1. Vikten av kontinuerlig kommunikation

Relationen mellan designers och utvecklare har en stor betydelse för slutresultatet av den produkt som tas fram. Av de byråer som idag har både design och utveckling in-house så är det inte ovanligt förekommande att man har separerat dessa avdelningar från varandra. Det kan enkelt resultera i att designers och utvecklare arbetar isolerat från varandra fram till att den mer klassiska överlämningen sker av projektet.

Ibland så går det inte att göra något åt att denna indelning av kontoret har gjorts men det jag vill poängtera är inte nödvändigtvis om vart i lokalen man sitter, eller om man delar lokal alls. Att kommunicera med utvecklare kan ju givetvis även göras digitalt om man inte sitter i närheten av varandra, det viktiga är att man inte isolerar sig!

Varför?

Det handlar dels om att undvika potentiella risker eller överraskningar vid en senare designöverlämning, att göra avstämningar om den design som hittills har tagits fram så att utvecklare får en chans att tycka till och komma med insikter i ett tidigt stadie. Det finns mycket att vinna på detta eftersom att en utvecklare med sin individuella kunskap kan komma med kreativa tekniska ideér som kan influera dina designbeslut till något positivt. Givetvis så kan dem också komma med kritik som innebär att du som designer behöver göra förändringar i din design genom att kanske anpassa utseendet eller funktionaliteten till projektets budget eller liknande. Det kanske inte är vad vi vill höra men åtminstone så har detta då flaggats för i god tid.

För att en produkt ska bli grym så är vikten av en god kommunikation mellan designers och utvecklare ett måste. Att låta en utvecklare vara delaktig även under designarbetet gör att den vanligt förekommande isolationen mellan avdelningarna suddas ut och att man arbetar mer som ett sammanfogat effektivt team.

2. Att tydligt namnge och skapa struktur

När du väl har kommit till stadiet att påbörja en konkret design så är det väldigt viktigt att tänka på din struktur och namngivning i dokumentet eftersom att det blir en onödig och tidsödande process att göra detta i efterhand eller värre, att du inte gör det alls. Eftersom att det försvårar för utvecklaren när det inte finns en konsekvent, begriplig och genomarbetad struktur.

Detta kan inkludera

3. Hur dina designbeslut påverkar utvecklingen

Som designer så ansvarar du inte enbart för att skapa otroligt schyssta produkter utan du har likt andra i teamet ett ansvar av att hålla dig inom budget. Vi som arbetar med design på daglig basis har en tendens att vilja överträffa oss själva för respektive projekt vi arbetar inom. Det kan handla om att vi vill kontinuerligt skapa kreativa lösningar och pusha oss själva att ligga i framkant och att inte halka efter.

För det är ju faktiskt lätt att man sveps med, man kanske har sett en schysst webbplats eller en app där någon har tagit ut svängarna och som i sin tur har resulterat i något nytt och fräscht… och man vill ju inte vara sämre, du kanske känner igen dig.

Men trots detta så är det viktigt att man som designer förhåller sig till verkligheten, visst du kanske har full möjlighet att skapa något liknande inom din designbudget men vad blir konsekvensen för utvecklingen av produkten. Att hitta en nivå på komplexitet för designen som matchar vad utvecklarna har i budget är inte alltid så enkelt men därför är det viktigt att återigen tänka på punkt 1 ”Vikten av kontinuerlig kommunikation” och att stämma av med utvecklare så att man inte lägger ribban för högt.

4. Att designa med ett ”komponenttänk”

Detta handlar mer om hur ni arbetar generellt med design och utveckling men även vilken typ av CMS ni använder. Men vi på Triggerfish använder oss av av så kallade ”komponenter” i de projekt vi har.

Genom att man använder ett sådant tänk och arbetssätt så separeras designen i sin helhet till individuella design-komponenter och det blir enklare för en utvecklare att estimera tidsåtgången till att utveckla respektive komponent enskilt.

Några fler anledningar

5. Designa för ”edge cases” och ”corner cases”

Utseendet är allt… eller? Det blir lätt så att man i sin design försöker få allt att se perfekt ut, i värsta fall så blir det nästintill en fantasi. Att det blir jättebra om den överlappande rubriken har x antal tecken och om just denna skissbilden ligger under. Eller om några textkolumner har exakt lika många rader text m.m. Men det är ju faktiskt så att verkligheten sällan lever upp till dem höga förväntningarna och önskemålen som man som designer har när produkten ska lanseras.

Därför är det viktigt med att tänka ”edge cases” och ”corner cases” och vad det innebär är i sin enkla form att man tar höjd för scenarion där innehåll eller dylikt kan spreta iväg eller tvärtom inte fylla ut enligt designens upplägg.

Edge cases: Sällsynta eller extrema fall där något kan inträffa som kan potentiellt ”haverera” designen/utvecklingen.

Corner cases: Situationer som kan uppstå utanför det ”normala”.

Bra att tänka på

Kortfattat så behöver du som designer tänka realistiskt och inte heller förvänta dig att användare kommer att göra det du tror. Det är därför viktigt att inkorporera design för sådana scenarion så att utvecklaren har det hen behöver för att täcka upp potentiella problem som annars kan uppstå.

6. Att skapa en konsekvent design

Något som kan få en utvecklare att slita sig i håret, eller kanske skägget är när de får en design som inte har en konsekvent röd tråd inom sig. Det kan röra sig om att man i sin design inte har använt sig av samma avstånd mellan komponenter, att det finns många unika detaljer som kanske inte är värt mödan eller försvarbart kostnadsvis att lägga tid på.

Att som designer se till att man har ett konsekvent tänk i den design man skapar och att gärna specificera den informationen om designen i detalj. Så att en utvecklare enkelt och överskådligt kan ta till sig det utan att höja ögonbrynen och klia sig på pannan.

7. Brytpunkter och responsivitet

Här är det lite olika från byrå till byrå och generellt bland designers. På Triggerfish så skapar vi i de allra flesta fall responsiva vyer för de enskilda komponenterna som finns så att utvecklarna förstår hur uppläggen ska anpassa sig för de olika enheterna.

Beroende på komplexiteten av designen så kan detta vara att föredra men i vissa fall så kanske det räcker med att kommunikativt förmedla som designer till utvecklare hur det ska anpassas.

Men det är onekligen mest effektivast att som utvecklare ha tillgång till de responsiva brytpunkterna framför sig, att enbart överlämna en design för mobil eller desktop lämnar mycket ansvar och förtroende för utvecklaren att anpassa detta på egen hand. Vissa utvecklare kan klara det galant och andra inte så värst, det hänger mycket på den individuella personen och hur mycket känsla för formgivning de har, vilket kan variera stort.

Jag tycker personligen att man som designer alltid ska inkludera responsiva versioner och det gäller inte enbart komponenter utan även annan information som storlekar på rubriker, texter, interaktiva element, avstånd (padding), marginal och diverse delar som summerar upp en designs helhet. Din utvecklare kommer att tacka dig!

8. Specifikationer och dokumentation

Det leder oss till ännu en viktig del av samarbetet mellan designers och utvecklare, nämligen att sammanställa ”dokumentation” av den design som har tagits fram. För att utvecklare ska slippa leta igenom ett antal skisser och lista ut saker i detalj så är det alltid bra både för vår egna skull och för utvecklaren att man får en bra överblick.

Det kan inkludera

9. Färdigställning av assets

Detta går lite ihop med punkt 8 ovan men det jag vill lyfta är värdet av att som designer exportera ut ikoner m.m. och se till att dem fungerar tekniskt, t.ex. om dem ska in i Fontello eller dylikt så att ikonerna inte har något i dem som strular efter att ha exporterats. Allt för att bespara tid hos utvecklaren så att hen har allt de behöver för att verkställa designen så effektivt som möjligt.

Summering

Förhoppningsvis så tog du dig tid till att gå igenom punkterna och snappade upp åtminstone något som kan förbättra ditt samarbete med ”the other guys”… du vet vilka jag pratar om… utvecklarna förstås. För det är ju ändå så att produkten blir som bäst när vi samarbetar och när vi låter det isolerade arbetssättet höra hemma i det förflutna. Så låt oss effektivisera och göra varandras vardag enklare så bra vi kan. Om du är en utvecklare som läser detta och inte är helt nöjd med hur designen hamnar i ditt brevinkast idag så dela detta inlägget till dem, kanske leder det till något gott!