Hei designere, kjører du utviklerens kolleger gale?
Sjansen er at du har noen vaner som ikke oversetter spesielt godt å kode, og det gjør livet tøft for utvikleren som jobber med deg på prosjekter. Vil du være en bedre kollega (og venn)?
Lær hvordan du bedre kommuniserer og utformer slik at utviklere vil elske deg. Det vil påskynde prosjekter og gjøre arbeidslivet enklere. Og det handler ikke om å bringe godterier til møter heller. Du kan få utviklere til å elske deg ved å gjøre små endringer i måten du jobber på.
Det største problemet mellom designere og utviklere er at de ofte jobber i bobler. Individer eller lag begynner ikke å snakke om et prosjekt før det første utkastet til designet er ferdig. Deretter er det en handoff fra designeren til utvikleren.
Sukk.
Det er bare ikke vei til jobb. Designere og utviklere bør være involvert sammen fra begynnelsen for å snakke om hvordan et prosjekt vil komme sammen. Mens designeren kan fokusere på farge og skrifttyper og bilder, kan utvikleren gi innsikt i brukbarhet, funksjon og ytelse.
Designere og utviklere bør ha en god ide om hvordan den andre siden ser ut. Designere bør forstå nok kode og brukervennlighet for å snakke med utviklere og forstå utfordringer; utviklere bør ha litt kunnskap om designteori, slik at de kan komme med forslag når designideer ikke er riktige for nettet.
En av de største tingene en designer kan gjøre er å prep og pakke filer på samme måte hver gang.
Hvor mange ganger har du åpnet et Photoshop-dokument med hundrevis av ikke-navngitte lag? Ikke gi denne typen fil til en utvikler. Hvert lag og stil - uavhengig av hvilken programvare du bruker - skal oppgi riktig.
Hvor mange ganger har du åpnet et Photoshop-dokument med hundrevis av ikke-navngitte lag?
Stiler, fargestifter og typografi bør være konsistente gjennom hele designet. (En knapp skal ikke se annerledes ut fra side til side.)
Navn på filer og stiler på samme måte for hvert prosjekt. Grupper som elementer på en lignende måte og bruk et konsistent mappesystem. På den måten trenger utvikleren ikke å gjenoppleve hvordan man finner deler og elementer med hvert nytt prosjekt.
En av de største utfordringene for designprosjekter som inkluderer utskrift og digitale brikker, er typografihåndtering. Ikke bruk skrivebordsskrifter for utskriftsprosjekter for web- eller appdesign og bare antar at de vil fungere. (Ofte gjør de det ikke.)
For digitale prosjekter velger du Google Fonts for typografi. Dette betyr at du kanskje må finne et lignende skrifttype for nettet for å matche det du bruker til utskrift. (Det er greit.)
Ikke la utvikleren gjøre dette for deg. Plukk ut de sammenlignbare Google Fonts og bruk dem fra starten. Du kan til og med merke utskrift mot digitale skrifttyper i din stilguide.
Årsaken bak dette er enkel: Embedding fonter kan bli litt vanskelig. I tillegg er Google Fonts gratis og sikrer at du ikke pådrar ekstra prosjektkostnader. (Mens du er i det, bør du vurdere å gjøre det samme med ikoner og bruke en pakke som Font Awesome, som gjør at utvikleren kan style ikoner ved hjelp av CSS, ikke importere en haug med bildefiler!)
Mens vi er på emnet for bildeaktiver, er eksport og pakking av filer ordentlig super viktig. Mens en utvikler kan åpne og eksportere alle bildefiler for å dekke deres behov, kan du spørre hva de trenger og gjøre det underveis.
Dette sikrer at du får avlingene du vil ha på bilder, mens du komprimerer filer for å hjelpe nettstedet ditt til å laste raskt.
Ikke prøv å gjøre dette på egen hånd. Be utvikleren hvordan filer skal lagres, navngitt og komprimert for best mulig bruk.
Det er bare så mange enhetstørrelser og aspektforhold som du kan tenke på når du designer nettsteder og mobilapper. Som designer må du vite lerretets størrelse, marginer, polstring, etc. for å lage en mockup som faktisk er brukbar.
Snakk med utvikleren før du begynner å tegne for å sikre at du vet hvordan designmiljøet ser ut før du begynner. Det er ingenting verre enn et design som ser utrolig ut i Photoshop eller Sketch og faller flatt i produksjon.
Du må vite disse tingene på forhånd:
Det har blitt nevnt noen ganger allerede, men kommunikasjon mellom designer og utvikler er virkelig nøkkelen til å gjøre alt dette arbeidet. Kommunikasjon kan gjøre eller ødelegge prosjekter, påvirke tidsfrister og påvirke sluttprosjektdesign og funksjonalitet.
Kommunikasjon kan gjøre eller ødelegge prosjekter
Ta utvikleren til lunsj. Bli kjent med dem. Spør mange spørsmål underveis. Hvis du ikke er sikker på om noe vil fungere eller ikke, bare spør. Utviklere er ikke skummelt folk, og det er mye lettere å svare på et spørsmål tidlig i prosessen enn å tenke på og hele konseptet.
Mens du snakker med utvikleren og stiller spørsmål, dykk dypere. Lær ut noen grunnleggende grunnleggende utviklingsarbeid hvis du ikke allerede har disse ferdighetene i ditt designarsenal.
Designere som jobber med digitale prosjekter bør vers seg i:
Du kan aldri skrive kode, men lære utviklingsprinsipper vil gjøre deg til en bedre designer fordi du vil forstå verdien av verktøyene og arbeidsflytene.
Utformingsprosessen strekker seg også til utvikling. Designere, du må gjenkjenne at utvikleren er like viktig for designprosessen som du er.
Med det for øye, lage en "levende" stilguide som ikke bare inkluderer farge og skrifter, men også komponenter. Alle skal kunne få tilgang til og oppdatere dokumentet når prosjektet kommer til liv.
En god stil guide vil hjelpe alle som jobber med et prosjekt å opprettholde konsistens med visuelle elementer, gi kontekst for designvalg, tjene som et samarbeidspunkt for prosjektet og bidra til å standardisere kode. Den levende stilguiden lar alle dele ideer og gi veiledning gjennom et prosjekt. Det er ikke bare et dokument som noen skaper rett før et design går live.
Legg følgende informasjon i stilguiden for å få mest mulig ut av det:
Respekter rutenettet. I responsivt nettsteddesign er nettverket mer enn bare en retningslinje for plassering av elementer på skjermen, det kan også diktere hvor elementene går i forskjellige skjermstørrelser og hvordan kolonner stabler og shuffle.
Gitteret kan hjelpe deg med å designe og vedlikeholde strøm. (Utfordringen er at du ikke vilkårlig kan bryte designregler.)
Tenk på det slik: Designet ditt har fire innholdsblokker lined opp på skjermen på en rad (med samme rangerbredder) på en skjerm på skjermen. Deretter skifter disse blokkene på en tavle for å danne to kolonner, med to rader. På en mobil enhet skifter de til en enkelt kolonne med fire rader.
Forstå hvordan nettverket påvirker størrelsen på objekter og hvordan objekter skal skifte på ulike enheter, er viktig fordi det kan diktere hvordan du designer for innholdet du har. Tenk på det samme scenariet igjen. Hva om du hadde fem innholdsblokker? Det ville kreve et redesign for å sikre at du oppretter en konsistent visuell oversikt.
Den virkelige nøkkelen til å sikre prosjekter kommer sammen med letthet er å være fleksibel. Designteknikker og standarder for nettet endres hele tiden. Mens noen prosjekter gjør at du kan være en klistremerke for detaljer og unmoving, reagerer design ikke egentlig på den måten.
Den gylne regelen når det gjelder å jobbe med utviklere er ... ikke vær en rykk.
Designere som er lette å jobbe med, vil tjene mer respekt og ha bedre relasjoner til utviklere. Dette vil føre til bedre og mer vellykkede prosjekter. Det burde være uten å si, men for ofte er det mye jerk-ish atferd der ute. Ikke fall inn i den fellen.
Vær fleksibel, åpne og snakk ut ting med utvikleren din. De vil elske deg for det.