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
- Vikten av kontinuerlig kommunikation
- Att tydligt namnge och skapa struktur
- Hur dina designbeslut påverkar utvecklingen
- Att designa med ett ”komponenttänk”
- Designa för ”edge cases” och ”corner cases”
- Att skapa en konsekvent design
- Brytpunkter och responsivitet
- Specifikationer och dokumentation
- 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
- Att beskrivande namnge varje lager som skapas, det inkluderar grafiska lager, textlager, grupperingar m.m.
- Att skapa tydligt indelade grupper.
- Om du använder t.ex. Sketch, arbeta med symboler och därigenom skapa ett samlat bibliotek för de UI element som kommer att skapas.
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.
- Vad är komponenter? Dem kan kallas lite olika, t.ex. moduler, komponenter m.m. Men oavsett så rör det sig om att man designar och utvecklar dessa som individuella ”block” som kan användas flexibelt på t.ex. en webbplats. En komponent skulle alltså kunna vara en lista av nyheter, ett bildgalleri, en bild med text vid sidan av sig o.s.v.
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
- Att använda sig av detta tänk som både designer och utvecklare resulterar i ett enhetligt arbetssätt redan från designens tidiga stadie till att utvecklare sitter och kodar.
- Det är viktigt som designer att förstå vad som är tekniskt möjligt och vad som inte är realistiskt, att dela upp sin design i konkreta komponenter och definiera funktionaliteten för respektive förenklar såväl ditt och utvecklarens arbete.
- Att i tidigt designskede uppskatta vilka unika komponenter som behövs i projektet och estimera vad du tror om tidsåtgången är också bra för projektledare att se om budget kommer att hålla.
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å
- Tillåt designen att vara realistisk. Låt texter i olika kolumner ha fler eller färre rader, det gäller även rubriker.
- Även om det tar emot, använd bilder som kanske inte är helt perfekta eller harmoniserande. Detta hänger givetvis på vad du vet om kundens bildmaterial, har dem schyssta foton så unna dig och lyxa till det.
- Vid interaktiva element, förutse vad som kan ske när något inte fungerar. Exempelvis ett formulär, vad händer om informationen som fylls i inte accepteras.
- Det handlar också om att designa för scenarion som också är positiva, att någon har fyllt i sin e-post för nyhetsbrev och tryckt ”Registrera”, vad ska då hända?
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
- Text stilar (H1, H2, H3… ingress, brödtext o.s.v.) och hur deras storlekar anpassas för respektive brytpunkt. Här är det även bra att lista alternativ på formatering för admin, exempelvis om H1 rubriken ska kunna vara svart #242424000 och vit #ffffff.
- Alla färger i hexkod som används i skisserna och vart/hur de används.
- UI element, knappar, fält, m.m. i de olika utförendena för hover, fokus, aktiv m.m.
- Att skriva ned funktionalitet. Om det exempelvis gäller ett formulär, skriv vad för funktioner det ska ha. Tankar, prototyper eller exempel på animationer och generella anteckningar från dig som designer så att det finns konkret att läsa någonstans. Vi på Triggerfish använder oss ofta av Trello och dess kortupplägg för just komponenter, det är ett bra sätt att se till så att inget glöms bort.
- Att använda tjänster som InVision med Invision inspect är också ett bra sätt att förenkla för utvecklaren. Det finns flera tjänster att nyttja och det kan vara värt att Googla runt och se vad som passar, eller så kanske ni idag redan har bestämt er för en sådan tjänst.
- Att se till att designskisser m.m. är uppdaterade och att samtliga i teamet arbetar med korrekta versioner. Detta kan hanteras genom olika lösningar och det kan variera om utveckling sker parallellt med design eller om dem t.ex. inte överlappar alls. Något som är populärt och effektivt är att arbeta med designsystem, speciellt om det rör sig om ett större team under en längre period men detta kommer vi att skriva mer om i ett annat inlägg.
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!