5 Pet Peeves Designere har med utviklere (og hvordan man kan unngå dem)
Katter og hunder. Kain og Abel. Designere og utviklere. Disse er bare noen av de store historiske ansikts-offene.
Designere og utviklere synes ofte å komme fra forskjellige planeter og har helt forskjellige hjerner.
Utviklere ønsker at et nettsted skal fungere riktig, designere vil ha det til å se riktig ut.
Selv om disse målene har mye overlapping (og selvfølgelig, jeg stereotyperer her litt), kommer forskjellene ofte ned til designeren og utviklerens forventninger om suksess.
Å håndtere forventningene er et spørsmål om kommunikasjon: å gjøre poeng tydelig til den andre siden, finne felles grunnlag og avtale mål.
Ok, så kanskje det er ikke så lett, men det er viktig for begge sider å prøve å forstå hverandre .
I et forsøk på å fremme goodwill mellom designere og utviklere, vil jeg dele noen kjærester jeg har møtt og utforske problemene som fører til dem og deres løsninger.
Peeve # 1: "Hvorfor kan ikke utvikleren bare få det til å ligne kompisen?"
Du lager en flott design og gir deg komplikasjonen til utvikleren din, men når du får siden tilbake, ser det ut som et lappeteppe av det du designet.
Utgave
Comps er ikke websider; de er ikke en blanding av HTML, CSS og JavaScript-kode. Photoshop, fyrverkeri og Illustrator kan gjøre mange ting som er umulige (eller i det hele tatt vildt upraktiske) på nettet, noe som ofte betyr at utviklere må skala ned designet.
Løsning
Snakk med utvikleren din mens du designer, ikke bare etterpå. Spør dem om en effekt du bruker, vil være lett å oppnå, eller om et bedre alternativ eksisterer. Også, når du lærer mer om webutvikling, kan du bedre fortelle forskjellen mellom når designen er upraktisk og når utvikleren bare slipper av.
Peeve # 2: "Farger er feil!"
Du velger ikke farger vilkårlig, men utviklere synes å tro at "nær er nær nok".
Utgave
Jeg vet ikke om dette gjelder alle utviklere, men jeg jobbet en gang med en utvikler som var rødgrønn fargeblind (han var en stor fan av innholdsansvarlig, som sendte alle e-postene i rosa tekst på en limegrønn bakgrunn). Men å være fargeblind stoppet han ikke fra å være en kick-ass-utvikler.
Løsning
Hvis du vil at fargene skal være riktige, må du stave ut alle fargeværdiene på siden. Ikke stol på utvikleren din for å øye fargeverdiene eller å prøve fargene i Photoshop.
Du må også vurdere at problemet ikke kan være med utvikleren, men med deg. Farger ser annerledes ut på en Mac og i CMYK (hvis du tilfeldigvis aktiverer den fargeplassen). Kontroller at dokumentfargemodus og -sikkerhet er satt til generisk RGB som standard.
Peeve # 3: "Vet utviklere selv hva" hvitt rom " betyr?"
Du har forlatt mange puste rom rundt elementene for å skape en fluid øyebane og forbedre lesbarheten, men utvikleren klapper alt sammen og forteller deg, "Det er den eneste måten det passer til."
Utgave
Jeg klaget en gang til en utvikler at han ikke forlot plass mellom grensen til en modul og innholdet, noe som gjør det veldig vanskelig for de fleste å lese. Han svarte: "Jeg bryr meg ikke om andre mennesker. Jeg kan lese det. "Selv om de fleste utviklere ikke er så kveløse, har de ikke blitt trent i kunsten å blande positive og negative rom for å veilede besøkendes øye rundt designet.
Løsning
Hvis du virkelig vil at designene dine skal være så presise som mulig, ikke bare gi designeren en kompis og forvent at de skal finne ut avstanden. Angi eksakte bredder, høyder og lengder i et designspesifikasjonsdokument. Dette fungerer som en tegning som du og utvikleren er enige om for hvordan ting skal skilles inn.
I det minste definere generelle regler for marginer og polstring. For eksempel, "Alle moduler må ha minst 10 piksler med polstring mellom innholdet og grensen."
Peeve # 4: "Utvikleren kan aldri få designene mine til å se det samme ut i forskjellige nettlesere."
Du ser på nettstedet i Firefox, og det ser bra ut, men når du bytter til Internet Explorer, faller det i stykker.
Utgave
Du må være sympatisk overfor utviklernes situasjon når det gjelder å lage design ser konsekvent på tvers av nettlesere. Hver nettleser har sine egne kjennetegn med avstand. Ting blir bedre (spesielt med langsom død av Internet Explorer 6), men å få dem alle til å leke fint med hverandre er fortsatt vanskelig.
Løsning
Jeg tillater generelt noen få piksler med wiggle-rom i designene mine for å imøtekomme problemer med nettleseren, men det hjelper å vite hva disse problemene er mens du designer, slik at du kan hjelpe utvikleren til å unngå dem.
Ikke vær redd for å påpeke problemene med nettleseren til utvikleren og forventer at de blir løst. Men å løse noen av dem kan kreve at du tilpasser designen din.
Peeve # 5: "Dette vil ta lengre tid?"
Ingenting er mer deprimerende enn å brenne midnattsoljen på dobbelt tid for å få del av et prosjekt ferdig i tide, bare for å få tilbake en utvikling LOE (Nivå på innsats) som setter prosjektutgivelsesdatoen tilbake en måned fra enden av enden .
Utgave
I en klassisk episode av Star Trek: The Next Generation , forklarer Scotty fakta om ingeniørlivet til Geordi La Forge: "Du sa ikke [kaptein Picard] hvor lenge det egentlig ville ta, gjorde du? Oh, laddie. Du har mye å lære om du vil at folk skal tenke på deg som mirakelarbeider. "Noen utviklere tenker på designere på samme måte som Scotty tenker på Starfleet Captains.
Løsning
Utviklere vet at de vil møte uforutsette problemer og så pleier å grove pudse sine estimater. Dette gjør at de ser veldig bra ut hvis de får sin ende gjort mye tidligere enn estimert. Haggle med utvikleren ned til en rimelig tidslinje og hold dem til den. Som du blir kjent med en utvikler, vil du forhåpentligvis finne din egen måte å være "mirakelarbeider".
Spesiell bonus Peeve: "Utviklere forstår bare designere."
Eller verre:
"Utvikleren mener de er designer!"
Det er dårlig nok når utviklere ser ut til å nekte å se designers synspunkt, men denne meningsforskjellen kan vanligvis formidles (vanligvis av en god prosjektleder). Men når utvikleren mener at de vet mer om design enn designeren, kan temperaturen blusse.
Utgave
Jeg har hatt å håndtere flere enn en utvikler som leser en artikkel av Jakob Nielsen og så ønsket å foredle meg om god design praksis midt i et møte. Dette viser ikke bare respekt for designeren, men reduserer prosjektet ettersom debatt følger.
Løsning
Å jobbe med know-it-all utviklere er vanskelig, og måten å håndtere disse situasjonene avhenger av størrelsen på egoet du har å gjøre med. Generelt synes jeg det er best å bare lytte til hva de har å si og da, hvis de har et poeng, anerkjenner det og fortsetter. Unngå å krangle med dem hvis det er mulig .
Ofte deres klage handler om en design "regel" som er brutt. Ikke vær redd for å erkjenne at du brøt en regel - det er det som nyskapende designere gjør - men sørg for at du kan rettferdiggjøre hvorfor du brøt den .
Når jeg finner meg selv i denne situasjonen, tenker jeg tilbake til mine anmeldelsesdager i designskolen, da jeg måtte forsvare arbeidet mitt mot noen ganske brutal kritikk. Disse øktene var ofte ego-blåmerker, men de lærte meg hvordan jeg raskt kunne forsvare mine beslutninger mens jeg holdt meg kult.
Det kan virke ydmygende å hele tiden begrunne dine beslutninger, men jo mer du viser "metoden i galskapen din," jo mer vil du oppdage at dine kolleger verdsetter og stoler på din vurdering .
Skrevet utelukkende for WDD av Jason Cranford Teague .
Hvilke pet har du med utviklere? Vi vil gjerne vite mer om dette, vennligst del dine kommentarer nedenfor.