5 Pet Peeves Designere har med udviklere (og hvordan man undgår dem)
Katte og hunde. Kain og Abel. Designere og udviklere. Disse er blot nogle få af de store historiske face-offs.
Designere og udviklere synes ofte at komme fra forskellige planeter og har helt forskellige hjerner.
Udviklere vil have en hjemmeside til at fungere rigtigt, designere vil have det til at se rigtigt ud.
Selvom disse mål har en masse overlapning (og selvfølgelig, jeg stereotyperer her lidt), kommer forskellene ofte ned til designeren og udviklerens forventninger til succes.
Forvaltningen af forventningerne er et spørgsmål om kommunikation: At gøre point klart til den anden side, finde fælles ground, og nå til mål.
Okay, så måske er det ikke så let, men det er vigtigt for begge sider at i det mindste forsøge at forstå hinanden .
I et forsøg på at fremme godvilje mellem designere og udviklere vil jeg dele nogle dyreforsøg jeg har stødt på og udforske de problemer, der fører til dem og deres løsninger.
Peeve # 1: "Hvorfor kan ikke udvikleren bare få det til at ligne comp?"
Du laver et smukt design og afleverer komplikationen til din udvikler, men når du får siden tilbage, ser det ud som et lappeteppe af det, du designede.
Problem
Comps er ikke websider; de er ikke en blanding af HTML, CSS og JavaScript-kode. Photoshop, Fireworks og Illustrator kan gøre mange ting, der er umulige (eller i det mindste vildt upraktiske) på nettet, hvilket ofte betyder, at udviklere skal nedskalere designet.
Løsning
Tal med din udvikler, mens du designer, ikke bare efterfølgende. Spørg dem, om en effekt du bruger, vil være let at opnå, eller om der findes et bedre alternativ. Også som du lærer mere om webudvikling, kan du bedre fortælle forskellen mellem, hvornår dit design er upraktisk, og når udvikleren bare slår af.
Peeve # 2: "Farverne er alle forkerte!"
Du vælger ikke farver vilkårligt, men udviklere synes at tro, at "tæt er tæt nok".
Problem
Jeg ved ikke, om dette gælder for alle udviklere, men jeg har engang arbejdet med en udvikler, der var rødgrøn farveblind (han var en stor fan af vores indholdsadministrator, som sendte alle sine e-mails i pink tekst på en limegrøn baggrund). Men at være farvelind, forhindrede han ham ikke fra at være en kick-ass-udvikler.
Løsning
Hvis du vil have farverne til at være rigtige, skal du stave alle farveværdierne på siden. Stol ikke på din udvikler for at øye farveværdierne eller for at prøve farverne i Photoshop.
Du skal også overveje, at problemet måske ikke er med udvikleren, men med dig. Farverne ser anderledes ud på en Mac og i CMYK (hvis du tilfældigvis aktiverer det farveområde). Sørg for, at din dokumentfarvefunktion og -sikkerhed er indstillet til generisk RGB som standard.
Peeve # 3: "Vælger udviklere selv hvad" hvide rum " betyder?"
Du har forladt masser af åndedræt omkring elementer for at skabe en flydende øjensti og forbedre læsbarheden, men udvikleren smager alt sammen og fortæller dig, "det er den eneste måde, det passer til."
Problem
Jeg klagede en gang til en udvikler om, at han ikke forlod noget mellem grænsen for et modul og dets indhold, hvilket gør det meget vanskeligt for de fleste at læse. Han svarede: "Jeg er ligeglad med andre mennesker. Jeg kan læse det. "Mens de fleste udviklere ikke er helt så uhøflige, har de ikke været uddannet i den fine kunst, der blander positive og negative rum til at lede det besøgendes øje rundt om designet.
Løsning
Hvis du virkelig ønsker at dine designs skal være så præcise som muligt, skal du ikke bare give designeren et komplement og forvente at de skal finde ud af afstanden. Angiv de nøjagtige bredder, højder og længder i et designspecifikationsdokument. Dette tjener som en tegning, som du og udvikleren er enige om for, hvordan tingene skal fordeles.
Definere i det mindste generelle regler for marginer og polstring. For eksempel "Alle moduler skal have mindst 10 pixel af polstring mellem indholdet og grænsen."
Peeve # 4: "Udvikleren kan aldrig få mine designs til at se ens ud i forskellige browsere."
Du kigger på webstedet i Firefox, og det ser fint ud, men når du skifter til Internet Explorer, falder det i stykker.
Problem
Du skal være sympatisk over for udviklerne, når det drejer sig om at gøre designene ensartede på tværs af browsere. Hver browser har sine egne quirks med afstand. Tingene bliver bedre (især med den langsomme død i Internet Explorer 6), men det er stadig svært at få dem alle til at spille godt sammen med hinanden.
Løsning
Jeg tillader generelt et par pixel af wiggle-rum i mine designs for at imødekomme problemer med tværbrowser, men det hjælper med at vide, hvad disse problemer er, mens du designer, så du kan hjælpe udvikleren med at undgå dem.
Vær ikke bange for at påpege problemer med tværbrowser til udvikleren og forventer, at de bliver løst. Men at løse nogle af dem kan kræve, at du tilpasser dit design.
Peeve # 5: "Dette vil tage så lang tid?"
Intet er mere deprimerende end at forbrænde midnattsolien på dobbelt tid for at få del i et projekt udført på skema, kun for at komme tilbage til en udvikling LOE (Level of Effort), der sætter projektudgivelsesdatoen tilbage en måned fra endenens ende .
Problem
I en klassisk episode af Star Trek: The Next Generation forklarer Scotty fakta om ingeniørlivet til Geordi La Forge: "Du sagde ikke til ham [Kaptajn Picard], hvor længe det virkelig ville tage, gjorde du? Åh, laddie. Du har meget at lære, hvis du vil have folk til at tænke på dig som mirakelarbejder. "Nogle udviklere tænker på designere på samme måde som Scotty tænker på Starfleet Captains.
Løsning
Udviklere ved, at de vil støde på uforudsete problemer og så tendens til at grove pudse deres estimater. Dette får dem også til at se rigtig godt ud, hvis de får deres ende gjort meget tidligere end estimeret. Haggle med udvikleren ned til en rimelig tidslinje og hold dem derefter til den. Som du lærer at kende en udvikler, vil du forhåbentlig finde din egen måde at være en "mirakelarbejder" på.
Special Bonus Peeve: "Udviklere forstår bare designere."
Eller værre:
"Udvikleren mener, at de er designer!"
Det er dårligt nok, når udviklere synes at nægte at se designers synspunkt, men denne meningsforskel kan normalt formidles (normalt af en god projektleder). Men når udvikleren mener, at de ved mere om design end designeren, kan temperaturer blusse.
Problem
Jeg har været nødt til at beskæftige mig med mere end en udvikler, der læste en artikel af Jakob Nielsen og så ønskede at foredra mig om god design praksis midt i et møde. Dette viser ikke kun respekt for designeren, men nedsætter projektet, efterhånden som debatten følger.
Løsning
At arbejde med know-it-all udviklere er vanskelig, og vejen til at håndtere disse situationer afhænger af størrelsen af det ego du har at gøre med. Generelt finder jeg det bedst at bare lytte til, hvad de har at sige, og så, hvis de har et punkt, anerkender det og fortsætter. Undgå at krangle med dem hvis det er muligt .
Ofte deres klage handler om et design "regel", der er blevet brudt. Vær ikke bange for at erkende, at du brød en regel - det er det, som innovative designere gør - men sørg for, at du kan retfærdiggøre, hvorfor du brød den .
Når jeg finder mig selv i denne situation, tænker jeg tilbage til mine gennemgangsdage i designskolen, da jeg var nødt til at forsvare mit arbejde mod nogle temmelig brutale kritik. Disse sessioner var ofte ego-blå mærker, men de lærte mig, hvordan man hurtigt kunne forsvare mine beslutninger, mens jeg holdt mig cool.
Det kan virke ydmygende, at du hele tiden skal retfærdiggøre dine beslutninger, men jo mere du viser "metoden i din vanvid", jo mere vil du opdage, at dine kolleger værdsætter og stoler på din dom .
Skrevet udelukkende til WDD af Jason Cranford Teague .
Hvilke kæledyr har du med udviklere? Vi vil gerne vide mere om dette, vær venlig at dele dine kommentarer nedenfor.